song.3_3

하계 보안 세미나 6일차 - 보안적합성 검사

song.3_3 — Fri, 10 Jul 2026 15:40:24 +0900

이번 6강에서는 국가 보안적합성 검증 체계를 배웠다.

앞선 강의에서는 암호가 어떻게 깨지는지, 양자내성암호는 어떤 원리인지, 자동차와 임베디드 코드에는 어떤 취약점이 생기는지를 살펴봤다. 이번 강의는 기술 자체보다는, 그렇게 만든 보안 제품을 국가·공공기관에서 사용하려면 어떤 검증 절차를 거쳐야 하는지를 다뤘다.

처음에는 보안적합성 검증, 보안기능 확인서, KCMVP, CC 인증처럼 이름이 비슷한 제도가 계속 등장해서 헷갈렸다. 하지만 강의 전체를 관통하는 질문은 비교적 단순했다.

“이 제품은 안전합니다”라고 개발자가 말하는 것과
국가가 실제 시험을 거쳐 검증한 것은 무엇이 다른가?

CTF에서는 주로 “내가 이 시스템을 깰 수 있는가?”를 생각한다. 하지만 제품 개발과 납품 단계에서는 질문이 달라진다.

이 기능을 구현했는가?
요구사항을 정확히 지켰는가?
그 사실을 누가 검증했는가?
검증 결과를 증명할 문서가 있는가?

즉 제품을 잘 만들었다고 주장하는 것만으로는 부족하고, 그 주장을 객관적인 시험과 문서로 증명해야 한다.

이름이 비슷한 세 가지 제도

강의에서 먼저 구분한 것은 보안기능 확인서, KCMVP, CC 인증이었다.

셋 다 보안과 관련된 검증 제도라서 비슷해 보이지만, 실제로 확인하는 대상이 다르다.

구분확인 대상쉽게 말하면

보안기능 확인서	제품에 구현된 보안기능	제품 기능을 실제로 시험한 결과
KCMVP	제품 안의 암호모듈	암호 구현이 규격대로 만들어졌는지 검증
CC 인증	제품 전체의 보안성	제품 전체를 일정한 평가기준으로 평가

보안기능 확인서는 영상기기와 같은 IT 제품의 보안기능 시험 결과를 나타내는 증서다. 이번 강의에서 중심적으로 다룬 제도이기도 하다.

KCMVP는 제품 전체가 아니라, 제품에 탑재된 암호모듈을 검증하는 제도다. 암호 알고리즘만 사용한다고 끝나는 것이 아니라, 그 알고리즘을 구현한 모듈이 규격과 보안요구사항을 제대로 지켰는지를 확인한다.

CC 인증은 ISO/IEC 15408을 기반으로 제품 전체의 보안성을 평가하는 제도다.

한 문장으로 구분하면 다음과 같다.

보안기능 확인서 = 제품의 보안기능 시험
KCMVP = 제품 안의 암호모듈 검증
CC 인증 = 제품 전체의 보안성 평가

예를 들어 IP카메라가 국가·공공기관에 들어가려면 제품 보안기능 시험을 거쳐 보안기능 확인서를 받아야 한다. 그리고 카메라 안에서 영상을 암호화한다면, 그 암호화 기능에는 KCMVP 검증필 암호모듈이 요구될 수 있다.

즉 하나가 다른 하나를 완전히 대신하는 관계는 아니다.

한 제품에도 여러 층의 검증이 붙는다

강의 자료에서는 하나의 제품에도 세 가지 층위의 검증이 붙을 수 있다고 설명했다.

운용 환경
→ 보안적합성 검증

제품 보안기능
→ 보안기능 시험제도(VSFT)

암호 구현
→ KCMVP 암호모듈 검증

제품의 암호화 코드가 정상적으로 동작한다고 해서, 제품 전체가 국가·공공기관에 바로 도입될 수 있는 것은 아니다.

반대로 제품의 로그인 기능과 감사기록이 잘 구현되어 있어도, 저장 암호화에 사용한 암호모듈이 KCMVP 검증필 목록에 없다면 관련 요구사항을 충족하지 못할 수 있다.

이번 강의에서 가장 중요하게 느껴진 부분도 이것이었다.

“구현이 맞다”와
“검증을 통과했다”는
서로 다른 문장이다.

보안적합성 검증이란

보안적합성 검증은 국가·공공기관이 IT 제품을 도입하기 전에 해당 제품의 안전성을 검증하는 제도다.

제품을 먼저 도입한 뒤 문제가 발생하면 수정하는 것이 아니라, 도입 전에 시험하고 취약점을 보완한 뒤 사용하는 구조다. 따라서 공공기관에 제품을 납품하려는 업체에는 일종의 관문 역할을 한다.

제품 개발
→ 보안기능 시험
→ 취약점 발견
→ 보완
→ 결과 검토
→ 확인서 발급
→ 공공기관 도입

강의에서는 국가정보원법, 사이버안보업무규정, 전자정부법 등이 제도의 근거로 연결된다고 설명했다.

개인 프로젝트에서는 “기능이 실행되는가?”가 중심이 되지만, 공공기관 납품에서는 “도입 요건을 통과했는가?”가 더 중요한 질문이 된다.

어떤 제품이 검증 대상인가

보안적합성 검증 대상에는 방화벽, VPN, 스위치와 라우터, 안티바이러스, DB 접근통제, 양자키분배 장비, 영상정보처리기기 등 여러 종류가 포함된다.

강의 자료에서는 국가용 보안요구사항이 공통 요구사항과 제품별 요구사항으로 구성되며, 제품별 요구사항은 10개 제품군, 총 34종으로 나뉜다고 설명했다.

대표적인 제품군은 다음과 같다.

침입차단
침입방지
구간보안
전송자료보안
보안관리
가상화
엔드포인트 보안
네트워크 장비
양자암호통신
영상정보처리기기

제품 종류가 달라도 인증, 데이터 보호, 업데이트 보호, 감사기록 같은 기본 뼈대는 반복된다.

IP카메라도 검증 대상이 된다

강의에서는 영상정보처리기기가 검증 대상에 편입된 사례를 집중적으로 다뤘다.

2024년 4월 1일부터 TCP/IP 네트워크로 연결되어 데이터를 전송하는 영상정보처리기기는 보안적합성 검증 대상에 포함됐다.

여기서 중요한 구분은 네트워크 연결 방식이다.

TCP/IP로 연결되는 IP카메라
→ 검증 대상

아날로그 또는 SDI 방식으로 영상을 전송하는 카메라
→ 해당 기준에서는 대상 제외

IP카메라는 인터넷이나 내부 네트워크와 연결되기 때문에 계정 탈취, 영상 유출, 펌웨어 변조, 네트워크 침입과 같은 위험이 생긴다. 그래서 단순한 촬영 장비가 아니라 하나의 네트워크 보안 제품처럼 관리할 필요가 있다.

어느 제품이든 반복되는 공통 보안요구사항

제품마다 기능은 다르지만, 공통적으로 확인하는 보안 항목이 있다.

강의에서는 서버 공통 보안요구사항을 다음과 같은 영역으로 정리했다.

식별 및 인증
보안관리
데이터 보호
자체보호
업데이트 보호
안전한 세션 관리
감사기록
암호지원
취약성 대응

영상정보처리기기에는 여기에 영상 보안이라는 제품 고유 항목이 추가된다.

예를 들어 방화벽과 VPN, IP카메라는 서로 전혀 다른 제품처럼 보이지만 다음과 같은 기준을 공통으로 적용받을 수 있다.

패스워드는 일정 길이 이상이어야 한다.
인증에 반복 실패하면 계정을 잠근다.
사용하지 않는 세션은 일정 시간이 지나면 종료한다.
중요한 행위는 감사기록으로 남긴다.
업데이트 파일의 무결성과 출처를 검증한다.
암호 기능은 정해진 기준에 맞게 구현한다.

강의 예시에서는 패스워드 9자리 이상, 인증 실패 5회, 유휴시간 10분 같은 구체적인 수치도 등장했다.

보안요구사항은 “로그인을 안전하게 구현한다”처럼 모호한 문장이 아니라, 실제 시험할 수 있는 형태로 작성된다는 점이 중요했다.

보안기능 시험제도에 참여하는 기관

보안기능 시험제도에는 여러 기관이 서로 다른 역할로 참여한다.

강의에서는 이를 네 주체로 정리했다.

NIS: 정책기관

국가정보원은 검증 정책을 수립하고 시험기관 지정과 확인서 효력 등을 관리한다.

NSR: 검증기관

국가보안기술연구소는 시험 가이드를 제공하고, 시험 결과를 검토하며 확인서 발급을 승인한다.

TTA: 시험기관

영상기기 분야에서는 한국정보통신기술협회가 실제 보안기능 시험을 수행하고 확인서를 발급한다.

신청기관: 제조업체

제품을 개발한 업체는 시험을 신청하고, 필요한 문서를 제출하며, 시험 중 발견된 취약점을 보완한다.

정리하면 다음과 같다.

정책은 NIS
검증은 NSR
시험은 TTA
신청은 제조업체

제품을 개발한 업체가 직접 접촉하는 곳은 시험기관이지만, 그 뒤에는 결과를 검토하는 검증기관과 제도를 관리하는 정책기관이 있다.

시험 신청부터 도입까지

제품은 신청 즉시 확인서를 받는 것이 아니다.

강의에서 설명한 전체 흐름은 다음과 같다.

시험 신청
접수 및 계약
시험수행 계획 수립
보안기능 시험
시험 결과 검토
보안기능 확인서 발급
공공기관 도입

시험 과정에서 부적합 판정을 받으면 신청기관이 취약점을 수정하고 다시 시험을 받아야 한다.

여기서 시험은 서류만 읽고 통과 여부를 정하는 방식이 아니다. 실제 제품을 실행해 로그인, 계정 잠금, 세션 종료, 암호화, 업데이트, 감사기록 등의 동작을 확인한다.

문서에는 안전하다고 적혀 있지만
실제 제품은 다르게 동작할 수도 있다.

따라서 시험기관은 문서와 실제 동작을 함께 확인한다.

보안기능 확인서가 의미하는 것

보안기능 확인서는 제품이 시험기준을 만족했다는 사실을 확인하여, 검증기관의 승인 아래 시험기관이 발급하는 증서다.

도입기관은 이 확인서를 통해 해당 제품이 검증 절차를 거쳤는지 확인한다.

강의 자료에서는 확인서가 발급일까지 알려진 취약점이 제거됐는지 확인하는 결과물이라고 설명했다. 하지만 확인서가 발급된 이후에 새로 발견되는 모든 취약점까지 없다고 보증하는 것은 아니다.

즉 확인서는 다음을 의미한다.

발급 시점의 기준과 알려진 취약점을 바탕으로
시험을 통과했다.

다음 의미는 아니다.

앞으로 절대 취약점이 발견되지 않는다.

국가용 보안요구사항을 기준으로 시험한 제품은 5년, 신기술 등 구현명세서를 기반으로 시험한 경우는 2년의 유효기간이 적용될 수 있다고 강의에서 설명했다.

시험을 위해 제출해야 하는 문서

신청기관은 제품만 보내는 것이 아니라, 제품의 구조와 보안기능을 설명하는 문서도 제출해야 한다.

강의에서 소개한 문서는 다음 다섯 종류였다.

문서주요 내용

제품설명서	제품 개요와 구성
보안기능 구현명세서	보안기능, 인터페이스, 계정
운용설명서	설치와 운용 방법
시험결과서	시험 결과
취약점 개선내역서	발견된 취약점과 조치 내용

이 문서들은 모두 한국어로 작성해야 한다.

특히 구현명세서에는 제품의 모든 인터페이스와 계정을 적어야 한다.

시험 과정에서 명세서에 없는 인터페이스나 숨겨진 계정이 발견되면 백도어로 간주될 수 있고, 확인서 발급이 거부될 수 있다.

숨겨진 관리자 계정
문서에 없는 디버그 포트
알려지지 않은 원격 접속 기능
개발용으로 남겨 둔 서비스

→ 검증 관점에서는 모두 심각한 문제

개발자는 편의를 위해 테스트 계정이나 디버그 기능을 남겨 둘 수 있지만, 검증 제품에서는 그런 숨겨진 기능 자체가 취약점이 된다.

제품 요구사항이 KCMVP를 요구하는 경우

제품 보안요구사항에는 KCMVP 검증필 암호모듈을 사용해야 한다는 조건이 들어갈 수 있다.

강의에서는 IP카메라가 영상을 기기 내부에 저장하는 상황을 예로 들었다.

기기 내부에 영상을 저장할 때
KCMVP 검증필 암호모듈로 암호화해야 한다.

즉 “AES로 암호화했습니다”라는 설명만으로는 부족할 수 있다.

어떤 AES 구현인가?
어떤 모듈에 포함되어 있는가?
그 모듈의 버전은 무엇인가?
어떤 운영환경에서 검증됐는가?
KCMVP 검증필 목록에 등재되어 있는가?

이런 부분까지 확인해야 한다.

KCMVP란

KCMVP는 Korea Cryptographic Module Validation Program의 약자로, 우리나라의 암호모듈 검증 제도다.

암호 알고리즘 이름만 확인하는 것이 아니라, 해당 알고리즘과 키 관리, 난수 생성, 자가시험 등을 포함한 암호모듈이 규격에 맞게 구현되었는지를 검증한다.

검증을 통과한 모듈은 검증필 암호모듈 목록에 등재된다.

암호모듈 개발
→ 시험기관 시험
→ NSR 검토
→ 검증필 목록 등재

실무에서 첫 번째로 확인할 질문은 다음과 같다.

제품에 탑재한 암호모듈이
검증필 목록에 있는가?

암호모듈의 경계

KCMVP에서는 암호모듈의 경계가 중요하다.

암호모듈의 경계 안에는 다음과 같은 기능이 포함될 수 있다.

암호 알고리즘 구현
키 생성·저장·폐기 등의 키 관리
난수 생성
알고리즘 자가시험
코드 무결성 검사

검증은 이 경계 안을 대상으로 한다.

예를 들어 암호 라이브러리는 KCMVP 검증을 받았지만, 그 라이브러리를 호출하는 애플리케이션 코드에서 키를 로그로 출력한다면 제품 전체는 안전하지 않다.

검증필 암호모듈
≠
그 모듈을 사용하는 모든 애플리케이션까지 자동으로 안전함

모듈 경계 밖의 앱 코드와 운영 설정은 별도로 안전하게 만들어야 한다.

KCMVP 보안수준 1~4

KCMVP 암호모듈에는 보안수준이 있다.

강의에서는 수준이 높아질수록 소프트웨어 구현뿐만 아니라 물리적인 침해까지 고려한다고 설명했다.

수준주요 특징

Level 1	소프트웨어 중심의 기본 구현 검증
Level 2	변조 흔적과 역할 기반 접근통제
Level 3	물리적 침해 대응과 키 접근 보호
Level 4	전압과 온도 같은 환경 이상 대응

무조건 가장 높은 수준이 좋은 것은 아니다. 제품이 놓이는 환경과 예상되는 공격을 고려해 적절한 수준을 선택해야 한다.

