키·해시·암호화·전자서명

자물쇠 하나로 비밀·변조·신원을 모두 해결할 수 없다

메시지를 남이 읽지 못하게 만드는 것과 메시지가 바뀌지 않았음을 확인하는 것은 다른 문제다. 같은 비밀번호인지 확인하고 싶은 경우와 특정 사람이 문서에 동의했음을 입증하려는 경우도 필요한 도구가 다르다. 암호기술은 비트열에 수학적 변환을 적용하지만, 어떤 기본도구를 어떤 키와 절차로 조합하느냐에 따라 얻는 보안속성이 달라진다. 알고리즘이 강해도 키가 노출되거나 잘못 재사용되면 보호는 무너진다.

먼저 되짚기: 비트열과 보호목표

비트는 두 상태로 구분한 정보의 최소 단위이고 파일과 메시지는 비트열로 표현된다. 기밀성은 허가되지 않은 공개를, 무결성은 허가되지 않은 변경을 막으며 인증은 주체의 신원 주장을 확인한다. 책임추적성은 행위와 결과를 주체·시간·근거에 연결한다.

키·해시·암호화·전자서명

암호 기본도구는 키, 암호학적 해시함수, 암호화, 메시지 인증코드와 전자서명처럼 더 큰 보안체계를 만드는 기본 연산이다. 키는 암호 연산의 결과를 통제하는 비밀값 또는 공개·개인 값의 쌍이다. 같은 알고리즘을 사용해도 키가 다르면 암호문이나 서명이 달라진다.

암호학적 해시함수는 길이가 임의인 입력을 고정 길이의 해시값으로 바꾸는 키 없는 함수다. 해시값에서 원래 입력을 찾기 어렵고, 같은 해시값을 만드는 서로 다른 두 입력을 찾기 어려워야 한다. 해시는 입력의 작은 변화도 다른 요약값으로 드러내 무결성 확인의 재료가 되지만 입력을 숨기지는 않는다.

대칭키 암호화는 송신자와 수신자가 공유한 같은 비밀키로 암호화와 복호화를 수행한다. 공개키 암호화는 공개해도 되는 공개키와 소유자만 보관할 개인키의 쌍을 사용한다. 암호화의 직접 목표는 평문을 권한 없는 사람이 읽지 못하게 하는 기밀성이다. 변조 탐지까지 필요하면 인증된 암호화 방식이나 별도의 메시지 인증을 사용해야 한다.

메시지 인증코드(message authentication code, MAC)는 공유 비밀키와 메시지로 검사값을 만들어 키를 아는 주체가 만든 메시지인지와 변조 여부를 확인한다. 여기서 MAC은 접근통제 모델의 강제적 접근통제(Mandatory Access Control)를 뜻하지 않는다. 전자서명은 개인키로 메시지의 해시값에 서명값을 만들고 대응하는 공개키로 검증하는 방식이다. 서명은 메시지 무결성과 개인키 소유에 대한 인증 증거를 제공하지만, 법적 부인방지까지 성립하려면 공개키와 사람의 신원 연결, 키 보관, 시각과 검증기록이 함께 신뢰되어야 한다.

문서를 비밀로 보내고 출처와 변조도 확인하기

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

검토된 봉투형 구성의 역할 모형이다. 무작위 세션키로 원문을 인증된 암호화 방식으로 암호화하고, 검증된 수신자 공개키로 세션키를 보호하거나 안전한 키 합의를 사용한다. 수신자 개인키는 전달하지 않는다. 검사 실패 데이터는 사용하지 않으며, 검사 통과 뒤에도 송신자 신원·서명 확인을 별도로 수행한다. 논스 조건과 실패처리는 선택한 검증된 구성의 규칙을 따른다.

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

원문 해시로 송신자 개인키의 서명값을 만들고, 수신자는 신원이 확인된 송신자 공개키로 서명과 수신 원문의 해시를 대조한다. 원문 대조선은 검증 대상의 관계이며 평문 전송을 지시하지 않는다. 신원이나 서명 확인 실패는 신뢰·사용 거부다. 검증 성공은 기밀성이나 법적 부인방지를 자동 보장하지 않는다.

