1. Overview (컴퓨터 보안 개요)

컴퓨터 보안은 단순히 시스템을 ‘안전하게 만든다’는 수준을 넘어, 지속적으로 변화하는 적응형 공격자(adaptive adversary)를 상대로 정보를 보호하는 매우 도전적인 영역이다. 이 챕터에서는 왜 보안이 어려운지, 그리고 컴퓨터 보안에서 다루는 핵심 개념들이 무엇인지에 대해 전체적인 그림을 제시한다.

1.1. 왜 보안은 어려운가?

But let me be clear about one thing that may make cybersecurity different than all else and that is that we have sentient opponents.

Geer

보안이 어려운 가장 큰 이유는 공격자가 지능적이고 반응형(adaptive adversary)이라는 점이다.

While bridge-builders must address hostile conditions, Nature does not form new type of storms in response to improved techniques. Security is seen as uniquely difficult.

Herly and Oorschot

예를 들어 건축가는 바람이나 지진처럼 정해진 물리적 조건에 맞춰 설계하면 된다. 건축가가 이러한 악조건에 대응하는 동안 자연이 새로운 형식의 위협을 만들지는 않는다.

하지만 보안 설계자는 ‘생각하는 인간’ 즉, 공격자와 싸운다. 우리가 보안을 강화하면, 공격자는 더 정교한 방법을 고안해 그것을 뚫는다. 이런 끊임없는 공격과 방어의 군비경쟁(arms race)이 보안의 본질이다.

If you want security, you must be prepared for inconfinience.

General B.W. Chidlaw 12 December 1954

보안을 강화하면 일반 사용자 입장에서는 시스템이 불편해질 수밖에 없다. 예를 들어, 인증을 강화하면 로그인 절차가 복잡해지고, 접근을 제한하면 업무 흐름이 느려질 수 있다. 이처럼 보안(security)과 편의성(convenience)은 종종, 아니 많은 경우에서 트레이드오프(trade-off) 관계에 있다.

1.2. 왜 보안이 필요한가?

우리는 AI와 컴퓨터의 힘으로 점점 더 똑똑한 세상을 만들고 있고, 이는 인간의 번영(prosperity)과 직결되어 있다.

하지만 이 지능은 악의적인 의도(malicious intent)로도 사용될 수 있다. 영화 ‘1984’에서처럼 감시사회가 현실이 될 수도 있고, 실제로도 LLM(대규모 언어 모델)을 악용한 프롬프트 탈취(prompt injection), 피싱 URL 자동 생성, 훈련 데이터 유출 등의 사례가 등장하고 있다.

Training Data Extraction Attacks 학습 데이터를 출력시키는 프롬프트 입력을 통한 공격
System Prompt Extraction Attacks 시스템 프롬프트를 출력시키는 프롬프트 입력을 통한 공격
Phishing URL Generation 무고한 유저(Benign User)의 복붙에 대해 피싱 URL을 응답시키는 악의적 외부 프롬프트

그렇기 때문에 우리는 보안과 프라이버시를 통해 개인과 사회를 지키지 않으면 안 된다.

1.3. 메모리 안전성의 “위기”

Google은 Chrome의 5개 Major Release 버전의 Renderer 프로세스에서 5~15개의 공격 가능한 취약점을 보고했다.
Google은 안드로이드 오픈소스 프로젝트의 취약점 중 90%가 메모리 손상(Memory Corruption)에서 기인한다고 추정한다.
Microsoft는 지난 12년 동안의 보안 패치가 메모리 손상 버그에 대한 것이었다고 보고했다.

이렇듯 C, C++에서 메모리 안전성 관리에 실패하여 발생하는 취약점이 매우 많았고, 안드로이드의 경우 Memory-Safe 한 Rust로 코드를 이전하고 있다.

1.4. 보안이란?

Security: [noun] the state of being free from danger danger or threat.

이러한 위협(Threat)은 공격자(Adversaries)에 기인한다.

안전한 시스템(Secure System)은 공격자의 시도에도 해야하는 일을 하는 시스템을 말한다. 공격자는 시스템의 내/외부 모두에서 공격을 시도할 수 있다.

1.5. CIA Triad - Threats to what

다음의 3가지 요소를 정보 보안의 가장 기본이 되는 3요소 - CIA Triad라 부른다.

기밀성 (Confidentiality) - 허가되지 않은 사람이 정보에 접근하지 못하도록 하는 것 - 예: 암호화(encryption), 접근 제어(access control) 등
무결성 (Integrity) - 정보가 허가되지 않은 방식으로 변경되지 않도록 보장하는 것 - 예: 서명(digital signature), 체크섬(checksum), 무결성 검증
가용성 (Availability) - 정상적인 사용자가 필요할 때 정보나 시스템에 지속적으로 접근할 수 있는 것 - 예: DoS(Denial of Service), DDos(Distributed Denial of Service) 공격

위의 CIA Triad의 각 요소를 위반하거나 침해하는 잠재적 요소를 Threat(위협) 이라 한다.

컴퓨터 시스템이 위협받는 방식은 다양하며, 대표적으로 다음 네 가지로 분류할 수 있다.

Disclosure (정보 노출)
- 비인가된 정보 접근으로 Confidentiality를 침해한다.
- 예: 스누핑(snooping), 패킷 감청 등
Deception (속임수)
- 잘못된 정보의 수용 유도로 Integrity를 침해한다.
  - 예: 위조 데이터, 가짜 신호 수용 등
Disruption (운영 방해)
- 정상적인 기능을 방해하는 행위로 Availability를 침해한다.
  - 예: 시스템 중단, 네트워크 단절 등
Usurpation (권한 탈취)
- 비인가된 시스템 컨트롤로 Confidentiality와 Integrity를 침해한다.
  - 예: 관리자 권한 탈취, 루트킷 설치 등

공격자(adversary)는 내부에 있을 수도 있고(내부자 공격), 외부에 있을 수도 있다. 내부자는 시스템 권한을 이미 일부 갖고 있기 때문에, 더 치명적인 위협이 될 수 있다.

1.6. Threats to Data (데이터의 위협)

보안에서 다루는 데이터는 세 가지 상태에서 위협받을 수 있다.

전송 중인 데이터 (Data in Transit)
- 네트워크를 통해 이동할 때 도청되거나 변조될 수 있다.
- 예: MITM(man-in-the-middle) 공격
저장 중인 데이터 (Data at Rest)
- 하드디스크나 클라우드에 저장되어 있는 데이터는 도난이나 유출 위험이 있다.
- 예: 디스크 암호화
사용 중인 데이터 (Data in Use)
- 메모리에서 실행 중인 데이터를 노리는 공격.
- 예: 메모리 취약점 공격

1.7. Defend Against Threats (보안 대응)

보안 대응은 크게 다음의 두가지로 이루어진다.

Security Policy (보안 정책) 어떤 것이 허용되고, 허용되지 않는지
Security Mechanism (보안 수단) 보안 정책을 강제하는 도구, 프로시저, 메소드

또한 보안 대응은 다음의 세 가지 레벨에서 이루어진다.

예방 (Prevention): 공격 자체를 막는 것. (예: 방화벽, 암호화)
탐지 (Detection): 공격이 발생했는지 확인하는 것. (예: 로그, IDS)
복구 (Recovery): 피해를 회복하고 시스템을 정상 상태로 되돌리는 것. (예: 백업 복구)

보안은 집 보안 시스템과 유사하다. 문을 잠그고(예방), 알람을 설치하며(탐지), 보험에 가입한다(복구). 각각의 계층이 서로를 보완해야 진정한 보안이 달성된다.

많은 경우에서 Defense = Attacking 으로 간주된다.

아이러니하게도, 자신이 Attacker라고 생각한다면 이러한 보안 위협에 대해 더 잘 대응할 수 있다.

1.7.1. Defense in Depth (다층 방어)

보안을 강화하는 방법 중 하나는 여러 계층(layer)의 방어막을 두는 것이다.

예를 들어, 시스템에 들어오려면 먼저 VPN을 거쳐야 하고, 그 안에서도 관리자 권한이 필요하며, 최종적으로 민감 정보는 암호화되어 있어야 한다.

이러한 다층 방어는 공격자가 한 계층을 뚫더라도 다음 방어를 우회하기 어렵게 만든다.

1.7.2. Assumption & Trust (신뢰와 가정)

보안 정책과 메커니즘은 어떤 가정(assumption) 위에서 작동한다. 예를 들어, “열쇠가 복제되지 않는다”는 가정을 했는데, 실제로는 쉽게 복제된다면 보안은 실패한다.

신뢰(Trust)는 시스템 설계 시 어디에 의존할지를 정하는 것이며, 이 신뢰가 잘못되면 전체 보안이 무너질 수 있다.

잘 설계된 policy와 mechanism은 믿을만 한가? (우리의 집 자물쇠를 믿을 수 있는가?)
나아가 “잘 설계된” policy와 mechanism을 구현한 “사람”은 믿을 수 있는가?

이와 관련된 유명한 이야기로는 켄 톰슨(Ken Thompson)의 논문, Reflections on Trusting Trust 가 있다. 그는 “컴파일러가 악성 코드를 심을 수도 있다”고 경고하며, 신뢰의 문제는 ‘모든 것이 의심받을 수 있다’는 사실을 지적한다.

1.7.3. Trusted Computing Base (TCB)

TCB(신뢰할 수 있는 컴퓨팅 기반)란, 시스템의 보안 정책이 제대로 작동하기 위해 필수적으로 신뢰해야 하는 모든 SW와 HW를 말한다. 예를 들어, OS 커널, root 권한을 가진 프로그램, CPU, 저장 스토리지 등은 전부 TCB에 포함된다.

TCB는 작을수록 좋다. 왜냐하면 TCB 내에서 발생한 취약점은 전체 보안을 무너뜨릴 수 있기 때문이다. 최근 보안 설계에서는 TCB를 줄이는 방향으로 진화하고 있다.

1.7.4. Precision of Mechanism (보안 메커니즘의 정밀성)

보안 메커니즘이 효과적인지를 판단하는 기준으로 다음 세 가지 관계를 정의한다.

$Q$ : Security Policy가 정의하는 “정상적인 시스템 상태”의 집합

$R$ : Security Mechanism에 의해 허용되는 “도달 가능한 시스템 상태”의 집합

Precise: 메커니즘이 정책에서 허용한 것만 정확히 수행함 → 이상적이지만 구현 어려움 $R = Q$
Secure: 메커니즘이 정책보다 덜 허용함 → 안전하지만 사용성이 떨어질 수 있음 $R \subseteq Q$
Broad: 메커니즘이 정책보다 더 많이 허용함 → 정책을 위반할 가능성이 높아 위험함 $R \supset Q$

1.8. Operational Issues & Human Issues

Cost-Benefit Analysis 어떠한 Security Policy/Mechanism이 그만큼의 비용에 대응하는 가치를 가지는가?
Risk Analysis 어떠한 자산을 보호할 것인가? 지금 직면한 위협은 무엇인가? 공격 받았을 때의 결과는 어떠한가? 이러한 리스크는 어떻게 정량화할 것인가?
각 나라별 혹은 자치 구역별 법령에 따라 Security Policy / Mechanism 이 제한될 수도 있다.
Human Issue
1. 누가 보안을 책임질 것인가?
2. 보안 담당자의 급여는? 권한은 어디까지 주어질 것인가?
3. 누가 보안 시스템을 강제하는가?

