패스키: 도대체 무엇이고 왜?

플라톤에 의해 재발행

팔로워 : 0

이런 것들은 암호 확실히 요즘 돌고 있습니다. 그들은 에서 주요 매력이었다 W3C TPAC 2022, 에서 지지를 얻음 사파리 16, 그들의 길을 찾고 있습니다 macOS 및 iOS, 그리고 예정 1Password와 같은 암호 관리자의 미래. 그들은 이미 지원 Android에서, 곧 향후 릴리스에서 Chrome OS 및 Windows로 진출할 것입니다.

Geeky OS 보안 향상은 프런트 엔드 커뮤니티에서 정확히 큰 헤드라인을 장식하지는 않지만 암호 키가 "사물"이 될 것이라는 점은 당연합니다. 그리고 암호 및 암호 앱이 인증 및 양식 처리와 같은 사용자 경험에 어떤 영향을 미치는지 고려할 때 적어도 마음을 감싸서 어떤 일이 일어날지 알 수 있습니다.

그것이 이 글의 요점입니다. 저는 한동안 암호 키와 그 기반이 되는 WebAuthn API를 연구하고 실험해 왔습니다. 내가 배운 것을 공유하겠습니다.

차례

술어

다음은 파고들면서 알아야 할 용어의 필수 섹션입니다. 대부분의 기술과 마찬가지로 암호 키는 종종 이해에 장애물이 되는 난해한 말과 약어로 만들어집니다. 나는 여기서 당신을 위해 몇 가지 신비를 풀려고 노력할 것입니다.

신뢰 당사자 : 인증할 서버. 이 기사에서는 신뢰 당사자를 의미하기 위해 "서버"를 사용합니다.
고객: 우리의 경우 웹 브라우저 또는 운영 체제입니다.
인증 자 : 공개 키 쌍의 생성 및 저장을 허용하는 소프트웨어 및/또는 하드웨어 장치.
피도: FIDO 자격 증명에 대한 사양도 만드는 개방형 표준 기관입니다.
웹인증: 패스키의 기본 프로토콜로, FIDO2 자격 증명 또는 단일 장치 FIDO 자격 증명.
암호: WebAuthn이지만 클라우드 동기화를 사용합니다(다중 장치 FIDO 자격 증명, 검색 가능한 자격 증명 또는 상주 자격 증명이라고도 함).
공개 키 암호화: 개인 및 공개 키를 포함하는 생성된 키 쌍입니다. 알고리즘에 따라 서명 및 확인 또는 암호화 및 암호 해독에 사용해야 합니다. 이것은 또한 비대칭 암호화.
RSA: 제작자 이름인 Rivest Shamir와 Adel의 약어입니다. RSA는 오래되었지만 여전히 유용한 공개 키 암호화 제품군으로, 인수분해 소수를 기반으로 합니다.
타원 곡선 암호화(ECC): 새로운 암호화 제품군 타원 곡선을 기반으로.
ES256 : ECDSA 서명 알고리즘을 사용하는 타원 곡선 공개 키(PDF)와 SHA256 해싱을 위해.
RS256 : ES256과 비슷하지만 RSA를 사용합니다. RSASSA-PKCS1-v1.5 및 SHA256.

암호 키는 무엇입니까?

암호 키에 대해 구체적으로 이야기하기 전에 다음이라는 또 다른 프로토콜에 대해 이야기해야 합니다. 웹인증 (FIDO2라고도 함). 패스키는 WebAuthn 위에 구축된 사양입니다. WebAuthn은 암호를 대체하는 공개 키 암호화를 허용합니다. 우리는 하드웨어 키 또는 신뢰할 수있는 플랫폼 모듈 (TPM), 개인 및 공개 키를 생성합니다.

공개 키는 누구나 사용할 수 있습니다. 그러나 개인 키는 이를 생성한 장치에서 제거할 수 없습니다. 이것은 WebAuthn의 문제 중 하나였습니다. 장치를 분실하면 액세스할 수 없습니다.

Passkeys는 자격 증명의 클라우드 동기화를 제공하여 이 문제를 해결합니다. 즉, 컴퓨터에서 생성한 내용을 이제 휴대폰에서도 사용할 수 있습니다(혼란스럽게도 단일 장치 자격 증명도 있음).

