Один сертифікат на пристрій не робить ключ прив’язаним до пристрою
Сертифікат для кожного пристрою — це вибір адміністратора, а не прив’язка до пристрою. Прив’язку визначає те, де живе приватний ключ: від файлу, який можна скопіювати, до TPM.
Ви видаєте окремий сертифікат для кожного ноутбука, тому припускаєте, що VPN може їх розрізнити. Не може. Сертифікат клієнта доводить, що той, хто підключається, має відповідний приватний ключ, і скопійований профіль теж його має.
Сертифікат для кожного пристрою все одно гарна ідея. Він просто робить іншу роботу, ніж більшість людей очікує.
Що насправді доводить сертифікат клієнта
Під час встановлення з’єднання клієнт підписує приватним ключем, що відповідає його сертифікату, а сервер перевіряє цей підпис щодо CA, якій довіряє. Ніщо в цьому обміні не описує машину. Будь-який пристрій, що має і сертифікат, і ключ, створює ідентичний підпис, тому профіль, скопійований на другий ноутбук, виглядає точно як оригінал. Сертифікат називає ідентичність; він не називає апаратне забезпечення.
Унікальність на пристрій усе ще варта свого, бо робить відкликання точним. Це адміністративна властивість, а не технічний замок.
Три рівні зберігання ключа
Перший рівень — файл ключа на диску. Він переносний за задумом, і саме там живе більшість профілів OpenVPN.
Другий рівень — ключ, який операційна система позначає як такий, що не експортується. Windows може згенерувати ключ пристрою у своєму сховищі сертифікатів і відмовити у звичайному експорті, що зупиняє випадкове копіювання. Він не підкріплений апаратно, і за достатнього доступу до машини такі ключі можна відновити, тож це підвищує складність, а не будує стіну.
Третій рівень — ключ, згенерований усередині апаратного захисту: TPM, смарткарта, SIM або токен PIV. Ці модулі не мають схеми для експорту згенерованого ключа, а підписування відбувається всередині модуля. Ключ ніколи не стає файлом, який хтось може скопіювати.
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
Ця таблиця — весь аргумент у трьох рядках.
Що easy-rsa може і чого не може
Видавати сертифікати на пристрій просто. Створіть окреме спільне ім’я для кожного пристрою щодо тієї самої CA, наприклад ./easyrsa build-client-full laptop-a nopass, і повторіть для кожного пристрою. Запишіть, яке спільне ім’я належить якій людині та машині.
Відкликання так само пряме: ./easyrsa revoke laptop-a, згенеруйте CRL заново за допомогою ./easyrsa gen-crl і переконайтеся, що сервер справді читає його через crl-verify.
Чого CA не може — це перевірити, де приватний ключ живе потім. Якщо ви згенеруєте ключ на хості CA і скопіюєте його на пристрій, під час видачі ви створили другу копію. Ключ, що не експортується, треба генерувати на пристрої або імпортувати в апаратне забезпечення, яке його не віддасть.
Засоби контролю, які переживуть скопійований профіль
Припустіть, що профіль можна скопіювати, і проєктуйте з огляду на це. Прив’яжіть обліковий запис до другого фактора, щоб самого сертифіката не вистачало. Дайте кожному пристрою власну політику, щоб охоплення однієї ідентичності залишалося обмеженим. І стежте за тим самим спільним іменем, підключеним одночасно з двох адрес, — саме так виглядає спільний профіль у журналі з’єднань.
Швидке й задокументоване відкликання — це контроль, який працює навіть після того, як копія сталася. Усе інше — запобігання.
Твердження, на яке сервер справді може покластися
Унікальність походить від CA. Прив’язка до пристрою походить від зберігання ключа. Лише апаратне забезпечення, яке не може експортувати свій ключ, перетворює один сертифікат на пристрій на твердження, яке сервер забезпечує, а не на політику, з якою всі погоджуються.