SPECIFICATION

제 10 장: 보안 고려사항

본 장은 CAP 프로토콜의 위협 모델, 알려진 위험 및 완화책을 기술한다. 본 장은 비규범적 내용이지만(MUST/SHOULD/MAY 등 키워드를 사용하지 않음), 본 장에서 기술하는 위험과 완화책은 SHOULD 구현자에 의해 진지하게 다루어진다.

10.1 위협 모델

CAP 프로토콜의 위협 모델은 다음 전제와 고려에 기반한다.

10.1.1 신뢰 전제

CAP 프로토콜은 다음 엔티티를 신뢰 가능으로 가정한다:

  1. Registration_Authority: 신뢰 앵커, 그 키 배포 능력은 프로토콜 보안의 기초
  2. 프리인스톨된 신뢰 앵커 키: 단말 제조 또는 배포 시 프리인스톨된 RA 공개 키
  3. 단말의 안전 보관: Verification_Key와 로컬 서명 키 보관용 하드웨어/소프트웨어 보안 모듈

CAP 프로토콜은 다음 엔티티를 신뢰 가능으로 가정하지 않는다:

  1. Fay 인스턴스: Fay는 악의적 프로그래밍 또는 공격자 제어를 받을 수 있음
  2. iFay_Runtime: 버그가 있거나 교체될 수 있음
  3. 네트워크 채널: 도청, 변조, 차단될 수 있음
  4. 미인가 애플리케이션 프로세스: 단말상의 다른 프로세스가 CAP 제어를 우회 시도할 수 있음

10.1.2 공격자 능력

다음 능력의 공격자를 고려한다:

공격자 종류능력
네트워크 공격자네트워크 메시지의 도청, 변조, 차단, 리플레이
불량 Fay합법 자격 증명 보유하지만 행동 이상
자격 증명 절도자다른 채널로 타인의 자격 증명 사본 획득
내부 위협Descriptor_Issuer 자체가 함락
물리 공격자단말 장치에 물리 접촉

CAP 프로토콜은 앞 4 종류의 공격자에 대해 보호 메커니즘을 제공하며, 물리 공격자에 대한 방어는 단말의 하드웨어 보안 메커니즘에 의존한다(프로토콜 계층에서 해결하지 않음).

10.2 알려진 위험과 완화

10.2.1 자격 증명 누출 위험

위험: Authorization_Descriptor 파일이 공격자에 의해 절도된 후, 자격 증명을 보유한 Fay 외의 엔티티에서 단말에 제출 가능.

완화책:

  • Authorization_Descriptor의 subject_fay_id는 구체적 Fay에 바인딩되며, 단말은 §3.3.2 단계 4에서 주체 매칭을 검증
  • 공격자는 대상 Fay의 런타임을 동시에 제어해야 하며(즉 Fay 자체를 공격해야 함), 자격 증명 누출 자체로는 공격을 구성하기에 부족
  • 자격 증명 보관은 MUST 암호화됨(§3.2.3), 오프라인 추출 방지
  • Trusted_Ticket은 짧은 유효 기간(최대 7 일)과 실시간 폐기 조회로 손해 윈도우 제한

잔여 위험: 공격자가 Fay 프로세스(키 포함)를 완전 제어한 경우, 자격 증명은 여전히 남용될 수 있다. 본 프로토콜은 "이미 완전히 함락된 Fay"의 문제를 해결할 수 없다 — 이것은 더 상위의 Fay 무결성 보호 문제다.

10.2.2 폐기 지연 위험

위험: 자격 증명 폐기에서 폐기 선언이 단말에 도달하기까지 지연 윈도우가 존재하며, 그 동안 폐기된 자격 증명은 여전히 검증 통과 가능.

완화책:

  • 단말 지속 온라인 시, 폐기 선언은 기본적으로 1 시간 이내에 동기화(§3.4.5)
  • Trusted_Ticket 사용 시, 단말은 MAY 실시간 폐기 조회로 지연 해소(§4.3.2 단계 5)
  • 자격 증명 유효 기간 상한(오프라인 90 일 / 온라인 7 일)이 최대 지연 제한
  • 발급자는 고민감 시나리오에서 SHOULD 더 짧은 유효 기간(1 일 등) 사용