현재 작성 당시에는 iOS, macOS 및 Android만 클라우드 동기화 암호 키를 완벽하게 지원하며 사용 중인 브라우저에 의해 제한됩니다. Google과 Apple은 동기화를 위한 인터페이스를 제공합니다. Google 비밀번호 관리자 및 애플 아이클라우드 키체인 서비스, 각각.

암호 키는 어떻게 암호를 대체합니까?

공개 키 암호화에서는 다음과 같은 작업을 수행할 수 있습니다. 로그인. 서명은 데이터 조각을 가져온 다음 개인 키로 서명 알고리즘을 통해 실행한 다음 공개 키로 확인할 수 있습니다.

누구나 공개 키 쌍을 생성할 수 있으며 처음부터 누구라도 생성할 수 있기 때문에 누구에게도 귀속되지 않습니다. 유용한 점은 개인 키로 서명된 데이터만 공개 키로 확인할 수 있다는 것입니다. 그것이 암호를 대체하는 부분입니다. 서버는 공개 키를 저장하고 우리는 무작위 챌린지에 서명하여 나머지 절반(예: 개인 키)이 있는지 확인하여 로그인합니다.

추가 이점으로 사용자의 공개 키를 데이터베이스에 저장하므로 수백만 명의 사용자에게 영향을 미치는 암호 유출에 대해 더 이상 걱정할 필요가 없습니다. 이렇게 하면 현재 암호에 의존하는 세상이 직면하고 있는 피싱, 위반 및 기타 수많은 보안 문제가 줄어듭니다. 데이터베이스가 침해되면 모든 정보가 사용자의 공개 키에 저장되어 공격자에게 거의 쓸모가 없게 됩니다.

더 이상 잊어버린 이메일과 관련 비밀번호도 없습니다! 브라우저는 귀하가 어떤 웹사이트에 어떤 자격 증명을 사용했는지 기억할 것입니다. 몇 번의 클릭만 하면 로그인됩니다. 생체 인식 또는 핀과 같은 암호 키를 사용하기 위한 보조 확인 수단을 제공할 수 있습니다. , 그러나 그것들은 여전히 과거의 암호보다 훨씬 빠릅니다.

암호화에 대한 추가 정보

공개 키 암호화에는 개인 키와 공개 키(키 쌍이라고 함)가 있습니다. 키는 함께 생성되며 별도의 용도로 사용됩니다. 예를 들어 개인 키는 비밀로 유지하기 위한 것이며 공개 키는 메시지를 교환하려는 사람을 위한 것입니다.

메시지를 암호화하고 해독할 때 받는 사람의 공개 키를 사용하여 메시지를 암호화하므로 받는 사람의 개인 키만 메시지를 해독할 수 있습니다. 보안 용어로 이를 "기밀성 제공"이라고 합니다. 그러나 누군가에게 공개 키를 사용하여 누군가에게 암호화된 메시지를 보낼 수 있기 때문에 이것은 보낸 사람이 자신이 누구인지에 대한 증거를 제공하지 않습니다.

메시지가 실제로 보낸 사람에게서 온 것인지 확인해야 하는 경우가 있습니다. 이러한 경우 서명 및 서명 확인을 사용하여 보낸 사람이 본인이 맞는지 확인합니다(또는 정품). 공개 키(또는 비대칭 인) 암호화, 이는 일반적으로 메시지의 해시에 서명하여 수행되므로 공개 키만 올바르게 확인할 수 있습니다. 해시와 보낸 사람의 개인 키는 알고리즘을 통해 실행한 후 서명을 생성하고 보낸 사람의 메시지가 보낸 사람의 공개 키로 누구나 확인할 수 있습니다.

암호 키에 어떻게 액세스합니까?

암호 키에 액세스하려면 먼저 암호를 생성하여 어딘가에 저장해야 합니다. 이 기능 중 일부는 인증자와 함께 제공될 수 있습니다. 안 인증 자 암호화 키 생성 기능을 제공하는 하드웨어 또는 소프트웨어 지원 장치입니다. 에서 얻은 일회용 암호를 생각해 보십시오. 구글 인증 자, 1Password및 제작 : LastPass, 다른 사람의 사이에서.

