대칭·비대칭 암호·해시·서명

암호화된 문서가 엉뚱한 고객에게 전달되면

문서 내용은 읽을 수 없게 저장했는데, 겉에 붙은 고객번호를 바꾸자 다른 고객의 문서함에 나타났다. 또는 암호문을 그대로 다시 보내자 같은 지급 요청이 두 번 처리됐다. 두 사고 모두 “암호화했으니 안전하다”는 설명으로는 원인을 찾을 수 없다. 숨길 내용, 변경을 탐지할 정보, 작성자를 확인할 근거, 중복 실행을 막을 상태가 서로 다르기 때문이다.

이 절의 한 사례는 조직 A가 조직 B에 보내는 지급 문서 M이다. 내용에는 지급액과 계좌가 있고, 공개 가능한 겉표지에는 문서 ID·버전·수신 조직이 있다. 보관 운영자는 저장 파일을 바꿀 수 있으나 조직의 비밀키는 갖지 못한다고 가정한다. 같은 M을 만들고 보관하고 읽고 지급하는 과정에서, 누가 읽을 수 있는지와 누가 무엇을 바꿀 수 있는지를 끝까지 추적한다.

이 절에서는 기본도구의 정의를 다시 외우기보다 보호목표를 실제 조합과 실패 판정으로 옮긴다. 수치와 문서 반출 사례는 자체 교육 예제이며 실제 서비스의 보안성 평가나 암호모듈 인증 결과가 아니다.

먼저 되짚기: 자물쇠와 서명의 역할

키·해시·암호화·전자서명에서 암호화는 기밀성을, 메시지 인증코드는 공유키 기반 변조 탐지를, 전자서명은 대응 개인키에 의한 생성 증거를 제공한다는 점을 배웠다. 해시만으로는 비밀키 보유자나 작성자를 확인할 수 없고, 공개키의 신원은 별도로 확인해야 한다. 이제 이 도구들이 보호하는 범위와 처리 순서를 한 설계 안에서 연결한다.

1. 기본도구에서 조합 설계로

암호 조합 설계는 보호할 데이터와 위협에 맞춰 암호 연산·키·매개변수·검증 순서를 연결하고, 그 조합이 보장하지 않는 업무 조건을 따로 통제하는 설계다.

같은 “암호화” 요구라도 저장 파일 보호, 연결 중 도청 방지, 작성자 증명, 비밀번호 검증은 다른 설계가 된다. 먼저 누가 무엇을 바꿀 수 있는지를 정한다. 저장소 운영자가 파일과 해시를 함께 바꿀 수 있다면 그 해시는 독립된 기준이 아니다. 수신자도 공유키를 가진다면 유효한 메시지 인증코드만으로 두 공유자 중 누가 만들었는지 제3자가 구별할 수 없다. 이런 반례가 필요한 도구와 신뢰경계를 결정한다.

지급 문서 M으로 먼저 구별할 세 가지 질문

기밀성은 권한 없는 사람이 내용을 알아내지 못하게 하는 성질이고, 무결성은 내용이 허가 없이 바뀌었는지 판별할 수 있는 성질이다. 생성 근거의 인증은 정해진 키로 만들어진 메시지임을 확인하는 것이며, 곧바로 업무 승인이나 사람의 신원 확인과 같은 뜻이 되지는 않는다. 다음 표에서 M의 지급액은 같고 보호 수단만 바꾼다.

왜 해시와 인증코드를 구별하는가? 해시는 비밀값 없이 누구나 계산하므로, 공격자가 M과 비교값을 함께 바꿀 수 있으면 비교 기준도 바뀐다. 인증코드는 비밀키를 비교 기준에 연결하므로 이 권한 가정에서는 그런 교체를 탐지할 수 있다. 그러나 B도 공유키로 태그를 만들 수 있어 제3자에게 A만의 작성 증거가 되지는 않는다. 공개키는 누구나 검증할 수 있는 값이고, 서명 개인키는 작성자가 보호해야 하는 값이다. 공개 검증키를 M과 함께 받기만 하고 A의 키인지 확인하지 않으면 공격자의 키를 신뢰하는 문제가 남는다.

이 설명은 보호 역할의 비교이며 특정 서명 알고리즘을 구현하는 순서는 아니다. M의 비밀 내용을 숨기는 일과 작성 근거를 제공하는 일은 별도로 선택한다. 다음 두 소절에서 이를 긴 문서 보호와 AEAD 입력으로 옮긴다.

1.1 알고리즘 이름·키 길이·운영모드는 다른 선택이다

AES(Advanced Encryption Standard)는 128비트 블록을 변환하며 128·192·256비트 키를 지원하는 대칭 블록암호다. 블록은 알고리즘이 한 번에 변환하는 데이터 단위이고, 키 길이는 비밀값의 비트 수다. 따라서 AES-256이라는 이름이 파일을 256비트씩 나누거나 암호문에 매번 256비트를 덧붙인다는 뜻은 아니다. FIPS(Federal Information Processing Standards) 197의 2023년 개정은 편집 개선이며 AES 알고리즘 자체를 바꾼 개정은 아니다.[CT-C01]

운영모드는 블록암호 같은 기본 연산을 긴 메시지와 필요한 보호속성에 맞게 사용하는 규칙이다. AES만 적으면 긴 파일의 연결 방식과 변조 탐지 여부가 빠진다. GCM(Galois/Counter Mode)은 AES를 기밀성·변조 탐지를 함께 제공하는 인증된 암호화에 사용하는 운영모드다. 이 절의 계산에는 RFC(Request for Comments) 5116의 AES-256-GCM 구성을 명시한다. 키는 32바이트, 호출 구분값인 논스는 12바이트, 변조 검사값인 인증 태그는 16바이트로 고정하며 다른 구성의 길이를 이 예에 섞지 않는다.[CT-C02]

