분류 mobile

웹용 Face ID 및 Touch ID 만나기

컨텐츠 정보

  • 조회 370 (작성일 )

본문

사람들은 종종 암호가 웹 인증의 원죄라고 생각합니다. 암호는 추측하기 쉽고 침해에 취약 할 수 있습니다. 웹에서 동일한 비밀번호를 자주 재사용 하면 침해의 수익성이 더욱 높아집니다. 암호가 더 강력하고 고유 해지면서 많은 사용자가 빠르게 사용할 수 없게 될 수 있습니다. 암호는 실제로 악명 높은 것처럼 보이지만 암호 자체가 문제입니까, 아니면 인증을 위한 유일한 요소로 사용됩니까?


많은 사람들이 후자를 믿기 때문에 다단계 인증이 점점 더 대중화되었습니다. 두 번째 요소의 도입은 암호와 관련된 대부분의 보안 문제를 해결하지만 추가 단계를 통해 전체 인증 경험을 번거롭게 만듭니다. 따라서 다단계 인증은 웹에서 사실상의 인증 메커니즘이 되지 않았습니다. 웹용 Face ID 및 Touch ID는 다단계 인증의 보안 보장과 사용 편의성을 모두 제공합니다. 단일 단계로 다단계 인증을 제공합니다. 10 억 개 이상의 Apple 기기에서 사용할 수 있는 이 기술을 사용하여 웹 개발자는 이제 부드럽고 편리한 경험으로 기존의 다단계 인증을 광범위하게 제공 할 수 있습니다. 또한 웹 인증 API를 기반으로 구축되어 Face ID 및 Touch ID 피싱도 방지 할 수 있습니다.


https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/


이 블로그 게시물은 다양한 사용자 에이전트 사용자 인터페이스를 관리하는 방법, 사용자 제스처를 전파하는 방법을 포함하여 개발자가 이 새로운 기술을 채택하는 데 도움이 되는 자세한 예제를 제공하여 WWDC 2020 "웹용 Face ID 및 Touch ID를 만나십시오"세션의 내용을 확장합니다. 사용자 활성화 이벤트에서 WebAuthn API 호출, Apple 익명 증명 해석 방법에 이르기까지. 이 기사는 Apple 플랫폼 인증 자의 고유 한 특성과 보안 키 지원의 현재 상태를 요약하는 것으로 끝납니다. WebAuthn에 대해 들어 본 적이 없다면 먼저 기본 개념을 다루는 WWDC 2020 세션을 시청하는 것이 좋습니다. 그렇지 않으면 즐기십시오.


사용자 경험 관리 


사용자 에이전트는 WebAuthn 흐름 중에 사용자에게 UI 지침을 제공 할 필요가 없지만 실제로는 모두 수행합니다. 이를 통해 사용자 에이전트는 사용자 경험을 관리하는 웹 사이트의 부담을 일부 공유 할 수 있지만, 각 사용자 에이전트는 UI에서 WebAuthn 행사를 다른 방식으로 표현하므로 웹 사이트에 또 다른 복잡성이 발생합니다. WebAuthn 행사는 인증 프로세스 또는 등록 프로세스가 될 수 있습니다. 이 섹션에서는 WebAuthn 행사 옵션이 WebKit / Safari의 UI에 매핑 되는 방법과 웹용 Face ID 및 Touch ID에 대한 권장 사용자 환경을 보여줍니다.


한 가지 과제는 플랫폼 인증 자와 보안 키간에 서로 다른 사용자 경험을 관리하는 것입니다. WebAuthn API를 사용하면 사용자에게 두 옵션을 동시에 제공 할 수 있지만 최선의 방법은 아닙니다. 첫째, 대부분의 사용자는 플랫폼 인증 기의 브랜딩 (예 : Apple 플랫폼의 Face ID 및 Touch ID)에만 익숙하지만 보안 키에는 익숙하지 않습니다. 두 가지를 동시에 제공하면 사용자를 혼란스럽게 하고 무엇을 해야 할지 결정하기가 어려울 수 있습니다. 둘째, 플랫폼 인증자는 보안 키와 다른 동작 및 사용 사례를 가지고 있습니다. 예를 들어 Face ID 및 Touch ID는 대부분의 보안 키가 아닌 경우 로그인을 위한 보다 편리한 대체 메커니즘으로 사용하기에 적합합니다. 또한 보안 키에 저장된 자격 증명은 여러 장치 및 플랫폼에서 사용될 수 있지만 플랫폼 인증 자에 저장된 자격 증명은 일반적으로 플랫폼과 장치에 연결됩니다. 따라서 이 두 가지 옵션을 사용자에게 개별적으로 제공하는 것이 좋습니다.