1.9. “Security is a Process, not a Product”

보안은 한 번 설치하고 끝나는 것이 아니다. 지속적인 패치, 취약점 관리, 침해 탐지 등이 함께 이뤄져야 한다. 시스템이 설계된 후 보안을 나중에 붙이는 것은 매우 어렵고, 많은 비용과 리스크를 초래한다.

2. Access Control (접근 제어)

Access Control(접근 제어)는 시스템 자원에 대해 “누가 무엇을 할 수 있는가?“를 결정하는 보안의 핵심 요소 중 하나다. 우리는 컴퓨터 시스템에서 공유(Sharing)와 격리(Isolation)라는 상충하는 요구사항을 조화롭게 다루어야 한다.

예를 들어 한 시스템에서 여러 사용자가 파일을 공유하기도 하지만, 서로의 데이터에 무단 접근해서는 안 된다. 따라서 보안 시스템은 정확히 어떤 사용자(주체, subject)가 어떤 자원(객체, object)에 어떤 행동(권한, rights)을 할 수 있는지를 결정하고, 이를 강제하는 메커니즘이 필요하다.

2.1.1. 2️.1. 컴퓨터 보안의 골든 스탠다드: AAA

접근 제어는 인증(Authentication), 인가(Authorization), 감사(Audit)의 3가지로 이루어진다.

구성요소	설명
Authentication	누구인지 확인 – “너 누구야?”
Authorization	무엇을 할 수 있는지 판단 – “너 이거 해도 돼?”
Audit	기록 남기기 – “무슨 일이 있었지?”

접근 제어는 이 세 요소가 모두 협력해서 동작할 때 비로소 완성된다.

위 그림에서 오른쪽의 큰 사각형을 Isolation Boundary 하며, Channel에 대한 공격을 제한한다.

Access Control이 이 Channel 내에서의 트래픽을 제어하고, Policy는 리소스에 접근하기 위한 권한인 Authorization 규칙을 설정한다.

따라서 우리가 이 챕터에서 다루고자 하는 Access Control은 Authorization과 관련되어 있다.

2.1.2. 기본 모델: Access Control Matrix (접근 제어 행렬)

액세스 컨트롤을 모델링 할 때에는 다음과 같은 기호를 사용한다.

접근 제어의 가장 기본적인 개념 모델은 Access Control Matrix (ACM)으로 다음과 같이 구성된다.

행(Row): 주체( $S$ , subject)들 (예: 사용자, 프로세스)
열(Column): 객체( $O$ , object)들 (예: 파일, 디렉터리, 포트)
셀(Cell): 해당 주체가 객체에 대해 가지는 권한( $R$ , Right)들 (예: read, write, execute, append, own)

	fileA	fileB
Alice	read, write	read
Bob	-	read, execute

위 표에서 Alice는 fileA에 대해 읽고 쓸 수 있고, fileB는 읽기만 가능하다.

이 모델은 개념적으로 매우 깔끔하지만, 실제 시스템에선 너무 희소(sparse)하고 거대(huge)해서 현실적으로 그대로 구현하기 어렵다. (=희소 행렬)

그래서 이를 간접적으로 표현하는 두 가지 방식이 등장한다.

2.2. Implementation of Acceess Control Matrix

2.2.1. Access Control List (ACL, 접근 제어 리스트)

객체( $O$ , Object) 중심 방식으로, 각 객체마다 접근 가능한 주체들과 권한을 기록한다.

fileA:
  Alice: read, write

fileB:
  Alice: read
  Bob: read, execute

2.2.2. Capability List (가용성 리스트)

주체( $S$ , Subject) 중심 방식으로, 각 주체마다 접근 가능한 객체와 권한을 기록한다.

Alice:
  fileA: read, write
  fileB: read

Bob:
  fileB: read, execute

2.2.3. Relationship-Based

주체( $S$ , Subject)와 객체( $O$ , Object) 간의 관계( $R$ , Relationship)에 따라 접근 권한을 판단하는 접근 제어 모델이다.

Subject	Access	Object
p	r	f
p	w	f
p	o	f
q	a	f
q	r	g
q	o	g

2.2.4. ACL vs. Capability

기준	ACL (객체 중심)	Capability (주체 중심)
접근 검토 (Access review)	누가 객체에 접근 가능한지 확인 쉬움	어떤 객체에 접근 가능한지 확인 쉬움
권한 회수 (Revocation)	특정 객체에 대한 권한 제거 쉬움	특정 주체에 대한 권한 제거 쉬움
권한 유출 방지	더 어렵다	더 어렵다 (단, capability 유출 주의)

→ 어떤 방식이 더 좋은지는 시스템의 목적과 상황에 따라 다르다.

2.3. 유닉스 시스템에서의 접근 제어 (ACL)

Unix나 Linux 같은 운영체제는 간단한 ACL 기반 접근 제어를 사용한다.

2.3.1. UID & GID

유닉스 시스템에서 유저는 (UID, GID, +Supplementary GIDs…) 정보를 가진다.

UID: 유저 ID
GID: 유저가 속한 주 그룹의 ID
Supplementary GIDs: 주 그룹 이외에 유저가 속한 그룹의 ID들

해당 시스템의 가장 초기에 생성되는 root / super 유저는 UID=0을 가진다.

2.3.2. Object’s Attributes in Filesystem

UNIX 파일 시스템에서 모든 파일(File, Directory, Link 등)은 내부적으로 inode라고 하는 데이터 구조를 가지고 이 안에는 다음과 같은 정보가 저장되어있다.

UID, GID
접근 권한 비트 (permission bits)
파일 크기, 생성/수정/접근 시각
실제 데이터가 저장된 디스크 블록의 위치 등

즉, 접근 제어 정보도 inode에 저장되어 있다

필드	설명
UID	파일의 소유자 사용자 ID
GID	파일의 소유 그룹 ID
Permission Bits	사용자, 그룹, 그 외 사용자에 대한 r/w/x 권한
Special bits	SUID, SGID, Sticky bit

$ ls -l
-rwsr-xr-x 1 root root 68208 Feb 6 2024 /usr/bin/passwd
...

부분	의미
-rwsr-xr-x	파일 유형 및 권한 (SUID 포함됨)
root root	첫 번째 root: UID (소유자), 두 번째 root: GID (소유 그룹)
/usr/bin/passwd	패스워드 변경 프로그램 (root 권한으로 실행되어야 함)

2.3.3. Permission Bits (접근 권한 구조 비트)

각 파일이 지니는 Permmision Bits는 다음의 구조로 이루어져 있다.

[ special ][ owner ][ group ][ others ]
    3bit     3bit     3bit     3bit

그룹	의미	순서
Special	SUID, SGID, Sticky bit	setuid 실행, 그룹 권한 상속, 디렉토리 고정
Owner	소유자의 r/w/x 권한	r, w, x
Group	그룹 사용자의 r/w/x 권한	r, w, x
Others	나머지 모든 사용자	r, w, x

2.3.4. Special Permission Bits (특수 비트)

Permission Bits의 특수 비트 3자리는 각각 SUID, SGID, Sticky Bit 순서로 나타난다.

비트	의미	설명
SUID (Set User ID)	실행 시 해당 파일의 소유자 권한 상속	주로 /usr/bin/passwd 등에서 사용
SGID (Set Group ID)	실행 시 파일의 그룹 권한 상속	또는 디렉토리 내 파일이 동일 그룹 상속 받도록
Sticky Bit	디렉토리에서 본인만 삭제 가능하게 함	예: /tmp

SGID

SGID는 프로그램에 설정된 경우, 그룹 권한을 상속하지만 디렉토리에 설정된 경우 디렉토리 내에 생성되는 모든 파일이 해당 그룹을 상속받도록 한다.

예시로 다음의 파일을 살펴보자.

-rwsr-xr-x 1 root root 68208 Feb 6 2024 passwd

s는 SUID (Set UID)를 의미: 실행 시 해당 파일의 owner 권한으로 동작한다.
owner가 root이기 때문에 일반 사용자가 passwd 명령어를 실행해도 root 권한으로 동작한다.

2.3.5. ID in User & Process

리눅스 시스템에서 각 유저와 프로세스는 다음의 ID 체계를 가진다.

유형	설명
UID, GID	실제 사용자/그룹 ID (real ID)
EUID, EGID	효과적인 권한을 결정하는 ID (effective ID)
fsuid, fsgid	파일 시스템 접근 검사 시 사용하는 ID (파일 접근용)
Supplementary GIDs	하나의 사용자에게 여러 그룹을 부여 가능

→ 이때 접근 제어는 주로 EUID / EGID 또는 fsuid / fsgid를 기준으로 판단한다.

fsuid (filesystem UID): - 접근하는 프로세스의 파일 시스템 사용자 ID - 보통 EUID와 같지만, setfsuid() 시스템 호출로 따로 설정 가능
fsgid (filesystem GID): - 접근하는 프로세스의 그룹 ID (파일 시스템 기준) - 마찬가지로 setfsgid()로 설정 가능

위와 같이 fsuid와 fsgid가 있을 때, 파일 접근 권한 평가는 다음의 순서로 이루어진다.

fsuid == file.UID이면 → owner 권한 평가
fsgid == file.GID 또는 보조 그룹 목록 중 하나가 file.GID와 일치 → group 권한 평가
모두 다르면 → others 권한 평가

2.4. sudo의 동작

sodu 명령은 일반 사용자가 일시적으로 root 권한을 사용할 수 있도록 하는 권한 위임 도구로 다음과 같이 작동한다.

재인증 요구: - 사용자가 sudo를 실행하면, 비밀번호를 입력하라는 프롬프트가 뜬다. - 이때 입력된 비밀번호는 현재 사용자의 비밀번호이며, 시스템은 이를 통해 인증(Authentication)을 수행한다.
sudo 그룹 확인: - 사용자가 sudo 그룹 또는 /etc/sudoers에 정의된 규칙에 포함되어 있는지를 확인한다.
setuid 비트: - sudo는 실행 파일 /usr/bin/sudo에 setuid 비트가 설정되어 있고, sudo의 소유자인 root 권한으로 실행된다.
로그: - sudo로 사용한 모든 명령어는 /var/log/auth.log 같은 로그 파일에 이력이 남는다. - 관리자는 나중에 sudo 사용 내역을 감사할 수 있다.

$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root ... /usr/bin/sudo

2.5. chown의 동작

chown (Change Owner)은 UNIX/Linux에서 파일의 소유자(UID)와 소유 그룹(GID)를 변경하는 명령어이자 시스템 콜이다. 이 명령어는 접근 제어 정책이나 감사 정책을 회피할 수 있다. 따라서 UNIX의 핵심 보안 원칙 중 하나로써 일반 사용자는 파일의 소유자를 변경할 수 없게끔 되어있다.

세부 조건은 다음과 같다.

caller가 root (UID 0)
group 변경만 수행하고, caller가 그룹의 멤버이며, 파일의 owner인 경우 (이건 Linux만 허용)