큰 데이터는 빠른 대칭키 방식으로 암호화하고, 그때만 쓰는 세션키를 공개키 방식으로 보호하거나 키 합의 절차로 공유하는 혼합 구성이 흔하다. 수신자는 자신의 개인키 없이는 세션키를 얻을 수 없고, 인증된 암호문의 검사에 실패하면 변조된 데이터를 사용하지 않는다. 서명검증은 서명된 원문이 바뀌지 않았고 대응 개인키로 만들어졌다는 증거를 주지만, 그 공개키가 실제 송신자의 것인지 인증서나 신뢰할 수 있는 등록정보로 별도로 확인해야 한다.

솔트(salt)는 비밀번호별로 생성해 검증값과 함께 저장하는 임의값이다. 비밀번호 저장은 복호화가 필요한 암호화와 목적이 다르다. 비밀번호마다 임의의 솔트를 붙이고 비밀번호용으로 설계된 느린 해시 파생함수로 검증값을 저장하면, 로그인 때 같은 계산 결과만 비교할 수 있다. 솔트는 비밀일 필요는 없지만 같은 비밀번호의 저장값을 서로 다르게 만들어 미리 계산한 대량 대입의 효율을 낮춘다.

위 그림은 검토된 봉투형 구성을 이해하기 위한 역할 모형이며 아래 표를 자체 암호 프로토콜 구현 지침으로 사용하지 않는다.

표의 논스(nonce)는 선택한 암호 방식이 호출을 구별하기 위해 요구하는 값이다. 비밀키나 암호문 자체가 아니며, 같은 키 아래 논스에 요구되는 생성·재사용 조건은 그 방식의 규칙을 따른다.

MAC은 양쪽이 같은 비밀키를 보유하므로 제3자가 공유자 중 어느 쪽이 생성했는지 구별하기 어렵다는 점에서 전자서명과 다르다. 실제 서비스에서는 정해진 라이브러리·프로토콜이 제공하는 키/메시지 형식과 실패처리를 그대로 검토한다.

키는 생성부터 폐기까지 살아 있는 자산이다

1. 목적과 알고리즘에 맞는 길이·용도의 키를 신뢰할 수 있는 난수원으로 생성한다.
2. 키 식별자, 소유자, 허용 연산, 사용 시스템, 생성·만료시점과 교체 조건을 등록한다.
3. 비밀키와 개인키는 전송·저장 중 보호하고, 평문 코드·로그·문서에 넣지 않으며 접근을 최소화한다.
4. 필요한 상대에게 안전하게 배포하고 공개키는 신원과의 연결을 검증한다.
5. 사용을 기록·감시하고 키별 사용량·기간을 제한하며 정기 또는 사건 기반으로 교체한다.
6. 노출이 의심되면 폐기·취소하고 새 키로 재암호화·재서명할 범위와 영향을 처리한다.
7. 보존기간이 끝나면 복구본까지 안전하게 파기하되 과거 서명 검증과 법정 보존 필요는 별도로 설계한다.

알고리즘 교체보다 키 교체가 어려운 이유는 데이터, 서비스, 백업, 인증서와 상대 시스템이 기존 키에 연결되어 있기 때문이다. 키 버전과 사용처를 모르면 노출된 키를 끊거나 암호화된 데이터를 복구할 수 없다. 그래서 키 목록, 의존관계, 복구 시험과 비상 교체 절차가 암호 설계의 일부다.

보호목표에 맞는 기본도구를 고른다

한 도구의 이름만으로 속성을 단정하지 않는다. 암호화 방식이 인증된 변조검사를 포함하는지, 해시가 암호학적 용도인지, 공개키를 누구의 것으로 믿는 근거가 무엇인지, 키가 노출되었을 때 어떤 속성이 사라지는지를 확인한다.

