Един сертификат на устройство не обвързва ключа с устройството
Сертификатът за всяко устройство е административен избор, а не обвързване с устройството. Обвързването зависи от това къде живее частният ключ — от копируем файл до 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. Обвързването с устройството идва от съхранението на ключа. Само хардуер, който не може да експортира ключа си, превръща един сертификат на устройство в твърдение, което сървърът налага, вместо в политика, с която всички се съгласяват да се съобразяват.