서버에서 실행되는 소프트웨어 암호모듈과, 공격자가 직접 만질 수 있는 하드웨어 보안장비는 위협 모델이 다르기 때문이다.

KCMVP 목록에서 확인해야 하는 정보

검증필 목록에 비슷한 이름의 모듈이 있다고 해서 바로 사용할 수 있는 것은 아니다.

강의에서는 목록에서 다음 다섯 가지를 확인해야 한다고 설명했다.

모듈명과 버전
지원 알고리즘
보안수준
유효기간
운영환경

같은 코드라도 버전이나 운영체제, 암호모듈 경계가 다르면 다른 검증 대상으로 볼 수 있다.

예를 들어 Linux용으로 검증된 특정 버전의 암호모듈을 다른 운영체제나 다른 버전에서 사용하면, 기존 검증의 적용 범위에 포함되지 않을 수 있다.

그래서 실무 질문은 단순히 다음과 같지 않다.

AES를 사용했는가?

조금 더 정확한 질문은 다음과 같다.

우리가 실제로 사용하는 그 모듈과 그 버전,
그 운영환경이 검증필 목록에 있는가?

구현이 올바른 것과 검증필인 것은 다르다

강의에서는 IP카메라의 영상 저장 암호화를 예시로 들었다.

AES-256-CBC를 사용하고, 프레임마다 IV를 새로 생성하며, 데이터 암호화 키인 DEK와 키 암호화 키인 KEK를 분리했다면 기술적으로는 비교적 올바른 구조일 수 있다.

AES-256-CBC
프레임 단위 암호화
DEK와 KEK 분리
IV 매번 무작위 생성

하지만 그 구현이 KCMVP 검증필 목록에 없는 자체 구현이라면, “검증필 암호모듈 사용”을 요구하는 조건은 충족하지 못한다.

암호 사용 방법이 맞음
≠
KCMVP 검증필 모듈임

수업이나 공개 예제에서는 환경 제약 때문에 일반 라이브러리를 사용할 수 있지만, 실제 제품에서는 검증필 모듈로 교체해야 한다는 점을 분명하게 적어야 한다.

KCMVP 검증 대상 암호 알고리즘

강의에서는 KCMVP 검증 대상이 되는 암호 알고리즘도 소개했다.

블록암호

SEED
ARIA
HIGHT
LEA

SEED와 ARIA는 범용적인 블록암호이고, HIGHT와 LEA는 자원이 제한된 환경에서도 사용할 수 있도록 고려된 경량 블록암호다.

해시

SHA-2
LSH

해시는 데이터의 무결성을 확인하거나 전자서명, 키 유도 등의 과정에 사용된다.

메시지 인증

HMAC

HMAC은 비밀키와 해시를 함께 사용해 메시지의 변조 여부와 인증을 확인한다.

공개키·전자서명

RSA
KCDSA
ECDSA

공개키 암호와 전자서명에 사용된다.

키 설정과 난수

키 교환
키 유도
DRBG

DRBG는 결정론적 난수비트생성기로, 암호키와 nonce 등에 필요한 안전한 난수를 만든다.

여기서 중요한 것은 알고리즘을 하나만 골라 넣는 것이 아니다.

암호화
해시
메시지 인증
키 생성과 유도
난수 생성
키 저장과 폐기
자가시험

이 과정이 하나의 암호모듈 안에서 안전하게 이어져야 한다.

암호모듈은 스스로 상태를 점검해야 한다

KCMVP 보안요구사항에는 자가시험도 포함된다.

대표적으로 KAT와 무결성 검사가 있다.

KAT(Known Answer Test)는 미리 정해진 입력과 정답을 가지고 암호 알고리즘이 올바른 결과를 내는지 확인하는 시험이다.

정해진 입력을 암호화
→ 미리 알고 있는 정답과 비교
→ 같으면 정상
→ 다르면 모듈 사용 중단

무결성 검사는 모듈 코드나 중요 파일이 변조되지 않았는지 확인한다.

자가시험에 실패했는데도 계속 작동하면 잘못된 암호 결과나 손상된 키가 사용될 수 있다. 그래서 실패 시 기능을 중단하는 fail-closed 방식이 중요하다.

요구사항은 실제 코드로 구현되어야 한다

강의 후반부에서는 IP카메라 예제 프로젝트를 통해 국가용 보안요구사항이 코드로 어떻게 연결되는지 살펴봤다.

가장 인상적이었던 점은 문서의 각 조항이 실제 조건문과 함수로 연결된다는 것이었다.

패스워드 정책

예를 들어 패스워드는 9자리 이상이어야 하고, 사용자 계정과 같은 값이나 qwer, asdf, 1234처럼 단순한 키보드 연속 문자열을 제한할 수 있다.

if len(password) < 9:
    return False

if username and password.lower() == username.lower():
    return False

강의 예제에서는 정방향 문자열뿐 아니라 rewq처럼 역방향 배열까지 검사했다.

결국 문서에 적힌 “취약한 패스워드를 제한한다”는 문장은 코드 안에서는 여러 개의 구체적인 조건문이 된다.

인증 실패 5회 계정 잠금

로그인에 연속으로 실패하면 계정을 잠그고, 그 사실을 감사기록에 남겨야 한다.

틀린 비밀번호 5회
→ 계정 잠금
→ 잠금 사건 감사기록
→ 일정 시간 후 해제

검사기는 서버 내부 코드를 직접 보지 않고 실제 로그인을 반복해 기능이 동작하는지 확인한다.

특히 5번 실패한 뒤 6번째 시도에서는 정상 비밀번호를 입력해도 인증이 거부되어야 진짜 계정 잠금이라고 판정할 수 있다.

인증 실패 원인을 자세히 알려주지 않기

로그인 실패 시 다음과 같이 구체적으로 알려주면 공격자가 계정 존재 여부를 확인할 수 있다.

존재하지 않는 사용자입니다.
비밀번호가 틀렸습니다.

따라서 외부에는 다음처럼 같은 메시지를 보여주는 편이 안전하다.

인증 실패

존재하는 계정과 존재하지 않는 계정의 응답을 같게 만들어 계정 열거 공격을 막는 것이다.

클라이언트가 보내는 헤더를 그대로 믿지 않기

X-Forwarded-For와 같은 HTTP 헤더는 프록시 환경에서 실제 클라이언트 IP를 전달할 때 사용한다.

하지만 신뢰할 수 있는 프록시를 거치지 않은 상황에서는 공격자가 헤더 값을 임의로 작성할 수 있다. 따라서 IP 기반 접근통제를 구현하면서 해당 헤더를 무조건 신뢰하면 우회될 수 있다.

클라이언트가 주장하는 IP
≠
실제로 연결한 네트워크 상대의 IP

강의 예제에서는 소켓에서 확인한 실제 peer 정보를 사용하도록 구현했다.

구동 시 자체시험과 주기적 무결성 검사

IP카메라가 켜질 때 다음 항목을 스스로 검사하도록 구현할 수 있다.

카메라 하드웨어 접근 가능 여부
서버 연결 가능 여부
TLS 인증서 유효성
암호모듈 동작 여부

작동 중에는 중요 파일의 현재 해시값을 기준값과 비교해 변조 여부를 확인한다.

강의 예제에서는 실행 시점과 24시간 주기로 무결성을 검사하고, 문제가 발생하면 안전하게 종료하는 방식을 사용했다. 이것은 KCMVP의 자가시험과 같은 방향의 설계라고 볼 수 있다.

감사기록도 보호해야 한다

보안제품은 중요한 사건을 로그로 남겨야 한다.

대표적인 감사 대상은 다음과 같다.

로그인 성공과 실패
계정 잠금
관리자 설정 변경
사용자 추가와 삭제
업데이트 수행
무결성 검사 실패
시스템 시작과 종료

하지만 로그를 남기는 것만으로는 충분하지 않다.

공격자가 로그를 수정하거나 삭제할 수 있다면 자신의 흔적을 없앨 수 있기 때문이다. 그래서 감사기록은 일반 사용자가 변경할 수 없도록 보호하고, 로그가 가득 찼을 때 어떻게 처리할지도 정해야 한다.

로그 생성
→ 권한 분리
→ 변경·삭제 방지
→ 저장공간 관리
→ 관리자 검토

추적매트릭스란

요구사항 문서에는 수많은 조항이 있다. 각 조항이 코드의 어느 파일과 함수에서 구현되었는지 정리한 표를 추적매트릭스라고 한다.

예를 들어 다음과 같이 연결할 수 있다.

요구사항구현 위치

패스워드 정책	password_policy.py
인증 실패 5회 잠금	auth.py
유휴 10분 세션 종료	verify_token()
감사기록 변경 방지	audit.py

시험관은 이 표를 따라가며 요구사항과 실제 구현이 연결되는지 확인할 수 있다.

추적매트릭스가 없다면 기능은 구현되어 있어도 어디에 있는지 찾기 어렵다. 반대로 표에 조항은 있지만 실제 코드가 없다면 미구현 상태가 드러난다.

조항 번호를 코드 주석에 남기기

강의에서는 코드에 요구사항 번호를 직접 주석으로 적는 방법도 소개했다.

# [NIS 2.2.1] 연속 인증 실패 시 계정 잠금
# [NIS 8.1.1] 계정 잠금 사건 감사기록

이런 주석을 일정한 형식으로 남기면 자동화 도구가 코드 전체를 검색해 다음 자료를 만들 수 있다.

조항별 구현 파일 목록
조항별 구현 함수 목록
미구현 조항 목록
검증 결과와 코드의 연결
구현명세서 초안

거창한 시스템을 처음부터 만드는 것보다, 일관된 조항 주석 한 줄이 자동화의 출발점이 될 수 있다는 설명이 인상적이었다.

검증 자동화의 흐름

강의에서는 요구사항을 코드와 시험으로 연결하는 과정을 여섯 단계로 정리했다.

요구사항을 체크리스트로 변환
조항 주석 작성 규칙 결정
조항별 기능 구현
추적매트릭스 자동 생성
외부 검증기 작성
구현명세서와 시험결과 초안 생성

검증기는 내부 구현을 믿지 않고 외부에서 제품을 실제로 두드린다.

예를 들어 다음을 자동으로 시험할 수 있다.

TLS 1.0과 1.1 연결이 거부되는가?
틀린 비밀번호를 5번 입력하면 계정이 잠기는가?
정상 비밀번호를 입력해도 잠금 상태가 유지되는가?
유휴시간이 지나면 세션이 종료되는가?
잘못된 업데이트 파일이 거부되는가?

모든 검증 결과를 PASS 또는 FAIL로 출력하고, 각 결과에 해당 조항 번호를 붙이면 시험 근거로 활용하기 쉬워진다.

강의에서 설명한 자동화의 종료 조건은 비교적 명확했다.

검증기 전 항목 PASS
+
추적매트릭스 미구현 조항 0개

FAIL이 나오면 해당 조항의 구현으로 돌아가 수정하고 다시 시험한다.

AI를 사용할 때도 원문 검수가 필요하다

강의에서는 AI를 활용해 요구사항 구현과 검증 자동화를 보조하는 방법도 소개했다.

예를 들어 다음처럼 구체적으로 요청할 수 있다.

IP카메라 요구사항 2.2.1을 구현한다.
연속 인증 실패 5회에서 계정을 잠근다.
5분 후 잠금을 해제한다.
잠금 발생 시 감사기록을 남긴다.
구현부마다 [NIS 2.2.1] 주석을 작성한다.

단순히 “보안을 강화해줘”라고 요청하는 것보다, 조항 번호와 수치, 필요한 산출물을 함께 알려주는 편이 훨씬 정확하다.

하지만 AI가 만든 코드와 문서는 어디까지나 초안이다.

조항 번호가 맞는가?
수치를 정확히 적용했는가?
조건부 요구사항을 잘못 필수로 해석하지 않았는가?
숨겨진 인터페이스나 계정을 만들지 않았는가?

이 부분은 반드시 원문 요구사항과 대조해 사람이 검수해야 한다. 검수되지 않은 자동화는 오히려 새로운 취약점이나 문서 불일치를 만들 수 있다.

이번 강의에서 기억할 핵심

이번 강의는 기술적으로 안전한 제품과, 공식적으로 검증된 제품 사이의 차이를 보여주는 내용이었다.

전체 흐름을 정리하면 다음과 같다.

보안적합성 검증
= 국가·공공기관 도입 전 제품 안전성 확인

보안기능 확인서
= 제품 보안기능 시험의 최종 결과물

KCMVP
= 제품 안의 암호모듈이 규격대로 구현됐는지 검증

CC 인증
= 제품 전체의 보안성 평가

그리고 제품 개발자의 관점에서는 다음 흐름으로 볼 수 있다.

보안요구사항 확인
→ 기능 구현
→ 조항과 코드 연결
→ 자체시험과 자동 검증
→ 취약점 수정
→ 제출문서 작성
→ 시험기관 시험
→ 확인서 발급

마무리

이번 강의를 듣기 전에는 제품에 AES나 TLS 같은 안전한 기술을 사용하면 보안제품이라고 부를 수 있다고 생각했다.

하지만 어떤 알고리즘을 사용했는지만으로는 부족했다. 암호모듈의 버전과 운영환경, 키 관리, 난수 생성, 자가시험까지 확인해야 하고, 제품 차원에서는 인증과 세션, 업데이트, 감사기록, 자체보호 기능도 함께 검증해야 한다.

무엇보다 중요한 점은 구현과 증명은 별개의 작업이라는 것이다.

코드를 잘 작성하는 것
요구사항을 정확히 구현하는 것
실제 동작을 시험하는 것
시험 결과를 문서로 남기는 것
공식 검증기관의 확인을 받는 것

이 모든 과정이 연결되어야 비로소 “검증된 제품”이 된다.

이번 6강의 핵심은 다음 문장으로 정리할 수 있을 것 같다.

보안은 “안전하게 만들었다”는 주장으로 끝나지 않는다.

무엇을 구현했고,
어떻게 시험했으며,
누가 그 결과를 확인했는지를
증명할 수 있어야 한다.

하계 보안 세미나 5일차 - 시큐어코딩 (임베디드·자동차 코딩 표준)

song.3_3 — Fri, 10 Jul 2026 15:36:09 +0900

이번 5강에서는 시큐어 코딩과 임베디드·자동차 코딩 표준을 배웠다.

이전 강의에서는 암호가 어떤 원리로 깨지는지, 양자내성암호가 왜 필요한지, 자동차 안에는 어떤 장치와 통신망이 있는지를 살펴봤다. 이번 강의는 그보다 조금 더 코드에 가까운 내용이었다.

버퍼 오버플로우, 해제된 메모리 사용, 널 포인터 역참조, 정수 오버플로우처럼 C와 C++에서 자주 발생하는 문제를 살펴보고, 이런 코드를 MISRA, AUTOSAR, CERT C 같은 표준에서는 어떻게 설명하는지 배웠다.

이번 강의의 핵심은 단순히 다음과 같이 말하는 데 있지 않았다.

이 코드는 위험하다.