단, Linux에서는 Kernel 2.2부터 root 권한을 Capability로 세분화하는 보안 모델을 도입하며

CAP_CHOWN: 파일의 소유자 및 그룹 변경 권한 이 부여된 사용자는 root가 아니더라도 chown() 실행할 수 있게 되어있다.

2.6. Capability-as-Key & Ambient Authority, Confused Deputy Problem

Capability-as-Key 모델은 주체 $S$ 가 어떠한 객체(리소스) $O$ 에 접근할 때 직접 접근할 수 있는 key를 선택해서 제시하여야 하는 보안 모델이다.

하지만 UNIX 시스템에서 Authority(권한)은 Ambient하게 부여된다.

예를 들어 사용자가 open을 호출하면서 Authority를 직접 제시하지 않고, 그 당시에 사용자에게 부여된 UID, GID를 통해 시스템이 Authority를 적절히 부여한다. 이를 Ambient Authority라고 한다.

하지만 이 경우 한가지 문제점이 생기는데, 어떤 프로그램(=deputy, 대리인) $X$ 가

A 사용자의 요청을 받아
프로그램 $X$ 자신에게 부여된 ambient한 권한을 사용해
B 사용자의 데이터나 자원 $f$ 를 실수로 노출하거나 덮어쓰는 상황 이 발생할 수 있다.

결과적으로 A사용자는 $f$ 에 접근할 수 없지만, 프로그램 $X$ 를 통해 $f$ 의 내용을 바꿀 수 있게 된다. 이러한 상황을 Confused Deputy Problem이라고 한다. 이는 $f$ 에 대한 $A$ 의 접근 권한이 명시적으로 전달되지 않기에 일어나는 문제이다.

이렇게 UNIX와 ACL 모델의 문제점은

파일 경로(path)는 누구나 알고 지정(Designation)할 수 있는데
그 경로에 대해 누가 어떤 Authority를 가지는지는 Ambient하게 따라오기에 Designation (지정)과 Authority (권한)이 분리되어 있다는 부분에서 위험성이 있다고 판단한다.

이러한 문제를 해결하고자 나온 Capability 시스템의 철학에서는 Capability 자체가 “지정 + 권한”을 동시에 내포하여 (file_cap = {file_reference + 권한 정보}) 적절한 Key를 제시하지 못하면 리소스 접근을 차단하는 방식을 사용한다.

2.7. Access Control Types (접근 제어의 유형)

Discretionary Access Control (DAC)
- 객체의 소유자가 권한을 관리
- 일반적인 운영체제에서 쓰임 (e.g., 유닉스 파일 시스템, ACL)
Mandatory Access Control (MAC)
- 시스템에서 정의된 정책(policy)에 따라 접근을 통제
- 예: 군사 등급 시스템, Bell-LaPadula 모델
Role-Based Access Control (RBAC)
- 주체에 직접 권한을 주는 게 아니라, 역할(Role)을 주고, 역할에 권한을 부여
- 현대 기업 환경에서 많이 사용됨
- 예: 직원에게 “회계팀” 역할을 주면, 자동으로 회계 관련 파일 접근 가능

우리가 지금까지 다룬 DAC에서는 파일(리소스)의 소유자가 해당 자원에 접근 가능한 사용자를 지정한다. 이는 악의적인 사용자 $A$ 가 자신이 읽을 수 있는 정보를 사용자 $B$ 에게 복사해서 넘길 수 있는 문제점이 있고, 이를 해결하기 위해 MAC 보안 모델이 도입되었다.

2.8. Mandatory Access Control (MAC, 강제 접근 통제)

항목	DAC (Discretionary)	MAC (Mandatory)
접근 결정 주체	파일 소유자 (user)	시스템 정책 (admin)
권한 변경	소유자가 가능	불가능 (정책 변경만 가능)
예시	UNIX 파일 권한 (rwx)	군사 기밀 시스템, SELinux
보안 성격	유연하지만 취약	엄격하고 강제적

MAC에서는 다음의 세가지 개념을 제시한다.

Security Level( $L$ ): 보안 등급 (e.g. Top Secret, Secret, Confidential)
Security Category( $C$ ): 주제 영역 (e.g. NATO, NUC, ACE 등)
Security Label( $L, C$ ): Security Level과 Security Category를 묶은 쌍

Level / Category 예시

Contents

또한, 정보의 흐름을 단일화하기 위한 정보 접근 조건 Bell-LaPadula Model을 제시한다.

규칙	이름	의미
Simple Security Property	No Read Up	주체는 자신보다 높은 등급의 정보를 읽을 수 없음
*-Property (Star)	No Write Down	주체는 자신보다 낮은 등급의 위치에 쓸 수 없음

즉 쓰기는 위로만 가능하고, 읽기는 아래로만 가능하도록 제한된다.

Security Level 만으로 보안 정책의 복잡성을 모두 충족할 수 없다. 따라서 각 객체 $O$ 가 속하는 주제별로 보안 정책을 구분하기 위해 내용 기반의 Security Category와 다음의 조건이 추가되었다.

주체 $S$ 가 객체 $O$ 에 접근하려면 $S$ 의 보안 라벨이 $O$ 를 “지배(dominates)” 해야 한다.

S can read O ↔ l(S) ≥ l(O) ∧ category(S) ⊇ category(O)

3. Authentication (인증)

Authentication(인증)은 컴퓨터 보안에서 가장 먼저 수행되는 과정으로, 시스템이 요청을 보낸 사용자가 누구인지 확인하는 절차를 말한다. 간단히 말해, “너, 누구야?”(Who are you?)를 묻는 단계로, 다음의 요소로 구성된다.

용어	설명
Principal	고유한 실체 (사람, 기계, 계정 등)
Identity	Principal을 식별하는 정보 (ID, 이메일 등)
Subject	시스템 내에서 행동하는 주체 (프로세스 등), Principal을 대신함
Authentication	특정 Subject가 특정 Identity에 바인딩되었는지 확인하는 행위

즉, 인증은 “이 행동을 하고 있는 프로세스가 정말 ‘홍길동’의 것인가?“를 확인하는 절차이다.

이와 달리, Authorization(권한 부여)은 인증 이후 “그럼 넌 뭘 할 수 있어?”(What can you do?)를 판단하는 과정이고, Access Control(접근 제어)은 이러한 인증과 권한을 바탕으로 실제 자원에 대한 접근을 허용 또는 차단하는 행위이다.

3.1. 인증 수단의 유형

Principal의 정체를 증명하기 위한 정보는 다음 네 가지 중 하나, 또는 조합으로 제공될 수 있다

What you know (지식 기반) → 예: 비밀번호, PIN
What you have (소지 기반) → 예: 스마트카드, OTP 토큰
What you are (생체 기반) → 예: 지문, 얼굴 인식
Where you are (위치 기반) → 예: 특정 네트워크 영역에서만 로그인 허용

3.2. 인증의 3단계

인증은 다음의 3단계로 이루어진다.

Registration (등록) - 사용자와 시스템이 어떤 비밀 정보(secret)를 공유하는 과정 - 예: 사용자에게 비밀번호 설정하게 하기
Authentication check (인증 확인) - 사용자가 시스템에 접근할 때, (ID, secret)를 제출하고 시스템은 등록된 정보와 일치하는지 확인함
Recovery (복구) - 사용자가 비밀번호를 잊었을 때 복구하는 절차 - 예: 이메일 인증, 보안 질문, 고객센터 전화 등

3.3. 인증 시스템의 수학적 모델

인증 시스템은 $(A, C, F, L, S)$ 로 구성된 튜플로 표현할 수 있다

$A$ : 인증 정보 (Authentication information)
$C$ : 시스템에 저장된 보조 정보 (Complementary info, 예: hash된 비밀번호)
$F$ : 보완 함수 (Complementation functions, $f : A \to C$ )
$L$ : 인증 함수 (Authentication functions, $l : A \times C \to T r u e, F a l se$ )
$S$ : 정보 선택 함수 (Selection functions, 사용자가 $A$ 나 $C$ 를 생성/수정하는 수단)

예를 들어 비밀번호 시스템에서는 사용자가 $A$ 로 비밀번호를 입력하면, $F$ 를 통해 $C$ 가 계산되고, $L$ 을 통해 비교하여 일치 여부를 판단하게 된다.

3.4. Unix Password System

비밀번호는 /etc/shadow에 저장되며, salt를 추가하여 동일한 비밀번호여도 서로 다른 해시값을 만들게 한다. 이는 Rainbow Table 공격을 어렵게 만든다.

$A$ : { strings of 8 chars or less }
$C$ : { 2 char salt || 11 char hash }
$F$ : { modified DES-4096 }
$L$ : { login, su }
$S$ : { passwd, nispasswd, passwd+ }
해시 포맷 예시

$6$salt$hashvalue

$6$ : SHA-512 해시 알고리즘을 의미
salt: 무작위 문자열 (Rainbow Table 공격 방지용)
hashvalue: 결과 해시값

사용자 정보는 /etc/shadow, /etc/passwd 에 나누어 저장된다.

/etc/passwd는 일반 사용자도 읽을 수 있으며 사용자명이나 UID 등을 저장하고 (hash는 x로 대체) 실제 비밀번호와 인증 관련 중요한 정보들은 /etc/shadow 에 저장된다.

3.5. 공격자 모델

공격자의 목표는 인증을 우회하거나 인증 정보를 얻는 것이다.

어떤 $a \in A$ 를 찾아서, $f (a) = c \in C$ 가 되는 경우를 찾는 것
즉, 유효한 비밀번호 $a$ 를 맞히는 것이 목적이다.
Online Attack - 시스템이 저장하고 있는 hash(C)를 유출한 후, 다양한 비밀번호를 대입해서 직접 f(a) == c가 되는지를 비교 - 도구: John the Ripper, hashcat, crack 등
Offline Attack
- 시스템에 직접 로그인 시도하며 비밀번호를 맞히는 방식
  - 로그인 시도를 차단하지 않으면 무한 반복 가능
Dictionary Attack: 자주 쓰이는 비밀번호 리스트를 기반으로 시도
Brute-force Attack: 가능한 모든 조합을 무작위로 시도
Pre-image Attack: 주어진 해시값 $C$ 에 대해 해당하는 입력 A를 찾는 것

3.5.1. Dictionary Attack

사전에 있는 단어 $w$ 에 대해 $f (w) == c$ 를 만족하는 단어 $w$ 를 찾는 공격 기법이다.

여기에 대항하는 방법으로는

$C$ 에 대한 접근 방지
여러번 틀릴 경우 $L$ 에 딜레이 부여
$f (a)$ 를 계산하기 위한 속도를 늦춤

3.5.2. Rainbow Table(Precomputed Hash Chain)과 Salt

Rainbow Table은 미리 계산된 대량의 평문–해시 쌍을 저장해둔 테이블로, 특정 해시값에 대응하는 평문을 빠르게 찾을 수 있게 한다. $C$ 를 가능한 $a \in A$ 로 다시 매핑하는 함수 $R$ 을 이용하여 검색 시간에서 손해를 감수하고 테이블 크기를 줄이는 방식이다.

