Шифрування

перетворення даних так, щоб їх не прочитали без ключа

Що це таке

Шифрування перетворює зрозумілі дані, відкритий текст, на шифротекст: їх пропускають через загальновідомий алгоритм разом із секретним значенням — ключем. Розшифрування з правильним ключем повертає відкритий текст байт у байт. Алгоритм відкритий навмисно: AES, яким користується більшість систем, у 2000 році переміг у відкритому конкурсі NIST і опублікований як безплатний стандарт. Тож дані, захищені шифруванням, залежать лише від того, чи ключ лишається таємним.

Шифри поділяють на дві родини. Симетричний шифр використовує той самий ключ в обидва боки. AES, описаний у FIPS 197, шифрує дані блоками по 128 біт ключем завдовжки 128, 192 або 256 біт. ChaCha20 з RFC 8439 — потоковий шифр, приблизно втричі швидший за AES на обладнанні без спеціальних інструкцій AES. Симетричне шифрування досить швидке для цілого диска, але обидві сторони мають знати той самий ключ, і найважче — безпечно доправити його на інший бік.

Криптографія з відкритим ключем розв’язує це парою ключів: один публікують, другий тримають у таємниці. Дві сторони можуть кожна поєднати свій закритий ключ із відкритим ключем іншої і дійти до того самого спільного секрету, жодного разу його не пересилаючи. Такі обчислення повільні, тож справжні системи поєднують обидва підходи: обмін відкритими ключами узгоджує свіжий симетричний ключ, а симетричний шифр несе самі дані. Так працює TLS, протокол за кожною адресою https://.

Найважливіша сучасна ідея — автентифікація. Голий шифр приховує вміст, але лишає його відкритим для змін: у режимі лічильника перевернутий біт шифротексту перевертає той самий біт відкритого тексту, і отримувач розшифровує змінене повідомлення як справжнє. Автентифіковане шифрування з приєднаними даними, AEAD, додає тег, який отримувач перевіряє, перш ніж довіритися бодай одному байту. AES-GCM і ChaCha20-Poly1305 — звична пара, а TLS 1.3, опублікований як RFC 8446 у 2018 році, залишив тільки шифри AEAD і забезпечує пряму секретність (forward secrecy) для кожного обміну відкритими ключами, тож ключ сервера, викрадений пізніше, не відкриває жодного записаного сеансу.

Чому це важливо

Дані рідко лишаються на обладнанні, яке контролює їхній власник: вони йдуть чужими мережами й лежать у чужих дата-центрах. Шифрування дає їм безпечно пройти крізь ці місця: викрадений диск, прослуханий кабель чи сховище, що опинилося у відкритому доступі, дають лише шифротекст, а шифротекст без ключа — це шум.

Це переносить проблему, а не усуває її: щойно дані зашифровано, їхня безпека — це безпека ключа. Рекомендація NIST щодо керування ключами, SP 800-57, порівнює ключі з кодом до сейфа: зловмисник, який знає код, проходить повз найміцніший сейф, а погане керування ключами легко підриває сильний алгоритм. Тож більша частина справжньої роботи — це робота з ключами: зберігати їх окремо від даних, обмежувати, скільки захищає кожен, замінювати за графіком і стерегти резервну копію так само пильно, як оригінал.

Законодавці проводять ту саму межу. Загальний регламент про захист даних (GDPR) у статті 32 називає псевдонімізацію та шифрування персональних даних серед заходів безпеки. Стаття 34 звільняє контролера від обов’язку повідомляти кожного суб’єкта даних про порушення, якщо дані, що витекли, були незрозумілими для будь-кого без дозволу на доступ, і шифрування — це приклад, який вона наводить.

Шифрування під час передавання, здебільшого TLS, захищає дані в мережі, а шифрування під час зберігання — на носії. Саме використання лишається поза обома: сервер, що розшифровує запис, щоб із ним працювати, тримає водночас відкритий текст і ключ, тож хто контролює сервер, той читає те саме, що й він.

Як це виглядає на практиці

Під час передавання щоденна робота — тримати сертифікати дійсними. Коли сто застосунків на Docker потребували сертифікатів SSL/TLS, робочий процес на основі ACME створював кожен сертифікат, поновлював його до завершення терміну дії й розгортав на хостах Ubuntu з Apache та Nginx. Метою було виключити людину з процесу, бо саме людина — та ланка, яка забуває, а прострочений сертифікат виводить застосунок з ладу так само певно, як зламаний шифр.