비대칭 알고리즘과 대칭 알고리즘의 키 비트 수를 그대로 비교해 더 큰 숫자가 더 안전하다고 판단하지 않는다. 서로 다른 공격 문제와 알고리즘의 보안강도, 보호기간, 검증된 구현, 상대 시스템과의 상호운용을 함께 검토해야 한다. 키가 길어도 키 노출이나 잘못된 매개변수의 문제를 해결해 주지 못한다.

2. 내용과 겉표지를 함께 검증하되 모두 숨기지는 않는다

연관데이터를 포함한 인증된 암호화(AEAD, Authenticated Encryption with Associated Data)는 평문의 기밀성과 변조 탐지를 제공하면서 암호화하지 않는 연관데이터도 함께 인증하는 구성이다. 연관데이터(AAD, Additional Authenticated Data)는 암호화하지 않지만 해당 암호문과 함께 변경 여부를 검증할 입력이다. 인증 태그는 인증된 복호화에서 입력의 일치와 위조 여부를 검사하는 값이다. 논스는 선택한 암호 구성의 호출을 구별하는 입력이며, 여기서 사용하는 GCM에서는 같은 키의 서로 다른 암호화 호출마다 중복되지 않아야 한다.[CT-C02]

교육용 문서의 내용은 평문 입력에 넣고, 공개 가능한 문서 식별자·버전·수신 조직 식별자는 형식을 고정해 AAD에 넣는다. AAD의 값도 숨겨야 한다면 별도의 평문 보호 범위에 포함해야 한다. 비밀키는 암호문 옆, AAD, 로그 어디에도 덧붙이지 않는다. 수신자는 검증된 요청과 문서의 조직·버전을 비교해야 하며, 공격자가 가져온 AAD를 그대로 검사했다는 사실만으로 업무상 올바른 문서라고 판단하지 않는다.

인증된 복호화의 결과는 검증된 평문 또는 실패다. 라이브러리가 중간 복호화 바이트를 먼저 돌려주더라도 최종 태그 검증 전에 파일로 공개하거나 업무 처리에 쓰지 않는다. 실패한 일부 문장을 “복구된 내용”으로 내보내는 경로도 만들지 않는다.[CT-C02]

M의 읽기 결과를 한 단계씩 판정하기

1. 생성자는 M의 지급액·계좌를 암호화할 평문에 넣고, 공개 가능한 문서 ID·버전·수신 조직을 AAD에 넣는다. 같은 키에서 쓰지 않은 논스를 배정하고 최종 결과를 보관한다. 내용과 겉표지의 역할을 먼저 고정했으므로 이후 값이 바뀌면 무엇을 검사할지 분명하다.
2. 수신자는 요청 권한과 키 버전·입력 형식을 확인한 뒤 인증된 복호화를 수행한다. 운영자가 암호문 또는 AAD의 조직 B를 C로 바꾸면 원래 입력에 대한 태그와 달라져 실패해야 한다. 실패 이유를 조사하되 평문은 공개하지 않는다.
3. 원래 M을 그대로 다시 보내면 암호문·태그·AAD가 모두 원래 입력이어서 검증을 다시 통과할 수 있다. 이 경우에는 태그 실패를 기대하지 않고 문서 ID·버전과 요청 ID별 지급 결과를 대조한다. 이미 반영한 요청이면 새 지급으로 실행하지 않는다.
4. 아직 반영하지 않은 정상 요청이라도 기대한 수신 조직과 서명 증거가 필요한 문서인지 확인한다. 필요한 검사가 끝난 뒤에만 지급을 반영하고 그 결과를 기록한다. 즉, 암호학적 성공에서 곧바로 지급으로 뛰어가는 경로를 두지 않는다.

이 순서를 읽을 때 “태그 실패”와 “정상 재전송의 업무 거부”를 같은 실패라고 쓰지 않는다. 앞의 것은 보호 입력을 인증할 수 없다는 결과이고, 뒤의 것은 인증된 입력의 실행 허용 조건이 충족되지 않았다는 결과다.

문서 전달의 네 경계

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

내용·공개 문맥과 보호된 키·논스가 각각 AEAD의 입력이다. 결과에는 비밀키를 붙이지 않는다.

문서 검증과 지급 허용의 다른 경계 · 상태 따라가기

복호화 구성의 인증·형식 검사를 먼저 수행한다. 모든 단계에서 암호문·평문·검사·업무 허용의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

암호 검증 실패는 평문 미공개로 끝난다. 성공한 뒤에도 문맥·재처리 상태와 필요한 작성자 증거를 확인한다. 앞단의 인가·형식 확인이 성공한 경로만 그렸다.

이 예의 조건