하지만 salt를 사용하면 같은 평문이라도 서로 다른 해시값을 생성하기 때문에 Rainbow Table이 거의 무력화된다. 각 사용자마다 고유한 salt를 사용하면, 공격자는 사용자별로 별도의 Rainbow Table을 생성해야 하므로 공격 비용이 급격히 증가한다.

3.5.3. 해시 함수 속도와 공격자 유리성

공격자는 해시 함수 $F$ 가 빠를수록 더 빠르게 공격을 수행할 수 있다. 기존의 해시 함수(MD5, SHA-1 등)는 속도가 빠르기 때문에 brute-force 공격자가 유리하다. 이에 대응하여 일부러 계산을 느리게 만든 다음과 같은 해시 함수들이 개발되었다.

bcrypt: 반복 연산을 통해 느리게 만든 해시 함수
scrypt: 메모리 접근이 포함되어 병렬화 공격에 강함
PBKDF2: 반복적으로 해시를 수행하여 키를 늘이는 함수

이러한 느린 해시 함수를 사용하면 공격자의 비용이 증가한다.

3.6. 비밀번호 재사용 문제와 비밀번호 복구의 문제점

많은 사용자가 여러 사이트에 같은 비밀번호를 사용한다. 이로 인해 한 사이트에서 비밀번호가 유출되면, 다른 사이트 계정도 위험해진다. 이를 Credential Stuffing Attack이라 한다. 실제로 Yahoo, Adobe, eBay 등 대규모 유출 사례가 존재하며, 수십억 개의 계정 정보가 도난당했다.

또한, 비밀번호를 잊어버렸을 경우, 대부분 이메일 기반 복구가 이루어진다. 그러나 이메일 계정 자체가 공격당할 경우, 모든 계정이 위험해질 수 있다. 이 외에도 보안 질문(Security Question)은 너무 예측하기 쉽고, SNS나 검색을 통해 답을 유추할 수 있는 경우가 많아 취약하다.

3.7. 2단계 인증 (2FA, Two-Factor Authentication)

2FA는 두 가지 인증 정보를 동시에 요구함으로써 보안성을 높인다.

예: 비밀번호(what you know) + OTP(what you have)

이는 비밀번호 재사용 공격과 피싱 공격, MITM 공격 등 을 방어할 수 있지만 만능은 아니다.

3.8. 기타 인증 방법

U2F (Universal 2nd Factor): USB 타입의 물리 키 (예: Yubikey)
IP 기반 인증: 특정 IP만 허용
위치 기반 인증: 특정 위치에서만 허용
생체 인증: 지문, 얼굴, 음성 등
지속 인증 (Continuous Authentication): 로그인 이후에도 사용자의 행동 기반으로 지속 확인

4. Cryptography – Classical (고전 암호 기법)

암호(Cryptography)는 허가되지 않은 주체로부터 정보를 숨기고 보호하는 기술을 의미한다. 이는 컴퓨터 보안에서 기밀성(Confidentiality)을 보장하기 위한 핵심 수단이다. 암호 기술의 목적은 공격자가 정보를 읽거나 변조하지 못하도록 만드는 것이다. 이로써 우리는 다음과 같은 이점을 얻을 수 있다.

정보의 기밀성(Confidentiality) 확보
정보의 무결성(Integrity) 유지
정보의 진위성(Authenticity) 확인
행위의 부인 방지(Non-repudiation)

하지만 암호화만으로 무결성은 보장되지 않는다!

(→ 이에 대한 해결은 MAC, digital signature에서 다룬다)

이 장에서는 현대 암호의 기초가 되는 고전 암호 기법들을 다룬다.

용어	설명
Plaintext	암호화 전의 원본 메시지
Ciphertext	암호화된 메시지
Encryption	평문을 암호문으로 바꾸는 과정
Decryption	암호문을 다시 평문으로 복원하는 과정
Cryptosystem	암호화/복호화를 위한 전체 시스템 정의 (함수, 키 등 포함)

4.1. Cryptosystem

암호 시스템은 수학적으로 다음과 같은 5개 구성요소 $(E, D, M, K, C)$ 로 표현된다:

$E$ : 암호화 함수 집합 $(E : M \times K \to C)$
$D$ : 복호화 함수 집합 $(D : C \times K \to M)$
$M$ : 평문 집합 (Messages)
$K$ : 키 집합 (Keys)
$C$ : 암호문 집합 (Ciphertexts)

4.2. Caesar Cipher

시저 암호(Caesar Cipher)는 각 문자를 알파벳 상에서 일정한 거리만큼 이동시켜 암호화한다. 예를 들어 키가 3이면 $A \to D$ , $B \to E$ , $Z \to C$ 가 된다. “HELLO”는 “KHOOR”로 암호화된다.

$E_{k} (m) = (m + k) m o d 26$
$D_{k} (c) = (26 + c - k) m o d 26$
$M$ : 알파벳 문자열 집합
$K$ : 정수 집합 {0, 1, …, 25}
$C = M$

4.3. 공격자 모델과 Kerckhoffs의 원칙

공격자(adversary)는 암호 알고리즘은 알고 있지만 키는 모른다고 가정한다.

Kerckhoffs' Principle

암호 시스템의 보안은 키의 비밀성에만 의존해야 하며, 알고리즘은 공개되어도 안전해야 한다.

공격은 다음의 3가지 방식으로 이루어진다.

수학적 공격(Mathematical attacks): 암호 구조의 수학적 취약점 이용
통계적 공격(Statistical attacks): 언어의 통계 모델과 암호문을 비교
구현 기반 공격(Implementation attacks): 실제 구현에서 생기는 오류를 이용

4.4. 고전 암호(Classical Ciphers)

고전 암호는 기본적으로 대칭 키 방식(symmetric key)을 기반으로 하며, 두 가지 방식으로 나뉜다

Substitution Cipher (치환 암호): 문자를 다른 문자로 바꾸는 방식
Transposition Cipher (전치 암호): 문자들의 위치만 바꾸는 방식

두 가지를 섞으면 Product Cipher라고 부른다.

4.4.1. Substitution Cipher (Caesar Cipher)

가장 고전적인 치환 암호 방식으로, 알파벳을 일정한 거리만큼 밀어서 바꾸는 방식이다.

예: HELLO → KHOOR (각 문자를 오른쪽으로 3칸 이동) - 암호화: $E_{k} (m) = (m + k) m o d 26$ - 복호화: $D_{k} (c) = (26 + c - k) m o d 26$

키( $k$ )는 0~25 사이의 정수이며, 총 26가지 키가 가능하다.

카이사르 키는 키 공간(Key Space)가 너무 작아 Brute-Force 공격이 가능하고 통계적 분석이 가능하다는 취약점이 있다. (영어 알파벳에서 가장 많이 쓰이는 문자는 ‘E’, ‘T’ 등이기에 암호문에서도 가장 자주 나오는 문자가 대응될 가능성이 높다)

이러한 문제는 Kerckhoffs’s Principle에서 출발한다

→ 알고리즘이 알려졌다는 전제 하에, 키가 짧다면 쉽게 뚫린다.

4.4.2. Vigenère Cipher (비즈네르 암호)

시저 암호의 단점을 보완하기 위해 나온 다중 문자 키 기반의 다알파벳 치환 암호(Polyalphabetic Substitution Cipher)이다.

예시: - 메시지: THE BOY HAS THE BALL - 키: VIG - 반복 적용된 키: VIGVIGVIGVIGVIGV - 암호문: OPKWWECIYOPKWIRG
핵심 개념: - 각 문자를 시저 암호로 암호화하되, 적용하는 키 문자가 주기적으로 바뀜 - Period (주기): 키의 길이 - 암호문 통계 분포가 고르게 퍼져서 단일 문자 분석이 어려움

하지만 이러한 Vigenère Cipher도 주기 $n$ 으로 암호문을 분할한 뒤 각각 Caesar Cipher의 문제로 해석하여 분석하면 쉽게 해결할 수 있다.

Kasiski Test: 평문 중 동일한 내용에 대해 같은 키의 글자가 대응되는 경우 암호문에서 반복이 발생
Friedman Test: 문자의 반복 확률(Index of Coincidence, IC)을 계산하여 키가 1일 (=Caesar)와 랜덤한 경우의 평균 확률과 비교

→ 결론: Vigenère도 완전히 안전하지 않다

4.4.3. Transposition Ciphers

전치 암호는 문자의 순서만 바꾸고 문자는 그대로 유지하는 방식이다.

평문의 문자를 행렬에 채운 후 열을 특정 순서대로 재배열하여 암호문을 생성한다.

if 평문: WE ARE DISCOVERED SAVE YOURSELF → 5열 행렬에 채운 후, 열의 순서를 바꾸어 전치함

전치 암호는 문자의 빈도는 유지되므로, 단독으로는 안전하지 않다. 하지만 치환 암호와 조합하면 강력해진다.

4.4.4. Product Cipher

Product Cipher는 치환 암호와 전치 암호를 반복적으로 조합하여 구성한 암호이다.

혼돈(confusion)과 확산(diffusion)을 모두 갖추기 위해 이 둘을 결합한 구조를 사용한다.

현대 블록 암호인 DES, AES 등은 이 구조를 기반으로 한다.

예를 들어 DES는 16라운드의 Feistel 구조를 사용하며, 각 라운드마다 S-box를 통한 치환과 P-box를 통한 전치를 수행한다.

4.5. Realistic Threats

4.5.1. Ciphertext-Only Attack (암호문만 있는 공격)

공격자는 암호문(ciphertext)만 가지고 있고 대응되는 평문(plaintext)이나 키(key)에 대한 정보는 전혀 없는 경우로, 암호문들 사이의 통계적 특성이나 구조를 분석해 원래 평문이나 키를 추정하려 시도한다.

대표적인 고전 암호 시나리오이며, Caesar cipher는 이 수준에서 깨질 수 있다. 현실 세계에서는 이 모델만 고려하면 매우 취약한 시스템이 많기 때문에 기본적이고 가장 약한 위협 모델로 간주된다.

4.5.2. Known-Plaintext Attack (알려진 평문 공격)

공격자는 일부 암호문과 그에 대응되는 평문 쌍을 알고 있고 이를 통해 사용된 키 또는 알고리즘의 구조를 분석하여 다른 암호문의 평문을 유추하려 한다.

4.5.3. Chosen-Plaintext Attack (선택 평문 공격)

공격자는 원하는 평문을 선택하여 암호화를 요청할 수 있는 능력을 가진다.

즉, 특정한 패턴이나 구조를 가진 평문을 암호화하여 그 결과를 관찰함으로써 암호 체계의 구조나 키를 추론한다.

이는 능동적인 공격자(active adversary)에 해당하며, 암호 시스템이 기본적으로 방어해야 할 최소한의 위협 모델로 간주된다.

미드웨이 해전에서의 암호 해독 작전

미국은 일본이 다음 타격지점으로 지정한 지역의 코드네임 “AF”가 미드웨이라는 가설을 검증하기 위해, 미드웨이 기지에서 “식수 부족”이라는 가짜 평문 메시지를 보내고, 일본이 이를 암호화한 메시지를 전송한 것을 감청함으로써 “AF”가 Midway임을 확정지었다.

4.5.4. Chosen-Ciphertext Attack (선택 암호문 공격)