Під час зберігання корисне питання — у кого ключ. Перш ніж компанія збудувала зашифровані резервні копії поза хостом із щомісячним навчанням з відновлення, усією позицією відновлення був провайдерський знімок. Він лежав у тому самому обліковому записі, що й машина, яку захищав, і не був зашифрований тут нікому відомим ключем. Нове рішення використовує restic, який шифрує все, що зберігає, алгоритмом AES-256 у режимі лічильника й автентифікує це через Poly1305-AES, перш ніж дані підуть через SFTP до сховища в іншого провайдера. Провайдер тримає шифротекст, компанія — парольну фразу.

Навіть шлях, яким парольна фраза потрапляє в програму, мав значення. Її читають із файлу, бо наглядач обробляє екранування у значеннях середовища, і парольна фраза зі зворотною похилою рискою мовчки відрізнялася б від тієї, що створила репозиторій. Щомісячне навчання витягує відомий файл із репозиторію та порівнює його, а оскільки відновлення потребує парольної фрази, кожне навчання доводить ще й те, що ключ досі відкриває дані.

Коли платформа ось-ось мала отримати другий хост, те саме міркування визначило, як кожен експлуатаційний секрет розділили за хостами. Рядок репозиторію — лише розташування; парольна фраза є всім шифруванням. Два хости зі спільною парольною фразою — це один репозиторій із двома каталогами, і витік з одного відкриває обидва. Кожен секрет став відображенням із ключем за хостом, а аргумент записано поруч із налаштуванням. SP 800-57 формулює загальне правило: обмежуючи, що захищає один ключ, обмежуєш шкоду, коли він витече.

Де виникають проблеми

Ключ існує в одному місці. Сильний шифр поводиться з власником, який забув пароль, так само як зі зловмисником. Документація restic каже прямо: втрата пароля означає, що дані втрачено безповоротно. Кожне зашифроване сховище потребує другої копії ключа, яку тримають там, куди не дістане те, що знищить першу.

Ключ лежить поруч із даними. База даних, зашифрована ключем із конфігурації того самого сервера, або резервна копія, чия парольна фраза лежить у тому самому сховищі, зупиняє лише злодія, що забрав половину файлів. Шифрування диска — тихіший варіант: воно захищає накопичувач, вийнятий із вимкненої машини, а сервер, що працює, уже розблокував свій диск, і зловмисник на ньому читає відкритий текст.

Таємність плутають із цілісністю. Система на голому режимі шифру приховує вміст, але все одно дає зловмисникові його змінити. Використовуйте конструкцію AEAD і відкидайте кожне повідомлення з тегом, що не зійшовся, перш ніж діяти на основі бодай одного його байта.

Nonce повторюється. AES-GCM і ChaCha20-Poly1305 приймають nonce — значення, яке має бути унікальним для кожного повідомлення під одним ключем. RFC 8439 називає це найважливішим міркуванням безпеки: два повідомлення з однаковим nonce мають спільний потік ключа й одноразовий ключ автентифікації, а це розкриває XOR двох відкритих текстів. Лічильник — безпечний спосіб отримувати nonce, якщо ключем володіє один лічильник: два процеси, що мають спільний ключ і кожен рахує від нуля, дають саме те повторення, від якого застерігає RFC.

Пароль стає ключем. Люди обирають паролі, а шифрам потрібні випадкові ключі фіксованої довжини. Парольна фраза спершу проходить функцію виведення ключа, як у restic зі scrypt, який RFC 7914 робить вибагливим до пам’яті, щоб масовий перебір на спеціалізованому обладнанні лишався дорогим. Збережені паролі для входу — окремий випадок: їм місце в такій функції у вигляді хешів, бо сервер, що вміє їх розшифрувати, може їх і злити.

Метадані лишаються видимими. Шифрування приховує вміст, а розмір, час і адреси на обох кінцях лишаються на виду. TLS 1.3 дозволяє відправникові додавати до записів заповнення (padding), щоб приховати їхній розмір, але воно необов’язкове, тож довжина часто каже більше, ніж розраховує власник.

Що почитати далі

Словник