조금 더 구체적으로 다음과 같이 설명할 수 있어야 한다.

어떤 경계 검사가 빠졌는가?
어떤 표준 규칙을 위반했는가?
어떻게 수정해야 하는가?
수정됐다는 사실을 어떤 도구와 테스트로 증명할 것인가?

즉 시큐어 코딩은 단순히 코드를 조심해서 작성하는 것이 아니라, 위험한 코드를 공통된 규칙으로 설명하고 검증하는 과정이라고 볼 수 있었다.

시큐어 코딩이란 무엇인가

시큐어 코딩은 처음부터 취약점이 생기지 않도록 안전한 방식으로 코드를 작성하는 것을 말한다.

보안 문제가 발견된 후 패치하는 것도 중요하지만, 개발 단계에서부터 위험한 코드 패턴을 제한하면 취약점이 만들어질 가능성 자체를 줄일 수 있다.

특히 자동차와 임베디드 환경에서는 작은 실수가 단순한 프로그램 오류에서 끝나지 않을 수 있다. 센서값을 잘못 읽거나 ECU가 중단되면 차량 기능이나 실제 안전에까지 영향을 줄 수 있기 때문이다.

강의에서는 취약점이 주로 다음 네 가지 경계에서 시작한다고 설명했다.

입력 경계
메모리 수명
권한 경계
시간 예측성

입력 경계에서는 데이터의 길이와 타입을 확인해야 한다. 메모리 수명에서는 누가 메모리를 할당하고 해제하는지 분명해야 한다. 권한 경계에서는 어떤 사용자가 어떤 API나 기능을 호출할 수 있는지를 검사해야 한다.

자동차 코드에서는 시간도 중요한 경계다. 평균적으로 빠르게 동작하는 것보다, 가장 오래 걸리는 경우에도 정해진 시간 안에 끝나는지가 더 중요할 수 있다.

표준마다 하는 역할이 다르다

강의에는 MISRA, AUTOSAR C++14, SEI CERT C, ISO 26262, ISO/SAE 21434처럼 여러 표준이 등장했다.

처음에는 비슷한 문서들이 이름만 다르게 존재하는 것처럼 느껴졌다. 하지만 각각 보는 범위와 질문이 달랐다.

MISRA C/C++

MISRA는 임베디드 환경에서 C와 C++의 위험한 기능을 제한하기 위한 코딩 규칙이다.

C언어는 메모리와 포인터를 직접 제어할 수 있어 빠르고 자유롭지만, 개발자가 실수하면 정의되지 않은 동작이나 메모리 손상이 발생할 수 있다. MISRA는 이런 자유를 일부 제한해서 코드의 동작을 더 예측 가능하게 만든다.

쉽게 말하면 다음 질문을 다룬다.

C와 C++를 어떤 방식으로 작성해야 안전한가?

AUTOSAR C++14

AUTOSAR C++14는 자동차에서 현대적인 C++ 기능을 안전하게 사용하기 위한 지침이다.

스마트 포인터, RAII, 템플릿, 예외, 상속처럼 C++에서 제공하는 기능을 무조건 금지하는 것이 아니라, 안전성과 실행시간 예측 가능성을 유지할 수 있는 범위를 정한다.

자동차 환경에서 C++ 기능을 어디까지, 어떻게 사용할 것인가?

SEI CERT C

CERT C는 취약점으로 이어질 수 있는 C 코드 패턴을 설명하는 데 가깝다.

예를 들어 버퍼 오버플로우, 널 포인터 역참조, 해제 후 사용, 정수 오버플로우, 포맷 스트링 문제를 각각 규칙 번호와 함께 설명한다.

이 코드 패턴이 실제 보안 취약점으로 이어질 수 있는가?

ISO 26262와 ISO/SAE 21434

ISO 26262는 자동차 기능안전 표준이고, ISO/SAE 21434는 자동차 사이버보안 표준이다.

이 두 표준은 특정 함수나 문법을 어떻게 작성할지 알려주는 코딩 규칙이라기보다, 위험을 어떻게 분석하고 관리하며 검증 근거를 남길지를 다룬다.

정리하면 다음 세 층으로 구분할 수 있었다.

언어 규칙
MISRA, AUTOSAR

취약점 설명
CERT C

안전·보안 프로세스와 증거
ISO 26262, ISO/SAE 21434

Safety와 Security의 차이

ISO 26262와 ISO/SAE 21434를 구분하면서 Safety와 Security의 차이도 다시 정리할 수 있었다.

Safety는 시스템의 고장이나 오작동이 사람을 해치지 않도록 하는 것이다.
반면 Security는 외부 공격자가 시스템을 침해하지 못하도록 막는 것이다.

Safety
시스템 → 바깥세상
시스템이 사람을 해치지 않도록 관리

Security
바깥세상 → 시스템
공격자가 시스템을 뚫지 못하도록 관리

ISO 26262에서는 HARA를 통해 위험을 분석하고 ASIL 등급을 정한다. ISO/SAE 21434에서는 TARA를 통해 사이버보안 위협을 분석한다.

둘은 서로 다른 분야처럼 보이지만 자동차에서는 연결되어 있다. 보안 공격으로 ECU나 차량 기능이 오작동하면 결국 안전사고로 이어질 수 있기 때문이다.

TARA는 위협을 위험도로 바꾸는 과정이다

TARA는 Threat Analysis and Risk Assessment의 약자로, 위협 분석 및 위험 평가를 의미한다.

단순히 “이 시스템에 취약점이 있다”고 말하는 것이 아니라, 그 취약점이 얼마나 위험한지 평가하고 어떤 대응이 필요한지를 결정하는 과정이다.

강의에서는 TARA의 흐름을 다음과 같이 설명했다.

자산 식별
→ 위협 시나리오 식별
→ 영향 평가
→ 공격 경로 분석
→ 공격 실현 가능성 평가
→ 리스크 결정
→ 리스크 처리

먼저 보호해야 할 자산을 찾고, 어떤 공격이 가능한지 생각한다. 이후 공격이 실제로 일어났을 때 안전, 재정, 운영, 개인정보 측면에서 어떤 피해가 발생하는지 평가한다.

공격에 필요한 시간, 지식, 장비, 접근 기회도 함께 고려한다. 마지막에는 위험을 회피할지, 줄일지, 다른 곳으로 전가할지, 아니면 수용할지를 결정한다.

이 과정이 필요한 이유는 모든 취약점을 같은 수준으로 처리할 수 없기 때문이다. 단순한 화면 오류와 원격 차량 제어 가능성을 같은 우선순위로 볼 수는 없다.

Shift Left: 보안을 개발 초기에 적용하기

강의에서 기억에 남았던 개념 중 하나가 Shift Left였다.

일반적인 개발 흐름을 왼쪽에서 오른쪽으로 적으면 다음과 같다.

요구사항 → 설계 → 구현 → 분석 → 검증

Shift Left는 보안 검사와 테스트를 가능한 한 앞 단계로 옮기는 것을 말한다.

완성된 제품에서 취약점이 발견되면 설계나 구조까지 다시 바꿔야 할 수 있다. 반면 요구사항이나 설계 단계에서 발견하면 더 적은 비용으로 수정할 수 있다.

따라서 정적 분석이나 보안 테스트를 개발 마지막에 한 번 실행하는 것으로 끝내면 안 된다.

요구사항
보안 요구와 금지 사항 작성

설계
위협 모델과 권한 경계 정의

구현
코딩 표준과 코드 리뷰 적용

분석
정적 분석과 Sanitizer 실행

검증
테스트 결과와 수정 근거 기록

도구는 최종 검사관이 아니라 개발 과정에 계속 붙어 있어야 한다는 의미로 이해했다.

스택과 힙의 차이

메모리 취약점을 이해하려면 스택과 힙의 차이를 알아야 한다.

스택

스택은 함수가 호출될 때마다 만들어지는 임시 공간이다. 지역 변수, 함수의 반환 주소, 저장된 레지스터 등이 들어간다.

함수가 끝나면 해당 공간의 수명도 끝난다.

스택의 고정 길이 배열에 너무 긴 값을 복사하면 주변 메모리까지 덮어쓸 수 있다. 경우에 따라 반환 주소가 변조되어 프로그램의 실행 흐름이 바뀔 수도 있다.

힙

힙은 malloc이나 new처럼 프로그램 실행 중에 동적으로 할당하는 공간이다.

스택보다 객체의 수명을 자유롭게 관리할 수 있지만, 개발자가 직접 할당과 해제를 관리해야 하므로 문제가 발생하기 쉽다.

스택에서 자주 발생하는 문제
스택 버퍼 오버플로우

힙에서 자주 발생하는 문제
힙 오버플로우
Use-After-Free
Double Free
메모리 누수

자동차와 임베디드 코드에서는 실행 중 동적 메모리 할당을 아예 금지하거나 초기화 단계에서만 허용하는 경우도 있다고 한다. 실행시간을 예측하기 어렵고 메모리 단편화가 발생할 수 있기 때문이다.

스택 버퍼 오버플로우

다음 코드는 강의에서 나온 대표적인 위험 패턴이다.

void handle_name(const char *input)
{
    char name[16];

    strcpy(name, input);

    printf("hello %s\n", name);
}

name은 16바이트 배열인데, input의 길이는 검사하지 않는다. 만약 16바이트보다 긴 문자열이 들어오면 남은 문자가 사라지는 것이 아니라 배열 옆의 메모리까지 덮어쓴다.

입력 길이 > 버퍼 크기
→ 인접 메모리 덮어쓰기
→ 다른 변수 또는 반환 주소 손상
→ 프로그램 중단이나 실행 흐름 변조

이 문제의 핵심은 strcpy()라는 함수 이름만이 아니다. 복사되는 데이터의 최대 크기를 코드가 보장하지 않는 것이 문제다.

조금 더 안전한 형태는 다음과 같이 대상 버퍼 크기를 지정하는 것이다.

void better(const char *input)
{
    char name[16];

    snprintf(name, sizeof(name), "%s", input);
    name[sizeof(name) - 1] = '\0';
}

하지만 snprintf()를 사용했다고 자동으로 모든 문제가 해결되는 것은 아니다. 문자열이 잘렸는지 반환값도 확인해야 한다.

결국 중요한 질문은 이것이었다.

이 복사의 최대 길이는 어디에서 보장되는가?

스택 카나리

스택 버퍼 오버플로우를 탐지하는 방어 기법 중 하나가 카나리다.

카나리는 지역 버퍼와 반환 주소 사이에 넣어 두는 특별한 값이다. 버퍼가 넘쳐 반환 주소까지 덮으려면 카나리 값이 먼저 바뀐다.

함수가 종료될 때 카나리 값이 원래 값과 같은지 확인하고, 달라졌다면 프로그램을 중단한다.

지역 버퍼
→ 카나리
→ 프레임 포인터
→ 반환 주소

카나리는 전형적인 연속 덮어쓰기 공격을 탐지하는 데 도움이 된다. 그러나 논리 버그, 힙 오염, 정보 유출까지 막지는 못한다.

공격자가 카나리 값을 먼저 알아낸다면 우회 가능성도 생길 수 있다.

따라서 카나리는 근본적인 해결책이 아니라 추가적인 안전장치다.

잘못된 생각
카나리가 있으므로 오버플로우가 있어도 괜찮다.

올바른 방향
오버플로우가 발생하지 않도록 경계를 검사하고,
카나리는 추가 방어로 사용한다.

Use-After-Free와 메모리 수명

힙에서는 포인터의 수명을 잘못 관리해서 문제가 발생할 수 있다.

char *make_token(void)
{
    char *p = malloc(32);

    if (p == NULL) {
        return NULL;
    }

    strcpy(p, "session");
    free(p);

    return p;
}

이 코드에서는 p가 가리키는 메모리를 free()로 해제한 뒤 그 포인터를 반환한다.

포인터 변수 자체에는 예전 주소가 남아 있지만, 그 메모리는 더 이상 이 코드가 사용할 수 있는 공간이 아니다. 이후 다른 데이터가 그 위치를 사용할 수도 있다.

이렇게 해제된 메모리에 다시 접근하는 문제를 Use-After-Free라고 한다.

malloc
→ 정상 사용
→ free
→ 포인터는 남아 있지만 메모리 수명 종료
→ 다시 접근하면 Use-After-Free

이를 막으려면 누가 메모리를 해제할 책임이 있는지 명확해야 한다. C++에서는 스마트 포인터나 컨테이너를 사용하여 소유권과 해제를 객체 수명에 묶는 RAII 방식이 권장된다.

널 포인터 역참조

포인터가 항상 정상적인 객체를 가리킨다고 가정하는 것도 위험하다.

int read_sensor(struct sensor *s)
{
    return s->value;
}

s가 NULL이라면 s->value에 접근하는 순간 프로그램이 비정상 종료될 수 있다.

자동차 시스템에서는 단순한 크래시도 서비스 거부나 안전 기능 중단으로 이어질 수 있다.

int safe_read_sensor(struct sensor *s, int *out)
{
    if ((s == NULL) || (out == NULL)) {
        return -1;
    }

    *out = s->value;
    return 0;
}

중요한 것은 정상적인 입력뿐만 아니라 실패 경로도 설계하고 테스트하는 것이다.

센서 포인터가 NULL이면 어떻게 할 것인가?
읽기 함수가 실패하면 받은 데이터는 사용할 수 있는가?
일부만 초기화된 상태에서는 어떻게 정리할 것인가?

정수 오버플로우와 값의 절단

정수 오버플로우는 계산 결과가 변수의 표현 범위를 넘어설 때 발생한다.

특히 메모리 크기를 계산할 때 정수 오버플로우가 발생하면 실제 필요한 크기보다 작은 메모리를 할당하고, 그보다 많은 데이터를 쓰는 문제가 생길 수 있다.

uint16_t count = get_count();
uint16_t size = count * sizeof(struct item);

struct item *buf = malloc(size);
read_items(buf, count);

count * sizeof(struct item)의 결과가 16비트 범위를 넘으면 size에는 잘린 값이 저장될 수 있다.

예를 들어 실제로는 70,000바이트가 필요하지만 변수에는 훨씬 작은 값이 들어갈 수 있다. 그러면 작은 공간만 할당한 뒤 많은 데이터를 써서 힙 오버플로우가 발생한다.

수정할 때는 계산 전 상한을 검사하고, 더 넓은 타입으로 계산해야 한다.

if (count > MAX_COUNT) {
    return ERR_RANGE;
}

size_t size = (size_t)count * sizeof(struct item);

여기서 연산 결과가 타입 범위를 넘어 다시 처음부터 시작하는 것을 래핑이라고 한다. 큰 타입의 값을 작은 타입에 넣으면서 상위 비트가 사라지는 것은 절단에 가깝다.

INT30-C
덧셈이나 곱셈 같은 연산 결과가 범위를 넘는 문제

INT31-C
큰 값을 작은 타입으로 변환하면서 값이 손실되는 문제

둘은 비슷해 보이지만 발생하는 지점이 다르기 때문에 구분해야 한다.

포맷 스트링 취약점

출력 함수도 입력 검증의 대상이 된다.