공격자는 암호문을 임의로 선택하여 복호화해볼 수 있는 능력을 가진다. 이를 통해 암호문과 평문 간의 관계를 분석하고, 키 또는 암호 알고리즘의 취약점을 이용하여 전체 시스템을 붕괴시킬 수 있다.

이는 Chosen-Plaintext보다 더 강력한 공격 모델이며, 현대 암호에서는 이 수준에서의 안전성(CCA-security) 보장이 요구된다.

Padding Oracle Attack

이 공격은 블록 암호에서 padding을 복호화하는 과정에서 에러 메시지를 이용해 평문을 유추하는 방식이다. 암호문을 조금씩 수정해 서버에 보내고 이때 서버가 보내는 에러가 “Padding Error” 인지 “MAC Error”인지 관찰하며 한 바이트씩 평문을 유추할 수 있다. 이 주제는 현재 수업 범위에서는 “Out-of-scope”(범위 외)이지만, 매우 강력하고 실전적으로도 중요하다.

특히 현실에서는 복호화 요청을 할 수 있는 상황이 많다

로그인 실패 시 오류 메시지
TLS 핸드셰이크의 반응 차이
API 응답의 차이

이런 정보가 모두 공격자에게 복호화 결과의 힌트가 된다.

즉, 복호화 API를 직접 호출할 수 없더라도, 간접적으로 복호 결과에 접근 가능한 시나리오는 매우 흔하기에 가장 위험한 공격으로 간주된다.

비교 항목	CPA (Chosen-Plaintext)	CCA (Chosen-Ciphertext)
공격 권한	원하는 평문을 암호화해볼 수 있음	원하는 암호문을 복호화해볼 수 있음
정보량	평문–암호문 쌍만 존재	암호문–평문 쌍이 존재
분석 방향	암호화 경로만 탐색	복호화 경로까지 분석 가능
공격자 파워	중간 정도	훨씬 강력함
보안 요구 수준	대부분의 기본 암호에서 요구	고급 프로토콜, 실전 시스템에서는 반드시 고려해야 함

4.6. 🧱 Chapter 5: Symmetric Cryptography (대칭 키 암호)

4.7. 대칭키 암호 개요

이 챕터에서는 대칭키 암호는 암호화와 복호화에 같은 키를 사용하는 암호 방식으로, 고속성과 효율성 덕분에 실제 시스템에서 널리 사용된다. 대칭키 암호에는 다음의 두가지 방식이 있다.

Block cipher (블록 암호): 일정 크기의 블록 단위로 데이터를 암호화한다.
Stream cipher (스트림 암호): 데이터 단위(보통 비트)로 암호화가 이루어진다.

4.8. Two Strategies to Defeat Statistic Cryptanalysis

통계적 분석을 막기 위해 혼돈(Confusion)과 확산(Diffusion)이라 불리는 개념이 필요하다.

확산(Diffusion): 평문의 한 비트를 바꾸면 암호문 전체에 영향을 미치도록 설계해야 한다. ⇒ 평문의 일부 변경이 암호문 전체에 영향을 미친다.
혼돈(Confusion): 암호문에서 키를 추측할 수 없도록 해야 한다. ⇒ 키의 일부 변경이 암호문의 전체에 영향을 미친다.

4.9. Feistel Cipher

Feistel 구조는 단방향 함수( $F$ )를 이용해 양방향 암호화를 가능하게 하는 프레임워크로 다음의 구성을 따른다.

평문 블록을 두 개의 하위 블록 $L_{0}, R_{0}$ 로 나눈다.
반복 라운드마다 아래 연산을 반복한다. $L_{i + 1} = R_{i}$ $R_{i + 1} = L_{i} \oplus F (R_{i}, K_{i})$
복호화는 키 순서만 반대로 하면 동일한 구조로 수행된다. 그림에서는 각 라운드의 입력과 출력, 함수 F의 역할, 마지막 라운드에서 swap이 없는 이유를 시각적으로 보여준다.

4.10. Data Encryption Standard (DES)

고전적 블록 암호인 DES (Data Encryption Standard)는 1974년 IBM이 제안했고, NSA의 조언을 거쳐 1977년에 미국의 표준 암호로 채택되었다.

64비트 블록 크기를 갖고, 56비트 키를 사용한다. 키는 64비트 중 8비트가 패리티 비트로 사용된다.

입력: 64비트 평문
키: 56비트
출력: 64비트 암호문 따라서 평문을 64비트 단위로 끊어 암호화를 진행하게 된다.

DES는 Feistel 구조를 사용하며, 초기 순열(IP), 16 라운드, 마지막 순열(FP)로 구성되어 있다.

F 함수는 다음 단계를 거친다

입력 32비트를 48비트로 확장 (E-box)
키와 XOR
8개의 S-box를 거쳐 다시 32비트로 줄임
P-box를 적용

이 과정은 혼돈과 확산을 효과적으로 구현했지만, 다음의 한계점으로 인해 결국 끝을 맞이했다.

56비트 키는 너무 짧아 brute-force 공격에 취약하다.
1998년 EFF는 약 25만 달러로 DES 전용 공격기를 제작해 이틀 만에 키를 찾아냈다.
2009년에는 COPACOBANA라는 FPGA 기반 장비로 단 1만 달러에 DES를 깨는 데 성공했다.

결국 DES는 더 이상 안전한 암호로 간주되지 않으며, 표준에서도 철회되었다.

4.11. Advanced Encryption Standard (AES)

현대 대칭 암호의 표준인 AES는 2001년에 Rijndael이라는 알고리즘을 채택하며 등장했다.

블록 크기: 128비트 (고정)
키 크기: 128, 192, 256비트 (가변)

AES는 라운드 기반 구조이며, 라운드 수는 키 길이에 따라 달라진다:

128비트 키 → 10 라운드
192비트 키 → 12 라운드
256비트 키 → 14 라운드

각 라운드에서 다음의 과정을 거친다.

SubBytes (S-box)
ShiftRows (P-box)
MixColumns (P-box)
AddRoundKey (F: XOR)

이중 첫번째 단계의 S-box는 Rijndael 알고리즘에서 정의된 고정된 16×16 테이블로, AES 암호의 보안성에 큰 기여를 했다.

이러한 AES는 하드웨어로 구현하면 효율이 매우 높아, 대부분의 CPU에 내장된 AES-NI 명령어로 빠르게 수행되기에 고성능 네트워크 암호화에도 적합하게 만든다.

4.12. Modes of Operation (암호 모드)

4.12.1. Block Cipher, Stream Cipher, One-time Pad

큰 데이터에 적용하는 방식은 크게 Block Cipher, Stream Cipher, One-time Pad가 있다.

Block Cipher는 고정 길이 블록 단위 암호화이며 대표적으로 AES, DES가 있다.

Stream Cipher는 1비트 또는 1바이트 단위로 암호화하며, 키 스트림을 XOR하는 방식으로 실시간 스트리밍, VoIP, 무선통신 등에 유리하다.

One-time Pad는 이론상 완벽하게 안전한 암호화 방식(perfect secrecy)으로, 평문과 같은 길이의 진짜 무작위 키를 생성하여 XOR하는 방식이다. 이때 키는 당연하지만 매 순간 새로 생성되고, 쓰이자마자 폐기되어야 한다.

4.12.2. Message Authentication Code (MAC)

MAC은 무결성과 인증을 위해 사용하는 수단으로, 공유된 비밀 키로부터 암호문과 함께 메시지에 대한 MAC을 생성하여 전송하고, 수신자는 MAC을 검증함으로써 메시지가 변조되지 않았음을 확인한다.

기밀성은 없고, 오직 무결성과 인증에만 초점을 둔다.

4.12.3. Modes of Operation (암호 모드)

AES나 DES는 기본적으로 고정된 블록 크기만 처리할 수 있는 블록 암호(block cipher)이다.

따라서 실제 데이터가 여러 블록으로 구성되어 있을 경우, 각 블록을 어떻게 연결해서 처리할지 결정하는 모드(mode of operation)가 필요하다.

ECB (Electronic Code Book): 각 블록을 독립적으로 암호화한다. ⇒ 병렬처리가 가능하지만, 같은 평문 블록은 항상 같은 암호문 블록으로 변환되어 원래 데이터의 구조가 그대로 드러나는, 혼돈과 확산의 원리가 전혀 작동하지 않는 대표적인 안티-패턴이다.
CBC (Cipher Block Chaining) ⇒ 첫번째 블록을 무작위 IV(Initialization Vector)와 XOR하고 암호화하며, 이후 블록들은 이전 블록과 XOR한 후 암호화하며, Diffusion에 유리하다. 하지만 병렬처리가 불가능한 단점이 있다.
CTR (Counter Mode) ⇒ IV 대신 nonce와 counter를 이용해 암호화된 스트림 생성하여 평문과 XOR한다. nonce값이 바뀌면 같은 내용의 평문도 아른 암호문으로 바뀌며 병렬 처리, 스트림 처리가 가능하고 안전하면서도 빠른 속도를 자랑한다.
GCM (Galois Counter Mode) ⇒ GCM은 CTR 모드 + MAC(GMAC)을 결합하여 기밀성과 무결성을 동시에 제공한다. 태그가 조작되면 복호화 자체를 거부하기에 Chosen-CipherText 공격에 안전하며, 다양한 보안 프로토콜에 현재 사용된다. (순서가 바뀌면 AEAD가 아니라 굉장히 위험하다. Chosen-CipherText에 대한 대응 방안을 잃어버리게 된다.)

5. Asymmetric Cryptography (비대칭 키 암호)

비대칭 키가 등장하는 핵심 동기는 다음의 두가지이다.

공개 채널에서 안전하게 키를 공유하는 방법
- Alice와 Bob이 Eve(공격자)가 들을 수 있는 공개 채널을 통해 통신한다고 할 때, 비밀 키를 어떻게 안전하게 공유할 수 있는가? (이는 TLS(HTTPS)의 핵심 문제이기도 하다.)
메시지의 출처를 인증하는 방법
- Alice가 어떤 메시지를 보냈다는 사실을 제3자도 인정할 수 있게 하려면 어떻게 해야 하는가?(부인방지, Non-Repudiation)

5.1. 비대칭 키의 역사

Diffie-Hellman (1976): 최초의 공개키 기반 키 교환 방식 제안
RSA (1977): Rivest, Shamir, Adleman이 개발한 공개키 암호 시스템
사실 이보다 먼저(1970) 영국의 GCHQ에서 James Ellis가 “비밀 없는 암호(non-secret encryption)” 개념을 고안했고, 1973년 Clifford Cocks가 RSA를 독립적으로 구현했으나, 이는 1997년까지 기밀이었다.

5.2. 비대칭 키 암호란?

비대칭 암호에서는 각 사용자가 다음 두 개의 키를 가진다:

키	설명
Public Key ( $P$ , 공개 키)	누구나 알고 있어도 되는 키
Private Key ( $S$ , 개인 키)	절대 노출되면 안 되는 비밀 키

이 두 키는 수학적으로 서로 연결되어 있어, 다음이 가능하다.

공개 키로 암호화 → 개인 키로 복호화
개인 키로 서명 → 공개 키로 서명 확인

5.2.1. Confidentiality (기밀성)