• 암호 검증 실패는 평문 미공개로 끝난다. 성공한 뒤에도 문맥·재처리 상태와 필요한 작성자 증거를 확인한다. 앞단의 인가·형식 확인이 성공한 경로만 그렸다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상요청 권한 확인	원 설명수신 요청의 인가
대상입력·키 버전 확인	원 설명복호화 입력을 확정
대상태그 검증	원 설명통과 / 실패
대상공개·업무처리 중단	원 설명검증 실패의 종료
대상문맥·중복 확인	원 설명조직·버전·반영 상태
대상작성자 근거	원 설명검증키·대상 확인
대상업무 반영	원 설명허용된 지급 결과를 기록

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결요청 권한 확인 → 입력·키 버전 확인	원 라벨·방향인가 / 정방향 / 실선
연결입력·키 버전 확인 → 태그 검증	원 라벨·방향입력 / 정방향 / 실선
연결태그 검증 → 공개·업무처리 중단	원 라벨·방향실패 / 정방향 / 실선
연결태그 검증 → 문맥·중복 확인	원 라벨·방향성공 / 정방향 / 실선
연결문맥·중복 확인 → 작성자 근거	원 라벨·방향문맥 / 정방향 / 실선
연결작성자 근거 → 업무 반영	원 라벨·방향증거 / 정방향 / 실선

원그림의 경계

경계	포함 대상
경계수신자: 공개 전 검사	포함 대상요청 권한 확인, 입력·키 버전 확인, 태그 검증, 공개·업무처리 중단
경계업무 허용: 검증 성공 이후	포함 대상문맥·중복 확인, 작성자 근거, 업무 반영

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
태그 검사 복호화 구성의 인증·형식 검사를 먼저 수행한다.	값·보충 정보 암호문·평문: 검사 중·사용 보류 검사·업무 허용: 태그 확인	변화·이유 평문이 계산됐다고 바로 외부에 노출하지 않는다.
태그 실패 검사에 실패한 데이터는 쓰거나 제공하지 않는다.	값·보충 정보 암호문·평문: 평문 미제공 검사·업무 허용: 실패·거부	변화·이유 실패 경계를 정상 데이터 경로로 잇지 않는다.
별도 통과 대안의 문맥 검사 태그 판정 시작점으로 재설정하여 검증을 통과한 대안에서만 문맥·재전송·중복을 대조한다.	값·보충 정보 암호문·평문: 태그 검증 통과 평문 검사·업무 허용: 문맥·중복 검사	변화·이유 태그 실패 종료의 후속이 아니며 무결성 통과와 업무 권한을 별도로 확인한다.
출처·허용 확인 송신자 근거와 현재 허용 조건이 맞아야 업무에 사용한다.	값·보충 정보 암호문·평문: 허용된 평문 사용 검사·업무 허용: 출처·행위 허용	변화·이유 수신자 키와 암호화만으로 송신자·업무 허용을 보장하지 않는다.

문서 검증과 지급 허용의 다른 경계 · 상태 따라가기

복호화 구성의 인증·형식 검사를 먼저 수행한다. 모든 단계에서 암호문·평문·검사·업무 허용의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

암호 검증 실패는 평문 미공개로 끝난다. 성공한 뒤에도 문맥·재처리 상태와 필요한 작성자 증거를 확인한다. 앞단의 인가·형식 확인이 성공한 경로만 그렸다.

이 예의 조건

• 암호 검증 실패는 평문 미공개로 끝난다. 성공한 뒤에도 문맥·재처리 상태와 필요한 작성자 증거를 확인한다. 앞단의 인가·형식 확인이 성공한 경로만 그렸다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상요청 권한 확인	원 설명수신 요청의 인가
대상입력·키 버전 확인	원 설명복호화 입력을 확정
대상태그 검증	원 설명통과 / 실패
대상공개·업무처리 중단	원 설명검증 실패의 종료
대상문맥·중복 확인	원 설명조직·버전·반영 상태
대상작성자 근거	원 설명검증키·대상 확인
대상업무 반영	원 설명허용된 지급 결과를 기록

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결요청 권한 확인 → 입력·키 버전 확인	원 라벨·방향인가 / 정방향 / 실선
연결입력·키 버전 확인 → 태그 검증	원 라벨·방향입력 / 정방향 / 실선
연결태그 검증 → 공개·업무처리 중단	원 라벨·방향실패 / 정방향 / 실선
연결태그 검증 → 문맥·중복 확인	원 라벨·방향성공 / 정방향 / 실선
연결문맥·중복 확인 → 작성자 근거	원 라벨·방향문맥 / 정방향 / 실선
연결작성자 근거 → 업무 반영	원 라벨·방향증거 / 정방향 / 실선

원그림의 경계

경계	포함 대상
경계수신자: 공개 전 검사	포함 대상요청 권한 확인, 입력·키 버전 확인, 태그 검증, 공개·업무처리 중단
경계업무 허용: 검증 성공 이후	포함 대상문맥·중복 확인, 작성자 근거, 업무 반영

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
태그 검사 복호화 구성의 인증·형식 검사를 먼저 수행한다.	값·보충 정보 암호문·평문: 검사 중·사용 보류 검사·업무 허용: 태그 확인	변화·이유 평문이 계산됐다고 바로 외부에 노출하지 않는다.
태그 실패 검사에 실패한 데이터는 쓰거나 제공하지 않는다.	값·보충 정보 암호문·평문: 평문 미제공 검사·업무 허용: 실패·거부	변화·이유 실패 경계를 정상 데이터 경로로 잇지 않는다.
별도 통과 대안의 문맥 검사 태그 판정 시작점으로 재설정하여 검증을 통과한 대안에서만 문맥·재전송·중복을 대조한다.	값·보충 정보 암호문·평문: 태그 검증 통과 평문 검사·업무 허용: 문맥·중복 검사	변화·이유 태그 실패 종료의 후속이 아니며 무결성 통과와 업무 권한을 별도로 확인한다.
출처·허용 확인 송신자 근거와 현재 허용 조건이 맞아야 업무에 사용한다.	값·보충 정보 암호문·평문: 허용된 평문 사용 검사·업무 허용: 출처·행위 허용	변화·이유 수신자 키와 암호화만으로 송신자·업무 허용을 보장하지 않는다.