다음 코드에서는 사용자 입력을 그대로 printf()의 포맷 문자열로 사용한다.

void bad(char *user)
{
    printf(user);
}

사용자 입력에 %x, %s, %n 같은 형식 지정자가 들어 있으면 printf()는 이를 단순한 문자로 출력하지 않고 명령처럼 해석한다.

그 결과 메모리 내용이 출력되거나, 특정 조건에서는 메모리에 값이 기록될 수도 있다.

다음처럼 포맷 문자열을 상수로 고정해야 한다.

void better(char *user)
{
    printf("%s", user);
}

이 부분의 핵심은 데이터와 명령을 분리하는 것이었다.

printf(user)
사용자 데이터가 명령으로 해석됨

printf("%s", user)
포맷은 개발자가 고정하고 사용자 입력은 값으로만 처리

MISRA 규칙을 코드에 연결하기

MISRA 규칙을 모두 외우는 것보다, 규칙이 어떤 위험을 막는지 이해하는 것이 중요했다.

강의에서는 다음 규칙들이 대표적으로 소개됐다.

Rule 1.3
정의되지 않은 동작에 의존하지 않는다.

Rule 10.3
더 좁은 타입에 값을 그대로 대입하지 않는다.

Rule 17.7
void가 아닌 함수의 반환값을 무시하지 않는다.

Rule 18.1
포인터 산술은 같은 배열 범위 안에서만 수행한다.

Rule 21.3
malloc/free 계열의 동적 메모리 할당을 사용하지 않는다.

예를 들어 CAN 메시지 길이를 32비트 변수에서 8비트 변수로 옮기는 상황을 생각할 수 있다.

uint32_t len = get_frame_len();
uint8_t dlc = len;

len이 255보다 크면 값이 잘릴 수 있다. 단순히 명시적 형변환을 붙이는 것만으로는 부족하고, 먼저 허용 범위를 검사해야 한다.

if (len > 8u) {
    return ERR_BAD_LEN;
}

uint8_t dlc = (uint8_t)len;

자동차 코드에서는 CAN의 데이터 길이처럼 프로토콜이 허용하는 범위와 함께 검증해야 한다.

CERT C 규칙과 취약 코드 연결

CERT C는 취약 코드와 규칙을 직접 연결해서 설명하기 좋았다.

취약 패턴CERT C 규칙

스택 버퍼 오버플로우	STR31-C
해제 후 사용	MEM30-C
널 포인터 역참조	EXP34-C
정수 연산 래핑	INT30-C
정수 변환 값 손실	INT31-C
포맷 스트링	FIO30-C

보고서나 코드 리뷰에서는 “위험해 보인다”라고만 적는 것보다 다음과 같이 작성하는 편이 정확하다.

외부 입력의 길이를 확인하지 않고 고정 배열에 복사하여
버퍼 경계를 초과할 수 있다.

CERT C STR31-C 위반에 해당하며,
대상 배열의 널 종료 공간까지 포함한 최대 길이를 보장해야 한다.

규칙 번호는 단순히 외우기 위한 번호가 아니라, 개발자들이 같은 문제를 짧고 정확하게 이야기하기 위한 공통 언어라는 점을 알 수 있었다.

현대·기아차의 자체 코딩 표준

국제 표준을 실제 자동차 기업에서 그대로 사용하기도 하지만, 기업의 개발 환경에 맞게 자체 표준으로 정리하기도 한다.

강의에서는 현대·기아차의 HKMC Secure C/C++ Coding Standard도 소개됐다.

예를 들어 앞에서 본 취약점들은 다음과 같이 HKMC 규칙으로도 연결된다.

버퍼 오버플로우
C-ARR-001

Use-After-Free
C-MEM-001

널 포인터 역참조
C-EXP-009

정수 오버플로우
C-INT-002 / C-INT-005

포맷 스트링
C-FIO-001

기업이 별도의 규칙 번호를 사용하더라도 기본적인 구조는 CERT C와 MISRA의 영향을 받는다.

결국 중요한 것은 규칙 이름보다도 입력 경계, 메모리 수명, 정수 범위, 오류 처리를 일관된 방식으로 관리하는 것이다.

AUTOSAR C++14와 RAII

C++에서는 메모리를 직접 할당하고 해제하기보다 객체의 수명에 자원 관리를 묶는 RAII 방식이 중요하다.

다음처럼 직접 malloc()과 free()를 사용하면 중간에 예외나 조기 반환이 발생했을 때 메모리 해제를 놓칠 수 있다.

int *p = static_cast<int *>(std::malloc(sizeof(int)));
std::free(p);

AUTOSAR C++14에서는 스마트 포인터와 표준 컨테이너를 사용하는 방향을 권장한다.

auto value = std::make_unique<int>(42);
std::vector<int> values{1, 2, 3};

객체가 범위를 벗어나면 메모리가 자동으로 해제되므로 사람이 모든 실행 경로에서 직접 delete를 호출할 필요가 줄어든다.

배열 할당과 해제 방식도 반드시 일치해야 한다.

int *a = new int[10];
delete a;        // 잘못된 방식

int *b = new int[10];
delete[] b;      // 형태는 맞음

다만 더 안전한 방향은 직접 new[]와 delete[]를 관리하기보다 std::array나 std::vector를 사용하는 것이다.

실패 경로도 코드의 일부다

함수가 실패할 수 있는데 반환값을 무시하면, 실패한 데이터를 정상 데이터처럼 사용할 수 있다.

can_read(&msg);
use(&msg);

can_read()가 실패했다면 msg는 사용할 수 없는 상태일 수 있다.

if (can_read(&msg) != CAN_OK) {
    return;
}

use(&msg);

C++의 std::optional을 사용할 때도 값이 있는지 확인해야 한다.

std::optional<Frame> frame = rx.read();

if (!frame) {
    return Error::NoFrame;
}

process(frame->id);

오류 처리는 정상 흐름을 방해하는 부가적인 코드가 아니라 프로그램 설계의 일부다.

소멸자처럼 객체를 정리하는 과정에서는 예외가 밖으로 빠져나가지 않도록 해야 한다. 정리 중 또 다른 예외가 발생하면 프로그램이 종료될 수 있기 때문이다.

~Logger() noexcept
{
    try {
        flush();
    } catch (...) {
        // 소멸자 밖으로 예외를 내보내지 않음
    }
}

결국 중요한 질문은 다음과 같다.

이 오류를 누가 복구할 수 있는가?
복구할 수 없다면 안전하게 중단할 수 있는가?
실패 경로가 테스트되어 있는가?

Required, Advisory와 Deviation

코딩 표준에는 규칙의 강도도 존재한다.

Required나 Mandatory 규칙은 원칙적으로 반드시 지켜야 한다.
Advisory는 품질과 안전을 위해 강하게 권고되는 규칙이다.

하지만 실제 산업 코드에서는 모든 규칙을 예외 없이 적용하기 어려운 경우도 있다. 이때 사용하는 개념이 Deviation이다.

Deviation은 규칙을 그냥 무시하는 것이 아니다.

왜 규칙을 지키지 못하는가?
어떤 위험이 남는가?
대체 방어 방법은 무엇인가?
누가 이를 검토하고 승인했는가?

이 내용을 문서로 남기는 절차다.

표준 준수의 목표는 무조건 위반 개수를 0으로 만드는 것만이 아니라, 남아 있는 위험을 알고 통제하고 있다는 사실을 증명하는 것이다.

정적 분석과 동적 분석

사람이 모든 코드 경로를 직접 확인하기는 어렵기 때문에 도구를 함께 사용한다.

강의에서는 정적 분석과 동적 분석의 차이를 설명했다.

정적 분석

정적 분석은 프로그램을 실행하지 않고 소스코드를 분석한다.

도구는 함수 이름, AST, 데이터 흐름, 제어 흐름 등을 살펴보며 잠재적인 문제를 찾는다.

찾을 수 있는 예
경계 밖 접근 가능성
널 포인터 역참조 가능성
미초기화 값
Use-After-Free
반환값 무시
MISRA/CERT 규칙 위반

장점은 프로그램을 실행하지 않아도 다양한 경로를 검사할 수 있다는 것이다. CI에 넣어 코드가 머지될 때마다 실행할 수도 있다.

단점은 실제 실행값을 모르기 때문에 오탐이 발생할 수 있다는 점이다. 도구가 위험하다고 판단했지만 실제로는 안전할 수도 있다.

하지만 오탐이라고 해서 그냥 무시해서는 안 된다. 왜 안전한지 근거를 남겨야 한다.

강의에서 사용한 대표적인 도구는 다음과 같았다.

cppcheck
C/C++ 정적 분석

clang-tidy
LLVM 기반 린터와 정적 검사

flawfinder
strcpy, printf 같은 위험 함수 탐지

gcc -fanalyzer
GCC의 코드 흐름 분석

동적 분석

동적 분석은 프로그램을 실제로 실행하면서 오류를 감시한다.

대표적인 도구가 AddressSanitizer와 UndefinedBehaviorSanitizer다.

ASan
버퍼 오버플로우
Use-After-Free
잘못된 메모리 접근

UBSan
정수 오버플로우
0으로 나누기
널 포인터 접근
잘못된 형변환

동적 분석의 장점은 실제로 오류가 발생한 줄과 원인을 정확하게 보여 준다는 것이다. 오탐도 비교적 적다.

단점은 실행한 경로만 검사한다는 점이다. 테스트에서 실행되지 않은 코드 경로의 문제는 찾지 못할 수 있다.

따라서 둘 중 하나만 사용하는 것이 아니라 함께 사용해야 한다.

정적 분석
실행하지 않고 넓게 검사

동적 분석
실제로 실행된 경로를 정확하게 검사

사람 리뷰
도구가 이해하지 못하는 설계와 의도를 판단

하나의 도구로 모든 문제를 찾을 수는 없다

강의 실습에서는 같은 취약 코드에 여러 도구를 실행했다.

위험 함수 이름을 찾는 flawfinder는 strcpy()나 위험한 printf() 사용은 잘 찾지만, 포인터의 수명을 추적해야 하는 Use-After-Free나 널 포인터 문제는 잡지 못할 수 있다.

cppcheck와 clang-tidy는 코드 흐름을 더 깊게 분석할 수 있지만, 모든 정수 오버플로우를 완벽하게 찾지는 못한다.

그래서 다음과 같은 흐름을 사용한다.

컴파일러 경고
→ 정적 분석
→ Sanitizer
→ 단위 테스트
→ 사람 코드 리뷰
→ 수정 후 재검사

도구별로 잡는 결함이 다르기 때문에 여러 단계를 통과시키는 것이 중요하다.

수정했다는 증거 남기기

취약점을 발견하고 코드를 수정했다고 말하는 것만으로는 충분하지 않다.

수정 전 코드에서 도구가 문제를 탐지하고, 수정 후 같은 도구를 실행했을 때 더 이상 문제가 나오지 않는지를 확인해야 한다.

강의에서는 실습 과정을 다음과 같이 정리했다.

취약 코드 확인
→ 정적 분석 실행
→ Sanitizer로 실제 오류 관찰
→ 표준 규칙에 매핑
→ 코드 수정
→ 같은 테스트와 분석을 다시 실행

예를 들어 다음과 같은 변경을 할 수 있다.

취약 코드보완 방향

strcpy(id, input)	크기를 제한한 복사
free(token) 후 다시 사용	해제 후 포인터를 NULL로 변경하고 재사용 금지
NULL 포인터 바로 역참조	사용 전 NULL 확인
작은 타입에서 정수 계산	더 넓은 타입과 범위 검사 사용
printf(user_msg)	printf("%s", user_msg)

그리고 한 번 고친 문제는 재발 방지 테스트로 남겨야 한다. 이후 코드가 변경되더라도 같은 취약점이 다시 생기지 않는지 자동으로 확인할 수 있기 때문이다.

코드 리뷰 보고서 작성 방식

이번 강의를 통해 취약 코드를 분석할 때 다음 구조로 작성하면 된다는 것을 알 수 있었다.

1. 취약 코드
어떤 코드에서 문제가 발생하는지 제시

2. 위험
버퍼 경계 초과, 크래시, 정보 유출 등 영향 설명

3. 원인
길이 검사 누락, 포인터 수명 오류, 정수 범위 오류 등

4. 표준 매핑
MISRA, AUTOSAR, CERT C, HKMC 규칙 연결

5. 수정 방향
안전한 코드와 설계 방식 제시

6. 검증 증거
정적 분석, Sanitizer, 단위 테스트 결과 기록

예를 들어 버퍼 오버플로우는 다음과 같이 정리할 수 있다.

원인:
외부 입력 길이를 검사하지 않고 고정 길이 배열에 복사함.

위험:
배열 밖의 메모리를 덮어써 인접 변수 또는 반환 주소가 손상될 수 있음.

표준:
CERT C STR31-C, MISRA Rule 18.1 등과 연결됨.

수정:
입력 길이를 검사하고 대상 버퍼 크기를 기준으로 제한하여 복사함.

검증:
경계값 테스트와 ASan을 실행하고 수정 전후 결과를 비교함.

이렇게 작성하면 단순한 코드 설명이 아니라, 실제 산업 코드 리뷰와 비슷한 형태가 된다.

이번 강의에서 기억할 핵심

이번 강의의 내용은 다음과 같이 정리할 수 있었다.

시큐어 코딩은 위험한 코드를 공통 규칙으로 설명하는 과정이다.

많은 취약점은 입력 경계와 메모리 수명에서 시작한다.

MISRA와 AUTOSAR는 안전한 작성 방법을 정하고,
CERT C는 취약 코드 패턴을 설명한다.

ISO 26262와 ISO/SAE 21434는
위험 관리와 검증 근거를 요구한다.

정적 분석, 동적 분석, 테스트와 사람 리뷰를 함께 사용해야 한다.

취약점 수정은 코드 변경에서 끝나는 것이 아니라,
수정 근거와 재검사 결과까지 남겨야 한다.

마무리

이번 강의를 듣기 전에는 코딩 표준을 단순히 회사에서 정해 놓은 까다로운 문법 규칙 정도로 생각했다.

하지만 자동차나 임베디드 환경에서는 작은 포인터 실수나 정수 변환 하나가 ECU 중단이나 차량 기능 오작동으로 이어질 수 있다. 이런 환경에서 코딩 표준은 개발자를 불편하게 만들기 위한 문서가 아니라, 과거에 반복됐던 사고를 줄이기 위한 공통 약속에 가깝다.

특히 기억에 남은 것은 다음 문장이었다.

시큐어 코딩의 목표는
취약한 코드를 보고 “위험하다”고 말하는 데서 끝나지 않는다.

왜 위험한지 설명하고,
어떤 규칙을 위반했는지 연결하고,
수정한 뒤 안전해졌다는 증거를 남기는 것까지가 한 과정이다.

결국 안전한 코드는 특별한 기술 하나로 만들어지는 것이 아니라, 입력 크기를 확인하고, 포인터 수명을 관리하고, 반환값을 검사하고, 위험한 함수 사용을 제한하는 기본적인 습관에서 시작된다는 점을 알 수 있었다.