Alice가 Bob에게 비밀 메시지를 전송한다. 이 상황에서 도청자 Eve가 중간에 끼어 비밀 메시지를 열어보아 Confidentiality를 침해하려 한다.

Alice → Bob 에게 비밀 메시지 $M$ 을 보냄
Alice는 Bob의 공개 키( $P_{B}$ )로 $M$ 을 암호화: $C = P_{B} (M)$
Bob은 자신의 개인 키( $S_{B}$ )로 복호화: $M = S_{B} (C)$
중간에 도청자 Eve가 있어도, B의 개인 키 ( $S_{B}$ )없이는 복호화 불가능

5.2.2. Non-Repudiation (부인 방지)

Alice는 메시지 $M$ 을 전송하였으나, 자신은 그런 적이 없다며 부정하려 한다.

Alice는 메시지 $M$ 에 대해 자신의 개인 키( $S_{A}$ )로 서명 생성: $S i g na t u re = S_{A} (M)$
누구나 Alice의 공개 키( $P_{A}$ )로 $S i g a t u re$ 를 검증 가능: $P_{A} (S i g na t u re) = M$
이로써 Alice는 “이 메시지를 보냈다”고 부정할 수 없음

5.3. Diffie-Hellman Key Exchange (DH 키 교환)

Diffie-Hellman(DH)은 공개키 암호 방식으로 키를 교환하는 방법이다.

원리:

Alice와 Bob은 큰 소수 $p$ 와 생성자 $g$ 에 동의한다.
Alice는 자신의 비밀키 $a$ 를 선택하고 $A = g^{a} m o d p$ 를 Bob에게 보냄
Bob은 자신의 비밀키 $b$ 를 선택하고 $B = g^{b} m o d p$ 를 Alice에게 보냄

공통 비밀키 s는 다음과 같이 계산된다:

Alice: $s = B^{a} m o d p = (g^{b} m o d p)^{a} m o d p = (g^{b})^{a} m o d p$
Bob: $s = A^{b} m o d p = (g^{a} m o d p)^{b} m o d p = (g^{a})^{b} m o d p$

→ 결과적으로 둘은 동일한 s를 갖게 되며, 이 s를 대칭 암호용 키로 사용하면 된다.

→ 중간자(Mallory)는 A와 B는 볼 수 있어도, $a$ 또는 $b$ 를 모르면 $g^{ab}$ 를 알 수 없다.

이 구조는 이산 로그 문제(discrete logarithm problem)의 어려움을 기반으로 안전성을 갖는다.

비대칭 암호의 대표적인 활용은 공통 비밀키를 안전하게 생성하는 것이다. Diffie-Hellman은 그 대표적 방법이다.

5.4. MITM 공격 (Man-in-the-Middle)

Diffie-Hellman은 키 교환은 가능하지만 상대방이 진짜 누구인지 인증을 하지 않는다.

즉, Mallory가 중간에 끼어서:

Alice에게 Mallory의 공개키를 Bob의 것처럼 보내고,
Bob에게 Mallory의 공개키를 Alice의 것처럼 보내면, 각각 Mallory와 비밀키를 공유하게 되어 Mallory가 전문을 읽고 조작할 수 있게 된다.

이를 해결하기 위해 RSA가 등장한다.

5.5. RSA (Rivest-Shamir-Adleman)

RSA는 소인수분해(factorization)의 어려움을 기반으로 한다.

두 개의 큰 소수 $p, q$ 를 선택하여 $N = p \times q$ 를 만든다.
$N$ 은 공개되지만, 이를 다시 $p$ 와 $q$ 로 나누는 것은 매우 어렵다.

이에 따라 다음의 순서로 키를 생성한다.

두 소수 $p, q$ 선택
$N = p * q$
$T = (p - 1) \times (q - 1)$ (Euler totient)
$(e \times d) m o d T = 1$ 이 되도록 $e, d$ 를 선택한다.
- $e$ 는 공개키의 지수
- $d$ 는 개인키의 지수 (확장 유클리드 알고리즘 사용)
공개키: $P_{k} = (e, N)$
개인키: $S_{k} = (d, N)$

이제 어떤 메시지 M을 암호화하려면 다음의 과정을 거치면 된다.

암호화: $C = M^{e} m o d N$
복호화: $M = C^{d} m o d N$

5.6. 비대칭 암호의 단점과 대안

속도가 느림 → 긴 메시지 암호화에는 부적합
키 길이가 김 (보통 2048~4096비트)
→ 해결책: 하이브리드 암호화(Hybrid Cryptosystem)

5.7. ElGamal - Diffie-Hellman for Encryption

Diffie-Hellman은 기본적으로 키 교환에 사용되지만, 이를 확장하여 ElGamal 암호화도 가능하다. ElGamal은 공개키 암호 방식으로, 이산 로그 문제의 어려움을 기반으로 한다.

키 생성: DH와 동일하게 생성자 $g$ 와 소수 $p$ 를 기반으로 생성
암호화: $C = M \times s m o d p$ (여기서 $s$ 는 공유된 비밀 키)
복호화: $C \times s^{- 1} m o d p = M$

→ 이 방식은 대칭키를 보호하는 구조로 사용된다.

한편, RSA 역시 공통 비밀 공유 용도로 사용할 수 있다. 이때는 대칭키 $K$ 를 $C = E n c_RS A (K)$ 형태로 보내는 방식이다.

5.8. 키 크기와 보안 수준

RSA, DH와 같은 공개키 암호는 대칭키 암호보다 훨씬 큰 키 크기가 필요하다.

AES와 같은 대칭키 암호에서 128비트면 안전하지만,
같은 수준의 보안을 공개키 암호에서 제공하려면 보통 2048비트 이상이 필요하다.

이처럼 공개키 암호는 계산 비용이 크기 때문에, 실제 통신에서는 다음과 같은 하이브리드 구조를 사용한다.

공개키 암호로 세션 키(대칭키)를 안전하게 전송
이후 대칭키 암호로 전체 데이터를 빠르게 암호화

이 구조는 기밀성 + 성능 + 유연성을 동시에 제공하며, 실제 인터넷 보안의 표준이 되었다.

5.9. Long-term v.s. Short-term Keys

암호 시스템에서는 키를 사용 목적에 따라 두 가지로 나눈다:

장기 키 (Long-term): 사용자 ID와 영구적으로 연결된 키 (예: RSA 키)
단기 키 (Short-term, Ephemeral): 세션마다 생성되는 임시 키 (예: DH에서의 세션 키)

장기 키는 인증과 신뢰를 위한 역할,

단기 키는 비밀성 보호와 세션 격리를 위해 쓰인다.

5.10. Forward Secrecy (선행 비밀성)

Forward Secrecy는 다음을 보장하는 특성이다:

“나중에 장기 키가 유출되더라도, 과거의 세션 암호화 내용은 복호화할 수 없다.”

공격 시나리오:

공격자가 과거의 암호 통신을 녹음해두고,
나중에 사용자 장기 개인키가 유출되었을 때,
녹음된 세션을 복호화하려고 시도함

→ Forward Secrecy를 제공하면 이 공격은 실패한다.

이를 위해선 DH + Ephemeral 키(ECDHE) 구조를 사용해야 하며,

RSA는 기본적으로 Forward Secrecy를 제공하지 않기 때문에 보완이 필요하다.

5.11. SSH Authentication

SSH 로그인 과정은 다음과 같이 공개키 기반 인증을 사용한다:

클라이언트가 서버에 접속 요청 (예: ssh user@server)
서버가 클라이언트에게 challenge 메시지를 보냄
클라이언트는 개인키로 challenge를 서명
서버는 클라이언트의 공개키로 서명을 검증
서명이 일치하면 로그인 승인

이 방식은 ID/비밀번호보다 훨씬 강력한 인증을 제공하며,

개인키는 사용자의 ~/.ssh/id_rsa, 공개키는 서버의 ~/.ssh/authorized_keys에 저장된다.

5.12. PassKey

Passkey는 공개키 기반 인증의 현대적 구현 방식이다. 예:

사용자가 웹사이트에 가입 시, 기기에서 자동으로 공개/개인 키 쌍을 생성
로그인 시, 서버가 challenge를 전송
기기는 이 challenge를 비밀키로 서명하여 전송
서버는 등록된 공개키로 서명을 검증

비밀번호 기반 인증과 달리 사용자가 직접 패스워드를 입력할 일이 없기 때문에 피싱 공격에도 안전하다. macOS, iOS, Android, Chrome, Microsoft 등이 지원 중이다.

6. Cryptography (Miscellaneous and Applications)

6.1. Cryptographic Hash Function

해시 함수는 임의 길이의 입력을 고정된 크기의 출력으로 변환하는 함수다.

특히 암호학적 해시 함수는 다음과 같은 목적에서 사용된다:

인증 정보에서 추가 정보를 파생할 때, 예를 들어 salt와 함께 사용하는 경우
타임스탬프: 특정 시간에 어떤 값을 알고 있었음을 증명할 때
MAC이나 디지털 서명 등 다양한 암호 기법의 구성 요소로 사용됨

중요한 점은 이 함수들이 효율적이면서도 예측 불가능한 출력을 만들어야 한다는 것이다. 따라서 해시 함수는 다음의 요구사항을 충족시켜야 한다.

암호학적 해시 함수가 갖추어야 할 주요 성질은 다음과 같다:

전방향 계산이 쉬워야 한다 (효율적으로 해시값을 계산할 수 있어야 함)
역방향 계산이 어려워야 한다 (주어진 해시값에 대해 원래 입력을 찾기 어려워야 함)
다른 입력에 대해 충돌하는 해시값이 최대한 없어야 한다.
정보를 누설하면 안된다.

이 요구사항은 다음 세 가지 특성으로 구체화된다.

전상 이미지 저항성 (Pre-image resistance) 주어진 해시값 $h$ 에 대해 입력 $m s.t. ha s h (m) = h$ 를 찾기 어렵다.
두 번째 전상 이미지 저항성 (Second pre-image resistance) 어떤 입력 $m 1$ 이 주어졌을 때, $ha s h (m 1)$ 과 같은 해시값을 갖는 $m 2$ 를 찾기 어렵다.
충돌 저항성 (Collision resistance) 서로 다른 두 입력 $m 1, m 2$ 에 대해 $ha s h (m 1) = ha s h (m 2)$ 가 되도록 하는 쌍을 찾기 어렵다.

이 세 가지 조건은 각각 점점 더 강한 요구사항이다. 특히 마지막 충돌 저항성은 해시 함수의 근본적인 보안성을 보장하는 핵심 속성이다.

6.1.1. 해시 충돌 공격 시나리오

공격자 Eve가 두 개의 서로 다른 문서, 예를 들어 1.pdf, 2.pdf를 생성했다고 가정하자.

이 문서들은 동일한 해시값을 갖도록 의도적으로 설계되어 있다.

Eve는 먼저 Alice에게 1.pdf를 보내고, Alice는 그것에 디지털 서명을 한다.

그 후 Eve는 같은 서명을 2.pdf에 붙여 유효한 서명처럼 가장할 수 있다.

이는 해시 함수의 충돌 저항성이 약할 경우 발생 가능한 실제 공격 사례다.