화살표는 교육 사례의 처리 순서이며 새로운 암호 프로토콜의 규격이 아니다. 원문을 인증하기 위한 검증과 업무 반영을 허용하는 판단은 별개다. 통신 구간은 TCP·UDP·DNS·HTTP·TLS 프로토콜 분석의 TLS(Transport Layer Security) 보호채널을 사용하지만, 서버가 복호화한 뒤 저장하는 문서나 탈취된 정상 계정의 요청까지 TLS가 대신 통제하지 않는다.

3. 논스 중복은 “확률이 낮을 것 같다”로 넘기지 않는다

다음은 실제 GCM 논스 바이트가 아닌 호출 장부를 설명하는 작은 모형이다. 동일 키 K1을 쓰는 서버 A와 B가 각자 번호를 0부터 매기면 A의 0과 B의 0은 충돌한다. 서버 식별값과 증가 번호를 합쳐도 A가 재시작하면서 번호를 되돌리면 같은 K1 아래의 A-0을 다시 쓰게 된다. GCM의 논스 재사용은 기밀성과 인증을 훼손할 수 있다.[CT-C02]

설계안은 키별 고정 길이 논스 형식, 서버 식별값의 중복 없는 배정, 증가 번호의 영속 예약을 갖춘 검증된 구성으로 정한다. “다음 번호를 저장한 후 사용”하거나 미리 예약한 범위를 사용하고, 재시작 때 미사용 여부가 불확실한 범위는 건너뛴다. 키의 이름만 K2로 바꾸고 실제 키 바이트는 그대로 두면 다른 범위가 아니다. 번호 소진·식별값 충돌·장부 유실 때에는 신규 암호화를 중단하고 정상적인 새 키와 상태를 준비한다. 이 작은 장부는 전체 사용량 한도나 암호 보안성을 증명하지 않는다.

4. 직접 계산: 저장량과 보안 판정의 분모

자체 예제 CT-L1은 내용이 각각 1,024바이트인 문서 1,000개를 앞의 AES-256-GCM 구성으로 저장한다. 문서마다 논스와 태그를 보존하고, 다른 헤더·AAD 저장량·키 포장값·서명·인코딩 증가는 계산에서 제외한다. 한 바이트는 8비트다. GCM의 암호문 본체는 이 예에서 평문과 같은 길이이고 16바이트 태그가 더해진다.[CT-C02]

문서당 보존량은 1,024+12+16=1,052바이트이고, 전체는 1,052×1,000=1,052,000바이트다. 추가량은 (12+16)×1,000=28,000바이트이며 평문 대비 증가는 28/1,024×100≈2.734375%다. 32바이트 비밀키를 문서마다 함께 저장하는 계산은 하지 않는다. 이 수치는 명시한 필드만의 용량 계산이지 전체 서비스 저장량이나 “보안 향상률”이 아니다.

AAD의 조직번호를 바꾼 복호화, 태그를 바꾼 복호화, 다른 키 버전을 사용한 복호화는 각각 실패시켜야 한다. 정상 암호문을 그대로 두 번 제출하는 경우에는 둘 다 암호학적 검증을 통과할 수 있으므로 업무의 중복 처리 방지 상태가 따로 필요하다. 태그 통과율을 정상 업무 허용률로 세면 분모가 달라진다.

5. 무엇을 누구에게 증명해야 하는가

공개키 암호화, 키 합의, 전자서명은 같은 연산의 이름 바꾸기가 아니다. 수신자의 공개키로 키를 보호하는 구성은 수신자 개인키로 이를 열게 하는 것이고, 인증된 키 합의는 상대 확인과 함께 공유 비밀을 설정한다. 서명은 선택한 서명 알고리즘으로 메시지를 검증 가능하게 만드는 것이며, 모든 서명을 “해시를 개인키로 암호화”한다고 구현해서는 안 된다. 서명할 정확한 바이트와 의미를 고정해야 버전·수신처가 바뀐 문서에 옛 서명을 붙이는 혼동을 막을 수 있다.

인증된 키 설정과 프로토콜 협상은 검토된 프로토콜에 맡긴다. 서비스가 임의로 암호화·서명 순서를 조합하는 새 프로토콜을 만들지 않는다. 기존 암호 기본도구 비교와 TLS의 인증 경계를 이 요구에 적용하는 것이 핵심이다.

6. 실제 설계 산출물: 문서 보관·전달 정책 CT-P1

가상 서비스는 조직별 문서를 보관하며 인가된 수신자에게만 내용을 내보낸다. 저장소 운영자는 암호문을 교체할 수 있지만 키 관리자의 연산 권한은 가지지 않는다고 가정한다. 애플리케이션 자체와 키 관리 서비스가 함께 침해된 경우까지 이 저장 암호화만으로 막는다고 주장하지 않는다.

선택하지 않은 대안도 명시한다. 해시를 파일과 같은 저장소에 두는 방법만으로 악의적 교체를 방어하지 않는다. 공유키 인증을 제3자용 작성자 증명으로 쓰지 않는다. 통신 암호화만 하고 평문 저장을 방치하지 않는다. 반대로 모든 문서에 별도 서명을 덧붙이면 서명키·신원·보존 관리가 늘어나므로 실제 증명 요구가 있는 문서에 한정한다.