Face ID 및 Touch ID 만 제시 


다음은 웹에서 Face ID 및 Touch ID를 호출하는 권장 방법입니다. 아래는 등록 식에 해당하는 Safari UI입니다. 여기에서 신뢰 당사자 ID가 선택되어 대화 상자에 표시됩니다.


Screen-Shot-2020-08-11-at-2.34.11-PM.png 


다음은 위의 대화 상자를 표시하는 해당 코드 스니펫입니다.


const options = {
    publicKey: {
        rp: { name: "example.com" },
        user: {
            name: "john.appleseed@example.com",
            id: userIdBuffer,
            displayName: "John Appleseed"
        },
        pubKeyCredParams: [ { type: "public-key", alg: -7 } ],
        challenge: challengeBuffer,
        authenticatorSelection: { authenticatorAttachment: "platform" }
    }
};

const publicKeyCredential = await navigator.credentials.create(options);

필수 옵션은 authenticatorSelection : {authenticatorAttachment : "platform"}을 지정하는 것입니다. 이는 WebKit에게 플랫폼 인증 자만 호출하도록 지시합니다. publicKeyCredential이 반환 된 후 모범 사례 중 하나는 Credential ID를 서버 집합의 안전한 httpOnly 쿠키에 저장하고 해당 전송을 "내부"로 표시하는 것입니다. 이 쿠키는 향후 인증 행사의 사용자 경험을 개선하는 데 사용될 수 있습니다.


추적으로부터 사용자를 보호하기 위해 WebAuthn API는 웹 사이트가 기기의 사용자 인증 정보 존재를 쿼리하는 것을 허용하지 않습니다. 그러나 이 중요한 개인 정보 보호 기능을 사용하려면 웹 사이트가 프로비저닝 된 자격 증명 ID를 별도의 소스에 저장하고 인증 행사 전에 쿼리 하기 위해 약간의 추가 노력이 필요합니다. 별도의 소스는 종종 백엔드 서버에 있습니다. 이 방법은 여러 플랫폼에서 사용할 수 있다는 점에서 보안 키에 적합합니다. 유감스럽게도 자격 증명은 생성 된 장치에서만 사용할 수 있으므로 플랫폼 인증 자에서는 작동하지 않습니다. 서버 측 소스는 특정 플랫폼 인증자가 실제로 자격 증명을 보존하는지 여부를 알 수 없습니다. 따라서 쿠키가 특히 유용합니다. Safari의 Intelligent Tracking Prevention은 이러한 쿠키의 만료를 7 일로 제한하므로 이 쿠키는 document.cookie API를 통해 설정하면 안됩니다. 또한 WebKit이 사용자에게 보안 키를 동시에 요청하지 않도록 웹 사이트가 인증 방식 옵션에서 이를 제공 할 수 있도록 이러한 자격 증명을 "내부"로 표시하는 것도 중요합니다.


다음은 인증 행사를 위한 두 가지 UI입니다. 첫 번째는 사용자 에이전트에 단일 자격 증명 만 있는 경우에 간소화되고 두 번째는 사용자 에이전트가 사용자가 여러 자격 증명 중 하나를 선택할 수 있도록 허용하는 방법을 보여줍니다. 두 경우 모두 등록 식에 제출 된 user.name 만 표시하도록 선택됩니다. 두 번째 경우 목록의 순서는 자격 증명의 마지막 사용 날짜에 따라 정렬됩니다. WebKit은 마지막으로 사용한 날짜를 추적합니다. 따라서 웹 사이트는 그것에 대해 걱정할 필요가 없습니다.