암호학적으로 안전하지 않은 해시 함수들은 실제로 충돌 공격에 취약한 것이 입증되었다.

MD5는 이미 충돌이 여러 차례 성공적으로 입증되었으며, 보안 환경에서는 사용이 금지되고 있다.
SHA-1도 Google이 2017년에 실제 충돌을 만들어낸 바 있다 (shattered.io 참고)

이러한 공격은 공개적으로 발표되었으며, 해시 함수 교체의 필요성을 강조하게 되었다.

6.2. Merkle–Damgård 구조

많은 해시 함수는 Merkle–Damgård 구조를 따른다. 이 구조는 다음과 같이 구성된다:

입력 메시지를 고정된 블록 크기로 나누고, 패딩을 추가한다.
각 블록은 압축 함수 f에 의해 처리되며, 이전 단계의 출력값이 다음 단계의 입력으로 사용된다.
마지막 블록의 출력이 최종 해시값이 된다.

이 구조는 해시 충돌 저항성과 같은 속성을 보장하는 기반이 되지만, 일부 공격 기법(예: 길이 확장 공격)에도 취약하다.

6.3. MD5

MD5는 대표적인 메시지 다이제스트 알고리즘으로 한때 널리 사용되었지만, 현재는 다음과 같은 이유로 안전하지 않다:

실제 충돌 생성 사례가 다수 존재한다.
이론적인 전상 이미지 공격도 제안된 바 있다.

따라서 MD5는 인증, 서명, 암호화 등의 보안 목적으로는 절대 사용하지 말아야 하며, 단순 무결성 검사 같은 신뢰도 낮은 환경에서만 제한적으로 쓰일 수 있다.

6.4. SHA 해시 함수 계열

SHA(Secure Hash Algorithm) 계열은 NSA가 설계한 해시 함수 집합이다.

SHA-1 1995년에 발표되었으며, 출력 길이는 160비트다. 최근에는 충돌 공격이 입증되어 더 이상 보안 용도로는 부적합하다.
SHA-2 계열 SHA-256, SHA-512 등의 버전이 있으며, 각각 32바이트, 64바이트의 출력을 생성한다. SHA-2는 현재 대부분의 보안 프로토콜에서 기본적으로 사용되는 해시 알고리즘이다.
SHA-3 Keccak 기반의 완전히 새로운 구조이며, SHA-2와 병렬로 안전성을 확보하는 목적이다.

또한 현대 프로세서, 특히 인텔 x86 아키텍처는 SHA 연산을 하드웨어 수준에서 지원하는 명령어 집합을 포함한다. 예를 들어 OpenSSL에서는 다음과 같은 명령어들이 사용된다:

sha256msg1
sha256rnds2

이러한 명령어들은 해시 연산을 CPU에서 빠르게 수행할 수 있도록 도와주며, 특히 TLS와 같은 실시간 보안 통신에서 성능 이점을 제공한다.

6.5. Digital Signatures

Digital Signatures는 Alice가 메시지 $M$ 을 보냈다는 사실을 모두가 확인할 수 있도록 하는 부인방지 메커니즘이다.

서명은 다음과 같은 절차로 생성된다.

Alice는 메시지를 해싱한 값 $h = h_{A} = ha s h (M)$ 를 계산한다.
Alice: $S i g_M = S_{A} (h)$
Alice는 서명과 함께 메시지 $M$ 을 전송한다.
Bob은 받은 메시지 $M$ 에 대해 해시 $h = h_{b} = ha s h (M)$ 를 계산하고, 서명 $S i g M$ 에 Alice의 공개키를 적용하여 복호화한 뒤 앨리스가 준 서명 $h_{a} = h_{b} = h$ 인지 비교한다.

이 과정을 통해 Bob은 메시지가 Alice로부터 왔고, 전송 중 변경되지 않았음을 검증할 수 있다.

(만약 공격자 Eve가 $M$ 을 $M ’$ 으로 변경하고 $S i g M$ 을 그대로 붙여 보냈다면,

Bob이 해시를 계산했을 때 $ha s h (M ’)! = ha s h (M)$ 이므로 검증에 실패한다.)

6.6. Message Authentication Code (MAC)

메시지 인증 코드(MAC)는 암호화된 통신 중에서 메시지의 무결성과 인증성을 검증하기 위한 방식이다.

목적: 메시지가 변조되지 않았고, 키를 가진 인증된 주체에 의해 생성되었음을 확인
기본 아이디어: 암호화된 메시지에 MAC 값을 덧붙이고, 수신자가 이를 검증한다.

MAC은 공격자가 임의의 메시지에 대해 유효한 MAC을 계산할 수 없어야 안전하다.

대표적인 예시로 Galois Message Authentication Code(GMAC)가 있으며, 이는 GCM(Galois Counter Mode)에서 사용된다.

6.7. HMAC (Hash-based MAC)

단순히 $H (m ess a g e)$ 형태의 해시 함수는 보안상 안전하지 않다.

왜냐하면 이는 비밀을 기반으로 하지 않기 때문에, 공격자가 메시지와 해시를 동시에 변경할 수 있기 때문이다.

예를 들어 다음과 같은 공격이 가능하다:

“PLEASE SEND DAVID $100”이라는 메시지를 암호화했더라도,
공격자가 메시지와 해시를 동시에 바꿔서 새로운 의미를 만들어낼 수 있다.

따라서 H(key || message) 구조가 사용되지만, 이 또한 Merkle-Damgård 구조를 쓰는 해시 함수는 길이 확장(length extension) 공격에 취약할 수 있다. (해시함수는 내부 블록 상태를 반복적으로 압축 + 체이닝 하며 해시를 계산하기에 해시내부상태를 재구성해서 이후 메시지를 확장할 수 있다.)

이에 대항하는 HMAC은 모든 암호 해시 함수에서 사용할 수 있는 MAC 구성 방식이다.

HMAC(key, message) = H((key ⊕ opad) || H((key ⊕ ipad) || message))

여기서 opad와 ipad는 각각 외부 및 내부 패딩 상수다.

이 구조는 내부적으로 두 번의 해시를 수행하여 보안성을 높인다.

HMAC은 단순한 해시보다 훨씬 강한 보안성을 보장하며, 키를 모르고는 MAC을 위조하거나 분석할 수 없다.

6.8. HMAC과 디지털 서명의 차이

HMAC은 MAC의 일종이며, 디지털 서명과 다음과 같은 차이가 있다.

HMAC은 동일한 비밀키로 생성과 검증을 수행한다. ⇒ 무결성, 인증성
디지털 서명은 개인키로 서명하고, 공개키로 검증한다. ⇒ 부인 방지

가장 큰 차이점은 다음과 같다:

HMAC은 대칭키 기반이므로 인증자와 수신자가 같아야 한다.
디지털 서명은 비대칭키 기반이므로, 누구나 검증할 수 있다.

결과적으로, 디지털 서명은 부인 방지(non-repudiation)를 제공할 수 있지만, HMAC은 그렇지 않다.

6.9. Public Key Cryptosystem Weakness

공개키 암호 시스템의 근본적인 취약점 중 하나는 공개키의 신뢰성 문제다.

즉, “이 공개키가 진짜 Alice의 것인가?“라는 질문에 답할 수 있어야 하는데, 중간자 공격(MITM)은 이런 상황을 악용할 수 있다.

예를 들어, 공격자 Mallory가 통신을 가로채 Alice와 Bob의 공개키를 모두 자신의 것으로 바꾸면, Alice는 자신의 메시지를 Mallory에게 암호화하고, Mallory는 그것을 해독한 후 다시 Bob에게 Mallory의 키로 재암호화하여 전송한다.

이로써 Alice와 Bob은 서로와 안전하게 통신하고 있다고 착각하지만, 실제로는 모든 통신을 Mallory가 복호화하고 통제하고 있다.

6.10. Building Trust in Public Keys

공개키의 신뢰성을 보장하기 위해 공인된 제3자인 인증기관(CA, Certificate Authority)의 서명이 사용된다. 사용자는 자신의 공개키와 신원을 묶은 정보를 CA에 제출하고, CA는 이 정보에 서명함으로써 디지털 인증서를 발급한다.

이를 통해 사용자는 CA가 보장한 신뢰를 바탕으로 자신의 키에 대한 신뢰를 얻는다.

이러한 구조는 두 가지 방식으로 운영된다.

위임 중심의 중앙 집중화 모델 → PKI(Public-Key Infrastructure) 방식으로, 루트 인증기관과 계층 구조를 형성한다.
분산 신뢰 모델 → Web of Trust 방식으로, 사용자가 서로 인증하는 구조다.

6.11. Public Key Infrastructure (PKI, 공개키 기반 구조)

공개키 기반 구조(PKI)는 다음과 같은 구성 요소로 이루어진다:

Digital Certificates: 특정 개인 혹은 기업의 신원과 공개키를 연결하며, CA가 서명하여 보증한다.
Certificate Authorities (CA): 사용자의 신원을 확인하고, 이를 바탕으로 인증서를 발급한다. 또한, 다른 CA에게도 인증서를 발급할 수 있어 **신뢰 계층(hierarchy)**을 구성한다.
보안 목표: 인증서의 발급과 폐기(Revocation) 과정을 안전하게 관리하는 것이 핵심이다.

현대 웹 환경에서 PKI는 HTTPS를 통해 사용된다.

브라우저와 운영체제는 사전에 신뢰된 루트 인증기관(Root CA)의 공개키 목록을 보유하고 있다.

이러한 Root CA는 신뢰 사슬의 가장 위에 있는 존재이며, 이를 “신뢰의 근원(Root of Trust)“이라고 부른다.

이러한 디지털 인증서는 개인이나 서버의 신원과 공개키를 묶은 데이터로, CA가 서명한다.

인증서에는 다음과 같은 정보가 포함된다:

사용자 ID
사용자 공개키
유효 기간
서명 알고리즘 및 CA의 서명

브라우저 주소창에서는 이 인증서의 상태에 따라 보안 여부가 표시되는데, 자물쇠 아이콘은 HTTPS 기반으로 신뢰할 수 있는 인증서를 사용 중이라는 의미다. 반대로, 인증서가 다음과 같은 상태라면 경고 표시가 나타난다:

인증서가 만료됨
인증서가 철회됨
약한 암호화 방식 사용

6.12. Browser Phishing Attack

현대의 피싱 공격은 브라우저 내부에 가짜 브라우저 창을 띄우는 등 정교한 방식으로 이루어진다.

사용자는 진짜 웹사이트인 줄 착각하고 인증정보를 입력하게 되며, 이 정보가 공격자에게 전송된다.

대표적인 예시로 “Browser-in-the-Browser” 공격이 있다.

이러한 공격은 브라우저 보안 표시만으로는 막기 어렵기 때문에, 사용자의 인지와 시스템적 보호가 함께 필요하다.

다음은 HTTPS 통신에서 이루어지는 키 교환 과정을 도식화한 것이다.

사용자는 서버로부터 인증서를 받고, 공개키를 확인한다.
클라이언트와 서버는 Ephemeral 키 쌍을 생성하여 교환하고, 이를 통해 세션마다 독립적인 공유 비밀 키를 생성한다.
이 공유 비밀 키로부터 최종 세션 대칭키를 도출한다.

