Еден сертификат по уред не го врзува клучот за уредот
Сертификатот по уред е административен избор, а не врзување за уредот. Врзувањето го одредува тоа каде живее приватниот клуч, од датотека што може да се копира до 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. Врзувањето за уредот доаѓа од чувањето на клучот. Само хардверот што не може да го извезе својот клуч претвора еден сертификат по уред во тврдење што серверот го спроведува, наместо во политика со која сите се согласуваат да ја следат.