하계 보안 세미나 4일차 - 자동차 보안 이해

song.3_3 — Mon, 6 Jul 2026 10:32:46 +0900

1~3일차에서는 암호나 PQC처럼 비교적 수학적인 내용이 많았다면, 이번 강의는 실제 자동차 안에 들어가는 ECU, CAN, 인포테인먼트, 키 포브, 충전기, 모바일 API 같은 현실적인 공격면을 중심으로 진행됐다.

강의를 듣고 보니 자동차는 그냥 이동수단이 아니라 수많은 컴퓨터와 네트워크가 붙어 있는 하나의 거대한 임베디드 시스템에 가까웠다.

자동차 안에는 여러 ECU가 있고, ECU끼리는 CAN, LIN, Ethernet 같은 내부 네트워크로 연결된다. 여기에 인포테인먼트, 블루투스, 모바일 앱, 텔레매틱스, EV 충전기까지 연결되면서 공격면이 점점 넓어지고 있다.

자동차 보안에서 중요한 점

자동차 보안이 일반 IT 보안과 다른 점은, 공격 결과가 단순한 데이터 유출에서 끝나지 않을 수 있다는 것이다.

웹 서비스가 뚫리면 계정 정보나 데이터가 유출될 수 있다. 물론 이것도 심각하지만, 자동차에서는 공격이 차량 제어, 운전자 혼란, 안전 기능 오작동 같은 물리적인 문제로 이어질 수 있다.

예를 들어 인포테인먼트 시스템이 공격당하면 단순히 음악이 꺼지는 정도가 아니라, 차량 내부 네트워크로 연결된 CAN 메시지를 조작하거나 운전자에게 잘못된 정보를 보여줄 수도 있다. 강의에서도 기아 Gen5 Head Unit 취약점 사례를 통해, 공격자가 M-CAN 버스로 전송되는 CAN 프레임을 생성하는 명령을 삽입할 수 있고, 이로 인해 잘못된 속도나 경고 메시지 표시, 멀티미디어 기능 조작, 시스템 재부팅 같은 문제가 생길 수 있다고 설명했다.

즉 자동차 보안은 정보 보안이면서 동시에 안전과도 연결된다.

일반 IT 보안:
정보 유출, 계정 탈취, 서비스 중단

자동차 보안:
정보 유출 + 차량 기능 조작 + 운전자 안전 문제

Tesla VCSEC 취약점: 정수 오버플로우

강의 초반에는 Tesla Model 3의 VCSEC 모듈에서 발견된 CVE-2025-2082 사례가 나왔다.

이 취약점은 정수 오버플로우(Integer Overflow)와 관련되어 있었다. 정수 오버플로우는 컴퓨터가 처리할 수 있는 정수 범위를 넘어서는 값을 계산하거나 저장하려고 할 때 생기는 문제다. 단순한 계산 오류처럼 보이지만, 실제로는 잘못된 메모리 주소 계산이나 잘못된 버퍼 크기 할당으로 이어질 수 있다.

이 사례에서는 TPMS, 즉 타이어 공기압 모니터링 시스템에서 전송되는 인증서 응답을 조작하여 특정 조건에서 정수 오버플로우를 유발할 수 있었다고 한다. 성공하면 원격 코드 실행까지 가능할 수 있었기 때문에 위험도가 높게 평가되었다.

다만 이 공격은 아무 곳에서나 인터넷으로 바로 되는 형태가 아니라, 공격자가 차량 근처의 무선 통신 범위 같은 인접 네트워크 환경에 있어야 하는 것으로 설명됐다. 그래서 위험하지만 공격 조건도 같이 봐야 한다.

이 사례를 보면서 느낀 점은, 차량 보안 취약점도 결국 기본적인 소프트웨어 취약점과 이어져 있다는 것이다.

정수 오버플로우
→ 잘못된 크기 계산
→ 메모리 처리 오류
→ 코드 실행 가능성

자동차라고 해서 완전히 다른 보안 세계가 아니라, 메모리 취약점과 입력 검증 문제가 그대로 등장한다.

EV 충전기 취약점: 버퍼 오버플로우

다음으로는 Autel MaxiCharger AC Elite Business C50 충전소 취약점인 CVE-2024-23957 사례가 나왔다.

이 취약점은 DLB, 즉 Dynamic Load Balancing 프로토콜 구현에서 발생했다. 강의에서는 AES 키를 파싱하는 과정에서 사용자 입력 데이터의 길이를 제대로 검증하지 않고 고정 길이의 스택 기반 버퍼에 복사하면서 문제가 생겼다고 설명했다.

이런 경우 공격자는 버퍼 경계를 넘어 데이터를 덮어쓸 수 있고, 성공하면 충전소 장치에서 임의 코드를 실행할 수 있다.

여기서 중요한 점은 공격 대상이 차량 자체가 아니라 EV 충전기라는 것이다. 자동차 보안이라고 하면 차량 내부만 생각하기 쉽지만, 전기차 환경에서는 충전기, 충전 네트워크, 차량과 충전기 사이의 통신도 공격면이 된다.

차량 보안 공격면:
차량 내부 ECU
인포테인먼트
모바일 앱
블루투스
키 포브
OBD 포트
EV 충전기
텔레매틱스

강의 후반의 최신 취약점 동향에서도 Pwn2Own Automotive의 주요 타깃이 EV 충전기와 IVI, 즉 인포테인먼트 쪽으로 확장되고 있다고 설명했다. 최근 자동차 공격면은 차량 내부 ECU만이 아니라 차량 주변 생태계까지 넓어지고 있다.

Kia 인포테인먼트 취약점

기아 Gen5 Head Unit 관련 CVE-2020-8539 사례도 다뤘다.

Head Unit은 쉽게 말하면 차량 안의 인포테인먼트 시스템이다. 내비게이션, 오디오, 화면 표시, 스마트폰 연결 같은 기능을 담당한다. 겉으로는 편의 기능처럼 보이지만, 차량 내부 네트워크와 이어질 수 있기 때문에 보안 관점에서는 중요한 공격면이 된다.

강의에서는 공격자가 micomd 실행 데몬을 통해 허가되지 않은 명령 삽입과 기능 작동을 허용할 수 있었다고 설명했다. micomd는 마이크로컨트롤러 관련 장치를 관리하고 제어하는 백그라운드 프로세스라고 볼 수 있다.

이 사례에서 중요한 점은 인포테인먼트가 단순한 화면 장치가 아니라, 내부 CAN 버스와 연결될 수 있다는 점이다. 공격자가 M-CAN 버스로 CAN 프레임을 생성하는 명령을 삽입할 수 있다면, 해당 버스에 연결된 장치들이 오작동하거나 운전자에게 잘못된 정보를 표시할 수 있다.

처음에는 “인포테인먼트가 해킹되어도 음악이나 내비만 문제 생기는 거 아닌가?”라고 생각할 수 있는데, 차량 내부 네트워크와 연결되어 있으면 영향 범위가 더 커질 수 있다.

Kia 딜러/포털 API 취약점

이번 강의에서 가장 현실적으로 무섭게 느껴졌던 부분은 Kia 딜러/포털 및 모바일 API 취약점이었다.

이 취약점은 차량 내부 펌웨어나 CAN 메시지를 직접 건드리는 것이 아니라, 딜러/관리 포털 API의 인증 및 권한 논리 결함과 관련된 사례였다. 공격자는 차량 번호판 같은 단순 식별자를 이용해 VIN을 확보하고, 딜러 권한을 악용해 차량 제어 권한을 탈취할 수 있었던 것으로 설명됐다.

기술적 원인은 크게 네 가지로 정리할 수 있었다.

과도한 딜러 권한
권한 경계 오류
취약한 식별자 사용
약한 계정 생성 절차

여기서 핵심은 “딜러 계정인지 아닌지만 보고, 그 딜러가 실제로 해당 차량을 관리할 권한이 있는지 엄격하게 확인하지 않았다”는 점이었다. 즉, 인증은 된 것처럼 보여도 권한 검사가 제대로 되지 않으면 문제가 생긴다.

이건 웹 보안에서 자주 나오는 IDOR나 권한 검증 오류와도 비슷하게 느껴졌다. 차량 보안이라고 해도 결국 서버 API와 권한 모델이 약하면 차량 원격 기능까지 위험해질 수 있다.

차량 번호판
→ VIN 등 차량 식별 정보
→ 딜러 권한 악용
→ 소유자 연결 조작
→ 원격 제어 기능 악용 가능

이 사례를 보면서 자동차 보안은 차량 내부만 보는 것이 아니라, 모바일 앱과 클라우드 API까지 같이 봐야 한다는 점이 확실해졌다.

키 포브와 롤링 코드

키 포브(Key Fob)는 차량 문을 잠그거나 열고, 시동을 걸거나 트렁크를 여는 데 사용하는 무선 리모컨이다. 버튼을 누르면 RF 신호를 차량의 RKE 수신 장치로 보내는 방식이다.

만약 키 포브가 항상 같은 코드를 보낸다면, 공격자는 그 신호를 한 번 가로챈 뒤 나중에 그대로 재전송해서 차량 문을 열 수 있다. 이런 공격을 막기 위해 사용하는 방식이 롤링 코드(Rolling Code)다.

롤링 코드는 매번 다른 코드를 사용한다. 키 포브와 차량은 같은 알고리즘과 카운터를 가지고 있고, 버튼을 누를 때마다 카운터가 증가하면서 새로운 코드가 만들어진다.

고정 코드:
항상 같은 코드 전송
→ 한 번 가로채면 재사용 가능

롤링 코드:
매번 다른 코드 전송
→ 이전 코드는 다시 보내도 무시됨

그런데 CVE-2022-37418과 관련된 롤백 공격은 이 롤링 코드의 재동기화 메커니즘을 악용한다. 공격자는 차량 소유자가 키 포브를 누르는 순간 신호를 가로채고 동시에 방해해서, 소유자가 다시 버튼을 누르게 만든다. 이 과정에서 연속된 유효 신호를 확보하고, 재동기화 로직을 악용해 차량의 카운터를 과거 값으로 되돌릴 수 있다는 흐름이었다.

처음에는 롤링 코드가 있으면 재사용 공격이 불가능하다고 생각했는데, 구현된 재동기화 규칙에 논리적 결함이 있으면 다시 문제가 생길 수 있다는 점이 흥미로웠다.

ECU란 무엇인가

자동차 내부 구조를 이해하려면 ECU부터 잡아야 한다.

ECU는 Electronic Control Unit, 전자제어장치다. 자동차 안에서 조향, 제동, 엔진, 좌석, 창문, 정보 표시 등 특정 기능을 제어하는 작은 컴퓨터라고 보면 된다. 차량에는 기능별로 여러 ECU가 들어가고, 이 ECU들이 내부 네트워크를 통해 서로 통신한다.

보안 관점에서 ECU는 중요한 자산이다. 전원 입력, 네트워크 버스 라인, 센서 입력, 액추에이터 출력 등이 모두 공격 표면이 될 수 있다.

ECU 내부에는 PCB, 저항, 커패시터, 다이오드, 릴레이, 솔레노이드, 전원 관리 칩, 네트워크 트랜시버, 메모리 칩, MCU나 SoC 같은 제어 장치가 들어간다.

특히 MCU 기반 ECU에서는 메모리와 디버그 인터페이스가 중요하다. ECU 제어 소프트웨어와 캘리브레이션 데이터가 MCU 메모리에 들어 있고, 공격자는 온칩 디버그 기능이나 시리얼 플래시 프로그래밍 인터페이스를 악용해 접근을 시도할 수 있다.

ECU = 차량 안의 작은 제어 컴퓨터
MCU = ECU 안에서 실제 제어를 담당하는 핵심 칩
CAN/LIN/Ethernet = ECU들이 서로 말하는 통신망

차량 내부 네트워크와 CAN

차량 안의 ECU들은 혼자 동작하지 않는다. 서로 데이터를 주고받아야 한다. 이때 사용하는 대표적인 내부 네트워크가 CAN이다.

CAN 메시지는 대략 CAN ID, DLC, Data Field, CRC 같은 요소로 구성된다. CAN ID는 메시지 식별자이고, DLC는 데이터 길이, Data Field는 실제 데이터, CRC는 오류 탐지용 값이다.

CAN은 차량 제어에 오래 사용된 중요한 프로토콜이지만, 보안 관점에서는 약점도 있다. 내부 네트워크에 일단 접근하면 정상 ECU처럼 메시지를 보내는 공격이 가능할 수 있기 때문이다. 특히 OBD 포트나 취약한 게이트웨이를 통해 내부 네트워크로 들어갈 수 있다면 문제가 커진다.

강의에서는 여러 차량 통신 프로토콜도 함께 비교했다.

CAN:
엔진, 변속기, 섀시 제어, 진단에 사용

LIN:
좌석, 창문 같은 저가 센서/액추에이터에 사용

FlexRay:
ABS, ESC, ADAS 등 안전 핵심 기능 일부에 사용

Automotive Ethernet:
ADAS, 인포테인먼트, 고속 센서 데이터에 사용

UART/I²C:
디버그나 칩 내부/근거리 센서 통신에 사용

GMSL:
카메라, 디스플레이, 오디오 같은 대용량 멀티미디어 전송에 사용

각 프로토콜마다 속도와 용도가 다르기 때문에, 공격면도 다르게 봐야 한다. 예를 들어 CAN은 OBD 악용이나 DoS 공격, Automotive Ethernet은 외부 공격 경유지와 실시간성 붕괴, GMSL은 카메라나 영상 신호 변조로 인한 ADAS 오작동이 보안 포인트가 될 수 있다.

OBD 포트는 정비용이지만 공격 진입점도 될 수 있다

OBD 포트는 원래 차량 진단과 정비를 위해 만들어진 표준 기능이다. 정비소에서 차량 상태를 확인하거나 오류 코드를 읽을 때 사용한다.

하지만 보안 관점에서는 내부 네트워크에 접근할 수 있는 물리적 진입점이 될 수 있다. 강의에서는 OBD 포트를 통해 공격자가 차량 내부 네트워크에 무단 접근하고, 게이트웨이에 보안 필터가 부족하거나 네트워크 세분화가 약하면 안전하지 않은 메시지를 내부 ECU에 전달할 수 있다고 설명했다.

즉 OBD 포트 자체가 나쁜 것은 아니다. 문제는 OBD 포트로 들어온 메시지를 어디까지 허용할 것인지, 게이트웨이가 얼마나 잘 필터링하는지다.

OBD 포트의 원래 목적:
진단, 정비, 배출가스 관련 상태 확인

보안상 위험:
내부 네트워크 접근 경로
진단 명령 악용
게이트웨이 필터 부족 시 제어 메시지 전달 가능

차량 E/E 아키텍처의 변화

강의에서는 차량 E/E 아키텍처의 변화도 다뤘다. 예전에는 기능별로 ECU가 많이 흩어져 있는 분산 구조가 일반적이었다. 그런데 차량 기능이 복잡해지면서 ECU 수가 많아지고, 배선과 관리가 어려워졌다.

그래서 점점 도메인 집중형 구조와 존 아키텍처로 발전하고 있다.