6.13. Trasport Layer Security (TLS)

TLS는 전송 계층 보안 프로토콜로, OSI 모델 기준 전송 계층 위, 응용 계층 아래에서 작동한다.

즉, HTTP의 하단에서 데이터 암호화 및 복호화를 처리한다.

클라이언트-서버 간 통신 암호화
암호 스위트 협상
세션 키 공유
서버(또는 양쪽)의 인증

TLS는 하나의 세션에서 사용할 알고리즘 집합을 “암호 스위트(cipher suite)“라고 부른다.

암호 스위트는 다음과 같은 구성 요소를 포함한다:

키 교환 알고리즘 (예: ECDHE)
인증 알고리즘 (예: RSA)
대칭 암호 알고리즘 (예: AES-GCM)
해시 알고리즘 (예: SHA-256)

예시: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256은 ECDHE로 키 교환, RSA로 인증, AES-128-GCM으로 데이터 암호화, SHA-256으로 무결성 보장한다.

TLS 1.2의 핸드셰이크는 다음과 같은 순서로 이루어진다:

Client Hello: 사용 가능한 cipher suite, 랜덤값 전송
Server Hello: 선택된 cipher suite, 서버 인증서, 서버 키 전송
Client는 서버 공개키 또는 서버의 ECDHE 키를 기반으로 pre-master secret 전송
암호화된 pre-master secret을 기반으로 양측은 세션 키를 계산
Change Cipher Spec, Finished 메시지를 통해 암호 세션 개시

TLS 1.3에서는 핸드셰이크 구조가 간소화되었다.

핸드셰이크 왕복이 2회에서 1회로 축소됨
클라이언트 Hello에 바로 ECDHE 키 포함
서버 Hello에서 바로 응답하며 키 합의

이 방식은 보안성과 속도 모두를 향상시켰다.

핸드셰이크가 끝난 뒤, 실제 데이터는 TLS Record 단위로 전송된다.

각 레코드는 다음 구조를 갖는다:

헤더: TLS 버전, 길이, 타입 등
페이로드: 암호화된 데이터 블록

TLS는 이 구조를 통해 안전하고 구조화된 통신을 제공한다.

6.14. Hybrid Encryption on Ransomware

현대의 랜섬웨어는 대부분 하이브리드 암호 시스템을 사용한다.

즉, 공개키 암호와 대칭키 암호를 조합하여 성능과 보안을 동시에 확보하려는 구조다.

예시로 WannaCry와 Hive 랜섬웨어가 있다.

6.14.1. WannaCry의 구조

서버 공개키는 프로그램에 하드코딩되어 있다.
감염된 클라이언트는 자체적으로 개별 RSA 키 쌍을 생성한다.
이 클라이언트 RSA 개인키를 서버의 공개키로 암호화하여 저장하고, 원본 개인키는 폐기된다.
감염된 각 파일에 대해 새로운 대칭키(AES 키)를 생성하고, 파일을 AES로 암호화한다.
이 대칭키는 클라이언트 RSA 공개키로 암호화되어 저장된다.

이러한 구조는 겉보기에 보안적이지만, 일부 문제점이 있다.

랜섬웨어는 가능한 많은 파일을 빠르게 암호화해야 하므로, AES 같은 빠른 대칭키 암호화를 주로 사용한다. 특히 Hive 랜섬웨어는 자체적으로 암호화 로직을 구현했는데,

이 과정에서 다음과 같은 치명적인 실수가 있었다:

각 파일마다 사용하는 랜덤 키스트림이 충분히 예측 가능하거나 고정된 방식으로 생성됨
암호화된 데이터가 단순 XOR 연산으로 처리됨

이로 인해 국민대학교 연구진이 Hive의 암호 시스템을 분석하고 복호화 방법을 개발하게 되었다

이 사례는 “암호는 직접 구현하지 말라”는 보안 원칙을 실제로 증명하는 대표적 예시다.

6.15. Verified Boot: 암호의 바람직한 활용 예시

Verified Boot는 암호학적 서명을 사용하여, 디바이스가 부팅되는 과정에서 실행되는 모든 코드가 신뢰된 소스에서 왔는지를 검증한다.

6.15.1. Android Verified Boot 시퀀스

CPU가 켜지며, 읽기 전용 저장소에서 BL1을 로드한다.
BL1은 BL2를 찾고, 메모리에 로드한 뒤 루트 공개키로 서명 검증을 수행하고, 성공 시 실행한다.
BL2는 보안 환경과 비보안 환경을 설정하고, BL3 부트로더들을 로드한다.
…
BL33은 비보안 OS 커널을 찾아 서명 검증 후 실행한다.

이 과정을 통해 시스템 부팅 시 악성 부트로더나 커널이 실행되지 않도록 방지할 수 있다.

이는 암호 기술이 단순 데이터 보호를 넘어, **신뢰 부팅(Trusted Boot)**까지 확장되어 활용되는 예시다.

6.16. 정리

이제까지 배운 용어들을 다시 정리하면 다음과 같다.

DES, AES: 대칭키 블록 암호 알고리즘
Diffie-Hellman: 키 교환 프로토콜
RSA: 공개키 암호 방식
SHA 계열: 해시 함수 (무결성 검증용)
HMAC: 메시지 인증 코드
Digital Signature: 공개키 기반 서명
Certificate: 디지털 인증서
CA: 인증 기관 (신뢰 체계의 루트)

각 용어는 실제 보안 프로토콜에서 서로 조합되어 사용되며, 암호학적 목표(기밀성, 무결성, 인증, 부인방지)를 달성하는 데 기여한다.

6.17. 현대 암호 연구 분야

암호학은 다음과 같은 네 개의 분야로 활발히 연구되고 있다:

깨뜨리는 연구 - 이론적 공격 (수학적 약점, 알고리즘 분석) - 구현 공격 (측채널, 취약한 프로토콜 구성)
강화하는 연구 - 새로운 알고리즘 설계 - 안전한 구현 체계 개발
새로운 암호 기법 - 동형 암호(Homomorphic Encryption) - 양자 내성 암호(Post-Quantum Cryptography, PQC)
실용 암호 응용 - 다자간 보안 연산 - 프라이버시 보호 프로토콜

6.18. Side-Channel Attack

현대 공격자들은 알고리즘 자체가 아닌 구현 과정에서 생기는 부수 정보를 악용한다.

시간 정보 (Timing Attack)
전력 소비 패턴
메모리 접근 시간 등

6.18.1. Step 1: Key Generation

$p = 5$ , $q = 11$
공개지수 $e = 3$

문제 1.

$n = p \times q$ 를 구하시오.
$ϕ (n)$ (오일러 토션트 함수)를 구하시오.
$d$ 를 구하시오. 단, $e \cdot d \equiv 1 mod ϕ (n)$ 을 만족해야 함

6.18.2. Step 2: Encryption

평문 $M = 9$ (숫자 메시지라고 가정)
공개키 $(e, n)$ 을 사용해 암호문 $C$ 를 구하시오.

C = M^e \mod n

6.18.3. Step 3: Decryption

암호문 $C$ 를 비공개키 $(d, n)$ 으로 복호화하시오.
```
  M = C^d \mod n
```

맛있는고슴도치

탐색기

Computer Security

1. Overview (컴퓨터 보안 개요)

1.1. 왜 보안은 어려운가?

1.2. 왜 보안이 필요한가?

1.3. 메모리 안전성의 “위기”

1.4. 보안이란?

1.5. CIA Triad - Threats to what

1.6. Threats to Data (데이터의 위협)

1.7. Defend Against Threats (보안 대응)

1.7.1. Defense in Depth (다층 방어)

1.7.2. Assumption & Trust (신뢰와 가정)

1.7.3. Trusted Computing Base (TCB)

1.7.4. Precision of Mechanism (보안 메커니즘의 정밀성)

1.8. Operational Issues & Human Issues

1.9. “Security is a Process, not a Product”

2. Access Control (접근 제어)

2.1.1. 2️.1. 컴퓨터 보안의 골든 스탠다드: AAA

2.1.2. 기본 모델: Access Control Matrix (접근 제어 행렬)

2.2. Implementation of Acceess Control Matrix

2.2.1. Access Control List (ACL, 접근 제어 리스트)

2.2.2. Capability List (가용성 리스트)

2.2.3. Relationship-Based

2.2.4. ACL vs. Capability

2.3. 유닉스 시스템에서의 접근 제어 (ACL)

2.3.1. UID & GID

2.3.2. Object’s Attributes in Filesystem

2.3.3. Permission Bits (접근 권한 구조 비트)

2.3.4. Special Permission Bits (특수 비트)

2.3.5. ID in User & Process

2.4. sudo의 동작

2.5. chown의 동작

2.6. Capability-as-Key & Ambient Authority, Confused Deputy Problem

2.7. Access Control Types (접근 제어의 유형)

2.8. Mandatory Access Control (MAC, 강제 접근 통제)

3. Authentication (인증)

3.1. 인증 수단의 유형

3.2. 인증의 3단계

3.3. 인증 시스템의 수학적 모델

3.4. Unix Password System

3.5. 공격자 모델

3.5.1. Dictionary Attack

3.5.2. Rainbow Table(Precomputed Hash Chain)과 Salt

3.5.3. 해시 함수 속도와 공격자 유리성

3.6. 비밀번호 재사용 문제와 비밀번호 복구의 문제점

3.7. 2단계 인증 (2FA, Two-Factor Authentication)

3.8. 기타 인증 방법

4. Cryptography – Classical (고전 암호 기법)

4.1. Cryptosystem

4.2. Caesar Cipher

4.3. 공격자 모델과 Kerckhoffs의 원칙

4.4. 고전 암호(Classical Ciphers)

4.4.1. Substitution Cipher (Caesar Cipher)

4.4.2. Vigenère Cipher (비즈네르 암호)

4.4.3. Transposition Ciphers

4.4.4. Product Cipher

4.5. Realistic Threats

4.5.1. Ciphertext-Only Attack (암호문만 있는 공격)

4.5.2. Known-Plaintext Attack (알려진 평문 공격)

4.5.3. Chosen-Plaintext Attack (선택 평문 공격)

4.5.4. Chosen-Ciphertext Attack (선택 암호문 공격)

4.6. 🧱 Chapter 5: Symmetric Cryptography (대칭 키 암호)

4.7. 대칭키 암호 개요

4.8. Two Strategies to Defeat Statistic Cryptanalysis

4.9. Feistel Cipher

4.10. Data Encryption Standard (DES)

4.11. Advanced Encryption Standard (AES)

4.12. Modes of Operation (암호 모드)

4.12.1. Block Cipher, Stream Cipher, One-time Pad

4.12.2. Message Authentication Code (MAC)

4.12.3. Modes of Operation (암호 모드)

5. Asymmetric Cryptography (비대칭 키 암호)

5.1. 비대칭 키의 역사

5.2. 비대칭 키 암호란?

5.2.1. Confidentiality (기밀성)

5.2.2. Non-Repudiation (부인 방지)

5.3. Diffie-Hellman Key Exchange (DH 키 교환)

5.4. MITM 공격 (Man-in-the-Middle)

5.5. RSA (Rivest-Shamir-Adleman)