Tink 와이어 형식

이 페이지에서는 키 및 원시 출력에 관한 Tink의 와이어 형식을 설명합니다. 이 문서는 Tink에 언어를 추가하려는 암호화 전문가와 전송 호환 모드를 원하는 다른 고급 암호화 라이브러리의 유지보여자를 대상으로 합니다. 모든 연령대의 시청자를 대상으로 하지 않습니다.

키 세트 직렬화

Tink는 Google protobuf를 사용하여 키 집합을 직렬화합니다.

  • 바이너리 직렬화 키 세트는 tink.proto에 정의된 직렬화된 키 세트 프로토입니다. 키의 KeyData 값 속성은 해당 키 유형의 직렬화된 프로토입니다.
  • JSON 직렬화 키 세트는 JSON 형식으로 직렬화된 키 세트 프로토입니다. KeyData 값은 여전히 직렬화된 바이너리 프로토입니다.
  • 암호화된 키 세트는 tink.proto에 정의된 직렬화된 EncryptedKeyset 프로토입니다. 여기에는 암호화된 바이너리 직렬화 키 세트와 선택적으로 일부 암호화되지 않은 KeysetInfo 메타데이터가 포함됩니다.

Tink 출력 접두사

대부분의 Tink 원시 유형은 다음으로 구성된 5바이트 출력 접두사를 지원합니다.

  • 1바이트 버전: 0x01
  • 4바이트 키 힌트: 사용된 키의 키 ID입니다.

일부 기존 키는 버전 바이트 0x00도 지원할 수 있습니다.

이 접두사는 인증되지 않으며 보안 목적으로 사용할 수 없습니다. Tink는 이를 복호화 또는 확인 속도를 높이는 힌트로 사용합니다.

AEAD

일반적으로 Tink는 AEAD 암호문을 다음과 같이 형식 지정합니다.

prefix || IV || ciphertext || tag

해당 RFC에 달리 명시되지 않는 한 prefix는 비어 있거나 5바이트 Tink 출력 접두사입니다.

AES-CTR-HMAC

AES-CTR-HMAC의 경우 Tink는 다음과 같이 연결된 데이터 (AD)로 MAC을 계산합니다.

AD || IV || ciphertext || bitlen(AD)

여기서 bitlen(AD)는 64비트 big-endian 부호 없는 정수로 표시된 AD의 길이(비트)입니다. 이 HMAC 스키마는 Mcgrew의 AES-CBC-HMAC 초안을 따릅니다.

결정론적 AEAD

Tink는 AES-SIV용 RFC 5297을 구현하여 합성 초기화 벡터 (SIV)를 암호문의 시작 부분에 배치합니다. 이 원시 유형은 5바이트 Tink 출력 접두사를 추가할 수 있습니다.

RFC 5297은 연결된 데이터 목록을 지원하지만 Tink는 RFC 5297의 요소가 하나인 목록에 해당하는 연결된 데이터를 정확히 하나만 지원합니다. 연결된 빈 데이터는 빈 목록이 아니라 빈 요소가 하나 있는 목록입니다.

스트리밍 AEAD

AES-CTR HMACAES-GCM-HKDF를 참고하세요.

봉투 암호화

봉투 암호화는 Tink의 AEAD 기본을 사용하여 데이터 암호화 키 DEK로 데이터를 암호화합니다. 암호화는 다음과 같이 작동합니다.

  • 지정된 키 템플릿 (또는 키 매개변수)을 사용하여 새 DEK가 생성됩니다.
  • DEK는 바이트 문자열로 직렬화됩니다. 키 유형 proto의 프로토콜 버퍼 직렬화를 직렬화 형식으로 지정합니다. 예를 들어 다음은 키 유형 AES GCM의 DEK에 대해 aes_gcm.proto에 정의된 직렬화된 AesGcmKey 프로토콜 버퍼 메시지입니다. 프로토콜 버퍼를 직렬화하는 방법은 프로토콜 버퍼 직렬화를 참고하세요.
  • 직렬화된 DEK는 외부 제공업체 (예: GCP)에 의해 encrypted DEK로 암호화됩니다.
  • DEK는 일반 텍스트를 연결된 데이터와 함께 ciphertext로 암호화하는 데 사용됩니다. 따라서 ciphertextDEK에 상응하는 AEAD 원시 형식과 정확히 동일한 형식을 갖습니다.

봉투 암호화의 출력 형식은 다음과 같습니다.

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length는 4바이트이며 encrypted DEK의 길이를 32비트 big-endian 정수로 저장합니다.