출시 전에는 정상 읽기뿐 아니라 내용 변경, AAD 변경, 잘못된 키, 재전송, 재시작 후 논스 상태 유실을 각각 시험한다. 한 실패라도 평문 공개나 중복 업무 반영으로 이어지면 출시하지 않는다. 통과한 시험의 범위·키 버전·정책 버전을 기록하되 이를 모든 공격에 대한 안전 증명으로 확대하지 않는다.

실패가 나타나는 위치를 구별한다

태그 실패는 입력·키·논스·문맥 불일치를 조사할 신호이지 공격자 신원을 자동으로 특정하는 증거가 아니다. 운영상 잘못된 키 버전을 읽어도 실패할 수 있다. 반대로 태그 성공은 그 키에 대한 정합성 근거일 뿐 현재 요청 권한, 새 문서 여부, 작성자의 법적 의사까지 확인한 결과가 아니다.

검증 실패를 해결하려고 태그 검사를 끄거나 이전의 노출된 키로 되돌리지 않는다. 정상적인 키 교체 뒤 옛 문서를 읽는 절차와 노출 사고의 복구 절차는 다음 절에서 나눈다. 장기 보호와 알고리즘 변경은 키·자료의 의존관계까지 함께 검토해야 한다.

이 절이 담당하는 보안기술 범위

이 절은 보호목표에 맞는 암호 조합을 선택하고 검증 실패의 중단 조건을 정한다. 대상은 문서 내용·공개 문맥·키와 요청 상태다. 경계는 암호학적 검증과 업무 인가·중복 처리 방지의 구별이다. 실패 판단은 태그 오류·논스 중복·키 노출·재전송을 서로 다른 검사로 식별하는 것이다. 인증서 발급 운영·전체 인증 프로토콜·법적 부인방지 승인은 여기서 완료하지 않는다.

아래 두 문제는 이 보안기술 범위를 직접 연습한다. 인증서·접근통제의 상세 적용은 다음 두 절에서 이어지며, 이 장의 예제만으로 공식 출제범위 전체를 다뤘다고 판단하지 않는다.

개념을 답안으로 옮기기: 저장량 계산은 포함한 필드·단위·제외 비용을 먼저 쓰고, 문서 전달의 네 경계는 태그 검증·문맥 대조·업무 반영을 따로 설명한다. 설계 문제에서는 문서 보관·전달 정책의 결정마다 담당·남길 증거·실패 시 중단 조건을 붙인다.

7. 자체 10점 문제: 보호속성과 계산

CT-L1에서 AES-256-GCM으로 문서 1,000개를 저장할 때 보존량을 계산하고, AAD 변경과 정상 암호문 재전송을 같은 검사로 처리할 수 없는 이유를 설명하라.

“계산”은 포함한 필드와 단위를 먼저 적으라는 요구다. “이유”는 태그가 확인하는 범위와 업무 상태의 범위를 분리하라는 요구다. 실제 기출이나 공식 채점 기준이 아닌 자체 교육 문제다.

답안을 열기 전에: 문서당 보존 필드와 전체 계산을 직접 적고, “AAD 변경”과 “정상 재전송”의 실패 판정을 각각 한 문장으로 설명한다. 막히면 계산과 반례로 돌아간다.

10점 문제의 풀이 방향과 완성 답안 보기

논점을 목차로 만들기

1. 보호 구성과 제외한 비용
2. 문서당·전체 보존량
3. AAD 검증과 평문 공개
4. 재전송과 업무 상태

계산을 먼저 끝내고 실패 조건을 연결하면 키 길이와 저장량을 혼동하지 않는다.

답안 도식

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

위 줄은 명시한 필드만의 용량 계산이다. 중간 줄의 AAD 변경은 암호 검증에 실패하고, 아래 줄의 정상 재전송은 업무 상태를 별도로 검사한다.

완성 답안 예시

CT-L1은 내용 1,024바이트, 논스 12바이트, 태그 16바이트를 문서별로 보존하는 AES-256-GCM 구성이다. 다른 헤더·AAD 저장량·키 포장·서명·인코딩 비용은 제외하며, 32바이트 비밀키를 문서에 함께 붙이지 않는다.

문서당 보존량은 1,024+12+16=1,052바이트, 문서 1,000개의 전체 보존량은 1,052,000바이트다. 평문 전체 1,024,000바이트와의 차이는 28,000바이트이며 이는 포함한 필드만의 추가량이다.

AAD는 숨겨지지 않지만 암호문과 함께 검증된다. 조직이나 버전의 AAD가 바뀌면 인증된 복호화가 실패해야 하며 최종 태그 검증 전에는 평문을 공개하지 않는다. 검증한 문맥도 실제 요청의 기대한 문맥과 대조한다.

정상 암호문의 재전송은 내용·태그·AAD가 그대로이므로 암호 검증을 다시 통과할 수 있다. 따라서 요청 식별자와 반영 상태를 별도로 관리해 같은 업무를 두 번 실행하지 않는다. 암호학적 정합성과 업무 실행의 허용은 서로 다른 판정이다.

8. 자체 25점 문제: 저장소 교체와 키 사고까지 설계

저장소 운영자가 암호문과 겉표지를 바꿀 수 있는 조직별 문서 서비스에 CT-P1을 적용하라. 보호 범위, 키·논스 운영, 읽기·업무 반영, 작성자 증거, 거부한 대안, 검증·중단 조건을 포함한 설계안을 작성하라.

제품명 나열이 아니라 앞에서 결정한 필드와 담당·처리 순서를 써야 한다. 저장소만 침해되는 가정과 애플리케이션·키 서비스까지 함께 침해되는 가정을 혼동하지 않는다.

이 25점 문제도 실제 기출이나 공식 채점 기준이 아닌 자체 교육 문제다.

