SPECIFICATION

제7장 보안과 암호화

7.1 보안 모델

DTP 구현은 종단 간 암호화를 제공해야 한다. 보안 모델은 다음 불변 조건을 충족해야 한다:

  1. 대상 iFay 인스턴스만이 수신한 Payload를 복호화할 수 있어야 한다.
  2. FayGer 런타임 환경은 어떠한 경우에도 평문 데이터에 접근해서는 안 된다.
  3. 중간 네트워크 노드는 Payload 평문을 읽어서는 안 된다.
  4. DTP 구현은 암호화 키를 자체적으로 관리해서는 안 된다.

7.2 암호화 범위

암호화 범위는 LogicalFrame의 Payload로 엄격하게 한정되어야 한다.

7.2.1 반드시 암호화해야 할 내용

다음 데이터는 암호화해야 한다:

  • LogicalFrame의 payload 필드(즉, Fragment의 data 필드 그리고 (Frame 형식으로 운반되는 경우) RequestFrame, ResponseFrame, ControlFrame의 내용).

7.2.2 암호화해서는 안 되는 내용

다음 데이터는 암호화해서는 안 되며, 평문으로 전송해야 한다:

  • LogicalFrame의 header(protocolVersion, frameType, fragmentId, agreementId, originTimestamp, dagDependencies, encryptionMetadata, sequenceNumber를 포함).

암호화 메타데이터 자체는 암호화해서는 안 되며, 이는 수신측이 복호화 전에 복호화 매개변수를 결정할 수 있도록 한다.

7.3 키 관리

7.3.1 키 출처

DTP 구현은 CAP에서 사전 협상한 키를 사용해야 한다. 구체적 요구사항:

  1. CAP는 연결 수립 단계에서 신원 검증과 키 교환을 완료해야 한다.
  2. DTP 구현은 CAP가 제공한 sessionKey를 사용하여 Payload 암호화/복호화를 수행해야 한다.
  3. DTP 구현은 암호화 키를 자체적으로 생성, 협상 또는 교환해서는 안 된다.

7.3.2 CAPContext 인터페이스

DTP 구현은 다음 인터페이스를 통해 CAP가 제공하는 컨텍스트를 받아야 한다:

interface CAPContext {
  identity: string;
  sessionKey: Uint8Array;
  verified: boolean;
}
필드규범적 요구사항
identity상대측 신원 식별자여야 한다
sessionKeyCAP가 협상한 세션 키의 바이트 시퀀스여야 한다
verifiedCAP 검증 상태를 반영해야 한다

7.3.3 CAP 전제 조건

DTP 구현은 데이터 전송 시작 전에 CAPContext를 검증해야 한다:

  1. verified === false이면 데이터 프레임 전송을 거부하고 KEY_NOT_READY 오류(2002)를 반환해야 한다.
  2. sessionKey가 비어 있거나 길이가 유효하지 않으면 KEY_NOT_READY 오류를 반환해야 한다.
  3. 협상 프레임(Request_Frame, Response_Frame)의 전송도 동일하게 이 전제 조건의 제약을 받는다.

7.4 암호화 메타데이터

각 LogicalFrame의 프레임 헤더는 EncryptionMetadata를 포함해야 한다:

interface EncryptionMetadata {
  algorithm: string;
  keyVersion: number;
}

7.4.1 알고리즘 식별자

algorithm 필드는 암호화 알고리즘의 식별 문자열이어야 한다. 다음 표준화 명명 중 하나를 사용해야 한다(권장):

식별자알고리즘상태
"AES-256-GCM"AES-256 in Galois/Counter Mode권장
"ChaCha20-Poly1305"ChaCha20 with Poly1305권장
"AES-128-GCM"AES-128 in Galois/Counter Mode사용 가능

구현은 최소한 AES-256-GCM과 ChaCha20-Poly1305 중 하나를 지원해야 한다. 상호 운용성을 강화하기 위해 두 가지를 모두 지원하는 것을 권장한다.

구현은 다음을 사용해서는 안 된다:

  • ECB 모드(안전하지 않음)
  • 인증이 없는 암호화 모드(MAC 없는 CBC, CTR)
  • 알려진 약점이 있는 알고리즘(DES, 3DES, RC4)