잔여 위험: 장기 오프라인 단말은 며칠 또는 그 이상의 기간 동안 폐기된 자격 증명을 수용할 가능성이 있다. 이것은 오프라인 인가 메커니즘의 고유한 트레이드오프다 — 가용성과 폐기 시효성 사이에서 가용성 우선을 선택.

10.2.3 리플레이 공격 위험

위험: 공격자가 합법적인 프로토콜 메시지를 캡처 후 단말에 리플레이.

완화책:

  • AuthRequest는 message_id(UUID v7, 시간 관련)를 포함하며, 단말은 MAY 단기 기시 ID 캐시를 유지하여 리플레이 거부 가능
  • Heartbeat의 sequence_number는 단조 증가하며, 리플레이가 감지됨(§5.4.2)
  • TLS 채널이 기초적인 리플레이 보호 제공(각 TLS 세션은 독립)
  • 폐기 선언의 revocation_id는 고유, 리플레이 무효

잔여 위험: TLS 세션 내부에서 공격자가 이미 TLS 암호화를 돌파한 경우 메시지 리플레이 가능. 이것은 TLS 계층의 위협이며, CAP 프로토콜의 범위가 아니다.

10.2.4 시계 공격 위험

위험: 공격자가 단말 시계를 변조하여 유효 기간 검증을 우회하거나 시계 관련 취약점을 노출.

완화책:

  • 단말 시계 출처는 신뢰 가능해야 함(시스템 시계, NTP 동기화)
  • §3.6이 시계 드리프트 감지 정의: 현저한 시계 점프 시 검증 거부
  • 장기간 오프라인의 단말은 SHOULD 사용자에게 시계 재동기화를 권유

잔여 위험: 단말을 물리 제어하는 공격자는 시계를 조작할 수 있다. 물리 보안은 단말 하드웨어의 책임이다.

10.2.5 Descriptor_Issuer 함락 위험

위험: Descriptor_Issuer가 공격자에 의해 완전 제어되어 임의의 자격 증명을 발급 가능.

완화책:

  • §8.6.2가 긴급 키 폐기 메커니즘 정의
  • Registration_Authority는 Descriptor_Issuer의 Verification_Key를 폐기함으로써 그 모든 발급 자격 증명을 실효시킬 수 있음
  • 단말은 Verification_Key 폐기 수신 후 관련 Session을 즉시 종료(§5.5)
  • 신뢰 루트(Registration_Authority)의 보안이 핵심이다 — 그 함락은 신뢰 체인 전체의 붕괴를 초래

잔여 위험: Verification_Key 폐기 전에 이미 발급된 자격 증명은 남용될 가능성이 있다. 폐기 윈도우 기간은 불가피하다.

10.2.6 리소스 고갈 공격 위험

위험: 악의적 Fay가 대량 요청으로 단말 리소스(연결 수, Session 수, 보관)를 고갈시킴.

완화책:

  • §5.8이 Session 수량 제한 정의
  • §3.2.3이 자격 증명 보관 상한 정의
  • 하트비트 타임아웃으로 실효 Session 회수, 리소스 해제
  • 단말은 SHOULD fay_id 기반 속도 제한 실시(§7.4.2 빈도 제약 외)

잔여 위험: 합법적으로 발급된 여러 자격 증명이 공모하여 리소스를 고갈시킬 가능성. 단말 정책은 단일 Fay의 총 할당량을 제한해야 한다.

10.2.7 인계 경합 위험

위험: 공격자가 인계 흐름의 중간 상태(§6.5.1 [T2]의 "활성 Session 없음" 상태 등)를 이용하여 리소스를 가로챔.

완화책:

  • 인계 과정 중 리소스는 사전 점유 상태(handover_pending)에 있으며, 다른 Session 요청을 수락하지 않음(§6.5.3)
  • [T2]와 [T3] 사이에서 실패가 발생해도, 리소스는 명시적으로 "유휴" 상태에 진입하며, 후속 요청이 공정하게 경합(§6.5.2)
  • 인계 타임아웃으로 리소스가 장기간 pending 상태에 있지 않도록 함

잔여 위험: [T3]–[T4] 실패의 극단적 케이스에서, 원래 Fay의 세션은 복구 불가 — AuthRequest를 재발신해야 한다. 이것은 필요한 대가이며, "자동 복구"가 가져오는 더 복잡한 보안 분석을 회피.

10.2.8 디그레이드 공격 위험