답안을 열기 전에: 저장소 운영자의 권한을 가정에 적고, 보호 필드·키와 논스·읽기·업무 반영·작성자 증거·중단 조건을 자신의 설계로 연결한다. 근거가 빠진 항목은 정책 CT-P1과 실패 경계에서 확인한다.

25점 문제의 풀이 방향과 완성 설계 답안 보기

여섯 개의 설계 결과로 전개하기

1. 위협 가정과 보호할 필드
2. 키·논스 운영 책임
3. 읽기와 중복 반영 통제
4. 작성자 증명 범위
5. 대안 선택의 이유
6. 시험과 비상 중단

각 항목은 “수립한다”가 아니라 실제로 무엇을 허용·거부하는지까지 쓴다.

설계 답안의 구조

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

문서·키·서비스·업무 담당은 서로 다른 근거를 관리한다. 검증된 보관·전달에 네 근거가 함께 필요하며, 실패 시에는 중단하고 영향 목록을 남긴다. 최종 암호 검증과 요청별 업무 상태를 하나의 검사로 합치지 않는다.

완성 설계 답안 예시

CT-P1은 저장소 운영자가 파일을 교체할 수 있으나 키 연산 권한은 없다는 가정에서 문서 내용은 AEAD로 숨기고, 공개 가능한 문서 ID·버전·조직 식별자는 고정 형식의 AAD로 연결한다. 공개하면 안 되는 속성은 AAD에 그대로 두지 않고 암호화 대상에 넣는다. 서비스와 키 관리가 함께 침해되는 위험은 별도 통제로 남긴다.

키 관리자는 용도와 버전별 키 연산 권한을 분리한다. 동일 키의 논스는 서버 식별값과 영속적으로 예약한 증가 번호로 중복을 방지하며, 재시작 뒤 예약 여부를 모르는 번호는 사용하지 않는다. 식별값 충돌·번호 소진·장부 유실 때에는 새 암호문 생성을 중단하고 안전한 상태를 준비한다.

서비스는 요청 권한과 입력 형식을 확인한 뒤 복호화하며, 최종 태그 검증이 끝나기 전 평문을 공개하지 않는다. 검증된 문서의 조직·버전을 요청과 대조하고, 업무 담당자는 요청 ID별 반영 상태를 보존해 정상 재전송이 중복 업무로 이어지지 않게 한다.

제3자에게 작성자 증거가 필요한 문서에는 승인된 서명 형식과 신원에 연결된 검증키를 추가한다. 문서 버전과 수신 문맥을 서명 대상에 명확히 묶고 검증 결과를 보존한다. 서명 성공만으로 작성자의 법적 의사나 모든 시점의 유효성을 확정하지 않는다.

파일과 같은 위치의 해시만으로 악의적 교체를 막는 대안, 공유키 인증으로 두 공유자의 작성자를 구분하는 대안, 통신만 암호화하고 평문을 저장하는 대안은 기각한다. 별도 서명은 증명 요구가 있는 문서에 적용해 불필요한 서명키 운영 부담을 피한다.

정상 읽기와 함께 내용·AAD·키 변경, 정상 재전송, 재시작 후 논스 유실을 각각 시험하고 결과에 키·정책 버전을 연결한다. 태그 실패가 평문 공개로 이어지거나 재전송이 중복 반영되면 출시를 중단한다. 키 노출·논스 중복이 발견되면 신규 생성부터 멈추고 영향 문서·백업을 식별해 새 키 전환과 재시험을 수행한다.

9. 스스로 틀린 답안을 고치기

조건을 바꿔 다시 풀기

문서가 2,000개면? 같은 구성에서 전체는 2,104,000바이트, 추가량은 56,000바이트다. 문서당 추가 비율은 그대로다. 계산에서 문서 수만 바꿔 확인한다.

키 이름만 K2로 바꾸면? 실제 키가 K1과 같으면 N5도 새로운 범위가 아니므로 A-0 재사용을 거부한다. 논스 장부의 범위는 표시 이름이 아니라 실제 키다.

고객 조직번호 자체가 민감정보라면? AAD는 숨겨지지 않으므로 공개 가능한 대체 식별자를 설계하거나 그 속성을 암호화 대상에 넣는다. 필드 정책을 바꾸고 수신측의 문맥 대조도 다시 시험한다.

독립 확인: 분모와 공개 범위를 바꾸면

앞의 답안을 닫고 다음 자체 연습을 푼다. 조직 B는 같은 AES-256-GCM 구성으로 2,048바이트 문서 500개를 저장한다. 논스 12바이트와 태그 16바이트만 포함하고 나머지 비용은 제외한다. 수신 조직번호는 이제 비밀정보다. 원래 문서의 첫 지급은 끝났고 공격자는 그 암호문을 다시 제출한다. 전체 보존량을 계산하고, 조직번호의 보호 위치와 재전송의 처리 결과를 각각 이유와 함께 쓴다.

조건 변경 연습의 완전한 답안과 교정 보기

문서당 보존량은 2,048+12+16=2,076바이트이고 전체는 2,076×500=1,038,000바이트다. 포함한 추가량은 28×500=14,000바이트이며, 평문 전체 1,024,000바이트와 비교한다. 키 길이를 문서마다 더하거나 조직번호 저장 비용을 몰래 포함하면 문제의 분모를 바꾸므로 먼저 제외 조건으로 돌아가야 한다.

