기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
내부 통신 보안
서비스 호스트 또는 AWS KMS 운영자와 HSM 간의 명령은 인증된 세션에서 설명하는 두 가지 메커니즘, 즉 쿼럼 서명 요청 방식, 그리고 HSM 서비스 호스트 프로토콜을 사용하는 인증된 세션을 통해 보호됩니다.
쿼럼 서명 명령은 단일 운영자가 HSM이 제공하는 중요한 보안 보호 기능을 수정할 수 없도록 설계되었습니다. 인증된 세션을 통해 실행되는 명령을 사용하면 인증된 서비스 운영자만 KMS 키와 관련된 작업을 수행하도록 할 수 있습니다. 모든 고객 바인딩 보안 암호 정보는 AWS 인프라 전체에 걸쳐 보호됩니다.
키 설정
내부 통신을 보호하기 위해 AWS KMS는 두 가지 키 설정 방법을 사용합니다. 첫 번째는 이산 로그 암호화를 사용한 페어 방식 키 설정 체계에 대한 권장 사항(개정 2)
두 번째 키 설정 방법은 C(2, 2, ECC, DH)
HSM 보안 경계
AWS KMS의 내부 보안 경계는 HSM입니다. HSM은 독점적 인터페이스를 제공하며 작동 상태일 때 다른 활성 물리적 인터페이스는 없습니다. 작동 HSM은 초기화 중에 도메인에서 역할을 설정하는 데 필요한 암호화 키를 사용하여 프로비저닝됩니다. HSM의 민감한 암호화 구성 요소는 휘발성 메모리에만 저장되며, HSM이 의도하거나 의도하지 않은 종료 또는 재설정을 비롯한 작동 상태를 벗어날 때 지워집니다.
HSM API 작업은 개별 명령에 의해 또는 서비스 호스트가 설정한 상호 인증된 기밀 세션을 통해 인증됩니다.
쿼럼 서명 명령
Quorum-signed 명령은 운영자가 HSM에 대해 실행합니다. 이 섹션에서는 쿼럼 기반 명령을 만들고 서명하고 인증하는 방법에 대해 설명합니다. 이 규칙은 매우 간단합니다. 예를 들어 Foo 명령의 경우 Bar 역할의 두 멤버가 인증되어야 합니다. 쿼럼 기반 명령의 생성 및 검증은 세 단계로 이루어집니다. 첫 번째 단계는 초기 명령을 생성하는 것이고, 두 번째 단계는 서명할 추가 운영자에게 제출하는 것이며, 세 번째 단계는 검증하고 실행하는 것입니다.
이 개념을 도입하기 위해 운영자의 퍼블릭 키 및 역할 세트가 {QOSs}이고, 쿼럼 규칙 세트가 QR = {Commandi, Rule{i, t}}(여기서 각 Rule은 역할의 세트)이며, 최소 개수가 N {Rolet, Nt}이라고 가정합니다. 명령이 이 쿼럼 규칙을 충족하려면 해당 명령에 대해 나열된 규칙 중 하나를 충족하도록 {QOSs}가에 나열된 작업 세트로 명령 데이터 집합에 서명해야 합니다. 앞서 언급했듯이 쿼럼 규칙 및 운영자 세트는 도메인 상태 및 내보낸 도메인 토큰에 저장됩니다.
실제로 초기 Signer는 Sig1 = Sign(dOp1, Command) 명령에 서명합니다. 두 번째 운영자는 Sig2 = Sign(dOp2, Command) 명령에 서명합니다. 이중으로 서명된 메시지는 실행을 위해 HSM으로 전송됩니다. HSM은 다음을 수행합니다.
-
각 서명에 대해 도메인 상태에서 서명자의 퍼블릭 키를 추출하고 명령의 서명을 검증합니다.
-
Signer 세트가 명령에 대한 규칙을 충족하는지 확인합니다.
인증된 세션
키 작업은 외부에 연결된 AWS KMS 호스트와 HSM 간에 실행됩니다. 이러한 명령은 암호화 키의 생성 및 사용, 그리고 보안 난수 생성과 관련이 있습니다. 이들 명령은 서비스 호스트와 HSM 간의 세션 인증 채널을 통해 실행됩니다. 이러한 세션에는 신뢰성 외에 기밀성도 요구됩니다. 이러한 세션을 통해 실행되는 명령에서는 일반 텍스트 데이터 키 및 복호화된 메시지가 반환됩니다. 중간자 공격을 통해 이러한 세션을 악용할 수 없도록 하기 위해 세션이 인증됩니다.
이 프로토콜은 HSM과 서비스 호스트 간에 상호 인증된 ECDHE 키 계약을 수행합니다. 교환은 서비스 호스트에 의해 시작되고 HSM에 의해 완료됩니다. 또한 HSM은 협상된 키로 암호화된 세션 키(SK)와 이 세션 키가 포함된 내보낸 키 토큰을 반환합니다. 내보낸 키 토큰에는 유효 기간이 포함되며, 이 기간이 지나면 서비스 호스트가 세션 키를 다시 협상해야 합니다.
서비스 호스트는 도메인의 멤버이며 자격 증명 서명 키 페어(dHOSi, QHOSi)와 HSM의 자격 증명 퍼퍼블릭 키의 올바른 사본을 가지고 있습니다. 자격 증명 서명 키 세트를 사용하여 도메인의 서비스 호스트와 HSM 간에 사용할 수 있는 세션 키를 안전하게 협상합니다. 내보낸 키 토큰에는 유효 기간이 있으며 그 기간이 지나면 새 키를 협상해야 합니다.
이 프로세스는 그 자체와 도메인의 HSM 멤버 간의 중요한 통신 흐름을 보내고 받기 위해 세션 키가 필요하다는 것을 서비스 호스트가 인식하면서 시작됩니다.
-
서비스 호스트가 ECDH 임시 키 페어 (d1, Q1)를 생성하고 자격 증명 키 Sig1 = Sign(dOS,Q1)를 사용하여 서명합니다.
-
HSM이 현재 도메인 토큰을 사용하여 수신된 퍼블릭 키의 서명을 확인하고 ECDH 임시 키 페어 (d2, Q2)를 생성합니다. 그런 다음 이산 로그 암호화를 사용한 페어 방식 키 설정 체계에 대한 권장 사항(개정)
에 따라 ECDH 키 교환을 완료하여 협상된 256비트 AES-GCM 키를 구성합니다. HSM이 새로운 256비트 AES-GCM 세션 키를 생성합니다. 협상된 키로 세션 키를 암호화하여 암호화된 세션 키(ESK)를 만듭니다. 또한 내보낸 키 토큰 EKT으로서 도메인 키를 사용하여 세션 키를 암호화합니다. 마지막으로 자격 증명 키 페어 Sig2 = Sign(dHSK, (Q2, ESK, EKT))를 사용하여 반환 값에 서명합니다. -
서비스 호스트가 현재 도메인 토큰을 사용하여 수신된 키의 서명을 확인합니다. 그런 다음 서비스 호스트는 이산 로그 암호화를 사용한 페어 방식 키 설정 체계에 대한 권장 사항(개정)
에 따라 ECDH 키 교환을 완료합니다. 다음으로, ESK를 복호화하여 세션 키 SK를 가져옵니다.
EKT의 유효 기간 동안, 서비스 호스트는 협상된 세션 키 SK를 사용하여 봉투 암호화 명령을 HSM으로 보낼 수 있습니다. 이 인증된 세션을 통해 서비스 호스트가 시작한 모든 명령에는 EKT가 포함됩니다. HSM은 동일한 협상된 세션 키 SK를 사용하여 응답합니다.