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