조직번호가 비밀정보라는 새 조건에서는 그대로 AAD에 넣을 수 없다. 비밀 속성은 암호화할 평문 범위로 옮기거나 공개 가능한 대체 식별자를 별도로 설계하고, 검증 뒤에도 요청의 기대한 문맥과 대조한다. “AAD에 넣으면 인증되니 숨겨진다”는 답은 인증과 은닉을 혼동한 것이다.

정상 암호문은 다시 태그 검증을 통과할 수 있으나 요청 ID의 첫 지급 결과가 이미 반영됐으므로 새 지급으로 실행하지 않는다. “재전송이니 태그가 실패한다”는 답은 새로운 암호화 호출과 같은 입력의 재검증을 혼동한 것이다. 같은 키에서 새 암호화를 할 때의 논스 중복 금지와 업무 재실행 통제는 서로 다른 상태를 관리한다.

근거와 적용 한계

CT-C01: NIST FIPS 197, 2023-05-09 편집 개정의 Abstract·Planning Note에서 AES 블록/키 길이와 개정 범위를 확인했다. CT-C02: RFC 5116 §§1.2, 2.1–2.2, 3.1–3.2, 5.1–5.2에서 AEAD 인터페이스·논스·선택한 GCM 매개변수와 범위를 확인했다. 관찰일은 2026-09-18이며 원문 발행일과 구별한다.

표·도식·CT-L1·CT-P1과 두 답안은 자체 작성이다. 원문 그림을 복사·추적하지 않았다. 작은 장부와 용량 산술은 암호모듈 인증이나 전체 프로토콜 안전성 증명이 아니며 독립 기술·권리 검토는 남아 있다. 기본도구의 정식 정의는 키·해시·암호화·전자서명, TLS·서비스 신원은 TCP·UDP·DNS·HTTP·TLS 프로토콜 분석에서 확인한다.

2026-10-04에 위 두 공식 원문을 다시 대조했다. FIPS 197의 원문 발행은 2001-11-26, 편집 개정은 2023-05-09이며 RFC 5116은 2008년 1월 문서다. 앞의 2026-09-18은 기존 작성 기록의 관찰일로, 이번 확인일이나 발행일로 바꾸지 않는다. 이번 확인은 명시한 표준 인터페이스·선택 구성의 범위이며 특정 구현의 인증이나 현장 시험을 뜻하지 않는다.

2026-10-05 확인에서는 NIST SP 800-38D 공식 페이지도 함께 대조했다. 이 문서는 2007년 11월의 최종 GCM 권고이고 공식 페이지에는 2024-03-06 개정 계획이 표시된다. 여기서 쓰는 RFC 5116 AES-256-GCM의 12바이트 논스·16바이트 태그 조건을 다른 태그 길이의 일반 권장으로 확대하지 않는다. FIPS 197과 RFC 5116의 역할·입력·실패 의미를 다시 확인한 것이며, 미래 개정 내용이나 특정 제품의 안전성을 확인했다는 뜻은 아니다.

회독 때 붙잡을 결론

보호목표에서 알고리즘·키·모드·검증 순서를 결정한다. AEAD의 내용 보호와 AAD 인증을 구분하고, 같은 키의 논스 중복을 막으며 최종 검증 전에 평문을 사용하지 않는다. 인증된 내용이라도 올바른 상대·업무 권한·새 요청인지는 별도로 판단한다. 다음 절에서는 이 조합에 필요한 공개키 신뢰와 키 교체·복구를 운영 절차로 연결한다.

책을 덮고 확인하기: AAD에 넣을 수 없는 정보, 같은 키의 논스 중복을 막는 상태, 태그 성공 뒤에도 필요한 업무 판정을 각각 설명한다. 답이 짧거나 섞였으면 내용과 겉표지, 논스 장부, 실패 경계로 돌아가 한 문장씩 다시 쓴다.

조건을 바꾸어 연습하기: 바이트·논스 상태·업무 반영을 따로 확인한다.

다음은 앞의 구성에 적용할 입력과 상태를 명시한 별도 사례다. 작은 장부나 순서 모형은 암호 알고리즘을 직접 만드는 방법도, 실제 시스템의 안전성 증명도 아니다.

1. CT-U. 문서마다 문자열 가A를 100회 반복한 내용을 UTF-8로 저장한다. 여기서 가는 U+AC00 한 글자이며 분해된 자모로 바꾸지 않는다. 같은 RFC 5116 AES-256-GCM 구성의 논스 12바이트·태그 16바이트와, 이미 고정 형식으로 인코딩된 공개 AAD 40바이트를 각각 한 번씩 보존한다. 문서는 200개이고 다른 헤더·키 포장·서명·압축·문자 인코딩 외의 변환은 제외한다. 평문 바이트 수, 문서당·전체 보존량, 평문 대비 추가 비율을 구하라. 문자 수를 평문 바이트 수로 쓰거나 32바이트 비밀키까지 문서마다 더해도 되는가? AAD 40바이트는 이 계산에서 암호화된 내용인가?
2. CT-N. 호출 장부의 키 이름 K-old와 K-alias는 실제로 같은 키 A를 가리킨다. K-new는 독립적으로 새로 생성한 다른 키 B다. 논스 형식은 중복 없이 배정한 서버 식별값 4바이트와 증가 번호 8바이트를 이어 붙인 12바이트로 고정하며 번호는 같은 바이트 순서를 사용한다. E1은 (키 A, 서버 1, 번호 7)로 이미 암호화했다. E2=(K-alias, 서버 1, 번호 7), E3=(K-old, 서버 2, 번호 7), E4=(K-new, 서버 1, 번호 7)을 비교하라. 어느 것이 E1과 같은 키·논스인가? 또 서버 1이 키 A 아래에서 8~15를 미리 예약한 뒤 재시작하여 그 범위의 사용 여부를 알 수 없게 됐다. 다른 사용자는 그 범위를 배정받지 않았고 예약 경계 16은 영속적으로 확인할 수 있다고 가정한다. 다음 번호를 8로 되돌리는 안과 16부터 쓰기 전에 다음 예약 경계를 영속 저장하는 안을 비교하라. 예약 경계 자체도 확인할 수 없다면 어떻게 해야 하는가?
3. CT-P. 요청 R17은 한 번만 100단위를 반영해야 한다. 동일한 정상 암호문 두 개의 태그·문맥·요청 권한 검사는 모두 통과했다고 가정한다. 작업 T1과 T2가 각각 ‘미반영’을 읽은 뒤 T1이 100단위를 반영하고, T2도 100단위를 반영한 다음 각자 완료 상태를 썼다. 합계와 오류 원인을 구하라. 업무 효과와 요청 상태가 같은 데이터베이스 안에서 함께 확정될 수 있는 사례에서는 어떤 동시성 조건이 필요한가? 다른 사례에서 외부 지급 호출 뒤 시간 초과가 발생해 외부의 반영 여부를 아직 모른다면, 실패로 단정하고 새 요청 ID로 다시 지급해도 되는가?