Screen-Shot-2020-08-11-at-7.20.07-PM.png 

Screen-Shot-2020-08-11-at-7.23.02-PM.png 


다음은 위의 대화 상자를 표시하는 해당 코드 스니펫입니다.


const options = {
    publicKey: {
        challenge: challengeBuffer,
        allowCredentials: [
            { type: "public-key", id: credentialIdBuffer1, transports: ["internal"] },
            // ... more Credential IDs can be supplied.
        ]
    }
};

const publicKeyCredential = await navigator.credentials.get(options);

참고로 WebKit에 대한 개선을 통해 다음과 같이 전송할 수 있습니다. 허용 된 모든 자격 증명이 플랫폼 인증 자 내에서 발견되는 한 WebKit이 사용자에게 보안 키를 요청하는 것을 방지하기 위해 [ "internal"]은 필요하지 않습니다. 행복한 길만. 자격 증명을 찾을 수 없는 경우 이 추가 속성은 WebKit에 사용자에게 보안 키를 요청하는 대신 오류 메시지를 표시하도록 지시 할 수 있습니다.


보안 키와 함께 Face ID 및 Touch ID 제시 


다음과 같은 사용은 권장되지 않지만 WebKit / Safari는 사용자가 플랫폼 인증 자 외에 보안 키를 선택할 수 있도록 전용 UI를 준비했습니다. 아래는 등록 식입니다.

Screen-Shot-2020-08-12-at-1.44.52-AM.png 

위의 등록 행사 코드 스니펫에서 authenticatorSelection : {authenticatorAttachment : "platform"}을 삭제하면 위의 대화 상자를 얻을 수 있습니다.


Screen-Shot-2020-08-12-at-1.45.23-AM.png 

위의 인증 코드 스니펫에서 allowCredentials 배열의 항목에 transports : [ "internal"] 속성이 없는 경우 위의 대화 상자가 표시됩니다.


참고로 UI가 표시된 후 두 경우 모두 보안 키를 즉시 사용할 수 있습니다. "보안 키 사용"및 "보안 키의 계정"옵션은 보안 키와 상호 작용하는 방법에 대한 지침을 보여줍니다.


allowCredentials 지정 여부 


allowCredentials는 인증 행사를 위한 선택 사항입니다. 그러나 이를 생략하면 WebKit / Safari의 UI에서 결정되지 않은 동작이 발생합니다. 자격 증명을 찾으면 위의 인증 식 UI가 표시됩니다. 자격 증명이 없으면 WebKit은 사용자에게 보안 키를 묻습니다. 따라서 이 옵션을 생략하지 않는 것이 좋습니다.


사용자 제스처 전파


원치 않는 권한 프롬프트는 성가시다. Mozilla는 이를 확인하는 설문 조사 [1, 2]를 실시했습니다. WebAuthn 프롬프트는 오늘날 알림 프롬프트만큼 웹에서 자주 표시되지 않지만 웹용 Face ID 및 Touch ID가 출시됨에 따라 이러한 상황이 변경됩니다.


웹 사이트는 재미로 알림 권한을 요청하지 않습니다. 그들은 알림이 사용자를 사이트로 되돌리고 일일 활성 사용자 지표를 늘릴 수 있기 때문에 묻습니다. WebAuthn 프롬프트에서 유사한 재정적 인센티브를 찾을 수 있습니다. 특히 플랫폼 인증자가 이행 된 인증 요청으로 사용자의 충실도가 높고 영구적 인 고유 식별자를 사용할 수 있는 경우입니다. 이것은 인증에 대한 보편적 인 진실이며 사용자가 사이트와 상호 작용하기 전에 많은 사이트에서 인증을 요청하는 이유입니다. WebAuthn 자격 증명을 활용하여 사용자에게 타겟팅 된 광고를 제공하는 것은 불가피하지만, 알림 권한 프롬프트에 대해 Firefox에서 Mozilla가 수행 한 것과 유사한 보호 기능을 활용하여 WebAuthn 프롬프트가 사용자 제스처를 요구하는 불편 함을 덜어 줄 수 있습니다. WebAuthn API가 성가신 '로드시'프롬프트를 제거합니다.