예를 들어 소프트웨어 인증자는 TPM(신뢰할 수 있는 플랫폼 모듈) 또는 디바이스의 보안 엔클레이브를 사용하여 자격 증명을 생성할 수 있습니다. 그런 다음 자격 증명을 원격으로 저장하고 암호 키와 같은 장치 간에 동기화할 수 있습니다. 하드웨어 인증자는 다음과 같습니다. 유비 키, 장치 자체에서 키를 생성하고 저장할 수 있습니다.

인증자에 액세스하려면 브라우저가 하드웨어에 액세스할 수 있어야 하며 이를 위해 인터페이스가 필요합니다. 여기서 사용하는 인터페이스는 CTAP(Client to Authenticator Protocol)입니다. 서로 다른 메커니즘을 통해 서로 다른 인증자에 대한 액세스를 허용합니다. 예를 들어 CTAP를 활용하여 NFC, USB 및 Bluetooth를 통해 인증기에 액세스할 수 있습니다.

암호 키를 사용하는 더 흥미로운 방법 중 하나는 Bluetooth를 통해 암호 키를 지원하지 않을 수 있는 다른 장치에 휴대폰을 연결하는 것입니다. 장치가 Bluetooth를 통해 페어링되면 내 전화를 중개자로 사용하여 내 컴퓨터의 브라우저에 로그인할 수 있습니다!

암호 키와 WebAuthn의 차이점

암호 키와 WebAuthn 키는 여러 면에서 다릅니다. 첫째, 패스키는 다중 장치 자격 증명으로 간주되며 여러 장치에서 동기화될 수 있습니다. 반대로 WebAuthn 키는 단일 장치 자격 증명입니다. 즉, 확인을 위해 하나의 장치에 바인딩되어 있다고 말하는 멋진 방법입니다.

둘째, 서버에 인증하기 위해 WebAuthn 키는 로그인을 위한 사용자 핸들을 제공해야 합니다. allowCredentials 로그인에 사용할 수 있는 자격 증명을 알려주는 목록이 서버에서 클라이언트로 반환됩니다. 패스키는 이 단계를 건너뛰고 서버의 도메인 이름을 사용하여 해당 사이트에 이미 바인딩된 키를 표시합니다. 시스템에서 이미 알고 있으므로 해당 서버와 연결된 패스키를 선택할 수 있습니다.

그렇지 않으면 키는 암호학적으로 동일합니다. 저장 방법과 로그인 프로세스를 시작하는 데 사용하는 정보만 다릅니다.

그 과정… 간단히 말해서

WebAuthn 또는 암호 키를 생성하는 프로세스는 매우 유사합니다. 서버에서 인증 확인을 받은 다음 navigator.credentials.create 공개 키 쌍을 생성하는 웹 API. 그런 다음 챌린지와 공개 키를 서버로 다시 보내 저장합니다.

공개 키와 챌린지를 수신하면 서버는 챌린지와 챌린지가 생성된 세션의 유효성을 검사합니다. 확인되면 공개 키와 함께 사용자 식별자 또는 증명 데이터와 같은 기타 관련 정보가 데이터베이스에 저장됩니다.

사용자는 한 단계 더 있습니다. 서버에서 다른 챌린지를 검색하고 navigator.credentials.get 챌린지에 서명하기 위한 API입니다. 우리는 서명된 챌린지를 서버로 다시 보내고 서버는 챌린지를 확인한 다음 서명이 통과되면 로그인합니다.

물론 각 단계에는 꽤 많은 것이 있습니다. 그러나 이것은 일반적으로 WebAuthn 또는 패스키를 사용하여 웹사이트에 로그인하는 방법입니다.

고기와 감자

암호 키는 두 가지 단계로 사용됩니다. 증명 및 역설 단계.

증명 단계는 등록 단계라고도 할 수 있습니다. 새 웹사이트에 이메일과 비밀번호로 가입하지만 이 경우에는 비밀번호를 사용합니다.

어설션 단계는 가입 후 웹사이트에 로그인하는 방법과 유사합니다.

