Що насправді захищає парольна фраза на закритому ключі VPN

Запит, що з’являється під час запуску VPN-клієнта, легко прочитати неправильно. Це не пароль облікового запису VPN, не пароль тунелю, і його введення не доводить, що з’єднання безпечне. Він розблоковує одне збережене подання закритого ключа, щоб клієнт міг прочитати матеріал ключа й використати його для автентифікації. Усе, що відбувається після цього, — інше питання.

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

Один діалог, кілька різних секретів

Парольна фраза закритого ключа розшифровує файл. Пароль облікового запису автентифікує вас у сервісі. Пароль імпорту PKCS#12 розшифровує пакет, що містить ключ і його сертифікат, і може не збігатися з парольною фразою самого ключа. Ці запити можуть виглядати майже однаково, і здогад, який секрет куди належить, — це шлях до того, що ключі опиняються вставленими не в те поле.

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

Що охоплює шифрування на диску

Зашифрований ключ PEM буває двох форм, і заголовок каже, яка у вас. Сучасна форма PKCS#8 починається з -----BEGIN ENCRYPTED PRIVATE KEY-----; стара форма PEM, досі поширена в старих налаштуваннях OpenVPN, починається з -----BEGIN RSA PRIVATE KEY----- і містить Proc-Type: 4,ENCRYPTED і рядок DEK-Info одразу під ним. Файл зберігає закритий ключ зашифрованим під ключем, похідним від вашої парольної фрази, зазвичай через KDF на основі пароля із зазначеною кількістю ітерацій або робочим фактором. Документація OpenSSL pkey описує формати та параметри парольної фрази, застосовні під час читання.

Звідси випливають два наслідки. Слабку парольну фразу можна атакувати офлайн зі швидкістю, яку дозволяє KDF, тому права на файл і доступ до резервних копій залишаються важливими, навіть коли файл зашифровано. А атакувальник, який отримав лише файл без парольної фрази, мусить вгадувати; той, хто отримав файл і парольну фразу, володіє ключем, ніби його ніколи не шифрували.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 показує заголовок, а в старому файлі — рядки Proc-Type і DEK-Info, що доводять шифрування; один рядок сам по собі не є доказом у жодному напрямку. Рядок pkey запитує парольну фразу і друкує лише відкриту половину, що доводить працездатність файлу й фрази без розкриття закритого ключа. Не використовуйте -text для цієї перевірки: він друкує закриті компоненти, privateExponent, prime1, prime2 та інше, і цей вивід не можна нікуди вставляти — ні в тікет, ні в чат, ні в журнал. Команда PKCS#12 також повідомляє, чи має пакет окремий пароль MAC або шифрування, що варто знати перед передаванням колезі.

Що перестає захищатися після завантаження ключа

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

Це та сама межа, що в SSH-ключа з парольною фразою або відкритого сховища менеджера паролів. Вона підвищує вартість крадіжки файлу в стані спокою і нічого не робить проти шкідливого ПЗ, що працює від вашого імені, авторизованої програми, яка просить клієнт підписати, або адміністратора, здатного читати пам’ять. Розглядайте її як один шар, а не як контроль, що робить ключ безпечним для залишення без нагляду.

Чому запит постійно повертається

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

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

Втрата й розкриття — не те саме виправлення

Втрачену парольну фразу не можна відновити із сертифіката. Сертифікат — це відкритий матеріал, що пов’язує ім’я з ключем; у ньому немає шляху назад до закритого ключа й жодної підказки про парольну фразу. Практичні варіанти — авторизована резервна копія ключа або нова ідентичність, видана в звичайному процесі оператора. Будь-хто, хто пропонує «відновити» парольну фразу, пропонує її вгадати.

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