독립적으로 확인해 보자. 파일과 그 해시값을 같은 게시자에게 받았고 두 값은 일치한다고 하자. 이것만으로 원래 작성자가 올린 파일임을 확인했는가? 아니다. 게시 내용을 바꿀 수 있는 상대는 파일을 바꾸고 그 파일의 해시도 새로 계산할 수 있다. 해시는 키 없이 계산하므로 일치는 받은 파일과 비교 기준 사이의 관계를 보여 줄 뿐 작성자를 인증하지 않는다. 신뢰한 별도 경로의 기준 해시 또는 신원이 확인된 공개키의 서명 검증처럼 기준의 출처도 확인해야 한다. 또 서명만 전달했다고 파일 내용이 숨겨지는 것은 아니므로 기밀성 요구는 암호화로 따로 연결한다. 해시 일치=작성자 인증, 서명 있음=비밀이라는 오답은 도구의 주된 결과와 하지 못하는 일을 섞은 것이다.

강한 알고리즘도 키와 사용법이 틀리면 약해진다

비밀키를 소스코드 저장소, 로그, 메신저와 백업에 평문으로 남기면 알고리즘을 깨지 않고도 복호화하거나 서명할 수 있다. 같은 키를 너무 오래 여러 용도로 쓰면 한 번의 노출 범위가 커지고 교체가 어려워진다. 같은 키의 암호화 호출을 구분하도록 방식이 요구하는 일회성 값인 논스나 초기화 벡터를 재사용하면 안전성 전제가 무너질 수 있으므로 검증된 라이브러리의 생성·재사용 규칙을 따라야 한다.

해시를 암호화처럼 사용해 민감정보를 숨겼다고 말하거나, 암호문이 복호화되었다는 이유만으로 변조되지 않았다고 믿는 것도 실패다. 인증서 만료·취소를 확인하지 않거나, 개인키 접근이 여러 사람에게 열려 있으면 서명의 신원 증거가 약해진다. 자체 암호 알고리즘과 임의 조합을 만들지 말고 널리 검토된 구성과 라이브러리를 사용하며 키 노출·교체·복구를 실제로 시험한다.

GCM(Galois/Counter Mode)은 암호화와 변조검사를 결합한 대칭키 구성의 한 예다. 같은 키로 여러 메시지를 처리하는 것 자체가 항상 금지되는 것은 아니다. 예를 들어 GCM에서는 정해진 사용한도 안에서 같은 키 K와 서로 다른 논스 N1·N2를 사용할 수 있지만, 같은 K 아래 같은 논스를 다른 암호화에 재사용하면 안전성 전제가 깨진다. 다른 방식의 논스·초기화 벡터 조건까지 하나의 규칙으로 단정하지 않고 선택한 검증된 구성의 문서를 따른다.

시험에서는 도구 이름보다 보호목표와 키 실패를 먼저 적는다

예상 요구어: “암호학적 해시, 암호화, 메시지 인증코드와 전자서명을 비교하고 안전한 키 관리방안을 설명하시오.” 이 문제는 네 도구의 사전식 정의를 요구하는 것이 아니다. 먼저 보호목표를 기밀성·무결성·출처 인증으로 분해하고, 각 도구가 쓰는 키와 검증 주체를 대응시켜야 한다. 이어 키의 생성·배포·보관·교체·취소를 하나의 생명주기로 설명하고, 키 노출·공개키 신원 미확인·논스 재사용처럼 알고리즘 밖에서 발생하는 실패를 막는 통제까지 제시해야 한다.

풀이 방향과 모범답안 보기

답안 목차: 목표에 맞는 도구를 고르고 키 생명주기까지 연결하기

1. 개요: 암호 기본도구의 의미와 보호목표 분리
2. 도구 비교: 해시·대칭/공개키 암호화·메시지 인증코드·전자서명의 키, 결과, 한계
3. 구성 원리: 세션키 기반 혼합 암호화, 인증된 암호화, 서명 생성·검증
4. 키 관리: 생성 → 등록·배포 → 보호·사용 → 교체·취소 → 폐기·복구
5. 위험과 통제: 평문 키, 키·논스 재사용, 인증서 신뢰, 검증된 라이브러리와 비상 교체시험