우리는 얼마 전에 이 문제를 예견하고 WebAuthn 사양에 문제를 제기했지만 그 당시에는 그다지 견인력을 얻지 못했습니다. 한 가지 이유는 그것이 주요한 변화이기 때문입니다. 또 다른 이유는 보안 키가 그다지 인기가 없고 항상 플랫폼에 연결되어 있지 않기 때문에 위험이 높지 않기 때문입니다. 원치 않는 메시지의 양은 놀라 울 정도로 적습니다. 웹용 Face ID 및 Touch ID 출시로 상황이 다릅니다. 따라서 웹용 Face ID 및 Touch ID가 작동하려면 사용자 제스처가 필요합니다. (이전 버전과의 호환성을 위해 보안 키에는 사용자 제스처가 필요하지 않습니다.)


사용자 제스처는 현재 JavaScript 컨텍스트의 실행이 사용자 상호 작용의 직접적인 결과이거나 더 정확하게는 touchend, click, doubleclick 또는 keydown 이벤트와 같은 사용자 활성화 이벤트의 처리기에서 나온 것임을 WebKit에 알리는 표시기입니다. [삼]. WebAuthn API에 대한 사용자 제스처가 필요하다는 것은 API 호출이 위의 JavaScript 컨텍스트 내에서 발생해야 함을 의미합니다. 일반적으로 사용자 제스처는 컨텍스트 내에서 비동기 실행기로 전파되지 않습니다. 웹 사이트가 WebAuthn API를 호출하기 직전에 서버에서 챌린지를 비동기 적으로 가져 오는 것이 널리 사용되기 때문에 WebKit을 사용하면 WebAuthn API가 XHR 이벤트 및 Fetch API를 통해 전파 된 사용자 제스처를 수락 할 수 있습니다. 다음은 웹 사이트가 사용자 활성화 이벤트에서 웹에 대해 Face ID 및 Touch ID를 호출하는 방법의 예입니다.


사용자 활성화 이벤트에서 직접 API 호출 


// Fetching the challengeBuffer before the onclick event.

button.addEventListener("click", async () => {
    const options = {
        publicKey: {
            ...
            challenge: challengeBuffer,
            ...
        }
    };

    const publicKeyCredential = await navigator.credentials.create(options);
});

XHR 이벤트를 통해 사용자 제스처 전파 


button.addEventListener("click", () => {
    const xhr = new XMLHttpRequest();
    xhr.onreadystatechange = async function() {
        if (this.readyState == 4 && this.status == 200) {
            const challenge = this.responseText;
            const options = {
                publicKey: {
                    ...
                    challenge: hexStringToUint8Array(challenge), // a custom helper
                    ...
                }
            };

            const publicKeyCredential = await navigator.credentials.create(options);
        }
    };
    xhr.open("POST", "/WebKit/webauthn/challenge", true);
    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    xhr.send();
});

Fetch API를 통해 사용자 제스처 전파 


button.addEventListener("click", async () => {
    const response = await fetch("/WebKit/webauthn/challenge", { method: "POST" });
    const challenge = await response.text();

    const options = {
        publicKey: {
            ...
            challenge: hexStringToUint8Array(challenge), // a custom helper
            ...
        }
    };
    const publicKeyCredential = await navigator.credentials.create(options);
});

참고로 읽을 수 있는 스트림은 아직 사용자 제스처를 전파 할 수 없습니다 (관련 버그). 또한 사용자 제스처는 XHR 이벤트와 Fetch API 모두에 대해 10 초 후에 만료됩니다.


Easter Egg : setTimeout을 통해 사용자 제스처 전파 


button.addEventListener("click", () => {
    setTimeout(async () => {
        const options = { ... };
        const publicKeyCredential = await navigator.credentials.create(options);
    }, 500);
});

위 예의 사용자 제스처는 1 초 후에 만료됩니다.