위험: 공격자가 단말과 Ticket_Issuer의 연결을 차단하여, 단말을 디그레이드 모드(§4.5)로 강제하고 실시간 폐기 검사를 우회.

완화책:

  • 단말은 디그레이드 모드에서 기본적으로 새 Trusted_Ticket의 수용 거부
  • 이미 로컬 Authorization_Descriptor로 변환된 티켓의 유효 기간은 짧음(최대 7 일)
  • 단말은 SHOULD iFay_Runtime에 현재 디그레이드 모드임을 시사하여, 민감 작업이 능동 거부할 수 있도록 함

잔여 위험: 디그레이드 기간 중 이미 변환된 로컬 자격 증명은 여전히 사용 가능. 이것은 오프라인 우선 설계의 고유한 트레이드오프다.

10.2.9 사이드 채널 공격 위험

위험: CAP 프로토콜 응답 시간 또는 에러 코드 세부사항을 관찰하여 민감 정보(유효 자격 증명의 존재성 등)를 추론.

완화책:

  • 에러 코드는 내부 세부사항을 노출하지 않음(§9.9)
  • 구현은 SHOULD 검증 실패의 다른 분기에서 근사한 응답 시간을 유지
  • 에러 응답에서 키 핑거프린트, 내부 ID 등을 누출하지 않음

잔여 위험: 사이드 채널 공격을 완전히 배제하는 것은 극히 어렵다. 본 프로토콜 계층은 기초 조치를 제공하며, 심층 방어는 구현 품질에 의존.

10.3 배포 보안 권장

CAP 프로토콜을 구현하는 배포자는 다음 보안 실천을 고려해야 한다:

10.3.1 키 관리

  • 개인 키 보관은 하드웨어 보안 모듈(HSM, TPM, Secure Enclave) 사용
  • 키 로테이션 주기는 90 일 이하(단말 로컬 키) / 365 일 이하(Issuer 키)
  • 키 누출 긴급 대응 흐름 확립
  • 핵심 서명 작업은 다인 승인 또는 하드웨어 PIN 요구

10.3.2 모니터링과 감사

  • 모든 인가 검증 실패 이벤트 기록 및 경보
  • 비정상 폐기 요청 빈도 모니터링(Descriptor_Issuer 함락의 지표일 수 있음)
  • 감사 로그는 독립적인 영속화 보관 사용, 변조 방지
  • 고민감 리소스(configure 모드, require_human_confirmation 제약)의 모든 작업을 완전 감사

10.3.3 단말 강화

  • OS 강제 접근 제어(SELinux, AppArmor) 활성화
  • 샌드박스로 iFay_Runtime과 다른 프로세스 분리
  • 불필요한 시스템 서비스 정지, 공격면 감소
  • 정기적으로 시스템 패치 갱신

10.3.4 네트워크 세그먼테이션

  • Registration_Authority의 배포 네트워크와 공중망 분리
  • Descriptor_Issuer를 통제된 환경에 배포
  • 단말에서 Issuer로의 통신을 필요한 포트/프로토콜로 제한
  • mTLS(양방향 인증)로 핵심 통신 보호

10.4 프로토콜 한계

본 사양은 명시적으로 다음 보안 문제를 해결하지 않는다:

  1. Fay 무결성: CAP 프로토콜은 Fay 인스턴스 자체의 코드와 행동 무결성이 다른 메커니즘(코드 서명, 런타임 무결성 측정 등)으로 보장된다고 가정
  2. 물리 보안: 단말이 물리 공격자에 의해 완전 제어된 경우, 소프트웨어 계층에서는 보호를 제공할 수 없음
  3. 감사 로그 형식: v1은 감사 로그 형식을 규범화하지 않음(블루프린트 §3.2 제외 항목)
  4. 단말 간 신원 페더레이션: v1은 단말 간 통합 신원 관리를 지원하지 않으며, 각 단말은 독립적으로 Registration_Authority를 신뢰

10.5 후속 버전의 보안 진화

향후 버전(v2+)에서 도입 예정인 보안 강화:

  1. 분산 폐기 합의(블루프린트 §3.2 제외 항목)
  2. 감사 로그 표준 형식(블루프린트 §3.2 제외 항목)
  3. 양자 내성 암호 알고리즘(NIST PQC 표준 추적)
  4. 제로 트러스트 원칙의 더 깊은 통합
  5. 형식적 프로토콜 보안 증명