도메인 집중형 구조는 기능별 ECU들을 도메인 전용 ECU로 통합하는 방식이다. 예를 들어 파워트레인 도메인, 섀시 도메인처럼 기능별로 묶는다. 관리 효율이 좋아지고 비용을 줄일 수 있지만, 도메인 ECU가 공격당하면 영향 범위도 커진다.

존 아키텍처는 차량을 물리적인 구역, 즉 zone 단위로 나누고 각 Zone ECU가 주변 센서와 액추에이터를 모아 상위 Vehicle Computer와 연결하는 방식이다. 배선을 단순화하고 고성능 컴퓨팅을 집중시킬 수 있지만, Zone ECU와 Vehicle Computer가 핵심 공격 표면이 된다.

또 DCU, 즉 Domain Control Unit도 나왔다. DCU는 여러 소규모 ECU를 통합한 고성능 ECU로, SDV의 핵심 구성요소다. 하나의 플랫폼에서 여러 애플리케이션이 함께 실행될 수 있으므로 메모리와 자원 분리, 스케줄링 간섭 방지 같은 보안 설계가 중요하다.

분산형 ECU:
기능별 ECU가 많음

도메인 집중형:
기능별 도메인 ECU로 통합

존 아키텍처:
차량을 물리적 구역으로 나누어 Zone ECU가 담당

SDV / DCU:
소프트웨어 업데이트로 기능을 활성화하거나 변경

자동차가 점점 소프트웨어 정의 차량으로 바뀌면서, 보안도 단순한 ECU 보호에서 플랫폼 보안과 네트워크 보안으로 확장되고 있다는 느낌이었다.

블루투스와 외부 연결 공격면

요즘 차량은 스마트폰과 연결되는 기능이 많다. 핸즈프리 통화, 음악 재생, 앱 연동, 차량 초기 설정 등에서 블루투스가 사용된다. 일부 사용자는 OBD-II와 연결되는 블루투스 동글을 사용하기도 한다.

강의에서는 차량 환경에서 볼 수 있는 블루투스 위협도 정리했다. Car Whisperer, Bluesnarfing, Bluebugging, Bluejacking, BlueBorne, KNOB, BlueFrag 같은 공격 기법이 소개됐다.

이름은 많지만 핵심은 하나로 정리할 수 있다.

무선 연결은 편리하지만,
차량 바깥에서 접근 가능한 공격면이 된다.

특히 블루투스는 사용자가 가까운 거리에서 편하게 연결하기 위해 만든 기능이다. 그런데 보안이 약하면 공격자도 가까운 거리에서 접근할 수 있다. 자동차 보안에서는 이런 외부 연결 지점을 하나하나 공격면으로 봐야 한다.

자동차 보안 규정: UN R155

자동차 보안은 기술 문제이면서 동시에 규제 문제이기도 하다.

강의에서는 UN R155도 소개됐다. UN R155는 차량 사이버보안과 관련된 중요한 규정으로, 사이버보안 관리 시스템인 CSMS 구축과 차량 사이버보안 위험 관리 요구사항을 다룬다. 공급망 전반의 위험 관리와 차량 설계 단계에서의 보안 조치도 요구한다.

중요한 점은 자동차 보안이 이제 선택 사항이 아니라는 것이다. 차량을 만들 때부터 보안 위험을 식별하고, 관리하고, 대응하는 체계가 필요하다.

자동차 보안은 패치만의 문제가 아니라,
설계 단계부터 운영과 공급망까지 이어지는 관리 문제다.

핵심

자동차는 여러 ECU와 네트워크가 연결된 컴퓨터 시스템이다.
차량 보안 취약점은 메모리 오류, 권한 검증 실패, API 논리 오류, 무선 통신 문제 등에서 발생한다.
공격면은 차량 내부뿐 아니라 모바일 앱, 클라우드, 충전기, 블루투스, OBD 포트까지 확장된다.
차량 구조가 SDV와 존 아키텍처로 바뀌면서 보안 설계도 더 중요해진다.

특히 기억에 남은 건 자동차 보안이 단순히 차 문을 여는 해킹이 아니라는 점이었다.
정수 오버플로우, 버퍼 오버플로우, 명령 삽입, 권한 검증 오류, 롤링 코드 재동기화 문제처럼 우리가 일반 보안에서 배우는 개념들이 자동차 환경에 그대로 적용된다.

다만 자동차에서는 그 결과가 물리적인 안전 문제로 이어질 수 있다는 점이 다르다.

마무리

이번 강의를 통해 자동차 보안은 생각보다 훨씬 넓은 분야라는 걸 알게 되었다.

ECU와 CAN 같은 차량 내부 구조도 알아야 하고, 모바일 API와 클라우드 권한 모델도 봐야 한다. 블루투스나 키 포브 같은 무선 통신도 중요하고, 전기차 시대에는 충전기와 충전 인프라도 공격면이 된다.

자동차 보안은 차량 하나만 지키는 것이 아니라,
차량과 연결된 모든 컴퓨터, 네트워크, API, 무선 장치를 함께 지키는 일이다.

처음에는 자동차 보안이 낯설었지만, 결국 기본은 입력 검증, 권한 검증, 메모리 안전, 네트워크 분리, 안전한 업데이트, 공격면 관리라는 점에서 기존 보안과 이어져 있었다. 다만 자동차라는 특성상 보안 실패가 실제 안전 문제로 이어질 수 있기 때문에 더 조심스럽고 체계적인 접근이 필요하다고 느꼈다.

하계 보안 세미나 3일차 - ML-KEM·ML-DSA(Module-LWE에서 크기·속도·하이브리드 PQC까지)

song.3_3 — Mon, 6 Jul 2026 10:27:14 +0900

PQC 전환은 단순히 알고리즘 하나 바꾸는 일이 아니다

이번 3일차에서는 2일차에서 배웠던 격자 기반 암호가 실제 표준 알고리즘인 ML-KEM과 ML-DSA로 어떻게 이어지는지 배웠다.
2일차가 SIS, LWE, Module-LWE 같은 수학적인 배경을 잡는 시간이었다면, 3일차는 그 개념이 실제 통신, 코드, 패킷 안에서 어떻게 보이는지를 확인하는 느낌이었다.

처음에는 ML-KEM, ML-DSA, HKDF, AES-GCM, Wireshark 같은 단어가 한꺼번에 나와서 헷갈렸는데, 전체 흐름을 잡아보니 결국 중요한 질문은 하나였다.

패킷에 보여도 되는 값은 무엇이고,
절대 보이면 안 되는 값은 무엇인가?

이번 강의에서는 이 기준을 중심으로 PQC가 실제 통신에 들어갈 때 어떤 역할을 하는지 정리할 수 있었다.

안전한 통신에는 비밀과 신원이 둘 다 필요하다

보안통신에서 중요한 것은 단순히 내용을 못 보게 하는 것만이 아니다.
도청을 막는 것도 중요하지만, 내가 통신하고 있는 상대가 진짜 서버인지 확인하는 것도 중요하다.

강의에서는 이걸 비밀과 신원으로 나누어 설명했다.

키 교환 = 비밀을 만드는 역할
서명 = 상대의 신원을 증명하는 역할

예를 들어 클라이언트와 서버가 같은 대칭키를 만들어야 통신 내용을 암호화할 수 있다. 이 역할을 하는 것이 KEM이고, PQC에서는 ML-KEM이 여기에 해당한다.

반대로 “이 서버가 진짜 서버인지”를 확인하려면 전자서명이 필요하다. 인증서에 들어 있는 공개키가 정말 해당 서버의 것인지 확인해야 하기 때문이다. 이 역할을 하는 것이 ML-DSA다.

즉, 양자내성암호로 넘어갈 때는 키 교환만 바꾸면 끝나는 것이 아니라, 서명 쪽도 같이 봐야 한다.

키 교환 → ML-KEM
서명 / 인증서 → ML-DSA

공개키만으로는 진짜 주인을 알 수 없다

강의에서 인증서 이야기도 나왔다. 처음에는 공개키만 있으면 되는 것 아닌가 싶었는데, 공개키 자체에는 “이 키가 누구 것인지”라는 정보가 보장되어 있지 않다.

누군가가 “이게 내 공개키야”라고 말한다고 해서, 그 사람이 진짜 서버인지 알 수는 없다. 공격자가 중간에서 자기 공개키를 보내도 사용자는 겉으로 보기에는 구분하기 어렵다. 이것이 중간자 공격 상황이다.

그래서 인증서가 필요하다.

인증서는 쉽게 말하면 공개키에 신원을 묶어 놓은 디지털 신분증이다.
인증서에는 서버의 도메인, 서버 공개키, 발급자, 유효기간, 그리고 CA의 전자서명이 들어간다.

중요한 점은 개인키는 인증서에 들어가지 않는다는 것이다.
인증서에 들어가는 것은 공개키와 신원정보이고, 개인키는 서버가 따로 비밀로 보관해야 한다.

인증서에 들어가는 것:
서버 신원
서버 공개키
CA의 서명

인증서에 들어가면 안 되는 것:
서버 개인키

결국 인증서는 “이 공개키가 진짜 이 서버의 공개키다”라는 사실을 CA의 서명으로 보장하는 구조다.

암호화, KEM, DSA는 서로 다르다

강의에서 헷갈리기 쉬운 개념으로 공개키 암호화, KEM, DSA가 나왔다. 셋 다 공개키와 비밀키가 나오지만 목표가 다르다.

공개키 암호화는 메시지 자체를 보호하는 방식이다.
상대방의 공개키로 메시지를 암호화하고, 상대방은 자신의 비밀키로 복호화한다.

KEM은 메시지를 직접 암호화하는 것이 아니라, 양쪽이 같은 shared secret을 만들기 위한 방식이다. 여기서 만들어진 shared secret은 이후 대칭키를 만드는 재료가 된다.

DSA는 암호화가 아니라 서명이다.
비밀키로 메시지에 서명하고, 검증자는 공개키로 그 서명이 맞는지 확인한다. 그래서 DSA의 목표는 내용 숨기기가 아니라 출처와 무결성 확인이다.

정리하면 이렇게 볼 수 있다.

공개키 암호화 = 메시지를 잠근다
KEM = shared secret을 합의한다
DSA = 누가 보냈는지 증명한다

이 구분이 잡히니까 ML-KEM과 ML-DSA의 역할도 훨씬 명확해졌다.

ML-KEM은 shared secret을 만드는 방식이다

ML-KEM은 Key Encapsulation Mechanism이다.
긴 데이터를 직접 암호화하는 알고리즘이 아니라, 클라이언트와 서버가 같은 shared secret을 만들도록 도와주는 알고리즘이다.

강의에서는 ML-KEM의 흐름을 KeyGen, Encaps, Decaps 세 단계로 설명했다.

KeyGen  → 공개키 pk와 비밀키 sk 생성
Encaps  → pk로 ciphertext ct와 shared secret 생성
Decaps  → sk와 ct로 같은 shared secret 복원

여기서 패킷에 보여도 되는 값은 pk와 ct다.
반대로 sk와 shared secret은 절대 네트워크에 나오면 안 된다.

이 부분이 가장 중요했다.

보여도 되는 값:
public key(pk)
ciphertext(ct)

숨겨야 하는 값:
secret key(sk)
shared secret(ss)
AES-GCM key

ML-KEM에서 ciphertext는 일반적인 의미의 “암호화된 메시지”라기보다는, shared secret을 복원하기 위한 캡슐에 가깝다.

강의에서도 ct는 shared secret을 담은 상자가 아니라, 비밀키를 가진 쪽이 임시 비밀값을 복원할 수 있게 해주는 재료라고 설명했다. 이 임시 비밀값에서 다시 shared secret을 만들고, 그 shared secret을 HKDF에 넣어 AES-GCM 키를 만든다.

즉 실제 데이터 암호화 흐름은 이렇게 이어진다.

ML-KEM으로 shared secret 생성
→ HKDF로 AES-GCM 키 파생
→ AES-GCM으로 실제 데이터 암호화

shared secret은 바로 쓰지 않는다

ML-KEM으로 얻은 shared secret은 32바이트 값이다.
그런데 이 값을 그대로 데이터 암호화 키로 쓰는 것이 아니라, HKDF 같은 KDF를 거쳐 세션키를 만든다.

여기서 HKDF는 shared secret을 실제 암호화에 쓰기 좋은 키로 다듬어 주는 역할을 한다. 그리고 transcript 같은 통신 문맥 정보를 salt나 info로 같이 넣어 키를 파생한다.

최종적으로 실제 데이터를 보호하는 것은 AES-GCM이다.

shared secret
→ HKDF
→ AES-GCM key
→ nonce + ciphertext + tag

여기서도 역할 구분이 중요하다.
PQC가 실제 데이터를 직접 암호화하는 것이 아니라, 안전한 대칭키를 만들기 위한 앞단 역할을 한다. 실제 본문 암호화는 여전히 AES-GCM 같은 대칭키 암호가 맡는다.

ML-DSA는 암호화가 아니라 서명이다

ML-DSA는 디지털 서명 알고리즘이다.
ML-KEM이 shared secret을 만드는 역할이라면, ML-DSA는 “누가 보냈는지”와 “중간에 바뀌지 않았는지”를 확인하는 역할을 한다.

서버는 secret key로 메시지나 transcript에 서명한다.
클라이언트는 public key로 그 서명이 맞는지 검증한다.

여기서 신기했던 점은 검증자는 비밀키를 몰라도 된다는 것이다.
비밀키는 서명을 만들 때만 필요하고, 검증은 공개키로 가능하다.

Sign:
secret key로 signature 생성

Verify:
public key로 message와 signature 확인

메시지가 1바이트라도 바뀌면 검증이 실패한다.
그래서 서명은 출처 증명과 무결성 확인을 동시에 해준다.

NIST 표준 기준

이번 강의에서는 FIPS 203, 204, 205도 정리했다.

FIPS 203 → ML-KEM
FIPS 204 → ML-DSA
FIPS 205 → SLH-DSA

ML-KEM은 키 합의와 shared secret 생성 쪽 표준이고, ML-DSA는 전자서명 표준이다. SLH-DSA는 해시 기반 전자서명으로, 보수적인 백업 선택지에 가깝다.

SLH-DSA는 해시 기반이라 신뢰는 크지만, 서명 크기가 크고 느리다는 단점이 있다. 그래서 오늘 강의의 중심은 ML-KEM과 ML-DSA였다.

ML-KEM과 ML-DSA는 크기가 커진다

PQC로 전환하면 보안성만 좋아지는 것이 아니라, 운영 비용도 같이 봐야 한다. 특히 패킷 크기와 서명 크기가 커진다.

ML-KEM-768 기준으로 보면 공개키는 1184B, ciphertext는 1088B 정도다. shared secret은 세 파라미터 모두 32B로 동일하다.

ML-KEM-768
public key: 1184B
ciphertext: 1088B
shared secret: 32B

ML-DSA도 마찬가지로 서명 크기가 커진다.
ECDSA-P256 서명은 약 72B 정도인데, ML-DSA-65의 signature는 3309B 정도다.