iOS 14, iPadOS 14 및 macOS Big Sur Beta Seed 1에서는 첫 번째 케이스 만 지원됩니다. 개발자의 초기 피드백 덕분에 제한 사항을 식별하고 이후 사례를 추가 할 수 있었습니다. 이것은 또한 사용자 제스처가 웹 개발자들 사이에서 잘 이해되지 않는 개념임을 인식하는 데 도움이 되었습니다. 따라서 우리는 HTML 사양에 기여하고 브라우저 공급 업체 간의 일관성을 위해 잘 확립 된 사용자 제스처 개념을 설정하는 데 도움을 줄 것입니다. 진행 방식에 따라 사용자 제스처 요구 사항을 보안 키로 확장하는 것을 재고 할 수 있습니다.


Apple 익명 증명 해석 


증명은 특정 규정에 의해 제한되는 웹 사이트가 신뢰 결정을 내릴 수 있도록 웹 사이트에 인증 자의 출처에 대한 암호화 증거를 제공하는 선택적 기능입니다. 웹용 Face ID 및 Touch ID는 Apple 익명 증명을 제공합니다. 이 증명은 인증 된 Apple 장치가 WebAuthn 등록 행사를 수행했음을 보장하지만 해당 장치에서 실행 중인 운영 체제가 변경되지 않았음을 보장하지는 않습니다. 운영 체제가 변조 되지 않은 경우 방금 생성 된 자격 증명의 개인 키가 Secure Enclave에 의해 보호되고 개인 키 사용이 Face ID 또는 Touch ID로 보호되도록 보장합니다. (참고 : 생체 인식이 연속으로 여러 번 실패하면 경비원은 장치 암호로 대체합니다.)


Apple Anonymous Attestation은 최초로 익명화 CA와 같은 서비스를 제공합니다. 여기서 인증자는 제조업체가 소유 한 클라우드 운영 CA와 함께 작동하여 인증 자의 식별 정보가 공개되지 않도록 자격 증명 별 증명 인증서를 동적으로 생성합니다. 증명 문의 웹 사이트. 또한 등록 식 관련 데이터 중 인증을 위해 연결된 인증 자 데이터 및 클라이언트 데이터의 해시와 함께 자격 증명의 공개 키만 인증을 위해 CA로 전송되며 CA는 이들을 저장하지 않습니다. 이 접근 방식은 전체 증명 프로세스의 개인 정보를 보호합니다. 또한 이 접근 방식은 단일 장치의 손상으로 인해 동일한 증명 인증서가 있는 모든 장치에서 인증서가 취소되는 기본 증명의 보안 위험을 방지합니다.


Apple 익명 증명 활성화 


const options = {
    publicKey: {
        ...
        attestation: "direct", // the essential option
        ...
    }
};

const publicKeyCredential = await navigator.credentials.create(options);

명령문 형식 확인 


이것은 Apple 익명 증명 문 형식의 정의입니다. 문제 1453은 WebAuthn 표준에 이 문 형식을 추가하는 과정을 추적합니다.


$$attStmtType //= (
                       fmt: "apple",
                       attStmt: appleStmtFormat
                   )

appleStmtFormat = {
                       x5c: [ credCert: bytes, * (caCert: bytes) ]
                   }

위 필드의 의미는 다음과 같습니다. 

x5c credCert 다음에 각각 X.509 형식으로 인코딩 된 인증서 체인. 

credCert X.509 형식으로 인코딩 된 증명에 사용되는 자격 증명 공개 키 인증서입니다.


다음은 attStmt, authenticatorData 및 clientDataHash 입력이 주어진 확인 절차입니다.


  1. attStmt가 위에 정의 된 구문을 준수하는 유효한 CBOR인지 확인하고 이에 대해 CBOR 디코딩을 수행하여 포함 된 필드를 추출합니다.
  2. authenticatorData와 clientDataHash를 연결하여 nonceToHash를 형성합니다.
  3. nonceToHash의 SHA-256 해시를 수행하여 nonce를 생성합니다.
  4. nonce가 credCert의 OID (1.2.840.113635.100.8.2)가있는 확장의 값과 일치하는지 확인합니다. 여기서 nonce는 증명이 라이브임을 증명하고 authenticatorData 및 클라이언트 데이터의 무결성을 보호하는 데 사용됩니다.
  5. 자격 증명 공개 키가 credCert의 주제 공개 키와 일치하는지 확인합니다.
  6. 성공하면 증명 유형 익명 CA 및 증명 신뢰 경로 x5c를 나타내는 구현 별 값을 반환합니다.

