빠른 페어링 절차

절차

시커는 일반 BR/EDR 또는 BLE 연결 절차를 즉시 호출하는 대신 먼저 키 기반 페어링 특성에 관한 알림을 사용 설정한 다음 표 1.1의 데이터를 여기에 씁니다.

빠른 페어링 시커의 쓰기 요청을 처리할 때 빠른 페어링 제공자는 다음을 실행해야 합니다.

  1. 선택적 공개 키 필드가 있는 경우:
    1. 기기가 페어링 모드가 아닌 경우 쓰기를 무시하고 종료합니다.
    2. 그렇지 않으면 다음 단계를 따르세요.
      1. 수신된 공개 키(secp256r1 타원 곡선의 64바이트 지점), 사전 설치된 스푸핑 방지 비공개 키(secp256r1), 타원 곡선 디피-헬만 알고리즘을 사용하여 256비트 AES 키를 생성합니다.
      2. SHA-256을 사용하여 256비트 AES 키를 해시합니다.
      3. 결과의 처음 128비트를 가져옵니다. 이 키는 다음 단계에서 사용되는 스푸핑 방지 AES 키입니다.

  2. AES-128을 사용하여 값 복호화를 시도합니다. 값이 단일 16바이트 AES 블록이므로 IV 또는 다중 블록 암호화 모드가 필요하지 않습니다.

    1. 사용할 키:
      1. 1단계에서 스푸핑 방지 AES 키가 생성된 경우 이 키를 사용합니다.
      2. 아니면 영구 계정 키 목록의 각 키를 사용해 보세요.
    2. 키가 값을 성공적으로 복호화하면 중단하고 다음 단계로 진행합니다.

    3. 출력이 표 1.2.1 또는 표 1.2.2의 형식과 일치하면(즉, 빠른 페어링 제공업체의 현재 BLE 주소 또는 빠른 페어링 제공업체의 공개 주소가 포함된 경우) 값이 성공적으로 복호화됩니다.

      참고: 패킷 끝에 솔트가 첨부되어 있습니다. 가능한 경우 이러한 솔트를 추적해야 하며, 제공업체가 이미 사용된 솔트가 포함된 요청을 수신하는 경우 재전송 공격을 방지하기 위해 요청을 무시해야 합니다.

    4. 솔트 추적의 대안으로, 쓰기에 제공자의 비공개 주소가 포함된 경우 재생 공격을 방지하는 또 다른 방법은 다음 키 기반 페어링 쓰기가 수락되기 전에 순환이 일어나도록 확인 가능한 다음 비공개 주소 순환 시간을 가져오는 것입니다.

  3. 값을 성공적으로 복호화할 수 없는 키가 없는 경우 쓰기를 무시하고 종료합니다.

    1. 이러한 실패 횟수를 기록합니다. 실패 횟수가 10이 되면 모든 새 요청이 즉시 실패합니다. 5분 후, 전원을 켠 후 또는 성공 후 실패 횟수를 재설정합니다.

  4. 그렇지 않으면 성공 키를 K로 저장합니다. 이 K를 이 저전력 링크에서 수신한 패스키 및 맞춤설정된 이름 쓰기를 복호화하는 데 사용할 수 있지만 다른 링크에 대한 쓰기나 쓰기는 사용할 수 없도록 표시합니다. 페어링이 시작되지 않은 경우 타이머를 시작하여 10초 후에 K를 삭제합니다. 이 저전력 링크의 연결이 끊기면 K도 삭제합니다.

  5. 표 1.3에 표시된 16바이트 원시 응답을 생성합니다. 유형과 제공자의 BR/EDR 주소를 연결하고 패킷의 나머지 부분을 임의의 바이트 블록 (즉, 솔트)으로 채웁니다.

  6. 원시 응답을 K로 암호화하여 표 1.4에 표시된 16바이트 암호화 응답을 생성합니다. 키 기반 페어링 특성에 관한 알림을 통해 이를 전송합니다.

  7. 요청 플래그를 읽습니다.

    1. 요청의 플래그 바이트에 비트 2가 1로 설정된 경우 맞춤설정된 이름으로 추가 데이터 특성을 알립니다.
    2. 요청의 플래그 바이트에 비트 1이 1로 설정된 경우:
      1. 이는 탐색자가 제공자에게 8~13바이트로 존재하는 탐색자의 BR/EDR 주소와의 결합을 시작하도록 요청하고 있음을 나타냅니다.
      2. 탐색자의 BR/EDR 주소로 페어링 요청을 보냅니다. 페어링 요청은 아래 ('페어링 중' 단계)에 설명된 대로 진행해야 합니다.
      3. 필요한 이유: 제공자가 시작하도록 하면 일부 기기의 문제가 해결됩니다.
    3. 요청의 플래그 바이트에 비트 1이 0으로 설정된 경우:
      1. 페어링 요청을 위해 최대 10초 동안 기다립니다. 수신되지 않으면 종료합니다.
      2. 이는 다른 주소(확인 가능한 비공개 주소가 아닌 탐색자의 공개 주소)의 BR/EDR 요청일 수 있습니다. Google은 페어링하는 동안 요청하는 기기에서 K를 소유하고 있음을 다시 확인합니다.

  8. 페어링하는 동안:

    1. 시커에서 페어링 요청/응답 패킷을 수신한 경우: 요청의 기기 기능이 NoInput/NoOutput이면 Just Works 페어링 방법을 사용하지 않도록 페어링을 종료합니다.
    2. 제공업체에서 전송한 페어링 요청/응답 패킷의 경우 기기 기능 필드를 Display/YesNo로 설정하고 인증 요구사항을 MITM Protection Required로 설정합니다. 이렇게 하면 숫자 비교 페어링 메서드 (Android에서는 패스키 확인이라고도 함)가 트리거됩니다. 이를 통해 요청하는 기기가 실제로 빠른 페어링 시커이고 중간자(man-in-the-middle)가 없는지 확인합니다. 예를 참고하세요.
    3. 필요한 이유: 대역 외 페어링 방법이 더 적합하지만 플랫폼은 원하는 모든 버전의 Android에서 이를 노출하지 않습니다.

  9. 패스키 확인이 필요한 경우 패스키 특성에 쓸 때까지 최대 10초 동안 기다립니다.

    1. 일반적으로 사용자는 이 페어링 방법을 통해 각 기기의 화면에 표시되는 패스키가 동일한지 확인합니다. 대신 이 페어링의 경우에만 신뢰할 수 있는 사전 공유 키로 암호화된 BLE를 통해 전송합니다.
    2. 이 방법은 MITM 보호 기능이 약간 손상될 수 있으므로 화면이나 키보드가 있는 기기에는 사용하면 안 됩니다. 현재 빠른 페어링은 이 문제로 인해 아직 이러한 기기 유형을 지원하지 않습니다.
    3. 패스키 작성 없이 10초 타이머가 만료되면 K를 삭제합니다.

  10. 값이 패스키 특성에 작성되면 암호화된 패스키 블록이 됩니다. K로 복호화하여 특성: 패스키 > 표 2.2 - (유형 = Seeker's Passkey)에 표시된 형식으로 원시 패스키 블록을 생성합니다.

  11. 복호화에 실패하면 쓰기를 무시하고 K를 삭제합니다.

  12. 그 외의 경우 원시 패스키 블록에는 시커가 예상하는 패스키인 6자리 패스키 PSeeker가 포함됩니다.

  13. PSeeker를 자체 예상 패스키인 PProvider와 비교합니다.

    1. 값이 같으면 확인에 '예'라고 답장하세요.
    2. 그렇지 않은 경우 확인 메시지에 '아니요'라고 응답하면 페어링에 실패합니다.

  14. 페어링 실패 여부와 관계없이 특성: 패스키 > 표 2.2에 표시된 형식으로 다른 원시 패스키 블록을 생성하고, 여기에는 예상되는 자체 패스키인 PProvider가 포함됩니다.

    1. 블록의 유형이 올바른지 확인합니다 (제공업체의 패스키, 표 참조). 참고: 탐색자로부터 받은 패스키 블록의 솔트를 재사용하지 마세요. 새로운 임의의 값을 생성합니다.

  15. K로 원시 패스키 블록을 암호화하고 패스키 특성에 대한 알림을 통해 암호화된 패스키 블록을 전송합니다.

  16. 탐색자가 올바른 패스키 P를 수신하여 복호화하면 확인자도 확인에 '예'라고 응답하며 페어링에 성공합니다.

    1. 페어링에 성공하면 K를 이 저전력 링크의 계정 키 쓰기 복호화에 사용할 수 있는 것으로 표시하지만 이후의 패스키 쓰기나 다른 링크에 대한 쓰기에는 사용할 수 없습니다. 10초 후에 K를 삭제하도록 타이머를 시작합니다. 또한 계정 키 쓰기 시도 후 K를 삭제합니다. 4단계와 마찬가지로 저전력 링크의 연결이 끊어지는 경우에는
    2. 페어링에 실패하면 K를 삭제합니다.

  17. 기기 기능 필드를 기본 I/O 기능 및 인증 요구사항으로 다시 전환하여 새 페어링이 예상대로 계속되도록 합니다.

예시
예 1: 페어링 시도 성공(중간자 없음).
예 2: 중간자(man-in-the-middle)로 페어링 시도가 실패했습니다.