증명

패스키: 도대체 무엇이고 왜? PlatoBlockchain 데이터 인텔리전스. 수직 검색. 일체 포함. — 풀 사이즈보기

XNUMXD덴탈의 navigator.credentials.create API는 증명 단계의 초점입니다. 우리는 시스템에 새로운 사용자로 등록되었고 새로운 공개 키 쌍을 생성해야 합니다. 그러나 생성하려는 키 쌍의 종류를 지정해야 합니다. 즉, 다음과 같은 옵션을 제공해야 합니다. navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};

const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

우리는 PublicKeyCredential 포함하는 AuthenticatorAttestationResponse 생성 후 다시 돌아옵니다. 자격 증명에는 생성된 키 쌍의 ID가 있습니다.

응답은 몇 가지 유용한 정보를 제공합니다. 먼저, 이 응답에 공개 키가 있고 이를 저장하기 위해 서버로 보내야 합니다. 둘째, 우리는 또한 clientDataJSON 우리가 디코딩할 수 있는 속성, 거기에서 다시 얻을 type, challenge및 origin 패스키의.

증명을 위해 우리는 type, challenge및 origin 그리고 공개 키를 식별자(예: kid)와 함께 저장합니다. 우리는 또한 선택적으로 저장할 수 있습니다 attestationObject 우리가 원한다면. 저장할 수 있는 또 다른 유용한 속성은 편안히 앉다 위에서 정의한 알고리즘 PublicKeyCredentialCreationOptions 과 alg: -7 or alg: -256, 어설션 단계에서 서명된 챌린지를 쉽게 확인하기 위해.

역설

XNUMXD덴탈의 navigator.credentials.get API는 어설션 단계의 초점이 됩니다. 개념적으로 이것은 사용자가 가입 후 웹 애플리케이션에 로그인하는 위치입니다.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};

const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

우리는 다시 얻을 것이다 PublicKeyCredential 과 AuthenticatorAssertionResponse 이 시간. 자격 증명에는 다시 키 식별자가 포함됩니다.

우리는 또한 얻는다 type, challenge및 origin 인사말 clientDataJSON 다시. 그만큼 signature 이제 응답에 포함됩니다. authenticatorData. 우리는 그것들과 clientDataJSON 이것이 개인 키로 서명되었는지 확인합니다.

XNUMXD덴탈의 authenticatorData 추적할 가치가 있는 몇 가지 속성을 포함합니다. 첫 번째는 사용 중인 원본의 SHA256 해시로, 처음 32바이트 내에 있으며 요청이 동일한 원본 서버에서 오는지 확인하는 데 유용합니다. 두 번째는 signCount, 바이트 33에서 37까지입니다. 이것은 인증자에서 생성되며 이전 값과 비교하여 키에 문제가 없는지 확인해야 합니다. 다중 장치 암호 키인 경우 값은 항상 0이어야 하며 단일 장치 암호 키인 경우 이전 signCount보다 임의로 커야 합니다.

로그인을 확인하면 로그인해야 합니다 — 축하 해요! 패스키는 꽤 훌륭한 프로토콜이지만 몇 가지 주의 사항이 있습니다.

몇 가지 단점

Passkeys에는 많은 이점이 있지만 이 글을 쓰는 시점에서 몇 가지 문제가 있습니다. 우선, 암호 키는 Windows에서는 단일 장치 자격 증명만 허용되고 Linux 시스템에서는 거의 지원되지 않는 초기 지원 방식입니다. Passkeys.dev 를 제공합니다 이 프로토콜의 Caniuse와 같은 멋진 테이블.

또한 Google과 Apple의 패스키 플랫폼은 서로 통신하지 않습니다. 당신이 당신의 안드로이드 전화에서 당신의 아이폰으로 자격 증명을 얻고 싶다면… 음, 지금은 운이 없습니다. 상호 운용성이 없다는 말은 아닙니다! 휴대폰을 인증자로 사용하여 컴퓨터에 로그인할 수 있습니다. 그러나 공급업체 수준에서 잠그지 않고 운영 체제에 내장하고 동기화하는 것이 훨씬 더 깔끔할 것입니다.