문자와 바이트·논스 예약·동시 재전송 풀이

1. CT-U — 암호 입력의 길이는 인코딩한 바이트로 센다. UTF-8에서 주어진 가는 3바이트, A는 1바이트이므로 평문은 (3+1)×100=400바이트다. 문자 200개와 바이트 400개를 구별한다. 문서당 보존량은 400+12+16+40=468바이트이고 전체는 468×200=93,600바이트다. 평문 전체 80,000바이트에 비해 추가량은 13,600바이트이며 비율은 68/400×100=17%다. 앞의 CT-L1과 달리 이 문제는 AAD 저장량도 포함한다고 명시했다.

비밀키 32바이트는 문서에 붙이지 않는다. 공개 AAD는 인증 입력이지만 암호화된 내용이 아니며, 포함된 저장량과 은닉 여부는 다른 질문이다. 실제 포맷의 헤더·서명·인코딩 변환 등이 생기면 해당 비용을 추가로 정해야 한다. 이 계산은 주어진 필드의 용량이며 보호 수준이 17% 향상되었다는 뜻이 아니다.

2. CT-N — 중복 범위는 키의 이름이 아닌 실제 값에 연결된다. E2는 E1과 실제 키 A·서버 1·번호 7이 모두 같으므로 새 암호화에 사용하면 안 된다. E3은 서버 식별값이 달라 논스 바이트가 다르다. E4는 실제 키가 독립적인 B라는 조건에서 키 A의 중복 범위와 다르다. 이름만 새로 붙인 K-alias를 새 키로 취급하거나, 서버 번호가 달라도 실제 식별 바이트를 같게 배정하면 이 구별이 무너진다.

8~15는 사용 여부가 불확실하므로 재사용하지 않는다. 확인된 예약 경계 16부터의 새 범위를 사용하려면 다음 경계를 먼저 영속 예약하여 또 재시작해도 이미 사용했을 가능성이 있는 번호로 돌아가지 않게 한다. 예약 상태 자체를 잃으면 ‘아마 안 썼을 것’이라며 새 암호화를 계속하지 않고 중단하여 정상적인 키·논스 상태를 준비한다. 이는 공급한 장부 조건의 중복 판단이며 구성의 전체 사용량 한도나 구현의 원자적 예약까지 검증한 것은 아니다. 같은 논스로 기존 암호문을 다시 복호화하는 일과 논스를 재사용하여 새로 암호화하는 일도 다르다. RFC 5116 §§3.1–3.2, 5.1.1

3. CT-P — 확인과 반영 사이에 다른 작업이 끼어들 수 있다. 합계는 200단위이며 필요한 100단위를 초과한다. 두 태그가 정상이어도 두 작업이 모두 같은 이전 상태를 읽으면 단순한 ‘미반영 확인 → 지급 → 완료 기록’ 순서만으로 중복 실행을 막지 못한다.

같은 데이터베이스 안에서 업무 효과와 상태를 함께 확정할 수 있다는 조건에서는 같은 요청 ID에 대해 하나의 작업만 반영 권한을 얻도록 원자적 경쟁 판정과 유일성을 보장하고, 업무 효과·완료 상태를 함께 커밋하거나 함께 취소한다. 이미 완료된 재전송은 저장된 결과를 반환하며, 처리 중인 요청에 새 반영 권한을 주지 않는다. ID가 같지만 지급 대상·금액 등 의미가 다른 요청도 기존 결과로 덮어 처리하지 않고 거부·조사한다. 트랜잭션으로 묶는 것만으로 충분하다고 하지 말고, 같은 ID의 동시 작업을 실제로 배제하는 조건까지 확인한다.

외부 지급의 시간 초과는 결과를 아직 모른다는 뜻이다. 기존 요청 ID와 관련 상태를 보존하여 외부 결과를 대조하고, 외부 서비스가 제공하는 중복 방지·상태 조회 계약 안에서 복구한다. 새 ID로 다시 지급하면 첫 호출이 성공한 경우 중복 효과를 만들 수 있다. 로컬 데이터베이스의 완료 기록만으로 외부 효과까지 원자적으로 묶였다고 가정하지 않는다. 암호 검증·업무 상태·외부 결과는 각각의 경계에서 확인한다.