7.4.2 키 버전 번호

keyVersion은 음이 아닌 정수여야 하며, 키 로테이션을 지원하기 위해 사용된다:

  1. CAP가 키 로테이션을 트리거하면 새 키의 keyVersion은 이전 버전보다 엄격하게 커야 한다.
  2. 수신측은 keyVersion을 사용하여 대응하는 복호화 키를 선택해야 한다.
  3. 구현은 진행 중(in-flight)인 Fragment를 지원하기 위해 적어도 하나의 이전 키 버전을 유지해야 한다(권장).

7.5 암호화 왕복 일관성

구현은 다음 암호화 왕복 일관성 속성을 충족해야 한다:

  1. 올바른 키(송신측이 사용한 키와 일치)로 암호화 후 복호화하면 원본 Payload와 바이트 수준으로 동일한 출력이 생성되어야 한다.
  2. 잘못된 키로 복호화하면 실패해야 하며, DECRYPTION_FAILED 오류(2001)를 반환해야 한다.
  3. 복호화 실패 시 구현은 부분적으로 복호화된 결과나 손상된 데이터를 반환해서는 안 된다.

7.6 단말 측 복호화

단말이 수신측인 경우(데이터 주입 시나리오):

  1. DTP_Slave는 단말이 CAP 연결 수립 단계에서 제출한 키를 사용하여 복호화해야 한다.
  2. 해당 키는 단말이 CAP에서 제출한 비공개키/세션 키와 대응되어야 한다.
  3. 단말은 다른 어떠한 키의 복호화 결과도 받아들여서는 안 된다.

7.7 복호화 실패 처리

구현은 다음 규칙에 따라 복호화 실패를 처리해야 한다:

  1. 단일 복호화 실패: 프레임을 폐기하고 DECRYPTION_FAILED 오류 알림(2001)을 전송한다.
  2. 연속 복호화 실패가 임곗값(구현 정의, 권장 3회)을 초과: a. CAP 키 재교환을 트리거해야 한다(권장). b. 상위 애플리케이션에 보안 예외를 통지해야 한다(권장).
  3. 구현은 여러 차례 복호화 실패 후에도 동일 프레임에 대해 무한히 재시도해서는 안 된다.

7.8 보안 위협 방어

구현은 프로토콜 설계를 통해 다음 위협으로부터 방어해야 한다:

위협방어 메커니즘
중간자 도청Payload 종단 간 암호화
FayGer 엿보기Payload 암호화, FayGer는 암호문만 볼 수 있음
키 유출키 버전 번호 메커니즘으로 키 로테이션 지원
신원 위조CAP 검증에 위임
재전송 공격시퀀스 번호 단조 증가 + 세션 바인딩
프레임 변조인증 암호화(AEAD) 알고리즘 사용

7.9 재전송 보호

구현은 다음 메커니즘을 통해 재전송 공격으로부터 방어해야 한다:

  1. 시퀀스 번호 단조 증가: 수신측은 이미 확인된 최고 시퀀스 번호 이하의 프레임을 거부해야 한다(재개 시나리오 제외).
  2. 세션 바인딩: 시퀀스 번호 공간은 구체적인 세션과 바인딩되어야 한다. 새 세션은 시퀀스 번호를 재설정해야 한다.
  3. AEAD 인증: 암호화 알고리즘은 메시지 인증을 제공해야 한다(GCM, Poly1305 등).

7.10 메타데이터 프라이버시

구현은 다음에 유의해야 한다: 프레임 헤더의 평문 메타데이터는 다음 정보를 유출할 수 있다:

  • 통신 상대 신원(agreementId 연결을 통해)
  • 통신 시간 패턴(originTimestamp와 sequenceNumber를 통해)
  • 데이터 전송 빈도(프레임 간 시간차를 통해)

구현은 다음 방식으로 메타데이터 프라이버시를 강화할 수 있다:

  1. 트래픽 패딩 활성화(구현 정의).
  2. 난독화 전송 계층 사용(예: TLS 1.3 기반의 ECH).

다만 본 사양은 구현이 메타데이터 프라이버시 보호를 제공하도록 요구하지 않는다.