ECDSA-P256 signature: 약 72B
ML-DSA-65 signature: 약 3309B

이 부분에서 PQC 전환은 단순히 “더 안전한 알고리즘으로 교체”가 아니라는 생각이 들었다.
인증서 체인, 펌웨어, 코드서명, 저장공간, 네트워크 지연까지 같이 고려해야 한다.

TLS 핸드셰이크에서 KEM과 서명이 만나는 위치

강의에서는 TLS 핸드셰이크 안에서 ML-KEM과 ML-DSA가 어디에 들어가는지도 설명했다.

흐름은 대략 이렇다.

ClientHello
→ ML-KEM public key 전송

ServerHello
→ ML-KEM ciphertext 회신

Certificate / CertificateVerify
→ ML-DSA 서명으로 서버 신원 증명

Application Data
→ shared secret에서 파생한 AES-GCM 키로 본문 암호화

즉 KEM은 세션키 합의를 담당하고, 서명은 서버 신원을 증명한다.
둘은 비슷해 보이지만 완전히 다른 역할을 한다.

KEM = 세션키 합의
서명 = 서버 신원 증명

실습에서는 무엇이 보이고 무엇이 숨는지를 확인한다

이번 강의의 실습은 크게 세 단계로 볼 수 있었다.

첫 번째는 로컬에서 ML-KEM, ML-DSA, AES-GCM 출력이 정상인지 확인하는 것이다.
예를 들어 ML-KEM에서는 shared secret이 양쪽에서 같은지 확인하고, ML-DSA에서는 원본 메시지 검증은 True, 변조된 메시지 검증은 False가 나오는지 확인한다.

shared secret equal: True
verify original: True
verify tampered: False

두 번째는 서버와 클라이언트를 나눠 실행하는 것이다.
작은 TLS처럼 client_hello, server_hello, encrypted_request, encrypted_response 흐름을 직접 만들어 본다.

세 번째는 Wireshark로 패킷을 보는 것이다.
여기서 가장 중요한 건 “패킷에 보여도 되는 값”과 “보이면 안 되는 값”을 구분하는 것이다.

패킷에 보이는 값은 다음과 같다.

kem_public_key_b64
kem_ciphertext_b64
signature_b64
nonce_b64
ciphertext_tag_b64

반대로 보이면 안 되는 값은 다음과 같다.

shared secret
AES-GCM key
plaintext response body

이 구분이 실제 보안통신을 이해하는 데 가장 중요한 부분이라고 느꼈다.

하이브리드 전환

전환기에는 기존 ECDH를 바로 버리고 ML-KEM만 쓰는 것이 아니라, X25519와 ML-KEM을 함께 사용하는 하이브리드 방식도 나온다.

예를 들어 X25519MLKEM768은 기존 X25519와 ML-KEM-768을 함께 사용하는 형태다.
이 방식은 기존 방식의 안정성과 PQC의 양자내성 보안을 같이 가져가려는 전환기 전략이라고 볼 수 있다.

다만 하이브리드 방식은 key_share 크기가 커진다.
ClientHello가 커지면 MTU, 지연, 중간장비 호환성 같은 문제도 같이 봐야 한다.

그래서 PQC 전환은 “지원한다 / 지원하지 않는다”만 보면 안 된다.
실제로 어떤 그룹이 협상되었는지, 패킷 크기가 얼마나 커졌는지, 중간장비가 막지는 않는지까지 확인해야 한다.

구현이 새면 수학이 맞아도 깨질 수 있다

마지막으로 구현 취약점 이야기도 중요했다.

수학적으로 안전한 알고리즘이라도 구현에서 정보가 새면 공격이 가능해질 수 있다.
특히 PQC 구현에서는 디캡슐화 실패 처리, 상수시간 구현, 랜덤 품질, 패킹/역패킹 버그 같은 부분이 중요하다.

예를 들어 실패 여부가 시간 차이나 오류 메시지로 드러나면 공격자가 그 차이를 이용할 수 있다.
또 비밀값에 따라 분기나 배열 접근, 루프 횟수가 달라지면 타이밍 정보가 새어 나갈 수 있다.

강의에서는 KyberSlash 사례도 언급했다. ML-KEM/Kyber 구현에서 비밀 의존 나눗셈 타이밍 때문에 키 복원 가능성이 제기되었고, 여러 구현이 패치되었다. 이걸 보면서 “표준 알고리즘을 쓴다”는 것만으로는 부족하고, 구현 방식까지 안전해야 한다는 점을 다시 느꼈다.

마무리

이번 3강은 2강에서 배운 Module-LWE 개념이 실제 표준과 통신 흐름으로 이어지는 내용이었다.

정리하면 이렇게 볼 수 있다.

ML-KEM은 shared secret을 만드는 역할
ML-DSA는 서버 신원과 메시지 무결성을 증명하는 역할
shared secret은 HKDF를 거쳐 AES-GCM 키가 됨
실제 데이터 보호는 AES-GCM이 담당
패킷에는 pk, ct, signature는 보일 수 있음
shared secret, AES key, plaintext는 보이면 안 됨

가장 기억에 남은 점은 PQC 전환이 단순히 알고리즘 하나 바꾸는 일이 아니라는 것이었다.
키 교환, 서명, 인증서, 패킷 크기, 중간장비, 구현 취약점까지 같이 봐야 실제로 안전한 전환이 가능하다.

이번 강의를 듣고 나니 ML-KEM과 ML-DSA가 그냥 어려운 이름의 알고리즘이 아니라, TLS 같은 실제 보안통신 안에서 각각 “비밀 만들기”와 “신원 증명”을 맡는 부품이라는 점이 조금 더 명확해졌다.

하계 보안 세미나 2일차 - 격자 기반 암호 (SIS · LWE부터 Kyber와 ML-KEM)

song.3_3 — Mon, 6 Jul 2026 10:20:45 +0900

PQC가 AES를 없애는 것이 아니라 공개키 암호 쪽을 바꾸는 것

이번 강의에서는 양자컴퓨터 시대의 공개키 암호를 주제로, 격자 기반 암호가 왜 중요한지 배웠다.
제목만 봤을 때는 SIS, LWE, Kyber, ML-KEM 같은 용어가 한 번에 나와서 꽤 어렵게 느껴졌는데, 전체 흐름을 잡아보면 핵심은 생각보다 단순했다.

기존의 공개키 암호인 RSA와 ECC는 지금까지 많이 사용되어 왔지만, 양자컴퓨터가 충분히 발전하면 위험해질 수 있다. 특히 Shor 알고리즘은 소인수분해와 이산로그 문제를 빠르게 풀 수 있기 때문에 RSA와 ECC의 기반을 흔들 수 있다. 그래서 양자컴퓨터 이후에도 버틸 수 있는 암호, 즉 PQC(Post-Quantum Cryptography, 양자내성암호)가 필요해졌다.

PQC는 AES를 대체하는 것이 아니다

처음에 헷갈렸던 부분은 “PQC가 나오면 AES도 사라지는 건가?”였다.
그런데 강의에서는 역할이 다르다고 설명했다.

AES 같은 대칭키 암호는 실제 데이터를 빠르게 암호화하는 역할을 한다. 반면 PQC는 RSA나 ECC처럼 키 교환이나 서명 쪽 공개키 암호를 대체하는 쪽에 가깝다. 즉, PQC가 세션키를 안전하게 만들고, 그 세션키로 AES-GCM 같은 대칭키 암호가 실제 데이터를 보호하는 구조다.

보안통신 흐름을 간단히 보면 다음과 같다.

인증서 확인
→ KEM 또는 ECDH로 공유 비밀 생성
→ HKDF로 세션키 파생
→ AES-GCM으로 실제 데이터 암호화
→ 키 관리

결국 PQC 전환은 단순히 알고리즘 이름 하나 바꾸는 일이 아니라, 통신 프로토콜과 키 관리까지 같이 봐야 하는 문제였다.

격자란 무엇인가

이번 강의의 중심은 격자 기반 암호였다.
격자는 쉽게 말하면, 일정한 규칙으로 찍힌 점들의 집합이라고 볼 수 있다.

PPT에서는 격자를 “기저 벡터들의 모든 정수 결합”이라고 설명했다. 말이 조금 어려운데, 풀어보면 어떤 방향 벡터들이 있고, 그 벡터들을 정수 배만큼 더해서 만들 수 있는 점들이 격자점이 된다. 예를 들어 v = 2b₁ + b₂처럼 기저 벡터를 정수만큼 조합하면 격자 위의 한 점이 된다.

여기서 중요한 점은 같은 격자라도 어떤 기저로 보느냐에 따라 문제의 난이도가 달라질 수 있다는 것이다. 짧고 서로 직교에 가까운 좋은 기저를 알면 문제가 쉽게 풀리지만, 길고 거의 평행한 나쁜 기저만 알고 있으면 같은 문제도 매우 어려워진다. 강의에서는 이 차이를 “좋은 기저는 비밀키, 나쁜 기저는 공개키”처럼 설명했다.

SIS: 짧은 해를 찾는 문제

SIS는 Short Integer Solution의 약자로, 짧은 정수해 문제라고 한다.

형태는 대략 이렇게 생겼다.

A · z ≡ 0 (mod q)

여기서 공개된 행렬 A가 있고, 이 식을 만족하는 작은 벡터 z를 찾아야 한다.
그냥 아무 해나 찾는 것은 비교적 쉽지만, 성분이 -1, 0, 1처럼 작은 해를 찾는 것이 어렵다. 강의에서는 이 “짧다”는 조건이 SIS의 어려움을 만든다고 설명했다.

즉 SIS는 한마디로 정리하면 이렇게 볼 수 있다.

공개된 A가 있을 때,
A·z가 0이 되도록 만드는 작은 z를 찾아라.

SIS는 해시, 서명, 커밋먼트 같은 쪽과 연결된다.

LWE: 노이즈가 섞인 식에서 비밀을 찾는 문제

LWE는 Learning With Errors의 약자다.
이름 그대로, 오류가 섞인 상태에서 뭔가를 알아내야 하는 문제다.

기본 형태는 다음과 같다.

b = A · s + e

여기서 A와 b는 공개될 수 있고, s는 비밀값, e는 작은 오류다.

오류가 없다면 공격자는 그냥 연립방정식을 풀어서 s를 구할 수 있다. 그런데 중간에 작은 오류 e가 섞이면 상황이 달라진다. 겉보기에는 값이 조금만 흔들린 것 같지만, 실제로 식을 풀면 완전히 다른 답이 나올 수 있다. PPT에서도 노이즈가 없을 때는 비밀값이 깔끔하게 복원되지만, +1, -1 정도의 작은 노이즈만 들어가도 가우스 소거 결과가 틀어지는 예시가 나왔다.

내가 이해한 LWE의 핵심은 이거였다.

정답 근처에 일부러 안개를 끼워서,
겉으로는 보이지만 정확히 되돌리기는 어렵게 만든다.

SIS와 LWE 차이 정리

강의 중간정리에서는 SIS와 LWE를 이렇게 구분했다.

SIS = 짧은 우연을 찾는 문제
LWE = 오류가 섞인 직선을 복원하는 문제

SIS는 A·z ≡ 0을 만족하는 작은 z를 찾는 문제이고, LWE는 b = A·s + e에서 오류 e 때문에 숨겨진 s를 찾기 어렵게 만드는 문제다. 둘 다 결국 “작은 것”이 핵심이다. SIS는 작은 해, LWE는 작은 오류가 난이도를 만든다.

ML-KEM은 무엇인가

ML-KEM은 Module-Lattice Key Encapsulation Mechanism의 약자다.
쉽게 말하면, 격자 기반 수학을 이용해서 두 사람이 같은 공유 비밀을 만들 수 있게 해주는 방식이다.

여기서 중요한 건 ML-KEM이 긴 데이터를 직접 암호화하는 것이 아니라는 점이다. ML-KEM은 이후 대칭키를 만들기 위한 shared secret을 안전하게 합의하는 역할을 한다. 그 shared secret은 그대로 쓰이지 않고, KDF를 거쳐 AES-GCM 같은 AEAD 암호의 키로 사용된다.

흐름은 다음과 같다.

KeyGen   → 공개키 pk, 개인키 sk 생성
Encaps   → pk로 캡슐화해서 ct와 shared secret 생성
Decaps   → sk와 ct로 같은 shared secret 복원
그 다음 → KDF를 거쳐 실제 대칭키로 사용

공개키 pk와 암호문 ct는 네트워크로 오가도 되지만, 개인키 sk와 shared secret은 절대 새면 안 된다.

왜 Module-LWE가 나오는가

일반 LWE는 이론적으로는 좋지만, 그대로 쓰기에는 공개키가 너무 커질 수 있다. 그래서 실용화를 위해 Ring-LWE, Module-LWE 같은 구조가 나온다.

강의에서는 Module-LWE를 “숫자 행렬의 각 칸이 작은 다항식으로 바뀐 버전”처럼 설명했다. 숫자 하나하나를 전부 들고 다니는 대신, 다항식 구조를 이용해 더 작고 빠르게 만드는 것이다. Kyber, 즉 ML-KEM은 이런 Module-LWE 구조를 이용해 실용적인 키 교환 방식으로 만든 표준이라고 볼 수 있다.

NTT는 보안이 아니라 속도를 위한 장치

강의 후반부에서 NTT도 나왔다. 처음에는 이게 또 새로운 보안 가정인가 싶었는데, 그건 아니었다.

NTT는 Number Theoretic Transform의 약자로, 다항식 곱셈을 빠르게 하기 위한 계산 방식이다. ML-KEM 내부에서는 다항식 곱셈이 많이 필요한데, 그냥 모든 항을 하나씩 곱하면 느리다. NTT는 다항식을 곱하기 쉬운 좌표계로 바꾼 뒤, 각 자리끼리 곱하고 다시 원래 형태로 되돌리는 방식이다.

한 문장으로 정리하면:

Module-LWE는 보안의 근거,
NTT는 그 계산을 빠르게 돌리는 엔진.

이 둘을 구분하는 게 중요했다.

구현 보안도 중요하다

수학적으로 안전한 알고리즘이라고 해서 실제 구현까지 자동으로 안전한 것은 아니다. 강의에서는 KyberSlash 같은 사례도 언급하면서, 비밀값에 따라 실행 시간이 달라지면 타이밍이나 캐시를 통해 정보가 샐 수 있다고 설명했다.

구현에서 중요한 요소는 다음과 같았다.

상수시간 구현
정확한 mod q 감산
올바른 샘플링과 분포
재암호화 검사
실패 처리 숨기기
검증 벡터 확인

특히 Decaps 과정에서 실패 여부가 밖으로 드러나면 공격자가 반복 질의를 통해 정보를 모을 수 있기 때문에, 실패 처리도 조용하고 일정하게 해야 한다.

TLS에서는 어떻게 쓰이나

기존에는 X25519 같은 ECDH 방식으로 공유 비밀을 만들었다면, 양자컴퓨터 위협 이후에는 ML-KEM 같은 PQC 기반 KEM이 그 자리를 대체하거나 함께 사용될 수 있다.