마지막 단계는 x5c가 credCert에서 Apple WebAuthn 루트 인증서까지 유효한 인증서 체인인지 확인한 다음 증명을 증명하는 것입니다. (이 단계는 일반적으로 x5c [4]를 사용하는 여러 유형의 증명 간에 공유됩니다.) 참고로 AAGUID는 증명이 활성화 된 경우에도 모두 0입니다. 웹용 Face ID 및 Touch ID를 지원하는 모든 Apple 장치에는 이 섹션의 시작 부분에서 설명한 것과 동일한 속성이며 다른 장치는 Apple 익명 증명을 요청할 수 없습니다.


Apple Platform Authenticator의 고유 한 특성 


다음은 웹용 Face ID 및 Touch ID와 같은 Apple 플랫폼 인증 기의 고유 한 특성에 대한 요약입니다.


  • 옵션 세트가 다르면 UI가 다르므로 현명하게 지정하십시오.
  • RP ID와 user.name 만 선택하여 UI에 표시합니다.
  • 플랫폼 인증자를 호출하려면 사용자 제스처가 필요합니다.
  • Apple 익명 증명을 사용할 수 있습니다. 증명이 필요한 경우에만 사용하십시오.
  • AAGUID는 증명이 사용 되더라도 모두 0입니다.
  • 웹용 Face ID 및 Touch ID는 iOS 14, iPadOS 14 및 macOS Big Sur의 Safari, SFSafariViewController 및 ASWebAuthenticationSession에서 사용할 수 있습니다. macOS의 경우 하위 OS가있는 Safari 14는 증명이 새로운 시스템 프레임 워크에 의존하기 때문에 이 기능을 사용할 수 없습니다.
  • 플랫폼 인증 자에 의해 생성 된 모든 공개 키 자격 증명은 지정된 옵션에 관계없이 상주 키입니다.
  • 자격 증명은 Mac Safari의 경우 Safari> 기록> 기록 지우기…를 통해서만 지울 수 있으며 iOS 및 iPadOS에서는 설정> Safari> 기록 및 웹 사이트 데이터 지우기를 통해서만 지울 수 있습니다.
  • 서명 카운터가 구현되지 않았으므로 항상 0입니다. Secure Enclave는 소프트웨어 보호 장치 대신 자격 증명 개인 키가 유출되는 것을 방지하는 데 사용됩니다.


보안 키 지원 현황 


웹용 Face ID 및 Touch ID 도입 외에도 지원되는 모든 macOS에서 iOS 14, iPadOS 14 및 Safari 14는 PIN 입력 및 계정 선택을 포함한 향상된 보안 키 지원을 제공합니다. 다음은 현재 지원되는 기능 목록입니다. 앞서 언급 한 두 가지를 제외하고 모두 iOS 13.3, iPadOS 13.3 및 Safari 13부터 지원되었습니다.


  • WebAuthn 레벨 1의 모든 기능과 CollectedClientData.tokenBinding 및 대부분의 확장을 제외한 모든 선택적 기능이 있어야 합니다. appid 확장 만 지원됩니다.
  • setPin 및 changePin을 제외한 모든 CTAP 2.0 인증 자 API.
  • USB, Lightning 및 NFC 전송은 가능한 장치에서 지원됩니다.
  • U2F 보안 키는 CTAP 2.0을 통해 지원되지만 CTAP 1 / U2F JS는 지원되지 않습니다.
  • 웹용 Face ID 및 Touch ID와 마찬가지로 보안 키 지원은 Safari, SFSafariViewController 및 ASWebAuthenticationSession에서 사용할 수 있습니다.