MAC

Tink는 해당 RFC를 따릅니다. 프리미티브는 태그에 5바이트 Tink 출력 접두사를 추가할 수 있습니다.

PRF 세트

Tink는 해당 RFC를 따릅니다. PRF 세트의 경우 키 유형은 출력 길이를 포함하지 않으므로 동일한 알고리즘의 MAC 키 유형과 다릅니다. PRF 세트 키는 Tink 출력 접두사를 추가하지 않습니다. 이렇게 하면 출력이 실제로 PRF가 됩니다.

하이브리드 암호화

Tink 하이브리드 암호화의 일반적인 전송 형식은 다음과 같습니다.

prefix || encapsulated_key || encrypted_data

prefix는 비어 있거나 5바이트 Tink 출력 접두사입니다. 각 키 유형에는 파싱할 바이트 수와 encapsulated_key에서 이러한 바이트를 파싱하는 방법에 관한 정보가 포함됩니다.

HPKE (하이브리드 공개 키 암호화)

Tink는 RFC 9180에 정의된 HPKE 표준을 따릅니다. HPKE 암호 모음에는 다음 세 가지 원시 유형이 포함됩니다.

  • 키 캡슐화 메커니즘 (KEM)
  • 키 파생 함수 (KDF)
  • 연관 데이터로 인증된 암호화 (AEAD)

HPKE 표준은 RFC 9180, 섹션 10에서 일반 전송 형식을 정의하지 않습니다. Tink의 HPKE 구현은 다음 encapsulated_keyencrypted_data 값을 사용합니다.

  • encapsulated_key
    • 발신자의 직렬화된 공개 키
    • RFC 9180, 4.1항enc로 정의됨
    • 사용된 특정 HPKE KEM에 따라 결정되는 형식
  • encrypted_data
    • 암호문 및 태그 (예: ciphertext || tag(IV 제외)
    • RFC 9180, 4절에서 ct로 정의됨
    • 사용된 특정 HPKE AEAD에 따라 결정되는 형식
X25519 디피-헬만 기반 KEM

X25519 DHKEM의 경우 값 enc는 발신자의 32바이트 Diffie-Hellman 공개 키입니다.

ECIES-AEAD-HKDF

Tink의 ECIES-AEAD-HKDF 구현의 경우 encapsulated_key는 키 캡슐화 메커니즘 (KEM)의 출력이고 encrypted_data는 데이터 캡슐화 메커니즘 (DEM)의 출력입니다.

KEM

키 유형에 따라 Tink는 RFC 8422/ANSI.X9-62.2005 인코딩 표준에 따라 압축된 타원 곡선 포인트와 비압축 타원 곡선 포인트를 사용합니다. 비압축 포인트의 경우 바이트 0x04 뒤에 xy 좌표가 고정 크기 정수로 표시됩니다. 압축된 좌표의 경우 바이트 0x02 또는 0x03와 고정 크기 정수로 x 좌표가 사용됩니다. X25519의 경우 RFC 7748 정의가 사용됩니다 (x 좌표가 고정 크기 정수로 표시됨).

DEM

encrypted_data의 경우 Tink는 AEAD와 동일한 형식을 사용합니다. 여기에는 IV 지정이 포함됩니다.

키 파생

먼저 공유 지점의 x 좌표 x_ss가 계산됩니다. 그러면 AEAD의 키가 다음으로 설정됩니다.

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

여기서 encapsulated_key는 전체 KEM 출력을 바이트로 나타낸 것입니다.

디지털 서명

Tink는 해당 RFC를 따릅니다. 프리미티브는 생성된 태그에 5바이트 Tink 출력 접두사를 추가할 수 있습니다.

ECDSA

키의 EcdsaSignatureEncoding 필드에 따라 ECDSA 서명의 형식은 IEEE P1363 또는 ASN.1 DER입니다.

IEEE P1363 서명의 형식은 r || s입니다. 여기서 rs는 0으로 채워지며 곡선 순서와 동일한 바이트 크기를 갖습니다. 예를 들어 NIST P-256 곡선의 경우 rs가 32바이트로 0으로 채워집니다.

DER 서명은 ASN.1를 사용하여 인코딩됩니다.

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

특히 인코딩은 다음과 같습니다.

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink는 DER 인코딩된 ECDSA 서명을만 허용하여 서명 확인 권장사항을 따릅니다 (대체 BER 인코딩 서명은 유효하지 않음).

이렇게 하면 암호화폐 시스템에 영향을 미치는 서명 가변성 공격을 방지할 수 있습니다.