강의에서는 전환기에는 X25519와 ML-KEM을 함께 쓰는 하이브리드 방식도 설명했다. 중요한 점은 이것도 실제 데이터를 암호화하는 부분이 아니라, 세션키를 만드는 앞단이라는 것이다. 실제 데이터 보호는 여전히 AES-GCM 같은 AEAD가 담당한다.

마무리

이번 강의는 수식이 많아서 따라가기 쉽지는 않았지만, 큰 흐름은 이렇게 정리할 수 있었다.

양자컴퓨터가 RSA/ECC를 위협한다.
그래서 PQC가 필요하다.
그중 격자 기반 암호가 유력하다.
격자 기반 암호의 핵심 문제로 SIS와 LWE가 있다.
ML-KEM은 LWE 계열을 실용화한 키 캡슐화 표준이다.
실제 데이터 암호화는 여전히 AES-GCM 같은 대칭키 암호가 맡는다.

가장 기억에 남은 부분은 PQC가 AES를 없애는 것이 아니라 공개키 암호 쪽을 바꾸는 것이라는 점이었다. 그리고 수학적으로 안전한 구조를 만드는 것도 중요하지만, 실제 구현에서 시간 차이나 실패 처리 같은 작은 정보가 새지 않게 하는 것도 그만큼 중요하다는 걸 알 수 있었다.

하계 보안 세미나 1회차 - 깨지는 암호의 해부학

song.3_3 — Mon, 6 Jul 2026 10:11:41 +0900

암호 알고리즘 자체가 약해서 깨지는게 아니라 쓰는 방식이 잘못되면 깨진다

대칭키: 같은 키 하나로 암호화와 복호화 (빠른 본문 암호화)

AES, ChaCha20
빠르지만, 그 키를 어떻게 안전하게 나눠갖느냐가 문제

비대칭키: 공개키와 개인키가 따로 (키 교환/ 서명)

RSA, ECC, ECDSA
느리지만, 서로 미리 키를 공유하지 않아도 통신을 시작할 수 있음

해시: 키가 없고, 데이터를 고정된 길이의 값으로 바꿈 (무결성 확인)

SHA-256
무결성 확인에는 쓰지만, 인증은 아님
내용이 바뀌었나? 는 볼 수 있지만, 누가 보냈는지는 모름

TLS는 이 세 개가 같이 쓰임 (ex: HTTPS)

처음 연결할 때 비대칭키로 세션키를 안전하게 합의
실제 데이터 전송은 빠른 대칭키
중간에 변조됐는지는 해시 / MAC / AEAD 태그로 확인

AES는 블록하나를 암호화하는 기계

실제 데이터는 길다. 여러 블록을 어떻게 이어서 암호화할지 정해야함

→ 운영모드

ECB (평문 블록)

항상 같은 암호문 블록
이미지를 암호화해도 윤곽이 남아 실무x

CBC

이전 암호문 블록과 XOR해서 다음 블록을 암호화
패턴은 잘 숨기지만, 패딩 검사를 잘못하면 패딩 오라클 공격 가능

CTR

카운터 값을 암호화해서 키스트림을 만들고, 평문과 XOR
빠르고 편하지만, nonce를 재사용하면 큰일남

GCM

CTR 방식에 인증 태그까지 붙인 방식
요즘 많이 쓰지만, nonce 재사용에 매우 취약

nonce 재사용이 왜 위험하냐?

CTR/GCM에서는 이런 식

암호문 C = 평문 P ⊕ 키스트림 KS

그런데 nonce를 재사용하면 같은 키스트림 KS가 또 나옴

그러면

C1 = P1 ⊕ KS

C2 = P2 ⊕ KS

둘을 XOR하면

C1 ⊕ C2 = P1 ⊕ P2

왜냐하면 KS가 두 번 XOR돼서 사라짐

즉 키를 몰라도 두 평문의 관계가 드러남 그래서 사용금지

오라클은 서버가 실수로 알려주는 작은 힌트 (1비트 응답)

예를 들어 서버가 암호문을 복호화했을 때

“패딩 맞음”

“패딩 틀림”

이렇게 다르게 반응하면, 공격자는 그 차이를 이용

처음에는 겨우 1비트 정보 같지만, 이걸 수백 번, 수천 번 반복하면 평문이나 키를 알아낼 수 있음

핵심

오라클 = 서버가 흘리는 yes/no 힌트

이 1비트가 반복되면 비밀이 풀린다

패딩 오라클

CBC 복호화 공식이 핵심

Pᵢ = Dₖ(Cᵢ) ⊕ Cᵢ₋₁

여기서

Pᵢ = 알고 싶은 평문 블록
Cᵢ = 현재 암호문 블록
Dₖ(Cᵢ) = AES 복호화 결과, 공격자는 모름
Cᵢ₋₁ = 직전 암호문 블록, 공격자가 조작 가능

중요한 건

공격자는 AES 키를 모른다.

그런데 직전 암호문 블록 Cᵢ₋₁은 바꿀 수 있다.

그리고 서버가 패딩 맞는지 틀리는지 알려준다.

그래서 공격자가 Cᵢ₋₁을 한 바이트씩 바꿔가며 서버에 보냄

서버가 “패딩 OK”라고 하는 순간, 공격자는 그 바이트에 대한 정보를 얻음

결국 평문을 한 바이트씩 복원 가능

[git 배우기] - 다음 단계로

song.3_3 — Fri, 15 May 2026 04:18:07 +0900

다시 열심히 공부해 봅시다

앞 내용 벌써 까먹진 않았겠죠??

이번 내용도 총 4개인데요

HEAD 분리하기
상대 참조 (^) (Relative Refs)
상대 참조 #2 (~)
Git에서 작업 되돌리기

HEAD분리부터 시작할게요 이름이 되게 폭력적이다

이거는 현재 체크아웃된 커밋(현재 작업중인 커밋)을 가리키는데요

일반적으로 브랜치의 이름을 가리키고 있습니다

여기에

git checkout C1

이러면 HEAD가 분리가 되네요

다음으로는 상대 참조 입니다

커밋들을 해시로 구분하는 것은 귀찮기 때문에 사용합니다

상대 커밋은 두가지 간단한 방법이 있는데요

한번에 한 커밋 위로 움직이는 ^
한번에 여러 커밋 위로 올라가는 ~<num>

먼저 캐럿 (^) 연산자 입니다

참조 이름에 하나씩 추가할 때마다, 명시한 커밋의 부모를 찾게 됩니다

main^    //main의 부모
main^^   //main의 조부모

git checkout main^

이거 해주면

HEAD가 부모로 감

또 참조인 HEAD도 상대참조를 위해 사용할 수 있어요

git checkout C3; git checkout HEAD^; git checkout HEAD^; git checkout HEAD^

이거 해주면 C3에서 HEAD가 분리되어, 하나씩하나씩 올라갑니다

애니메이션이 너무 슉 지나가버려서 캡쳐를 못하겠어요

결과만 볼까요?

결과

자 다음 "~" (틸드) 연산자 입니다.

^는 올라가는데에 너무 오래걸리잖아요

이거는 올라가고 싶은 부모의 갯수가 뒤에 숫자로 옵니다

git checkout HEAD~4

쉽네요 ㅋㅑㅋㅑ

브랜치 강제로 옮기기도 해봅시다

-f 옵션을 이용해요

git branch -f main HEAD~3

브랜치를 저 위로 빠르게 옮길 수 있게 되었습니다!

문제를 하나 풀어보겠습니다

빨간화면처럼 만들어야하는데요

3개의 명령어로 간단하게 풀 수 있습니다

처음에 6개나 써서 풀었지만요..;

git branch -f bugFix C0
git branch -f main C6
git checkout C1

하면 다음으로 넘어갈 수 있어요

드디어 마지막

Git에서 작업 되돌리기입니다

낮은 수준의 일(개별 파일이나 묶음을 스테이징)과 높은 수준의 일(실제 변경이 복구)이 있는데

후자에 집중할게요

Git에서 변경한 내용을 되돌리는 방법은 크게 두가지가 있습니다

git reset
git revert

먼저 git reset은

마치 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것입니다

브랜치가 예전의 커밋을 가리키도록 이동시켜요

git reset HEAD~1

불투명해지네요

다음 Git 리버트(revert)입니다

각자의 컴퓨터에서 작업하는 로컬 브랜치의 경우 리셋(reset)을 잘 쓰겠지만

다른 사람이작업하는 리모트 브랜치에는 쓸 수 없습니다

이럴 때 변경분을 되돌리고, 이 내용을 다른 사람들과 공유하기 위해서는

git revert를 써야합니다

git revert HEAD

문제를 풀어볼게요

local(로컬 브랜치)과 pushed(리모트 브랜치)에 있는 최근 두 번의 커밋을 되돌려야해요

로컬에는 reset, 리모트는 revert쓰면 되겠네요

git reset main
git checkout pushed
git revert pushed

Git 재밌네요

근데 어려워요

공부하는 모든 분들 대단해요~

[git 배우기] - git 기본

song.3_3 — Fri, 15 May 2026 02:19:45 +0900

안녕하세요

git을 배워보겠습니다....

Learn Git Branching 사이트를 사용했구요

메인은 총 4갠데 그 중 첫 번째 git 기본 입니다

Git 커밋 소개
Git에서 브랜치 쓰기
Git에서 브랜치 합치기(Merge)
리베이스(rebase)의 기본

커밋은 Git 저장소에 디렉토리에 있는 모든 파일에 대한 스냅샷을 기록하는건데요

디렉토리 전체를 복붙하는거랑 비슷한데 훨씬 유용한 방법입니다

왜냐면 Git은 가능한 한 커밋을 가볍게 유지하고자 해서

커밋할 때마다 디렉토리 전체를 복사하지는 않거든요

각 커밋은 저장소의 이전 버전과 다음 버전의 변경내역("delta")를 저장해요

그래서 대부분 커밋이 그 커밋 위에있는 부모 커밋을 가리킵니다

저장소를 복제(clone)하려면 모든 변경분(delta)를 풀어내야 하는데, 이 때문에 명령행 결과로

resolving deltas

이거를 볼 수 있다네욥..

아직 뭔소린진 잘 모르겠지만

일단은

커밋은 프로젝트의 스냅샷이다

라는 것만 알고있을게욥

커밋은 매우 가볍고 커밋 사이의 전환도 엄청 빠르대요

두 번 커밋한 상태

여기서

git commit

을 하면

부모는 C1, 어떤 커밋을 기반으로 변경된 것인지를 가리킴

이렇게 됩니다

쉽네요 아직까지는!

커밋 두 번 더 하니까 다음 단계로 와졌어요

다음은 Git 브랜치입니다

브랜치는 특정 커밋에 대한 참조(reference)입니다

많이 만들어도 부담이 없어서, 작은 단위로 잘게 나누는 것이 좋습니다

많이 만들면 좋나봐요

브랜치는 단순히

하나의 커밋과 그 부모 커밋들을 포함하는 작업 내역

이라고 기억합시다

자 여기서

git branch newImage

해주면

브랜치 newImage가 커밋 C1을 가리킴

main 밑에 뭔가 생겼습니다

여기서 커밋을 하면 어떻게 될까요?!

다시

git commit

main(별 붙은 애) 만 움직이고 아까 만든 newImage는 가만히 있습니다

(*)별표 가 붙은 애가 이동하는거래요

근데 저는 newImage를 이동시키고 싶은데요?

그러면

git checkout newImage

해주면 됩니다

커밋까지 같이 해줄게요

git checkout newImage; git commit

브랜치 newImage가 커밋 C1을 가리킴

성공입니다!

저런식으로 하니까 넘어가지네요

이제 세 번째예요

브랜치와 합치기(Merge)인데요

두개의 부모(parent)를 가리키는 특별한 커밋을 만들어냅니다

-> 한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 그리고 그 두 부모의 모든 부모들의 작업내역을 포함한다는 말

음 잘 모르겠으니 그림을 볼까요

브랜치 두개와 독립되 커밋이 하나씩

저장소에 지금까지 작업한 내역이 나뉘어서 담겨 있네요

bugFix브랜치를 main브랜치에 합쳐봅시다

git merge bugFix

main이 두 부모가 있는 커밋을 가리키고 있어요

또 색도 바뀌었는데요

합쳐지면 두 색이 섞여요

이해하기 더 쉬워졌구만

bugFix브랜치 쪽을 제외한 나머지 커밋이 지금 main브랜치 색이네요

이거 다 합쳐야하니까 main브랜치에 bugFix를 합쳐볼게요

git checkout bugFix; git merge main

이제 색이 다 똑같아졌어요!

bugFix가 main 부모쪽에 있었어서

그냥 bugFix를 main이 붙어 있는 커밋으로 이동시키기만 하면 되네요

또 비슷하게 했더니 넘어가졌어요

이제 대망의 마지막

Git 리베이스(Rebase) 입니다

브랜치끼리의 작업을 접목하는건데요

리베이스는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는거래요

리베이스를 쓰면 저장소의 커밋 로그랑 이력이 깨끗하고 보기좋아져요

bugFix 브랜치에서의 작업을 main 브랜치 위로 직접 옮겨 놓으려고 합니다

그러면 순서대로 개발한 것처럼 보이게 돼요

git rebase main

오호

이거는 main을 선택한 상태인데요

이제 이거를 bugFix로 리베이스 해볼게요

git rebase main

main이 bugFix의 부모쪽에 있어서

단순히 그 브랜치를 더 앞쪽의 커밋을 가리키게 이동하는게 전부입니다

우와...

이렇게

commit, branch, merge, rebase를 배워봤습니다

복습을 잘 해야겠어요 헷갈리네요

또 merge랑 rebase의 차이점을 잘 모르겠어서 찾아봤는데요

구분	merge	rebase
핵심 이미지	갈라진 길을 다시 합류시킴	내 작업을 최신 길 뒤에 다시 붙임
한 줄 뜻	두 브랜치를 합친다	내 커밋을 다른 브랜치 뒤로 옮겨 붙인다
새 커밋	보통 merge commit이 생김	기존 커밋이 복사되어 C2'처럼 새 커밋이 생김
기록	“여기서 브랜치를 합쳤다”는 기록이 남음	갈라졌던 흔적이 줄어들고 깔끔해 보임
커밋 이름 변화	기존 커밋 이름이 거의 그대로 유지됨	커밋이 새로 만들어져서 이름이 바뀜
사이트에서 구분법	선이 갈라졌다가 다시 합쳐지면 merge	C2', C3'처럼 작은따옴표가 있으면 rebase
명령어 예시	git merge bugFix	git rebase main
명령어 뜻	현재 브랜치에 bugFix를 합침	현재 브랜치를 main 뒤로 옮겨 붙임
주의점	현재 내가 있는 브랜치에 합쳐짐	현재 내가 있는 브랜치가 이동됨
언제 사용?	합친 기록을 남기고 싶을 때	커밋 기록을 일자로 정리하고 싶을 때
초보자 기억법	“두 갈래를 합쳐서 새 합류점 만들기”	“내 작업을 최신 main 뒤에 다시 줄 세우기”

다음에 또 올게요.......