답안 도식: 보호속성과 키 생명주기의 이중 축

보호목표	도구 선택과 검증 주체
기밀성	인증된 암호화; 세션키를 확보한 수신자 검사
무결성·공유자 인증	MAC; 공유 비밀키 보유자 검사
요약·변경 비교	해시; 신뢰한 비교 기준의 출처도 확인
무결성·서명자 증거	서명; 신원이 확인된 공개키로 검증

키를 쓰는 도구는 생성 → 배포 → 보관 → 사용 → 교체 → 취소 → 폐기를 관리한다. 노출 시 영향분석·복구까지 연결한다. 해시 자체는 키 없는 함수이므로 키 생명주기와 동일시하지 않는다. 각 구성에 “어떤 키인가, 누가 검증하는가, 키가 노출되면 어떤 속성이 사라지는가”를 대조한다. 암호문·서명 검증 그림을 함께 사용한다.

이 도식의 왼쪽은 요구사항에 맞는 도구 선택이고 오른쪽은 선택한 도구가 운영 중에도 안전하게 유지되는 조건이다. 두 축을 함께 그려야 “강한 알고리즘을 골랐다”에서 답이 멈추지 않는다.

모범답안 축약본

암호 기본도구는 보호목표에 따라 조합하는 기본 연산이다. 해시는 키 없이 입력을 고정 길이로 요약해 변경 비교에 쓰지만 기밀성과 작성자 인증을 주지 않는다. 대칭키 암호화는 공유 비밀키로 대량 데이터를 빠르게 보호하고, 공개키 방식은 세션키 전달·합의와 전자서명에 쓰인다. 메시지 인증코드는 공유키 보유자 사이의 무결성·인증을, 전자서명은 개인키 소유자에 대한 검증 가능한 증거를 제공한다. 따라서 큰 문서는 무작위 세션키로 인증된 암호화를 하고 세션키를 수신자 공개키로 보호하며, 송신자 서명과 인증서 신뢰를 별도로 검증할 수 있다. 다만 안전성은 알고리즘만으로 완성되지 않는다. 키의 목적·소유자·버전을 등록하고 안전한 난수 생성, 접근 최소화, 사용감시, 정기·사건 기반 교체, 노출 시 취소·재암호화와 복구시험까지 운영해야 한다. 해시를 암호화로 오해하거나 방식의 키·논스 사용조건을 어기고 공개키의 신원을 확인하지 않는 구성이 대표 실패다.

30초 정리

1. 해시는 고정 길이 요약, 암호화는 기밀성, 메시지 인증코드는 공유키 기반 무결성·인증, 서명은 개인키 기반 무결성·인증 증거를 제공한다.
2. 대칭키는 빠르지만 공유가 필요하고, 공개키 쌍은 키 전달·합의와 서명에 쓰이지만 공개키의 신원을 확인해야 한다.
3. 전자서명의 부인방지에는 알고리즘뿐 아니라 신원 연결, 개인키 보관, 신뢰할 수 있는 시각과 기록이 필요하다.
4. 키 생성·배포·보관·사용·교체·취소·폐기와 복구시험이 암호 알고리즘 선택만큼 중요하다.

암호 구성과 키 관리의 근거

• NIST SP 800-38D의 7.2절과 8절은 GCM의 태그 검증 실패와 같은 키 아래 초기화 벡터의 유일성 조건을 확인하는 근거다. 이 조건을 모든 암호 방식의 논스 규칙으로 확대하지 않는다.
• NIST FIPS 186-5는 전자서명의 변경 탐지와 서명자 인증 목적을 확인하는 근거다. 서명만으로 이 사례의 법적 책임이나 국내 법률상 효력이 확정된다는 뜻은 아니다.
• NIST SP 800-57 Part 1 Rev. 5는 암호키 보호와 관리 기능의 개요를 확인하는 자료다. 실제 제품의 키 사용한도·교체·복구 절차는 선택한 구성의 문서와 운영조건을 별도로 검증한다.