Plaintext
암호화하기 전의 원래 메시지입니다. 사람이 읽는 문장뿐 아니라 파일의 byte도 plaintext가 될 수 있습니다.
Editorial study journal
오늘은 한 문항부터 시작하세요
실제 WiSe 25/26 시험의 네 챕터를 원문 순서대로 나누고, 각 Multiple Choice와 후속 소문제를 배치했습니다.
0/ 71
전체 학습 진도
0문항 다시 학습 · 0문항 추가 검토
Quick practice
조건을 정해 바로 풀기
Chapter 1
Krypto
Multiple Choice · Angreifermodelle · Asymmetrische Kryptographie
완전 초보자를 위한 1타 강사식 입문 강의
암호학은 ‘무엇을 숨기고, 무엇을 증명하는가’를 구분하는 과목입니다
개념이 하나도 없다면 여기서 시작
암호학(Kryptographie)은 데이터를 마법처럼 안전하게 만드는 기술이 아닙니다. 평문(plaintext)에 키(key)와 정해진 알고리즘을 적용해 암호문(ciphertext)을 만들고, 공격자가 무엇을 할 수 있어도 어떤 보안 목표가 유지되는지 따지는 분야입니다. 문제를 보면 먼저 기밀성(confidentiality), 무결성(integrity), 진위성(authenticity) 중 무엇을 묻는지 표시하세요.
01 평문·암호문·키 암호화의 세 등장인물
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
암호화의 가장 기본적인 등장인물
용어를 보기 전에 장면부터 잡아 봅시다. 누구나 자물쇠의 설계도를 볼 수 있지만 실제 열쇠가 없으면 열지 못하는 자물쇠를 생각하면 된다. 설계도를 숨기는 것이 아니라 열쇠를 관리하는 것이 핵심이다.
이제 그 장면에 실제 이름을 붙이면 평문(plaintext)은 보호하기 전의 원래 데이터이고 암호문(ciphertext)은 암호화 후 읽기 어렵게 바뀐 데이터다. 암호화(encryption)는 평문과 키(key)를 알고리즘에 넣어 암호문을 만드는 과정이고 복호화(decryption)는 올바른 키를 이용해 평문을 되찾는 과정이다. 키는 문을 여는 실제 열쇠에 해당하며, 현대 암호에서는 알고리즘 자체가 공개되어도 키가 비밀이면 안전해야 한다고 본다.
머릿속에서 순서대로 움직이면 누가 평문을 가지고 있는지 확인한다. → 어떤 키로 암호화하고 누가 복호화 키를 가지는지 확인한다. → 암호문이 노출되어도 공격자가 어떤 정보를 얻지 못해야 하는지 적는다.
보안이란 무엇을 지키는 것인가
용어를 보기 전에 장면부터 잡아 봅시다. 봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
이제 그 장면에 실제 이름을 붙이면 컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
머릿속에서 순서대로 움직이면 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다. → 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다. → 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
TERMS FROM ZERO
평문·암호문·키에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Ciphertext
암호화 결과입니다. 숨겨진 원문과 같은 말이 아니라, key 없이는 원문을 알아내기 어려워야 하는 출력입니다.
Key
암호 알고리즘의 동작을 결정하는 값입니다. 알고리즘 자체가 아니라 key를 비밀로 관리하는 것이 현대 암호의 기본입니다.
Encryption / Decryption
Encryption은 plaintext를 ciphertext로, decryption은 올바른 key로 ciphertext를 다시 plaintext로 바꾸는 과정입니다.
Asset
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
Confidentiality
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
Integrity
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
Availability
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
처음부터 설명하면
평문은 숨기고 싶은 원래 데이터, 암호문은 변환된 결과, 키는 변환 규칙을 결정하는 값입니다. 알고리즘은 공개되어도 괜찮고 키가 비밀이어야 한다는 것이 현대 암호의 기본 생각입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
암호화의 가장 기본적인 등장인물
평문(plaintext)은 보호하기 전의 원래 데이터이고 암호문(ciphertext)은 암호화 후 읽기 어렵게 바뀐 데이터다. 암호화(encryption)는 평문과 키(key)를 알고리즘에 넣어 암호문을 만드는 과정이고 복호화(decryption)는 올바른 키를 이용해 평문을 되찾는 과정이다. 키는 문을 여는 실제 열쇠에 해당하며, 현대 암호에서는 알고리즘 자체가 공개되어도 키가 비밀이면 안전해야 한다고 본다.
보안이란 무엇을 지키는 것인가
컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
쉬운 비유
자물쇠의 설계도는 모두가 볼 수 있지만, 실제 열쇠는 소유자만 갖는 상황과 비슷합니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
암호화의 가장 기본적인 등장인물
누구나 자물쇠의 설계도를 볼 수 있지만 실제 열쇠가 없으면 열지 못하는 자물쇠를 생각하면 된다. 설계도를 숨기는 것이 아니라 열쇠를 관리하는 것이 핵심이다.
보안이란 무엇을 지키는 것인가
봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
시험 함정
암호화(encryption)는 내용을 숨기는 기능입니다. 누가 보냈는지와 변조 여부까지 자동으로 증명하지는 않습니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
암호화의 가장 기본적인 등장인물
암호화는 기본적으로 내용을 숨긴다. 누가 보냈는지, 내용이 바뀌지 않았는지, 서비스가 계속 동작하는지까지 저절로 보장하지는 않는다.
보안이란 무엇을 지키는 것인가
TLS, 암호화, 서명, hash처럼 익숙한 단어가 나오더라도 그 기술이 제공하지 않는 목표까지 확대해서 쓰면 안 된다.
답안에 적용
먼저 ‘공격자가 키를 모른다’와 ‘보호하려는 목표가 confidentiality다’를 분리해 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
암호화의 가장 기본적인 등장인물 — 답안을 만드는 확인 순서
- 누가 평문을 가지고 있는지 확인한다.
- 어떤 키로 암호화하고 누가 복호화 키를 가지는지 확인한다.
- 암호문이 노출되어도 공격자가 어떤 정보를 얻지 못해야 하는지 적는다.
보안이란 무엇을 지키는 것인가 — 답안을 만드는 확인 순서
- 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다.
- 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다.
- 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
숫자와 입력값을 넣어서 한 번 따라가기
Alice와 Bob만 `K7`이라는 secret key를 공유하고, Eve는 algorithm과 전송된 ciphertext를 모두 볼 수 있다고 합시다.
- Alice의 입력 메시지 `MEET AT NOON`이 plaintext입니다. Plaintext는 ‘영어 문장’만 뜻하지 않고 암호화 전 byte 전체를 뜻합니다.
- 공개된 encryption algorithm에 plaintext와 key `K7`을 함께 넣습니다. Algorithm이 공개되어도 key가 비밀이면 안전해야 합니다.
- 출력된 ciphertext는 network를 통해 전송됩니다. Eve는 이를 복사할 수 있지만 그것만으로 원문을 알아내기 어려워야 합니다.
- Bob은 같은 key `K7`과 decryption algorithm을 사용해 plaintext를 복원합니다.
이 예제의 결론 · Algorithm은 공개된 조리법이고 key는 결과를 결정하는 비밀 재료입니다. Ciphertext는 key가 아니라 encryption의 출력입니다.
02 Block cipher·Mode·Padding AES와 ECB/CBC/CTR은 같은 층위가 아닙니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Block cipher, mode, padding을 서로 구분하기
용어를 보기 전에 장면부터 잡아 봅시다. 네 칸짜리 상자만 처리하는 기계가 block cipher다. 상자를 어떤 순서로 연결해 보낼지가 mode이고, 마지막 상자에 물건이 한 개만 있을 때 남은 칸을 약속된 재료로 채우는 것이 padding이다.
이제 그 장면에 실제 이름을 붙이면 Block cipher는 AES처럼 정확히 정해진 길이의 데이터 블록 하나를 키로 변환하는 부품이다. 긴 메시지를 여러 블록으로 처리하는 사용 규칙을 mode of operation이라고 하며 ECB, CBC, CTR 등이 있다. 마지막 조각이 블록보다 짧을 때 규칙에 맞는 값을 덧붙여 길이를 맞추는 것이 padding이다. XOR는 두 bit, 즉 0 또는 1인 두 자리 값이 서로 다를 때 1을 만드는 연산이다. 모든 mode가 padding을 요구하는 것은 아니다.
머릿속에서 순서대로 움직이면 블록 크기와 키 길이는 서로 다른 값임을 구분한다. → ECB와 CBC는 보통 완전한 마지막 블록이 필요하므로 짧으면 padding한다. → CTR은 keystream의 필요한 부분만 평문과 XOR할 수 있어 별도 padding 없이 부분 블록을 처리할 수 있다. → CBC에서 중간 블록을 복호화하려면 현재 암호문과 직전 암호문 또는 IV가 필요하다.
암호화의 가장 기본적인 등장인물
용어를 보기 전에 장면부터 잡아 봅시다. 누구나 자물쇠의 설계도를 볼 수 있지만 실제 열쇠가 없으면 열지 못하는 자물쇠를 생각하면 된다. 설계도를 숨기는 것이 아니라 열쇠를 관리하는 것이 핵심이다.
이제 그 장면에 실제 이름을 붙이면 평문(plaintext)은 보호하기 전의 원래 데이터이고 암호문(ciphertext)은 암호화 후 읽기 어렵게 바뀐 데이터다. 암호화(encryption)는 평문과 키(key)를 알고리즘에 넣어 암호문을 만드는 과정이고 복호화(decryption)는 올바른 키를 이용해 평문을 되찾는 과정이다. 키는 문을 여는 실제 열쇠에 해당하며, 현대 암호에서는 알고리즘 자체가 공개되어도 키가 비밀이면 안전해야 한다고 본다.
머릿속에서 순서대로 움직이면 누가 평문을 가지고 있는지 확인한다. → 어떤 키로 암호화하고 누가 복호화 키를 가지는지 확인한다. → 암호문이 노출되어도 공격자가 어떤 정보를 얻지 못해야 하는지 적는다.
TERMS FROM ZERO
Block cipher·Mode·Padding에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Block cipher
AES처럼 정해진 크기의 한 block을 key로 변환하는 암호 primitive입니다.
Mode of operation
한 block짜리 암호를 긴 메시지에 안전하게 반복 적용하는 연결 규칙입니다. ECB, CBC, CTR 등이 있습니다.
Padding
마지막 plaintext 조각이 block보다 짧을 때 필요한 길이를 채우는 규칙입니다.
IV / Nonce
같은 key로 암호화해도 결과가 반복되지 않게 mode에 넣는 시작값입니다. mode에 따라 무작위성·유일성 요구가 다릅니다.
Plaintext
암호화하기 전의 원래 메시지입니다. 사람이 읽는 문장뿐 아니라 파일의 byte도 plaintext가 될 수 있습니다.
Ciphertext
암호화 결과입니다. 숨겨진 원문과 같은 말이 아니라, key 없이는 원문을 알아내기 어려워야 하는 출력입니다.
Key
암호 알고리즘의 동작을 결정하는 값입니다. 알고리즘 자체가 아니라 key를 비밀로 관리하는 것이 현대 암호의 기본입니다.
Encryption / Decryption
Encryption은 plaintext를 ciphertext로, decryption은 올바른 key로 ciphertext를 다시 plaintext로 바꾸는 과정입니다.
처음부터 설명하면
Block cipher는 고정 길이 블록 하나를 바꾸는 부품이고, mode of operation은 그 부품으로 긴 메시지를 처리하는 사용법입니다. ECB/CBC는 마지막 블록이 짧을 때 padding이 필요할 수 있지만 CTR은 블록 암호로 keystream을 만들어 스트림처럼 처리합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Block cipher, mode, padding을 서로 구분하기
Block cipher는 AES처럼 정확히 정해진 길이의 데이터 블록 하나를 키로 변환하는 부품이다. 긴 메시지를 여러 블록으로 처리하는 사용 규칙을 mode of operation이라고 하며 ECB, CBC, CTR 등이 있다. 마지막 조각이 블록보다 짧을 때 규칙에 맞는 값을 덧붙여 길이를 맞추는 것이 padding이다. XOR는 두 bit, 즉 0 또는 1인 두 자리 값이 서로 다를 때 1을 만드는 연산이다. 모든 mode가 padding을 요구하는 것은 아니다.
암호화의 가장 기본적인 등장인물
평문(plaintext)은 보호하기 전의 원래 데이터이고 암호문(ciphertext)은 암호화 후 읽기 어렵게 바뀐 데이터다. 암호화(encryption)는 평문과 키(key)를 알고리즘에 넣어 암호문을 만드는 과정이고 복호화(decryption)는 올바른 키를 이용해 평문을 되찾는 과정이다. 키는 문을 여는 실제 열쇠에 해당하며, 현대 암호에서는 알고리즘 자체가 공개되어도 키가 비밀이면 안전해야 한다고 본다.
쉬운 비유
블록 암호가 한 칸짜리 도장이라면 mode는 긴 종이에 도장을 찍는 순서이고, padding은 마지막 빈칸을 채우는 방법입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Block cipher, mode, padding을 서로 구분하기
네 칸짜리 상자만 처리하는 기계가 block cipher다. 상자를 어떤 순서로 연결해 보낼지가 mode이고, 마지막 상자에 물건이 한 개만 있을 때 남은 칸을 약속된 재료로 채우는 것이 padding이다.
암호화의 가장 기본적인 등장인물
누구나 자물쇠의 설계도를 볼 수 있지만 실제 열쇠가 없으면 열지 못하는 자물쇠를 생각하면 된다. 설계도를 숨기는 것이 아니라 열쇠를 관리하는 것이 핵심이다.
시험 함정
‘Block cipher를 사용한다 → 항상 padding이 필요하다’는 결론은 틀립니다. mode와 메시지 길이를 먼저 봐야 합니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Block cipher, mode, padding을 서로 구분하기
‘블록 암호를 쓴다’에서 곧바로 ‘항상 padding이 필요하다’ 또는 ‘어디서나 독립 복호화가 가능하다’로 넘어가면 안 된다. mode를 먼저 확인해야 한다.
암호화의 가장 기본적인 등장인물
암호화는 기본적으로 내용을 숨긴다. 누가 보냈는지, 내용이 바뀌지 않았는지, 서비스가 계속 동작하는지까지 저절로 보장하지는 않는다.
답안에 적용
ECB/CBC/CTR 중 어느 mode인지, 마지막 블록 길이가 맞는지, 블록 사이 의존성이 있는지 순서대로 확인합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Block cipher, mode, padding을 서로 구분하기 — 답안을 만드는 확인 순서
- 블록 크기와 키 길이는 서로 다른 값임을 구분한다.
- ECB와 CBC는 보통 완전한 마지막 블록이 필요하므로 짧으면 padding한다.
- CTR은 keystream의 필요한 부분만 평문과 XOR할 수 있어 별도 padding 없이 부분 블록을 처리할 수 있다.
- CBC에서 중간 블록을 복호화하려면 현재 암호문과 직전 암호문 또는 IV가 필요하다.
암호화의 가장 기본적인 등장인물 — 답안을 만드는 확인 순서
- 누가 평문을 가지고 있는지 확인한다.
- 어떤 키로 암호화하고 누가 복호화 키를 가지는지 확인한다.
- 암호문이 노출되어도 공격자가 어떤 정보를 얻지 못해야 하는지 적는다.
03 One-Time Pad 계산 능력이 아니라 정보가 부족해서 안전합니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
One-Time Pad와 brute force가 만나는 지점
용어를 보기 전에 장면부터 잡아 봅시다. 상자 안에 고양이, 책, 사과 중 무엇이 들어 있는지 맞히려는데 각 답마다 완벽히 맞는 별도의 가림막이 존재하는 상황이다. 가림막을 전부 찾아도 진짜 답을 선택할 단서가 없다.
이제 그 장면에 실제 이름을 붙이면 One-Time Pad(OTP)는 메시지와 같은 길이의 완전한 난수 키를 만들고 평문과 XOR한 뒤 그 키를 딱 한 번만 쓰는 암호다. XOR는 0과 1로 표현한 두 값이 서로 다르면 1, 같으면 0을 만드는 연산이며 같은 키로 다시 XOR하면 원래 값이 돌아온다. 이 조건을 모두 지키면 완전 비밀성(perfect secrecy)을 얻는다. Brute force는 가능한 키를 전부 시험하는 공격이지만, OTP에서는 각 평문 후보마다 그것을 설명하는 키가 하나씩 존재하므로 모든 키를 시험해도 어느 평문이 진짜인지 고를 정보가 없다.
머릿속에서 순서대로 움직이면 키가 정말 무작위인지 확인한다. → 키 길이가 메시지 길이 이상인지 확인한다. → 같은 키를 두 번 사용하지 않았는지 확인한다. → 공격자가 후보를 생성하는 것과 진짜 후보를 식별하는 것을 구분한다.
암호화의 가장 기본적인 등장인물
용어를 보기 전에 장면부터 잡아 봅시다. 누구나 자물쇠의 설계도를 볼 수 있지만 실제 열쇠가 없으면 열지 못하는 자물쇠를 생각하면 된다. 설계도를 숨기는 것이 아니라 열쇠를 관리하는 것이 핵심이다.
이제 그 장면에 실제 이름을 붙이면 평문(plaintext)은 보호하기 전의 원래 데이터이고 암호문(ciphertext)은 암호화 후 읽기 어렵게 바뀐 데이터다. 암호화(encryption)는 평문과 키(key)를 알고리즘에 넣어 암호문을 만드는 과정이고 복호화(decryption)는 올바른 키를 이용해 평문을 되찾는 과정이다. 키는 문을 여는 실제 열쇠에 해당하며, 현대 암호에서는 알고리즘 자체가 공개되어도 키가 비밀이면 안전해야 한다고 본다.
머릿속에서 순서대로 움직이면 누가 평문을 가지고 있는지 확인한다. → 어떤 키로 암호화하고 누가 복호화 키를 가지는지 확인한다. → 암호문이 노출되어도 공격자가 어떤 정보를 얻지 못해야 하는지 적는다.
TERMS FROM ZERO
One-Time Pad에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
One-Time Pad
평문과 같은 길이의 완전 무작위 key를 정확히 한 번만 사용하는 암호입니다.
XOR
두 bit가 다르면 1, 같으면 0이 되는 연산입니다. 같은 key를 두 번 XOR하면 원래 값이 복원됩니다.
Brute force
가능한 key를 하나씩 모두 시험하는 공격 방법입니다.
Perfect secrecy
계산 능력이 무한해도 ciphertext만으로 plaintext 정보를 얻지 못하는 정보이론적 안전성입니다.
Plaintext
암호화하기 전의 원래 메시지입니다. 사람이 읽는 문장뿐 아니라 파일의 byte도 plaintext가 될 수 있습니다.
Ciphertext
암호화 결과입니다. 숨겨진 원문과 같은 말이 아니라, key 없이는 원문을 알아내기 어려워야 하는 출력입니다.
Key
암호 알고리즘의 동작을 결정하는 값입니다. 알고리즘 자체가 아니라 key를 비밀로 관리하는 것이 현대 암호의 기본입니다.
Encryption / Decryption
Encryption은 plaintext를 ciphertext로, decryption은 올바른 key로 ciphertext를 다시 plaintext로 바꾸는 과정입니다.
처음부터 설명하면
OTP는 메시지와 같은 길이의 완전한 난수 키를 딱 한 번 사용하고 XOR합니다. 조건을 지키면 모든 평문 후보에 대응하는 키가 존재하므로 ciphertext만 보고 진짜 평문을 고를 정보가 없습니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
One-Time Pad와 brute force가 만나는 지점
One-Time Pad(OTP)는 메시지와 같은 길이의 완전한 난수 키를 만들고 평문과 XOR한 뒤 그 키를 딱 한 번만 쓰는 암호다. XOR는 0과 1로 표현한 두 값이 서로 다르면 1, 같으면 0을 만드는 연산이며 같은 키로 다시 XOR하면 원래 값이 돌아온다. 이 조건을 모두 지키면 완전 비밀성(perfect secrecy)을 얻는다. Brute force는 가능한 키를 전부 시험하는 공격이지만, OTP에서는 각 평문 후보마다 그것을 설명하는 키가 하나씩 존재하므로 모든 키를 시험해도 어느 평문이 진짜인지 고를 정보가 없다.
암호화의 가장 기본적인 등장인물
평문(plaintext)은 보호하기 전의 원래 데이터이고 암호문(ciphertext)은 암호화 후 읽기 어렵게 바뀐 데이터다. 암호화(encryption)는 평문과 키(key)를 알고리즘에 넣어 암호문을 만드는 과정이고 복호화(decryption)는 올바른 키를 이용해 평문을 되찾는 과정이다. 키는 문을 여는 실제 열쇠에 해당하며, 현대 암호에서는 알고리즘 자체가 공개되어도 키가 비밀이면 안전해야 한다고 본다.
쉬운 비유
정답 후보마다 정확히 맞는 별도의 가림막이 존재해, 가림막만 보고 원래 답을 하나로 고를 수 없는 상황입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
One-Time Pad와 brute force가 만나는 지점
상자 안에 고양이, 책, 사과 중 무엇이 들어 있는지 맞히려는데 각 답마다 완벽히 맞는 별도의 가림막이 존재하는 상황이다. 가림막을 전부 찾아도 진짜 답을 선택할 단서가 없다.
암호화의 가장 기본적인 등장인물
누구나 자물쇠의 설계도를 볼 수 있지만 실제 열쇠가 없으면 열지 못하는 자물쇠를 생각하면 된다. 설계도를 숨기는 것이 아니라 열쇠를 관리하는 것이 핵심이다.
시험 함정
키를 재사용하면 C1 XOR C2에서 키가 사라져 두 평문의 관계가 노출됩니다. 올바른 OTP와 key reuse 사고를 섞지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
One-Time Pad와 brute force가 만나는 지점
OTP 키를 재사용하면 두 암호문을 XOR할 때 키가 사라져 평문 관계가 노출된다. 올바른 OTP와 키 재사용 사고를 같은 것으로 보면 안 된다.
암호화의 가장 기본적인 등장인물
암호화는 기본적으로 내용을 숨긴다. 누가 보냈는지, 내용이 바뀌지 않았는지, 서비스가 계속 동작하는지까지 저절로 보장하지는 않는다.
답안에 적용
random, message-length, one-time이라는 세 조건과 ‘brute force 후에도 후보를 식별할 수 없음’을 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
One-Time Pad와 brute force가 만나는 지점 — 답안을 만드는 확인 순서
- 키가 정말 무작위인지 확인한다.
- 키 길이가 메시지 길이 이상인지 확인한다.
- 같은 키를 두 번 사용하지 않았는지 확인한다.
- 공격자가 후보를 생성하는 것과 진짜 후보를 식별하는 것을 구분한다.
암호화의 가장 기본적인 등장인물 — 답안을 만드는 확인 순서
- 누가 평문을 가지고 있는지 확인한다.
- 어떤 키로 암호화하고 누가 복호화 키를 가지는지 확인한다.
- 암호문이 노출되어도 공격자가 어떤 정보를 얻지 못해야 하는지 적는다.
숫자와 입력값을 넣어서 한 번 따라가기
Plaintext `10101001`, 무작위 key `01100110`을 정확히 한 번만 사용합니다.
- 첫 bit는 `1 XOR 0 = 1`, 둘째는 `0 XOR 1 = 1`처럼 위치별로 계산합니다.
- 여덟 bit를 모두 계산하면 ciphertext는 `11001111`입니다.
- Bob은 `11001111 XOR 01100110`을 계산해 원래 `10101001`을 얻습니다.
- Eve가 ciphertext만 보면 임의의 plaintext 후보마다 그 후보를 설명하는 key가 하나씩 존재합니다.
이 예제의 결론 · 완전 안전성은 key가 평문과 같은 길이, 완전 무작위, 비밀, 단 한 번 사용이라는 네 조건을 모두 만족할 때만 성립합니다.
04 Hash·Collision 되돌리는 암호가 아니라 고정 길이 지문입니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Hash는 암호화가 아니라 고정 길이 지문이다
용어를 보기 전에 장면부터 잡아 봅시다. 수많은 책을 짧은 서가 번호로 압축해 표시하면 언젠가 같은 번호가 겹친다. 좋은 hash는 공격자가 원하는 겹침을 일부러 찾기 매우 어렵게 만든다.
이제 그 장면에 실제 이름을 붙이면 Cryptographic hash function은 길이가 제각각인 입력을 정해진 길이의 digest로 바꾼다. 같은 입력은 같은 digest를 만들지만 digest에서 원문을 되찾기는 어려워야 한다. 서로 다른 두 입력이 같은 digest를 만드는 상황을 collision이라고 한다. 입력 가능성은 사실상 무한하고 출력 종류는 유한하므로 collision은 수학적으로 반드시 존재하며, 보안 목표는 collision이 전혀 없게 하는 것이 아니라 현실적인 시간에 찾기 어렵게 하는 것이다.
머릿속에서 순서대로 움직이면 출력 길이는 입력 문장 길이가 아니라 알고리즘이 정한 bit 수로 고정된다. → Preimage resistance는 digest에서 원문을 찾기 어려운 성질이다. → Collision resistance는 서로 다른 두 입력의 같은 digest를 찾기 어려운 성질이다. → MD5처럼 실용적인 collision 공격이 알려진 알고리즘은 보안 용도로 사용하지 않는다.
보안이란 무엇을 지키는 것인가
용어를 보기 전에 장면부터 잡아 봅시다. 봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
이제 그 장면에 실제 이름을 붙이면 컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
머릿속에서 순서대로 움직이면 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다. → 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다. → 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
TERMS FROM ZERO
Hash·Collision에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Hash function
임의 길이 입력을 고정 길이 digest로 바꾸는 단방향 함수입니다. 암호화처럼 복호화 key가 있는 기능이 아닙니다.
Digest
Hash function의 고정 길이 출력으로, 데이터의 짧은 지문처럼 사용됩니다.
Collision
서로 다른 두 입력이 같은 digest를 만드는 경우입니다. 출력 공간이 유한하므로 존재 자체는 피할 수 없습니다.
Preimage resistance
주어진 digest를 만드는 입력을 현실적인 시간에 찾기 어려워야 한다는 성질입니다.
Asset
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
Confidentiality
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
Integrity
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
Availability
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
처음부터 설명하면
Cryptographic hash는 길이가 다른 입력을 알고리즘이 정한 고정 길이 digest로 바꿉니다. 입력이 무한히 많고 출력은 유한하므로 collision은 반드시 존재하며, 목표는 collision을 현실적인 시간에 찾기 어렵게 만드는 것입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Hash는 암호화가 아니라 고정 길이 지문이다
Cryptographic hash function은 길이가 제각각인 입력을 정해진 길이의 digest로 바꾼다. 같은 입력은 같은 digest를 만들지만 digest에서 원문을 되찾기는 어려워야 한다. 서로 다른 두 입력이 같은 digest를 만드는 상황을 collision이라고 한다. 입력 가능성은 사실상 무한하고 출력 종류는 유한하므로 collision은 수학적으로 반드시 존재하며, 보안 목표는 collision이 전혀 없게 하는 것이 아니라 현실적인 시간에 찾기 어렵게 하는 것이다.
보안이란 무엇을 지키는 것인가
컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
쉬운 비유
거대한 도서관의 책을 짧은 서가 번호로 표시하면 언젠가 같은 번호가 겹칠 수 있습니다. 좋은 hash는 그 겹침을 의도적으로 찾기 어렵게 합니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Hash는 암호화가 아니라 고정 길이 지문이다
수많은 책을 짧은 서가 번호로 압축해 표시하면 언젠가 같은 번호가 겹친다. 좋은 hash는 공격자가 원하는 겹침을 일부러 찾기 매우 어렵게 만든다.
보안이란 무엇을 지키는 것인가
봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
시험 함정
collision resistant와 collision-free는 다른 말입니다. MD5는 알려진 collision 공격 때문에 현대 보안 용도로 부적절합니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Hash는 암호화가 아니라 고정 길이 지문이다
collision-free라는 절대 표현과 collision-resistant라는 계산적으로 찾기 어렵다는 표현을 구분해야 한다.
보안이란 무엇을 지키는 것인가
TLS, 암호화, 서명, hash처럼 익숙한 단어가 나오더라도 그 기술이 제공하지 않는 목표까지 확대해서 쓰면 안 된다.
답안에 적용
fixed output length, one-way 성질, collision resistance를 encryption과 구분해 설명합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Hash는 암호화가 아니라 고정 길이 지문이다 — 답안을 만드는 확인 순서
- 출력 길이는 입력 문장 길이가 아니라 알고리즘이 정한 bit 수로 고정된다.
- Preimage resistance는 digest에서 원문을 찾기 어려운 성질이다.
- Collision resistance는 서로 다른 두 입력의 같은 digest를 찾기 어려운 성질이다.
- MD5처럼 실용적인 collision 공격이 알려진 알고리즘은 보안 용도로 사용하지 않는다.
보안이란 무엇을 지키는 것인가 — 답안을 만드는 확인 순서
- 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다.
- 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다.
- 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
숫자와 입력값을 넣어서 한 번 따라가기
원리를 보기 위해 출력이 2-bit뿐인 장난감 hash를 생각합니다. 가능한 digest는 `00`, `01`, `10`, `11` 네 개뿐입니다.
- 서로 다른 입력 8개를 준비하지만 digest 상자는 네 개뿐입니다.
- 각 입력은 반드시 네 digest 중 하나로 mapping됩니다.
- Pigeonhole principle에 따라 적어도 두 입력은 같은 digest를 공유합니다.
- 따라서 secure hash의 목표는 collision이 ‘존재하지 않음’이 아니라 공격자가 찾기 어려움입니다.
이 예제의 결론 · 고정 길이 hash에는 collision이 수학적으로 반드시 존재합니다. 보안은 그 collision을 현실적인 계산량으로 찾지 못하게 만드는 데 있습니다.
05 Modulo·Key space·고전 암호 나머지 계산은 독립 복호화를 보장하지 않습니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Modulo, 경우의 수, key space를 처음부터 계산하기
용어를 보기 전에 장면부터 잡아 봅시다. 시계에서 15시는 3시로 돌아오는 것이 modulo다. 자물쇠 번호가 9칸이고 각 칸에 26개 문자를 넣을 수 있다면 첫 칸 26가지마다 둘째 칸도 26가지가 붙으므로 선택지가 계속 곱해진다.
이제 그 장면에 실제 이름을 붙이면 Modulo는 나눗셈의 나머지를 구해 값을 일정 범위 안으로 되돌리는 연산이다. 29 mod 26은 3이다. Key space는 공격자가 고려해야 하는 가능한 키 전체의 집합이다. 독립적인 자리마다 선택지가 여러 개 있으면 곱셈 원리를 사용한다. 예를 들어 9자리 각각에 26개 문자를 고를 수 있으면 26을 9번 곱한 26^9개다.
머릿속에서 순서대로 움직이면 mod n의 결과 범위가 0부터 n-1임을 확인한다. → 각 자리가 독립적으로 선택되는지 확인한다. → 선택지 수를 자리 수만큼 곱하고 거듭제곱으로 적는다. → Modulo 산술과 block mode의 데이터 의존성은 별개의 문제임을 기억한다.
Shift cipher, Vigenère cipher, frequency analysis
용어를 보기 전에 장면부터 잡아 봅시다. 사람들의 키를 모두 3cm씩 늘려도 누가 가장 큰지는 그대로 드러난다. Shift cipher도 글자 이름만 이동할 뿐 자주 나온 글자의 순위와 모양은 남는다.
이제 그 장면에 실제 이름을 붙이면 Shift cipher는 알파벳의 모든 글자를 같은 수만큼 밀어 바꾸는 고전 암호다. Vigenère cipher는 여러 shift 값을 담은 키를 반복 사용해 위치마다 다른 이동을 적용한다. Frequency analysis는 자연어에서 E나 한글의 특정 글자처럼 어떤 기호가 자주 등장한다는 통계적 특징을 이용한다. 단순 shift는 빈도 분포의 모양이 그대로 이동하기 때문에 쉽게 공격할 수 있다.
머릿속에서 순서대로 움직이면 평문 문자를 숫자로 바꾼다. → 키만큼 더하거나 빼고 alphabet 크기로 modulo한다. → 암호문의 빈도를 세어 자연어 빈도와 비교한다. → Vigenère에서는 반복되는 키 길이를 먼저 추정한 뒤 같은 키 위치끼리 나누어 분석한다.
TERMS FROM ZERO
Modulo·Key space·고전 암호에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Modulo
어떤 수를 나눈 나머지만 보는 연산입니다. 시계가 12 다음 1로 돌아가는 것과 비슷합니다.
Key space
가능한 모든 key의 집합과 그 개수입니다.
Entropy
공격자가 key를 예측하기 어려운 정도를 bit 단위로 나타내는 관점입니다. 단순 길이와 항상 같지는 않습니다.
Multiplication principle
독립적으로 고르는 각 자리의 경우의 수를 곱해 전체 경우의 수를 계산하는 원리입니다.
Shift cipher
각 글자를 알파벳에서 같은 거리만큼 이동시키는 고전 암호입니다.
Vigenère cipher
여러 shift 값을 key word에 따라 반복 적용하는 다중 알파벳 치환 암호입니다.
Frequency analysis
언어에서 자주 나오는 글자와 패턴의 통계를 이용해 치환 관계를 추측하는 공격입니다.
Cryptanalysis
key를 모르는 상태에서 암호 구조나 구현의 약점을 분석해 정보를 얻는 작업입니다.
처음부터 설명하면
Modulo는 값을 일정 범위로 되돌리는 나머지 계산입니다. Vigenère에서 알파벳 26개와 길이 9인 키의 경우 각 자리에 26개 선택이 있으므로 key space는 26^9입니다. Shift cipher는 글자 빈도 모양이 이동할 뿐 사라지지 않습니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Modulo, 경우의 수, key space를 처음부터 계산하기
Modulo는 나눗셈의 나머지를 구해 값을 일정 범위 안으로 되돌리는 연산이다. 29 mod 26은 3이다. Key space는 공격자가 고려해야 하는 가능한 키 전체의 집합이다. 독립적인 자리마다 선택지가 여러 개 있으면 곱셈 원리를 사용한다. 예를 들어 9자리 각각에 26개 문자를 고를 수 있으면 26을 9번 곱한 26^9개다.
Shift cipher, Vigenère cipher, frequency analysis
Shift cipher는 알파벳의 모든 글자를 같은 수만큼 밀어 바꾸는 고전 암호다. Vigenère cipher는 여러 shift 값을 담은 키를 반복 사용해 위치마다 다른 이동을 적용한다. Frequency analysis는 자연어에서 E나 한글의 특정 글자처럼 어떤 기호가 자주 등장한다는 통계적 특징을 이용한다. 단순 shift는 빈도 분포의 모양이 그대로 이동하기 때문에 쉽게 공격할 수 있다.
쉬운 비유
시계에서 15시는 3시로 돌아오지만, 그렇다고 기차의 어느 칸부터 타도 같은 경로가 되는 것은 아닙니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Modulo, 경우의 수, key space를 처음부터 계산하기
시계에서 15시는 3시로 돌아오는 것이 modulo다. 자물쇠 번호가 9칸이고 각 칸에 26개 문자를 넣을 수 있다면 첫 칸 26가지마다 둘째 칸도 26가지가 붙으므로 선택지가 계속 곱해진다.
Shift cipher, Vigenère cipher, frequency analysis
사람들의 키를 모두 3cm씩 늘려도 누가 가장 큰지는 그대로 드러난다. Shift cipher도 글자 이름만 이동할 뿐 자주 나온 글자의 순위와 모양은 남는다.
시험 함정
mod 계산과 암호 mode의 블록 의존성을 혼동하지 말고, 경우의 수에서 ‘자리별 선택’은 곱셈의 반복, 즉 거듭제곱임을 기억하세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Modulo, 경우의 수, key space를 처음부터 계산하기
알파벳 26개와 키 길이 9를 26×9로 계산하면 안 된다. 9개 자리마다 26개 선택이 반복되므로 26^9다.
Shift cipher, Vigenère cipher, frequency analysis
Vigenère가 shift보다 복잡하다고 해서 현대적인 안전성을 갖는 것은 아니다. 반복 키는 통계적 구조를 남긴다.
답안에 적용
식의 각 기호가 무엇을 뜻하는지 적은 뒤 계산합니다. key length 9라면 독립 선택이 9번입니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Modulo, 경우의 수, key space를 처음부터 계산하기 — 답안을 만드는 확인 순서
- mod n의 결과 범위가 0부터 n-1임을 확인한다.
- 각 자리가 독립적으로 선택되는지 확인한다.
- 선택지 수를 자리 수만큼 곱하고 거듭제곱으로 적는다.
- Modulo 산술과 block mode의 데이터 의존성은 별개의 문제임을 기억한다.
Shift cipher, Vigenère cipher, frequency analysis — 답안을 만드는 확인 순서
- 평문 문자를 숫자로 바꾼다.
- 키만큼 더하거나 빼고 alphabet 크기로 modulo한다.
- 암호문의 빈도를 세어 자연어 빈도와 비교한다.
- Vigenère에서는 반복되는 키 길이를 먼저 추정한 뒤 같은 키 위치끼리 나누어 분석한다.
숫자와 입력값을 넣어서 한 번 따라가기
알파벳을 A=0부터 Z=25로 놓고 plaintext T=19, key C=2를 계산합니다.
- Plaintext T를 숫자 19, key C를 숫자 2로 바꿉니다.
- Encryption은 `19 + 2 = 21`을 계산합니다.
- `21 mod 26 = 21`이므로 숫자 21에 해당하는 V가 ciphertext입니다.
- 예를 들어 Z=25에 C=2를 더하면 27이고 `27 mod 26 = 1`, 즉 B로 돌아갑니다.
이 예제의 결론 · Modulo는 값을 알파벳 범위로 되돌리고, key space는 각 자리 선택 수를 곱해 계산합니다.
06 IND-CPA·IND-CCA 공격자가 사용할 수 있는 oracle을 그리는 게임
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
공격자 모델과 oracle을 게임처럼 읽는 법
용어를 보기 전에 장면부터 잡아 봅시다. 시험장에서 계산기는 허용하지만 인터넷은 금지하는 것처럼, 공격자에게 허용되는 도구를 정확히 적어야 난이도와 성공 조건을 말할 수 있다.
이제 그 장면에 실제 이름을 붙이면 공격자 모델(Angreifermodell)은 공격자가 어떤 정보를 보고 어떤 기능을 사용할 수 있는지 정한 규칙이다. Oracle은 공격자가 질문을 보내면 정해진 계산 결과를 돌려주는 가상의 상자다. Encryption oracle은 공격자가 고른 평문을 암호화해 주고, decryption oracle은 고른 암호문을 복호화해 준다. 보안 정의는 강한 공격자에게 이런 기능을 허용해도 목표를 달성하지 못하는지 시험한다.
머릿속에서 순서대로 움직이면 공격자가 처음에 알고 있는 정보를 적는다. → 어떤 oracle에 언제 질의할 수 있는지 적는다. → Challenger가 숨긴 값을 포함한 challenge를 만든다. → 금지된 질의와 공격자의 최종 성공 조건을 적는다.
IND-CPA와 IND-CCA를 0부터 구분하기
용어를 보기 전에 장면부터 잡아 봅시다. 두 상자 중 하나를 잠가 보여 주고 어느 상자인지 맞히는 게임이다. CCA에서는 다른 잠긴 상자를 열어 달라고 물을 수 있지만 바로 시험에 나온 상자 c*를 열어 달라고 할 수는 없다.
이제 그 장면에 실제 이름을 붙이면 IND는 indistinguishability, 즉 두 메시지 중 어느 것이 암호화됐는지 구별하기 어렵다는 뜻이다. 공격자는 같은 길이의 메시지 m0와 m1을 제출하고 Challenger는 무작위 bit b를 골라 mb의 암호문 c*를 준다. 공격자가 b를 1/2보다 의미 있게 높은 확률로 맞히지 못하면 안전하다고 본다. CPA에서는 encryption oracle을, CCA에서는 decryption oracle까지 허용한다.
머릿속에서 순서대로 움직이면 m0와 m1의 길이를 같게 해 길이만으로 답을 맞히지 못하게 한다. → Challenger가 b를 무작위로 선택하고 c*=Enc(mb)를 만든다. → IND-CCA2에서는 challenge 이후에도 다른 암호문의 복호화를 질의할 수 있다. → c* 자체의 복호화는 금지하고 마지막에 b'를 추측한다.
Ciphertext-only와 Known-plaintext 공격
용어를 보기 전에 장면부터 잡아 봅시다. COA는 자물쇠로 잠긴 상자만 보는 상황, KPA는 몇 개 상자의 잠그기 전 내용과 잠근 뒤 모습을 함께 본 상황, CPA는 원하는 물건을 골라 상자에 넣어 잠근 결과를 요청할 수 있는 상황이다.
이제 그 장면에 실제 이름을 붙이면 Ciphertext-only attack(COA)은 공격자가 암호문만 가지고 평문이나 키에 대한 정보를 찾는 모델이다. Known-plaintext attack(KPA)은 일부 평문과 그에 대응하는 암호문 쌍을 이미 알고 있는 모델이다. 공격자가 원하는 평문을 직접 고를 수 있는 CPA는 KPA보다 더 큰 능력을 준다.
머릿속에서 순서대로 움직이면 공격자가 평문을 전혀 모르는지 일부 쌍을 아는지 구분한다. → 알려진 평문을 공격자가 선택했는지 우연히 관찰했는지 구분한다. → 더 많은 능력을 가진 모델을 견디면 보통 더 약한 모델도 견딘다는 방향을 확인한다.
TERMS FROM ZERO
IND-CPA·IND-CCA에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Attacker model
공격자가 무엇을 보고, 선택하고, 질문하고, 바꿀 수 있는지를 정확히 정한 가정입니다.
Oracle
보안 게임에서 공격자가 정해진 형식으로 질의하고 답을 받을 수 있는 가상 인터페이스입니다.
Challenge
공격자가 구별하거나 위조해야 하는 중심 시험값입니다.
Advantage
공격자의 성공 확률이 무작위 추측보다 얼마나 높은지를 나타내는 값입니다.
CPA
Chosen-Plaintext Attack입니다. 공격자가 고른 plaintext의 암호문을 받아볼 수 있습니다.
CCA
Chosen-Ciphertext Attack입니다. 제한 아래 공격자가 고른 ciphertext의 복호 결과까지 질의할 수 있습니다.
IND
Indistinguishability입니다. 두 후보 plaintext 중 어느 것이 암호화됐는지 구별하기 어려워야 한다는 목표입니다.
Challenge ciphertext
보안 게임에서 숨겨진 bit에 따라 두 후보 중 하나를 암호화한 시험 암호문입니다.
Ciphertext-only attack
공격자가 ciphertext들만 알고 분석하는 공격 상황입니다.
Known-plaintext attack
일부 plaintext와 그에 대응하는 ciphertext 쌍을 공격자가 알고 있는 상황입니다.
Chosen-plaintext attack
공격자가 plaintext를 직접 골라 그 암호문을 받을 수 있는 더 강한 상황입니다.
Known pair
서로 대응하는 plaintext와 ciphertext 한 쌍입니다.
처음부터 설명하면
IND 게임에서 공격자는 길이가 같은 m0, m1을 내고 둘 중 하나의 암호문 c*를 받습니다. IND-CPA는 encryption oracle을, IND-CCA는 여기에 decryption oracle도 허용합니다. 단, CCA에서도 challenge ciphertext c* 자체의 복호화 질문은 금지됩니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
공격자 모델과 oracle을 게임처럼 읽는 법
공격자 모델(Angreifermodell)은 공격자가 어떤 정보를 보고 어떤 기능을 사용할 수 있는지 정한 규칙이다. Oracle은 공격자가 질문을 보내면 정해진 계산 결과를 돌려주는 가상의 상자다. Encryption oracle은 공격자가 고른 평문을 암호화해 주고, decryption oracle은 고른 암호문을 복호화해 준다. 보안 정의는 강한 공격자에게 이런 기능을 허용해도 목표를 달성하지 못하는지 시험한다.
IND-CPA와 IND-CCA를 0부터 구분하기
IND는 indistinguishability, 즉 두 메시지 중 어느 것이 암호화됐는지 구별하기 어렵다는 뜻이다. 공격자는 같은 길이의 메시지 m0와 m1을 제출하고 Challenger는 무작위 bit b를 골라 mb의 암호문 c*를 준다. 공격자가 b를 1/2보다 의미 있게 높은 확률로 맞히지 못하면 안전하다고 본다. CPA에서는 encryption oracle을, CCA에서는 decryption oracle까지 허용한다.
Ciphertext-only와 Known-plaintext 공격
Ciphertext-only attack(COA)은 공격자가 암호문만 가지고 평문이나 키에 대한 정보를 찾는 모델이다. Known-plaintext attack(KPA)은 일부 평문과 그에 대응하는 암호문 쌍을 이미 알고 있는 모델이다. 공격자가 원하는 평문을 직접 고를 수 있는 CPA는 KPA보다 더 큰 능력을 준다.
쉬운 비유
출제자가 두 상자 중 하나를 잠가 주고 어느 상자인지 맞히게 합니다. CCA에서는 다른 상자는 열어 달라고 부탁할 수 있지만 시험 상자 자체를 열어 달라고 할 수는 없습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
공격자 모델과 oracle을 게임처럼 읽는 법
시험장에서 계산기는 허용하지만 인터넷은 금지하는 것처럼, 공격자에게 허용되는 도구를 정확히 적어야 난이도와 성공 조건을 말할 수 있다.
IND-CPA와 IND-CCA를 0부터 구분하기
두 상자 중 하나를 잠가 보여 주고 어느 상자인지 맞히는 게임이다. CCA에서는 다른 잠긴 상자를 열어 달라고 물을 수 있지만 바로 시험에 나온 상자 c*를 열어 달라고 할 수는 없다.
Ciphertext-only와 Known-plaintext 공격
COA는 자물쇠로 잠긴 상자만 보는 상황, KPA는 몇 개 상자의 잠그기 전 내용과 잠근 뒤 모습을 함께 본 상황, CPA는 원하는 물건을 골라 상자에 넣어 잠근 결과를 요청할 수 있는 상황이다.
시험 함정
CPA/CCA의 차이는 메시지 종류가 아니라 공격자가 질의할 수 있는 oracle과 capability입니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
공격자 모델과 oracle을 게임처럼 읽는 법
공격자가 ‘강하다’라고만 쓰면 정의가 되지 않는다. 질의 가능 대상, 시점, 금지 조건을 구체적으로 써야 한다.
IND-CPA와 IND-CCA를 0부터 구분하기
CPA와 CCA의 차이는 평문 종류가 아니라 공격자가 사용할 수 있는 oracle의 차이다.
Ciphertext-only와 Known-plaintext 공격
Known plaintext와 chosen plaintext를 같은 말로 쓰지 않는다. KPA에서는 공격자가 그 평문을 선택할 권한이 없을 수 있다.
답안에 적용
attacker capability → challenge → forbidden query → 성공 조건 순서로 네 칸을 채웁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
공격자 모델과 oracle을 게임처럼 읽는 법 — 답안을 만드는 확인 순서
- 공격자가 처음에 알고 있는 정보를 적는다.
- 어떤 oracle에 언제 질의할 수 있는지 적는다.
- Challenger가 숨긴 값을 포함한 challenge를 만든다.
- 금지된 질의와 공격자의 최종 성공 조건을 적는다.
IND-CPA와 IND-CCA를 0부터 구분하기 — 답안을 만드는 확인 순서
- m0와 m1의 길이를 같게 해 길이만으로 답을 맞히지 못하게 한다.
- Challenger가 b를 무작위로 선택하고 c*=Enc(mb)를 만든다.
- IND-CCA2에서는 challenge 이후에도 다른 암호문의 복호화를 질의할 수 있다.
- c* 자체의 복호화는 금지하고 마지막에 b'를 추측한다.
Ciphertext-only와 Known-plaintext 공격 — 답안을 만드는 확인 순서
- 공격자가 평문을 전혀 모르는지 일부 쌍을 아는지 구분한다.
- 알려진 평문을 공격자가 선택했는지 우연히 관찰했는지 구분한다.
- 더 많은 능력을 가진 모델을 견디면 보통 더 약한 모델도 견딘다는 방향을 확인한다.
숫자와 입력값을 넣어서 한 번 따라가기
공격자 Eve가 같은 길이의 `YES`와 `NO!`를 내고 challenger가 둘 중 하나를 암호화합니다.
- Challenger가 secret key를 만들지만 Eve에게는 주지 않습니다.
- Eve는 길이가 같은 `m0=YES`, `m1=NO!`를 제출합니다. 길이가 다르면 ciphertext length가 답을 누설할 수 있습니다.
- Challenger는 비밀 bit b를 고르고 `c*=Enc(k, mb)`를 돌려줍니다.
- IND-CPA에서 Eve는 다른 plaintext의 encryption을 질의할 수 있고, IND-CCA에서는 다른 ciphertext의 decryption도 질의할 수 있습니다.
이 예제의 결론 · CPA와 CCA의 차이는 공격자에게 허용된 oracle이며, 보안 목표는 plaintext 자체 복원뿐 아니라 두 후보의 구별도 어렵게 하는 것입니다.
07 Public key·RSA·ElGamal·Signature 암호화와 서명은 키 방향과 목표가 다릅니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
공개키 암호와 RSA·ElGamal의 수학적 기반
용어를 보기 전에 장면부터 잡아 봅시다. 두 색의 물감을 섞기는 쉽지만 섞인 색에서 원래 정확한 두 물감을 분리하기는 어려운 것처럼, 한 방향 계산은 쉽고 역방향은 어렵게 만든다.
이제 그 장면에 실제 이름을 붙이면 공개키 암호는 누구나 알 수 있는 public key와 소유자만 보관하는 private key를 사용한다. RSA에서는 두 큰 소수를 곱해 n을 만드는 것은 쉽지만 n만 보고 원래 소수들을 찾는 factorization이 어렵다는 점을 이용한다. ElGamal은 g^x mod p를 계산하기는 쉽지만 결과와 g, p만 보고 x를 찾는 discrete logarithm problem이 어렵다는 점을 이용한다.
머릿속에서 순서대로 움직이면 Public key는 공개되어도 되고 private key는 비밀이어야 한다. → RSA의 대표 난제는 integer factorization이다. → ElGamal의 기반은 discrete logarithm과 관련 가정이다. → 구체적인 parameter 크기와 padding까지 올바르게 써야 실제 시스템이 안전하다.
RSA 계산에 필요한 소수·φ·서로소·역원
용어를 보기 전에 장면부터 잡아 봅시다. e로 자물쇠를 한 방향으로 돌린 뒤 d로 돌렸을 때 바퀴가 정확히 한 바퀴를 돌아 원위치에 오는 조합을 찾는다고 생각할 수 있다.
이제 그 장면에 실제 이름을 붙이면 소수(prime)는 1과 자기 자신으로만 나누어지는 2 이상의 정수다. RSA는 보통 서로 다른 소수 p와 q를 골라 n=pq를 만든다. Euler의 φ(n)는 1부터 n까지 중 n과 서로소인 수의 개수다. p와 q가 서로 다른 소수라면 φ(n)=(p-1)(q-1)이다. 공개 지수 e는 φ(n)과 최대공약수가 1이어야 하고, 개인 지수 d는 ed≡1 mod φ(n)을 만족하는 modular inverse다.
머릿속에서 순서대로 움직이면 n=pq를 계산하고 p와 q가 유효한 소수인지 확인한다. → p≠q이면 φ(n)=(p-1)(q-1)을 사용한다. p=q인 특수 입력은 φ(p²)=p²-p다. → gcd(e,φ(n))=1인 e를 고른다. → ed mod φ(n)=1이 되는 d를 찾는다. → 암호화 c=m^e mod n, 복호화 m=c^d mod n을 목적에 맞게 적용한다.
Digital signature는 무엇을 증명하는가
용어를 보기 전에 장면부터 잡아 봅시다. 편지 내용을 가리는 봉투가 encryption이라면 signature는 편지 내용에 연결된 위조하기 어려운 도장이다. 누구나 도장을 검사할 수 있지만 소유자만 새 도장을 만들 수 있어야 한다.
이제 그 장면에 실제 이름을 붙이면 Digital signature는 메시지를 숨기는 기술이 아니라 메시지가 private key 소유자에게서 왔고 중간에 바뀌지 않았음을 검증하는 기술이다. 보통 긴 메시지 자체가 아니라 메시지의 hash에 서명한다. RSA의 단순 교재식 표현에서는 서명 s=h^d mod n을 만들고 검증자는 s^e mod n이 h와 같은지 확인한다.
머릿속에서 순서대로 움직이면 메시지를 hash해 고정 길이 digest h를 만든다. → 서명자는 private key로 h에 대한 signature를 만든다. → 검증자는 public key와 원래 메시지로 signature를 확인한다. → Selective forgery에서는 공격 전에 정한 특정 새 메시지에 대한 유효 서명을 만드는 것이 목표다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
용어를 보기 전에 장면부터 잡아 봅시다. 처음 만날 때 신분증과 봉인된 절차로 둘만의 회의실 열쇠를 안전하게 정한 다음, 긴 회의 동안에는 그 열쇠로 빠르게 문을 여닫는 것과 같다.
이제 그 장면에 실제 이름을 붙이면 TLS는 HTTPS 연결에서 통신 상대를 확인하고 전송 내용을 보호하는 프로토콜이다. 공개키 암호(asymmetric cryptography)는 공개키와 개인키가 달라 키 교환과 서명에 편리하지만 큰 데이터를 처리하기에는 상대적으로 느리다. 대칭키 암호(symmetric cryptography)는 양쪽이 같은 비밀키를 사용하며 빠르다. 그래서 실제 TLS는 인증과 세션키 합의에 공개키 기술을 사용하고, 이후 데이터에는 빠른 대칭키 암호를 사용하는 hybrid 방식이다.
머릿속에서 순서대로 움직이면 Browser가 server의 certificate와 domain name을 검증한다. → Handshake에서 양쪽이 session key를 합의한다. → Application data는 합의된 대칭키로 빠르게 보호한다. → 암호화가 계산 시간을 없애거나 거래 내용을 절대적으로 안전하게 만들지는 않는다.
TERMS FROM ZERO
Public key·RSA·ElGamal·Signature에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Public key
누구나 알아도 되는 key로, 보통 encryption 또는 signature verification에 사용됩니다.
Private key
소유자만 비밀로 가져야 하는 key로, decryption 또는 signing에 사용됩니다.
Hard problem
정상 사용자는 비밀정보로 쉽게 계산하지만 공격자는 현실적 시간에 풀기 어렵다고 가정하는 수학 문제입니다.
Trapdoor
특별한 비밀정보를 알면 어려운 계산을 쉽게 뒤집을 수 있게 하는 정보입니다.
Prime number
1과 자기 자신으로만 나누어지는 1보다 큰 정수입니다.
Euler φ function
n 이하에서 n과 서로소인 수의 개수를 나타내며 RSA key 계산에 사용됩니다.
Coprime
두 수의 최대공약수가 1인 관계입니다.
Modular inverse
`a·b ≡ 1 (mod n)`을 만족하는 b로, modulo 세계에서 나눗셈 역할을 합니다.
Digital signature
private key 소유자가 특정 메시지에 서명했음을 검증하게 하는 값입니다.
Signing
메시지와 private key로 signature를 만드는 과정입니다.
Verification
메시지, signature, public key로 서명의 유효성을 검사하는 과정입니다.
Authenticity / Integrity
서명은 서명자와 메시지의 진위를 확인하지만 메시지 내용을 숨기는 confidentiality 기능은 아닙니다.
TLS
Browser와 server 사이 통신의 기밀성·무결성 및 server 인증을 제공하는 protocol입니다.
Hybrid encryption
공개키 기법으로 key를 합의하거나 보호하고, 실제 대량 데이터는 빠른 대칭키 암호로 처리하는 조합입니다.
Session key
한 연결이나 제한된 기간 동안 실제 application data 암호화에 사용하는 대칭 key입니다.
Handshake
암호 suite와 key material을 정하고 상대를 인증하는 TLS 연결 초기 단계입니다.
처음부터 설명하면
Public-key cryptography는 공개키와 개인키를 나눕니다. RSA의 핵심 난제는 큰 수의 factorization, ElGamal은 discrete logarithm 계열 문제입니다. RSA 암호화는 c=m^e mod n, 서명은 s=h^d mod n이며 서명의 목표는 secrecy가 아니라 authenticity와 integrity입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
공개키 암호와 RSA·ElGamal의 수학적 기반
공개키 암호는 누구나 알 수 있는 public key와 소유자만 보관하는 private key를 사용한다. RSA에서는 두 큰 소수를 곱해 n을 만드는 것은 쉽지만 n만 보고 원래 소수들을 찾는 factorization이 어렵다는 점을 이용한다. ElGamal은 g^x mod p를 계산하기는 쉽지만 결과와 g, p만 보고 x를 찾는 discrete logarithm problem이 어렵다는 점을 이용한다.
RSA 계산에 필요한 소수·φ·서로소·역원
소수(prime)는 1과 자기 자신으로만 나누어지는 2 이상의 정수다. RSA는 보통 서로 다른 소수 p와 q를 골라 n=pq를 만든다. Euler의 φ(n)는 1부터 n까지 중 n과 서로소인 수의 개수다. p와 q가 서로 다른 소수라면 φ(n)=(p-1)(q-1)이다. 공개 지수 e는 φ(n)과 최대공약수가 1이어야 하고, 개인 지수 d는 ed≡1 mod φ(n)을 만족하는 modular inverse다.
Digital signature는 무엇을 증명하는가
Digital signature는 메시지를 숨기는 기술이 아니라 메시지가 private key 소유자에게서 왔고 중간에 바뀌지 않았음을 검증하는 기술이다. 보통 긴 메시지 자체가 아니라 메시지의 hash에 서명한다. RSA의 단순 교재식 표현에서는 서명 s=h^d mod n을 만들고 검증자는 s^e mod n이 h와 같은지 확인한다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
TLS는 HTTPS 연결에서 통신 상대를 확인하고 전송 내용을 보호하는 프로토콜이다. 공개키 암호(asymmetric cryptography)는 공개키와 개인키가 달라 키 교환과 서명에 편리하지만 큰 데이터를 처리하기에는 상대적으로 느리다. 대칭키 암호(symmetric cryptography)는 양쪽이 같은 비밀키를 사용하며 빠르다. 그래서 실제 TLS는 인증과 세션키 합의에 공개키 기술을 사용하고, 이후 데이터에는 빠른 대칭키 암호를 사용하는 hybrid 방식이다.
쉬운 비유
공개키는 누구나 넣을 수 있는 우편함 투입구, 개인키는 소유자만 여는 열쇠입니다. 서명은 소유자만 찍을 수 있고 누구나 확인할 수 있는 도장에 가깝습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
공개키 암호와 RSA·ElGamal의 수학적 기반
두 색의 물감을 섞기는 쉽지만 섞인 색에서 원래 정확한 두 물감을 분리하기는 어려운 것처럼, 한 방향 계산은 쉽고 역방향은 어렵게 만든다.
RSA 계산에 필요한 소수·φ·서로소·역원
e로 자물쇠를 한 방향으로 돌린 뒤 d로 돌렸을 때 바퀴가 정확히 한 바퀴를 돌아 원위치에 오는 조합을 찾는다고 생각할 수 있다.
Digital signature는 무엇을 증명하는가
편지 내용을 가리는 봉투가 encryption이라면 signature는 편지 내용에 연결된 위조하기 어려운 도장이다. 누구나 도장을 검사할 수 있지만 소유자만 새 도장을 만들 수 있어야 한다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
처음 만날 때 신분증과 봉인된 절차로 둘만의 회의실 열쇠를 안전하게 정한 다음, 긴 회의 동안에는 그 열쇠로 빠르게 문을 여닫는 것과 같다.
시험 함정
encryption exponent e와 signing exponent d를 뒤섞지 말고, selective forgery에서는 미리 정한 새 target message의 valid signature를 만들어야 합니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
공개키 암호와 RSA·ElGamal의 수학적 기반
‘어려운 수학 문제 기반’이라는 말이 모든 작은 숫자 예제나 잘못 구성한 키까지 안전하게 만들지는 않는다.
RSA 계산에 필요한 소수·φ·서로소·역원
p=q인데 서로 다른 소수 공식 (p-1)(q-1)을 그대로 쓰거나, e와 d가 역원인지 확인하지 않고 숫자를 고르면 안 된다.
Digital signature는 무엇을 증명하는가
서명은 confidentiality를 제공하지 않는다. 또한 교재의 raw RSA 계산은 개념 연습이며 실제로는 안전한 signature encoding이 필요하다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
HTTPS가 오직 asymmetric cryptography만 사용한다거나, certificate가 있는 사이트는 정직한 상점이라고 단정하면 안 된다.
답안에 적용
RSA는 n과 φ(n), gcd(e,φ(n))=1, ed≡1 mod φ(n)을 확인한 뒤 목적에 맞는 exponent를 선택합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
공개키 암호와 RSA·ElGamal의 수학적 기반 — 답안을 만드는 확인 순서
- Public key는 공개되어도 되고 private key는 비밀이어야 한다.
- RSA의 대표 난제는 integer factorization이다.
- ElGamal의 기반은 discrete logarithm과 관련 가정이다.
- 구체적인 parameter 크기와 padding까지 올바르게 써야 실제 시스템이 안전하다.
RSA 계산에 필요한 소수·φ·서로소·역원 — 답안을 만드는 확인 순서
- n=pq를 계산하고 p와 q가 유효한 소수인지 확인한다.
- p≠q이면 φ(n)=(p-1)(q-1)을 사용한다. p=q인 특수 입력은 φ(p²)=p²-p다.
- gcd(e,φ(n))=1인 e를 고른다.
- ed mod φ(n)=1이 되는 d를 찾는다.
- 암호화 c=m^e mod n, 복호화 m=c^d mod n을 목적에 맞게 적용한다.
Digital signature는 무엇을 증명하는가 — 답안을 만드는 확인 순서
- 메시지를 hash해 고정 길이 digest h를 만든다.
- 서명자는 private key로 h에 대한 signature를 만든다.
- 검증자는 public key와 원래 메시지로 signature를 확인한다.
- Selective forgery에서는 공격 전에 정한 특정 새 메시지에 대한 유효 서명을 만드는 것이 목표다.
TLS가 대칭키와 공개키를 함께 사용하는 이유 — 답안을 만드는 확인 순서
- Browser가 server의 certificate와 domain name을 검증한다.
- Handshake에서 양쪽이 session key를 합의한다.
- Application data는 합의된 대칭키로 빠르게 보호한다.
- 암호화가 계산 시간을 없애거나 거래 내용을 절대적으로 안전하게 만들지는 않는다.
숫자와 입력값을 넣어서 한 번 따라가기
메시지 `PAY 10`을 Bob에게 비밀로 보내는 경우와 Alice가 작성자임을 공개적으로 증명하는 경우를 비교합니다.
- 기밀성에서는 Alice가 Bob의 public key로 `PAY 10`을 암호화합니다.
- Ciphertext는 Bob의 private key를 가진 Bob만 복호화할 수 있어야 합니다.
- 서명에서는 Alice가 자신의 private key로 message 또는 그 hash에 signature를 만듭니다.
- Bob을 포함한 누구나 Alice의 public key로 signature를 검증할 수 있습니다.
이 예제의 결론 · Encryption은 수신자의 key pair로 confidentiality를, signature는 서명자의 key pair로 authenticity와 integrity를 목표로 합니다.
이 챕터 문제를 푸는 고정 순서
- 1
문장이 요구하는 보안 목표(confidentiality, integrity, authenticity)를 먼저 표시합니다.
- 2
‘항상, 절대, only, garantiert’ 같은 강한 표현에 반례가 있는지 찾습니다.
- 3
공격자 모델 문제는 공격자가 볼 수 있는 것·질의할 수 있는 것·금지된 것을 씁니다.
- 4
계산 문제는 공식, 값 대입, modulo 중간값, 최종 결과 순서로 남깁니다.
출제·강의 근거 · Gedächtnisprotokoll Krypto 48p, Multiple Choice·Angreifermodelle·Asymmetrische Kryptographie 및 Moodle exam 암호 파트
01
블록 암호(Blockchiffren)에서는 모든 블록 길이를 같게 만들기 위해 padding function을 반드시 써야 한다. Wahr/Falsch?
Bei Blockchiffren muss man eine Auffüllungsfunktion (padding function) benutzen, um alle Blöcke auf die gleiche Länge zu bringen.
문제 풀기02
One-Time Pad(OTP)는 brute force로 완전히 깨질 수 있다. Wahr/Falsch?
Ein One-Time-Pad kann vollständig durch Bruteforcing gebrochen werden.
문제 풀기03
Hashingalgorithmus의 Hashwert 길이는 입력 텍스트 길이에 따라 달라진다. Wahr/Falsch?
Hashwerte eines Hashingalgorithmus haben verschiedene Längen abhängig von der Länge des Eingabetexts.
문제 풀기04
Kryptographie에서 Modulo-Operation 때문에 ciphertext의 어느 위치, 즉 앞이나 뒤에서 복호화를 시작해도 상관없다. Wahr/Falsch?
Speziell in der Kryptographie sorgt die Modulo-Operation dafür, dass es egal ist von welcher Position man die Entschlüsselung beginnt (am Anfang oder Ende des Ciphertexts).
문제 풀기05
Vigenère 암호에서 알파벳이 26글자이고 키 길이가 9이면 키의 경우의 수가 정확히 26²×9개라는 주장이다. Wahr/Falsch?
Vigenere-Chiffre: Wenn das Alphabet 26 Buchstaben hat, hat ein Schlüssel der Länge 9 genau 26^2 · 9 Möglichkeiten.
문제 풀기06
Shift-Chiffre는 Häufigkeitsanalyse로 성공적으로 공격할 수 없다. Wahr/Falsch?
Ein Shift-Chiffre kann nicht erfolgreich mit Häufigkeitsanalyse angegriffen werden.
문제 풀기07
MD5-Hashing-Algorithmus는 Kollisionen을 절대 만들지 않는다고 보장한다. Wahr/Falsch?
Der MD5-Hashing-Algorithmus produziert garantiert keine Kollisionen.
문제 풀기08
TLS(HTTPS)는 E-Commerce transactions를 빠르고 절대 안전하게 유지하기 위해 assymetrische Kryptographie만 사용한다. Wahr/Falsch?
TLS (HTTPS) benutzt nur assymetrische Kryptographie, damit E-Commerce Transaktionen schnell und absolut sicher bleiben.
문제 풀기09
IND-CCA(Chosen Ciphertext Attack) Angreifermodell을 설명하라.
Beschreiben Sie das Angreifermodell IND-CCA (Chosen Ciphertext Attack).
문제 풀기10
IND-CCA(Chosen Ciphertext Attack)와 IND-CPA(Chosen Plaintext Attack)의 차이를 설명하라.
Was unterscheidet den IND-CCA (Chosen Ciphertext Attack) vom IND-CPA (Chosen Plaintext Attack)?
문제 풀기11
IND-CCA와 IND-CPA 이외의 Angreifermodelle 두 가지를 들고 짧게 설명하라.
Welche zwei anderen Angreifermodelle als IND-CCA und IND-CPA kennen Sie? Beschreiben Sie diese kurz.
문제 풀기12
RSA의 보안은 어떤 수학적 Grundlage에 기반하는가? ElGamal의 보안은 어떤 수학적 Grundlage에 기반하는가?
Auf welcher mathematischen Grundlage beruht die Sicherheit von RSA? Auf welcher mathematischen Grundlage beruht die Sicherheit von ElGamal?
문제 풀기13
digital signatures 문맥에서 Selective-Forgery-Under-Chosen-Message-Angriff를 설명하라.
Beschreiben Sie einen Selective-Forgery-Under-Chosen-Message-Angriff im Kontext von digitalen Signaturen.
문제 풀기14
p = 7, q = 7인 RSA에서 gültiges Schlüsselpaar ((e,n),(d,n))를 구하라. 풀이 과정 없이 n, φ(n), e, d만 쓰며 e=1,d=1은 제외한다.
Bestimmen Sie ein gültiges Schlüsselpaar ((e, n), (d, n)) für das RSA Kryptosystem mit den Parametern p = 7 und q = 7. Sie müssen keinen Rechenweg angeben sondern nur Ihre Ergebnisse für n, φ(n), e und d. Die Werte e = 1, d = 1 sind hierbei ausgeschlossen.
문제 풀기15
öffentlicher Schlüssel (3,55)를 사용해 RSA로 Nachricht m=4를 verschlüsseln하고 Rechenweg를 쓰라.
Verschlüsseln Sie die Nachricht m = 4 mit dem RSA Kryptosystem. Verwenden Sie dazu den öffentlichen Schlüssel (3, 55). Geben Sie Ihren Rechenweg mit an.
문제 풀기16
RSA-Schlüsselpaar ((e,n),(d,n))=((11,15),(3,15))로 Hash h=3에 signieren하고 Rechenweg를 쓰라.
Signieren Sie den Hash h = 3 mit dem RSA-Kryptosystem. Verwenden Sie dazu das Schlüsselpaar ((e, n), (d,n)) = ((11,15), (3, 15)). Geben Sie Ihren Rechenweg mit an.
문제 풀기Chapter 2
Networking
Multiple Choice · DNS · BGP · DHCP · OSI · Domain Validation
완전 초보자를 위한 1타 강사식 입문 강의
네트워크 문제는 ‘누가 누구에게 무엇을 보내는가’를 그리면 풀립니다
개념이 하나도 없다면 여기서 시작
네트워크는 여러 컴퓨터와 중간 장치가 메시지(packet)를 주고받는 과정입니다. 보안 문제는 이름을 외우는 것보다 sender, receiver, message, attacker position, defense를 정확히 놓는 것이 중요합니다. 모든 시나리오를 화살표로 그린 뒤 어떤 보호 기술이 어느 구간을 지키는지 표시하세요.
01 Packet·주소·계층 한 통신에도 여러 주소와 역할이 겹칩니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
네트워크에서 누가 누구에게 무엇을 보내는가
용어를 보기 전에 장면부터 잡아 봅시다. IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
이제 그 장면에 실제 이름을 붙이면 네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
머릿속에서 순서대로 움직이면 송신자와 수신자를 먼저 적는다. → 출발지·목적지 IP와 port를 구분한다. → 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다. → 응답이 어느 방향으로 돌아오는지 그린다.
OSI 7계층을 역할로 이해하기
용어를 보기 전에 장면부터 잡아 봅시다. 택배에서 도로와 차량, 동네 배송, 건물 주소, 호수별 전달, 포장 형식, 최종 물건 사용을 서로 다른 담당 층으로 나눈 것과 같다.
이제 그 장면에 실제 이름을 붙이면 OSI model은 네트워크 통신 기능을 일곱 층으로 나눈 개념 모델이다. 아래 계층은 신호와 가까우며 위 계층은 사용자의 응용프로그램과 가깝다. 아래부터 Physical, Data Link, Network, Transport, Session, Presentation, Application 순서다. 실제 Internet protocol stack과 정확히 일대일 대응하지는 않지만 문제를 어느 범위에서 분석할지 돕는다.
머릿속에서 순서대로 움직이면 1 Physical: bit를 전기·빛·무선 신호로 전송. → 2 Data Link: 같은 링크의 frame과 MAC 주소. → 3 Network: IP 주소와 routing. → 4 Transport: TCP/UDP와 end-to-end 전달. → 5~7 Session, Presentation, Application: 대화 관리, 표현·암호화 형식, 사용자 protocol.
TERMS FROM ZERO
Packet·주소·계층에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Packet
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP address
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
Port
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
Protocol
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
OSI model
network 기능을 역할별 7개 계층으로 나눈 개념 모델입니다.
Encapsulation
상위 계층 data에 각 계층 header를 붙여 아래 계층으로 내려보내는 과정입니다.
Transport layer
End-to-end 전달과 port, 신뢰성 등을 담당하는 계층으로 TCP와 UDP가 대표적입니다.
Network layer
IP 주소와 routing으로 서로 다른 network 사이 packet 전달을 담당합니다.
처음부터 설명하면
Application data는 아래 계층을 내려가며 TCP/UDP port, IP address, link-layer address 같은 정보를 덧붙입니다. OSI 7계층은 Application, Presentation, Session, Transport, Network, Data Link, Physical 순서입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
네트워크에서 누가 누구에게 무엇을 보내는가
네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
OSI 7계층을 역할로 이해하기
OSI model은 네트워크 통신 기능을 일곱 층으로 나눈 개념 모델이다. 아래 계층은 신호와 가까우며 위 계층은 사용자의 응용프로그램과 가깝다. 아래부터 Physical, Data Link, Network, Transport, Session, Presentation, Application 순서다. 실제 Internet protocol stack과 정확히 일대일 대응하지는 않지만 문제를 어느 범위에서 분석할지 돕는다.
쉬운 비유
택배 내용물, 아파트 주소, 배송 차량의 경로가 서로 다른 정보인 것처럼 domain, IP, MAC, port도 다른 층의 정보입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
네트워크에서 누가 누구에게 무엇을 보내는가
IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
OSI 7계층을 역할로 이해하기
택배에서 도로와 차량, 동네 배송, 건물 주소, 호수별 전달, 포장 형식, 최종 물건 사용을 서로 다른 담당 층으로 나눈 것과 같다.
시험 함정
DNS 이름을 IP나 MAC과 같은 것으로 취급하거나 OSI 7계층과 TCP/IP 4계층을 섞지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
네트워크에서 누가 누구에게 무엇을 보내는가
하나의 port 번호가 그 port를 이용하는 데이터의 의미까지 보장하지는 않는다.
OSI 7계층을 역할로 이해하기
암기 순서만 쓰지 말고 각 계층의 대표 역할과 예시를 하나씩 연결하면 빈칸 위치를 복원하기 쉽다.
답안에 적용
먼저 현재 문제의 계층과 식별자(domain/IP/MAC/port)를 적고 sender→receiver 화살표를 그립니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
네트워크에서 누가 누구에게 무엇을 보내는가 — 답안을 만드는 확인 순서
- 송신자와 수신자를 먼저 적는다.
- 출발지·목적지 IP와 port를 구분한다.
- 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다.
- 응답이 어느 방향으로 돌아오는지 그린다.
OSI 7계층을 역할로 이해하기 — 답안을 만드는 확인 순서
- 1 Physical: bit를 전기·빛·무선 신호로 전송.
- 2 Data Link: 같은 링크의 frame과 MAC 주소.
- 3 Network: IP 주소와 routing.
- 4 Transport: TCP/UDP와 end-to-end 전달.
- 5~7 Session, Presentation, Application: 대화 관리, 표현·암호화 형식, 사용자 protocol.
숫자와 입력값을 넣어서 한 번 따라가기
노트북이 Wi-Fi router를 거쳐 IP `203.0.113.10`의 HTTPS server에 연결합니다.
- Browser는 사람이 입력한 domain `example.com`과 HTTPS라는 application 목적을 압니다.
- DNS가 domain을 server IP `203.0.113.10`으로 바꿉니다.
- TCP destination port 443은 server host 안의 HTTPS service를 선택합니다.
- IP header는 여러 router를 지나도 최종 destination IP를 나타냅니다.
이 예제의 결론 · Domain은 이름, IP는 network 목적지, port는 host 안의 service, MAC은 현재 link의 다음 전달 대상을 구분합니다.
02 DNS resolution·Cache·Records 주소록 한 권이 아니라 위임된 계층 구조입니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Root부터 authoritative server까지 이름을 찾는 순서
용어를 보기 전에 장면부터 잡아 봅시다. 국가 안내소가 독일 지역 안내소를 알려 주고, 지역 안내소가 대학 담당 사무실을 알려 주며, 담당 사무실이 최종 방 번호를 알려 주는 과정이다.
이제 그 장면에 실제 이름을 붙이면 DNS 이름은 오른쪽에서 왼쪽으로 계층을 이룬다. tu-darmstadt.de에서 de는 top-level domain(TLD), tu-darmstadt는 그 아래 domain이다. Root nameserver는 최종 IP를 보통 직접 주지 않고 .de TLD nameserver를 알려 준다. TLD server는 tu-darmstadt.de의 authoritative nameserver를 알려 주고, authoritative server가 최종 A, AAAA, MX 같은 record를 답한다.
머릿속에서 순서대로 움직이면 Resolver cache에 최종 답이나 delegation이 있는지 먼저 본다. → 없으면 root에 질의해 TLD nameserver referral을 받는다. → TLD에 질의해 domain authoritative nameserver referral을 받는다. → Authoritative server에 최종 record를 질의한다. → 각 답과 delegation을 TTL 동안 cache한다.
DNS와 resolver, cache를 처음부터 이해하기
용어를 보기 전에 장면부터 잡아 봅시다. DNS는 이름으로 전화번호를 찾는 분산 전화번호부다. Resolver는 여러 전화번호부 기관에 대신 문의하는 안내원이고 cache는 최근 찾아본 번호를 메모해 두는 수첩이다.
이제 그 장면에 실제 이름을 붙이면 사람은 tu-darmstadt.de 같은 domain name을 사용하지만 packet은 IP address로 전달된다. DNS는 이름을 IP와 다른 정보로 바꾸는 분산 데이터베이스다. 사용자의 질문을 대신 처리하는 프로그램이 recursive resolver이고, authoritative nameserver는 특정 zone의 공식 record를 가진다. Resolver는 받은 답을 TTL 동안 cache해 같은 질문을 빠르게 답한다.
머릿속에서 순서대로 움직이면 사용자 stub resolver가 recursive resolver에 이름을 묻는다. → Cache에 유효한 답이 있으면 즉시 사용한다. → 없으면 root, TLD, authoritative nameserver 방향으로 위임을 따라간다. → 받은 record를 TTL 동안 저장한다.
DNS Resource Record 한 줄 읽는 법
용어를 보기 전에 장면부터 잡아 봅시다. 주소록 한 줄에 이름, 메모 유효 기간, 정보 분류, 전화·메일 같은 종류, 실제 값이 차례로 적혀 있다고 생각하면 된다.
이제 그 장면에 실제 이름을 붙이면 DNS의 정보 한 줄을 Resource Record(RR)라고 한다. 일반 형식은 NAME TTL CLASS TYPE RDATA다. NAME은 어느 이름의 정보인지, TTL은 몇 초 동안 cache할 수 있는지, CLASS의 IN은 Internet, TYPE은 정보 종류, RDATA는 실제 값이다. MX record는 해당 domain의 메일을 받을 mail server와 우선순위 값을 나타낸다.
머릿속에서 순서대로 움직이면 NAME에서 record가 속한 domain을 읽는다. → TTL을 초 단위 cache 가능 시간으로 읽는다. → TYPE이 A, AAAA, NS, MX, TXT 중 무엇인지 확인한다. → MX RDATA의 작은 preference 값이 더 우선임을 확인한다. → 끝의 점이 붙은 이름은 root까지 적은 FQDN임을 이해한다.
TERMS FROM ZERO
DNS resolution·Cache·Records에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Root server
최상위에서 `.de`, `.com` 같은 TLD의 nameserver 방향을 알려주는 DNS server입니다.
TLD server
특정 top-level domain 아래의 authoritative server 방향을 알려줍니다.
Authoritative server
해당 zone의 실제 DNS record에 권한 있는 최종 답변자입니다.
Referral
최종 IP 대신 다음에 물어볼 nameserver 정보를 주는 응답입니다.
DNS
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
Recursive resolver
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
Cache
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
TTL
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
Resource Record
DNS에서 이름, type, 값, TTL 등을 담는 한 줄의 정보 단위입니다.
A / AAAA
Domain 이름을 각각 IPv4 또는 IPv6 주소에 연결하는 record type입니다.
MX
Domain의 mail을 받을 mail server와 우선순위를 지정하는 record입니다.
NS
해당 DNS zone의 authoritative nameserver를 나타내는 record입니다.
처음부터 설명하면
Client는 recursive resolver에 묻고, resolver는 필요하면 root → TLD(.de) → authoritative server 순서로 찾아갑니다. 받은 위임과 답은 TTL 동안 cache할 수 있습니다. A/AAAA는 주소, MX는 메일 서버, NS는 nameserver 정보를 나타냅니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Root부터 authoritative server까지 이름을 찾는 순서
DNS 이름은 오른쪽에서 왼쪽으로 계층을 이룬다. tu-darmstadt.de에서 de는 top-level domain(TLD), tu-darmstadt는 그 아래 domain이다. Root nameserver는 최종 IP를 보통 직접 주지 않고 .de TLD nameserver를 알려 준다. TLD server는 tu-darmstadt.de의 authoritative nameserver를 알려 주고, authoritative server가 최종 A, AAAA, MX 같은 record를 답한다.
DNS와 resolver, cache를 처음부터 이해하기
사람은 tu-darmstadt.de 같은 domain name을 사용하지만 packet은 IP address로 전달된다. DNS는 이름을 IP와 다른 정보로 바꾸는 분산 데이터베이스다. 사용자의 질문을 대신 처리하는 프로그램이 recursive resolver이고, authoritative nameserver는 특정 zone의 공식 record를 가진다. Resolver는 받은 답을 TTL 동안 cache해 같은 질문을 빠르게 답한다.
DNS Resource Record 한 줄 읽는 법
DNS의 정보 한 줄을 Resource Record(RR)라고 한다. 일반 형식은 NAME TTL CLASS TYPE RDATA다. NAME은 어느 이름의 정보인지, TTL은 몇 초 동안 cache할 수 있는지, CLASS의 IN은 Internet, TYPE은 정보 종류, RDATA는 실제 값이다. MX record는 해당 domain의 메일을 받을 mail server와 우선순위 값을 나타낸다.
쉬운 비유
학교 대표번호(root)가 학과 사무실(TLD)을 알려 주고, 학과가 담당 연구실(authoritative)을 알려 주는 방식입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Root부터 authoritative server까지 이름을 찾는 순서
국가 안내소가 독일 지역 안내소를 알려 주고, 지역 안내소가 대학 담당 사무실을 알려 주며, 담당 사무실이 최종 방 번호를 알려 주는 과정이다.
DNS와 resolver, cache를 처음부터 이해하기
DNS는 이름으로 전화번호를 찾는 분산 전화번호부다. Resolver는 여러 전화번호부 기관에 대신 문의하는 안내원이고 cache는 최근 찾아본 번호를 메모해 두는 수첩이다.
DNS Resource Record 한 줄 읽는 법
주소록 한 줄에 이름, 메모 유효 기간, 정보 분류, 전화·메일 같은 종류, 실제 값이 차례로 적혀 있다고 생각하면 된다.
시험 함정
root가 최종 IP를 모두 저장한다고 쓰거나, cache가 있는데 매번 root부터 시작한다고 쓰지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Root부터 authoritative server까지 이름을 찾는 순서
모든 질의마다 반드시 root부터 시작하는 것은 아니다. 유효한 cache가 있으면 가장 구체적으로 알려진 지점부터 재개한다.
DNS와 resolver, cache를 처음부터 이해하기
Resolver와 authoritative nameserver를 같은 서버 역할로 쓰지 말고, cache에 오래된 거짓 답이 들어가는 cache poisoning과 전송 암호화를 구분한다.
DNS Resource Record 한 줄 읽는 법
MX의 숫자를 port나 TTL로 읽지 말고, 여러 MX가 있으면 preference 순서와 장애 대체 관계를 설명한다.
답안에 적용
Client→Resolver와 Resolver→Root/TLD/Authoritative를 구분하고 각 응답이 referral인지 final answer인지 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Root부터 authoritative server까지 이름을 찾는 순서 — 답안을 만드는 확인 순서
- Resolver cache에 최종 답이나 delegation이 있는지 먼저 본다.
- 없으면 root에 질의해 TLD nameserver referral을 받는다.
- TLD에 질의해 domain authoritative nameserver referral을 받는다.
- Authoritative server에 최종 record를 질의한다.
- 각 답과 delegation을 TTL 동안 cache한다.
DNS와 resolver, cache를 처음부터 이해하기 — 답안을 만드는 확인 순서
- 사용자 stub resolver가 recursive resolver에 이름을 묻는다.
- Cache에 유효한 답이 있으면 즉시 사용한다.
- 없으면 root, TLD, authoritative nameserver 방향으로 위임을 따라간다.
- 받은 record를 TTL 동안 저장한다.
DNS Resource Record 한 줄 읽는 법 — 답안을 만드는 확인 순서
- NAME에서 record가 속한 domain을 읽는다.
- TTL을 초 단위 cache 가능 시간으로 읽는다.
- TYPE이 A, AAAA, NS, MX, TXT 중 무엇인지 확인한다.
- MX RDATA의 작은 preference 값이 더 우선임을 확인한다.
- 끝의 점이 붙은 이름은 root까지 적은 FQDN임을 이해한다.
숫자와 입력값을 넣어서 한 번 따라가기
Client와 recursive resolver의 cache가 모두 비어 있고 A record를 요청합니다.
- Client stub resolver가 recursive resolver에 `www.example.org A?`를 보냅니다.
- Resolver는 root에 묻고 `.org` TLD nameserver referral을 받습니다. Root가 최종 IP를 주는 것은 아닙니다.
- Resolver는 `.org` TLD에 묻고 `example.org` authoritative server referral을 받습니다.
- Authoritative server가 최종 A record `203.0.113.10`을 답합니다.
이 예제의 결론 · DNS resolution은 client→resolver와 resolver→root/TLD/authoritative라는 두 층의 대화를 구분해야 합니다.
03 DoH·DNSSEC·Amplification 암호화, 서명, DDoS 방어는 서로 다른 목표입니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
DoH와 DNSSEC는 서로 다른 문제를 해결한다
용어를 보기 전에 장면부터 잡아 봅시다. DoH는 전화번호부 안내원에게 가는 통화를 도청하기 어렵게 암호화한 전화선이고, DNSSEC는 전화번호부 항목 자체에 발행 기관의 위조하기 어려운 도장을 찍는 것이다.
이제 그 장면에 실제 이름을 붙이면 DNS over HTTPS(DoH)는 사용자와 선택한 resolver 사이의 DNS message를 HTTPS 안에 넣어 전송한다. 주변 Wi-Fi나 단순한 중간 관찰자가 질문을 쉽게 읽거나 바꾸기 어렵게 하지만 resolver 자체는 질문을 본다. DNSSEC는 DNS record에 digital signature를 붙여 resolver가 authoritative data의 출처와 무결성을 검증하게 한다.
머릿속에서 순서대로 움직이면 공격자가 사용자와 resolver 사이에 있는지 resolver의 cache를 공격하는지 구분한다. → DoH는 transport privacy를, DNSSEC는 signed data validation을 제공한다. → DoH만으로 악성 resolver나 poisoned cache의 거짓 답을 자동 검증하지는 못한다.
DNS amplification: spoofing, reflection, amplification
용어를 보기 전에 장면부터 잡아 봅시다. 공격자가 여러 가게에 작은 주문서를 보내면서 배송 주소를 피해자 집으로 적어, 가게들이 큰 상자를 모두 피해자에게 보내게 하는 상황이다.
이제 그 장면에 실제 이름을 붙이면 DNS amplification은 작은 DNS query로 큰 response를 만들고, query의 source IP를 victim 주소로 위조해 response가 victim에게 가도록 하는 DDoS 방식이다. Source IP spoofing은 발신 주소를 거짓으로 적는 것, reflection은 중간 DNS resolver가 victim에게 답을 보내게 하는 것, amplification은 요청보다 응답이 더 큰 비율을 이용하는 것이다.
머릿속에서 순서대로 움직이면 Bot은 source IP를 victim IP로 위조한 작은 UDP DNS query를 보낸다. → Open resolver는 query를 처리한다. → 큰 DNS response가 위조된 주소인 victim에게 전달된다. → 많은 bot과 resolver의 응답이 victim의 bandwidth를 소모한다.
DoS, DDoS, botnet, victim
용어를 보기 전에 장면부터 잡아 봅시다. 한 사람이 상담 전화 한 회선을 계속 점유하면 DoS, 수천 명이 여러 번호에서 동시에 전화해 모든 회선을 막으면 DDoS다. 피해자는 여전히 상담 센터 하나일 수 있다.
이제 그 장면에 실제 이름을 붙이면 Denial of Service(DoS)는 서버의 대역폭, CPU, memory, connection 같은 제한된 자원을 소모시켜 정상 사용자가 서비스를 이용하지 못하게 하는 공격이다. Distributed DoS(DDoS)는 공격 트래픽이 여러 분산된 장치에서 동시에 온다는 뜻이다. 공격자가 malware로 장악한 많은 장치의 집합을 botnet이라고 하며, 서비스를 잃는 대상이 victim이다.
머릿속에서 순서대로 움직이면 공격 출발지가 하나인지 여러 개인지 확인한다. → 피해 서비스가 하나인지 여러 개인지는 distributed의 정의가 아님을 구분한다. → 소모되는 자원이 bandwidth인지 connection state인지 계산 자원인지 확인한다.
TERMS FROM ZERO
DoH·DNSSEC·Amplification에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
DoH
DNS over HTTPS로 client와 resolver 사이 DNS message를 HTTPS 안에 암호화합니다.
DNSSEC
DNS record에 대한 signature chain으로 data origin과 integrity를 검증하는 확장입니다.
Authenticity
받은 정보가 주장된 권한 있는 출처에서 왔는지를 확인하는 성질입니다.
Transport encryption
통신 구간에서 제3자가 내용을 읽거나 쉽게 바꾸지 못하게 하는 보호입니다.
Source IP spoofing
packet의 source IP를 victim 주소인 것처럼 위조하는 행위입니다.
Reflection
공격자가 제3의 server들이 victim에게 response를 보내게 만드는 구조입니다.
Amplification
작은 request로 더 큰 response를 만들어 공격 traffic 양을 증폭하는 효과입니다.
Open resolver
불특정 외부 client의 recursive DNS 질의를 받아주는 resolver입니다.
DoS
서비스 자원을 소모하거나 장애를 일으켜 정당한 사용자의 접근을 방해하는 공격입니다.
DDoS
여러 분산된 장치가 동시에 수행하는 DoS 공격입니다.
Botnet
공격자가 원격 조종하는 감염 장치들의 집합입니다.
Victim
공격 traffic이나 자원 고갈의 직접 대상이 되는 시스템 또는 사용자입니다.
처음부터 설명하면
DoH는 client와 resolver 사이 전송을 암호화합니다. DNSSEC는 DNS record의 authenticity/integrity를 서명으로 검증합니다. DNS amplification은 공격자가 victim의 source IP를 spoof한 작은 query를 open resolver에 보내 큰 response가 victim에게 가게 하는 reflected DDoS입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
DoH와 DNSSEC는 서로 다른 문제를 해결한다
DNS over HTTPS(DoH)는 사용자와 선택한 resolver 사이의 DNS message를 HTTPS 안에 넣어 전송한다. 주변 Wi-Fi나 단순한 중간 관찰자가 질문을 쉽게 읽거나 바꾸기 어렵게 하지만 resolver 자체는 질문을 본다. DNSSEC는 DNS record에 digital signature를 붙여 resolver가 authoritative data의 출처와 무결성을 검증하게 한다.
DNS amplification: spoofing, reflection, amplification
DNS amplification은 작은 DNS query로 큰 response를 만들고, query의 source IP를 victim 주소로 위조해 response가 victim에게 가도록 하는 DDoS 방식이다. Source IP spoofing은 발신 주소를 거짓으로 적는 것, reflection은 중간 DNS resolver가 victim에게 답을 보내게 하는 것, amplification은 요청보다 응답이 더 큰 비율을 이용하는 것이다.
DoS, DDoS, botnet, victim
Denial of Service(DoS)는 서버의 대역폭, CPU, memory, connection 같은 제한된 자원을 소모시켜 정상 사용자가 서비스를 이용하지 못하게 하는 공격이다. Distributed DoS(DDoS)는 공격 트래픽이 여러 분산된 장치에서 동시에 온다는 뜻이다. 공격자가 malware로 장악한 많은 장치의 집합을 botnet이라고 하며, 서비스를 잃는 대상이 victim이다.
쉬운 비유
DoH는 봉투를 가리고, DNSSEC는 문서에 도장을 찍습니다. 어느 쪽도 우체국으로 엄청난 우편을 보내는 공격을 자동으로 멈추지는 않습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
DoH와 DNSSEC는 서로 다른 문제를 해결한다
DoH는 전화번호부 안내원에게 가는 통화를 도청하기 어렵게 암호화한 전화선이고, DNSSEC는 전화번호부 항목 자체에 발행 기관의 위조하기 어려운 도장을 찍는 것이다.
DNS amplification: spoofing, reflection, amplification
공격자가 여러 가게에 작은 주문서를 보내면서 배송 주소를 피해자 집으로 적어, 가게들이 큰 상자를 모두 피해자에게 보내게 하는 상황이다.
DoS, DDoS, botnet, victim
한 사람이 상담 전화 한 회선을 계속 점유하면 DoS, 수천 명이 여러 번호에서 동시에 전화해 모든 회선을 막으면 DDoS다. 피해자는 여전히 상담 센터 하나일 수 있다.
시험 함정
DNSSEC 응답은 더 커질 수도 있으므로 amplification을 자동 차단한다고 쓰면 안 됩니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
DoH와 DNSSEC는 서로 다른 문제를 해결한다
HTTPS를 사용한다는 이유만으로 DNS answer의 진위성이 자동 보장된다고 쓰면 안 된다.
DNS amplification: spoofing, reflection, amplification
DNSSEC는 response에 signature를 추가해 응답을 더 크게 만들 수 있으며, source spoofing과 open resolver 문제를 직접 제거하지 않으므로 이 DDoS를 자동 차단하지 않는다.
DoS, DDoS, botnet, victim
DDoS의 D는 여러 victim이 아니라 여러 공격 출발지를 뜻한다.
답안에 적용
small spoofed query → resolver → large response → victim 흐름과 spoofing/reflection/amplification 세 단어를 연결합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
DoH와 DNSSEC는 서로 다른 문제를 해결한다 — 답안을 만드는 확인 순서
- 공격자가 사용자와 resolver 사이에 있는지 resolver의 cache를 공격하는지 구분한다.
- DoH는 transport privacy를, DNSSEC는 signed data validation을 제공한다.
- DoH만으로 악성 resolver나 poisoned cache의 거짓 답을 자동 검증하지는 못한다.
DNS amplification: spoofing, reflection, amplification — 답안을 만드는 확인 순서
- Bot은 source IP를 victim IP로 위조한 작은 UDP DNS query를 보낸다.
- Open resolver는 query를 처리한다.
- 큰 DNS response가 위조된 주소인 victim에게 전달된다.
- 많은 bot과 resolver의 응답이 victim의 bandwidth를 소모한다.
DoS, DDoS, botnet, victim — 답안을 만드는 확인 순서
- 공격 출발지가 하나인지 여러 개인지 확인한다.
- 피해 서비스가 하나인지 여러 개인지는 distributed의 정의가 아님을 구분한다.
- 소모되는 자원이 bandwidth인지 connection state인지 계산 자원인지 확인한다.
숫자와 입력값을 넣어서 한 번 따라가기
Alice가 `bank.example`을 조회할 때 도청자, 위조자, DDoS 공격자를 각각 놓습니다.
- DoH는 Alice와 resolver 사이 query를 HTTPS로 숨겨 같은 구간의 관찰자가 domain 내용을 읽기 어렵게 합니다.
- Resolver 이후 authoritative DNS 전체가 자동으로 비밀이 되는 것은 아닙니다.
- DNSSEC validator는 signed record chain을 확인해 위조된 answer를 탐지하려 합니다.
- DNSSEC는 record 내용을 암호화하지 않으므로 confidentiality 기능이 아닙니다.
이 예제의 결론 · DoH는 전송 구간의 privacy, DNSSEC는 data authenticity/integrity, amplification 대응은 spoofing과 open resolver 악용을 다룹니다.
04 BGP·Prefix·AS_PATH 인터넷 사업자들이 어느 길로 갈지 알리는 프로토콜
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Internet의 길 안내: AS, prefix, BGP announcement
용어를 보기 전에 장면부터 잡아 봅시다. 각 AS를 도시, prefix를 동네, BGP announcement를 ‘이 동네로 가는 길은 우리 도시를 통과한다’는 안내판으로 생각하면 된다.
이제 그 장면에 실제 이름을 붙이면 Internet은 하나의 네트워크가 아니라 Autonomous System(AS)이라는 큰 네트워크들의 연결이다. IP prefix는 10.10.10.0/24처럼 연속된 주소 범위를 나타내며 /24는 앞의 24개 bit가 같은 주소들을 하나의 네트워크로 묶는다는 뜻이다. BGP는 AS끼리 ‘이 prefix로 가려면 나를 거쳐라’라는 경로 정보를 교환하는 protocol이다. Announcement에는 목적지 prefix, 경로에 포함된 AS들의 AS_PATH, next hop과 여러 route attribute가 들어갈 수 있다.
머릿속에서 순서대로 움직이면 목적지 prefix가 무엇인지 찾는다. → 누가 origin AS라고 주장하는지 확인한다. → AS_PATH가 어떤 순서의 AS를 나타내는지 읽는다. → 기본 BGP 정보가 항상 진실이라고 암호학적으로 보장되지는 않음을 기억한다.
BGP hijack과 longest-prefix routing
용어를 보기 전에 장면부터 잡아 봅시다. ‘서울로 가는 길’ 안내와 ‘서울 101번 건물로 가는 길’ 안내가 동시에 있으면 101번 건물에는 더 구체적인 두 번째 안내를 따르는 것과 같다.
이제 그 장면에 실제 이름을 붙이면 BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.
머릿속에서 순서대로 움직이면 정상 prefix와 공격자가 광고한 prefix를 비교한다. → 목적지 주소에 두 prefix가 모두 일치하는지 본다. → 일치하면 prefix length가 더 긴 route를 선택한다. → 길이가 같으면 local preference, AS path 등 추가 BGP 정책을 본다.
TERMS FROM ZERO
BGP·Prefix·AS_PATH에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Autonomous System
하나의 관리 정책 아래 운영되는 IP network 집합이며 AS 번호로 식별됩니다.
Prefix
`203.0.113.0/24`처럼 연속된 IP 주소 범위를 나타냅니다.
BGP announcement
어떤 prefix로 가는 route와 path 정보를 이웃 AS에 알리는 message입니다.
AS_PATH
해당 route가 거쳐 온 AS 번호의 순서로 loop 방지와 route 선택에 사용됩니다.
BGP hijack
잘못되거나 악의적인 route announcement로 traffic이 다른 AS로 향하게 되는 사건입니다.
Longest-prefix match
Router가 목적지 IP를 포함하는 route 중 가장 구체적인 prefix를 우선하는 forwarding 규칙입니다.
Origin AS
BGP path에서 해당 prefix를 최초로 광고한 AS입니다.
RPKI / ROV
어떤 AS가 prefix를 origin으로 광고할 권한이 있는지 검증하는 체계와 절차입니다.
처음부터 설명하면
BGP announcement는 destination prefix와 AS_PATH 등을 전달합니다. Router는 먼저 가장 구체적인 prefix(longest-prefix match)를 보고, 같은 prefix 후보 안에서는 policy와 AS_PATH 등을 비교합니다. 잘못된 origin이나 path 정보가 퍼지면 hijack이 생깁니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Internet의 길 안내: AS, prefix, BGP announcement
Internet은 하나의 네트워크가 아니라 Autonomous System(AS)이라는 큰 네트워크들의 연결이다. IP prefix는 10.10.10.0/24처럼 연속된 주소 범위를 나타내며 /24는 앞의 24개 bit가 같은 주소들을 하나의 네트워크로 묶는다는 뜻이다. BGP는 AS끼리 ‘이 prefix로 가려면 나를 거쳐라’라는 경로 정보를 교환하는 protocol이다. Announcement에는 목적지 prefix, 경로에 포함된 AS들의 AS_PATH, next hop과 여러 route attribute가 들어갈 수 있다.
BGP hijack과 longest-prefix routing
BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.
쉬운 비유
‘서울 전체는 A길’보다 ‘특정 골목은 B길’이라는 더 구체적인 표지판이 우선하는 것과 같습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Internet의 길 안내: AS, prefix, BGP announcement
각 AS를 도시, prefix를 동네, BGP announcement를 ‘이 동네로 가는 길은 우리 도시를 통과한다’는 안내판으로 생각하면 된다.
BGP hijack과 longest-prefix routing
‘서울로 가는 길’ 안내와 ‘서울 101번 건물로 가는 길’ 안내가 동시에 있으면 101번 건물에는 더 구체적인 두 번째 안내를 따르는 것과 같다.
시험 함정
더 구체적인 prefix와 더 짧은 AS_PATH를 같은 규칙으로 설명하지 마세요. RPKI/ROV는 origin 검증, BGPSec은 path 검증에 초점이 다릅니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Internet의 길 안내: AS, prefix, BGP announcement
BGP message가 정상 형식이라는 사실과 그 안의 경로 주장이 사실이라는 것은 별개다.
BGP hijack과 longest-prefix routing
AS_PATH가 짧다는 이유만 보기 전에 longest-prefix match가 먼저 경로 후보를 결정한다는 점을 확인한다.
답안에 적용
announcement를 먼저 적고 각 destination prefix별 선택 route와 선택 이유를 routing table에 한 줄씩 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Internet의 길 안내: AS, prefix, BGP announcement — 답안을 만드는 확인 순서
- 목적지 prefix가 무엇인지 찾는다.
- 누가 origin AS라고 주장하는지 확인한다.
- AS_PATH가 어떤 순서의 AS를 나타내는지 읽는다.
- 기본 BGP 정보가 항상 진실이라고 암호학적으로 보장되지는 않음을 기억한다.
BGP hijack과 longest-prefix routing — 답안을 만드는 확인 순서
- 정상 prefix와 공격자가 광고한 prefix를 비교한다.
- 목적지 주소에 두 prefix가 모두 일치하는지 본다.
- 일치하면 prefix length가 더 긴 route를 선택한다.
- 길이가 같으면 local preference, AS path 등 추가 BGP 정책을 본다.
숫자와 입력값을 넣어서 한 번 따라가기
Router table에 `1.1.0.0/16 → AS10`과 `1.1.1.0/24 → AS20`이 동시에 있습니다.
- Destination `1.1.1.42`는 /16과 /24 두 prefix에 모두 포함됩니다.
- Forwarding은 더 구체적인 /24 longest-prefix match를 선택합니다.
- 따라서 AS_PATH가 더 길더라도 서로 다른 prefix 길이 비교에서는 /24가 먼저입니다.
- 같은 /24에 여러 BGP route가 있을 때 local policy, AS_PATH 등의 속성을 비교합니다.
이 예제의 결론 · Longest-prefix match와 BGP path selection은 서로 다른 단계입니다. 먼저 destination에 가장 구체적인 prefix, 그다음 같은 prefix의 route 속성을 봅니다.
05 DHCP DORA·OSI IP가 없는 새 기기가 네트워크 설정을 받는 순서
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
새 컴퓨터가 주소를 받는 DHCP DORA
용어를 보기 전에 장면부터 잡아 봅시다. 새로 온 학생이 교실 전체에 ‘자리 있나요?’라고 묻고, 선생님들이 자리를 제안하면 하나를 선택해 요청하고 담당 선생님이 최종 승인하는 과정이다.
이제 그 장면에 실제 이름을 붙이면 새 computer는 처음에는 자신의 IP도 DHCP server의 위치도 모른다. 그래서 broadcast로 DHCPDISCOVER를 보내 server를 찾는다. Server는 DHCPOFFER로 사용할 수 있는 IP와 설정을 제안하고, client는 DHCPREQUEST로 선택한 제안을 요청하며, server는 DHCPACK로 임대를 확정한다. 이 네 단계의 앞글자를 DORA라고 한다.
머릿속에서 순서대로 움직이면 Discover: Client에서 server들을 향한 broadcast. → Offer: Server가 IP, subnet mask, gateway, DNS, lease time을 제안. → Request: Client가 선택한 server와 IP를 알림. → Acknowledge: Server가 임대를 확정.
네트워크에서 누가 누구에게 무엇을 보내는가
용어를 보기 전에 장면부터 잡아 봅시다. IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
이제 그 장면에 실제 이름을 붙이면 네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
머릿속에서 순서대로 움직이면 송신자와 수신자를 먼저 적는다. → 출발지·목적지 IP와 port를 구분한다. → 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다. → 응답이 어느 방향으로 돌아오는지 그린다.
OSI 7계층을 역할로 이해하기
용어를 보기 전에 장면부터 잡아 봅시다. 택배에서 도로와 차량, 동네 배송, 건물 주소, 호수별 전달, 포장 형식, 최종 물건 사용을 서로 다른 담당 층으로 나눈 것과 같다.
이제 그 장면에 실제 이름을 붙이면 OSI model은 네트워크 통신 기능을 일곱 층으로 나눈 개념 모델이다. 아래 계층은 신호와 가까우며 위 계층은 사용자의 응용프로그램과 가깝다. 아래부터 Physical, Data Link, Network, Transport, Session, Presentation, Application 순서다. 실제 Internet protocol stack과 정확히 일대일 대응하지는 않지만 문제를 어느 범위에서 분석할지 돕는다.
머릿속에서 순서대로 움직이면 1 Physical: bit를 전기·빛·무선 신호로 전송. → 2 Data Link: 같은 링크의 frame과 MAC 주소. → 3 Network: IP 주소와 routing. → 4 Transport: TCP/UDP와 end-to-end 전달. → 5~7 Session, Presentation, Application: 대화 관리, 표현·암호화 형식, 사용자 protocol.
TERMS FROM ZERO
DHCP DORA·OSI에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
DHCP
새 client에게 IP 주소, gateway, DNS server 같은 network 설정을 자동 제공하는 protocol입니다.
Discover
설정이 없는 client가 DHCP server를 찾기 위해 보내는 첫 message입니다.
Offer / Request / Ack
Server의 제안, client의 선택 요청, server의 최종 확정으로 이어지는 DORA의 나머지 단계입니다.
Broadcast
특정 수신자를 아직 정확히 모를 때 local network의 여러 장치에 전달하는 방식입니다.
Packet
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP address
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
Port
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
Protocol
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
OSI model
network 기능을 역할별 7개 계층으로 나눈 개념 모델입니다.
Encapsulation
상위 계층 data에 각 계층 header를 붙여 아래 계층으로 내려보내는 과정입니다.
Transport layer
End-to-end 전달과 port, 신뢰성 등을 담당하는 계층으로 TCP와 UDP가 대표적입니다.
Network layer
IP 주소와 routing으로 서로 다른 network 사이 packet 전달을 담당합니다.
처음부터 설명하면
새 client는 Discover로 server를 찾고, server는 Offer를 보냅니다. Client가 Request로 선택을 알리면 server가 Ack로 확정합니다. 처음에는 client가 정상 IP를 아직 갖지 못했으므로 broadcast가 중요한 역할을 합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
새 컴퓨터가 주소를 받는 DHCP DORA
새 computer는 처음에는 자신의 IP도 DHCP server의 위치도 모른다. 그래서 broadcast로 DHCPDISCOVER를 보내 server를 찾는다. Server는 DHCPOFFER로 사용할 수 있는 IP와 설정을 제안하고, client는 DHCPREQUEST로 선택한 제안을 요청하며, server는 DHCPACK로 임대를 확정한다. 이 네 단계의 앞글자를 DORA라고 한다.
네트워크에서 누가 누구에게 무엇을 보내는가
네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
OSI 7계층을 역할로 이해하기
OSI model은 네트워크 통신 기능을 일곱 층으로 나눈 개념 모델이다. 아래 계층은 신호와 가까우며 위 계층은 사용자의 응용프로그램과 가깝다. 아래부터 Physical, Data Link, Network, Transport, Session, Presentation, Application 순서다. 실제 Internet protocol stack과 정확히 일대일 대응하지는 않지만 문제를 어느 범위에서 분석할지 돕는다.
쉬운 비유
빈 방을 찾는 사람이 공개적으로 문의(Discover)하고, 집주인이 제안(Offer), 사람이 선택(Request), 집주인이 계약 확정(Ack)하는 과정입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
새 컴퓨터가 주소를 받는 DHCP DORA
새로 온 학생이 교실 전체에 ‘자리 있나요?’라고 묻고, 선생님들이 자리를 제안하면 하나를 선택해 요청하고 담당 선생님이 최종 승인하는 과정이다.
네트워크에서 누가 누구에게 무엇을 보내는가
IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
OSI 7계층을 역할로 이해하기
택배에서 도로와 차량, 동네 배송, 건물 주소, 호수별 전달, 포장 형식, 최종 물건 사용을 서로 다른 담당 층으로 나눈 것과 같다.
시험 함정
DORA의 O와 R 순서를 바꾸거나 Ack를 Accept라고 쓰지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
새 컴퓨터가 주소를 받는 DHCP DORA
처음부터 client와 server가 서로의 IP를 안다고 가정하지 말고 broadcast가 필요한 이유를 함께 쓴다.
네트워크에서 누가 누구에게 무엇을 보내는가
하나의 port 번호가 그 port를 이용하는 데이터의 의미까지 보장하지는 않는다.
OSI 7계층을 역할로 이해하기
암기 순서만 쓰지 말고 각 계층의 대표 역할과 예시를 하나씩 연결하면 빈칸 위치를 복원하기 쉽다.
답안에 적용
각 행에 packet, sender, receiver, function을 모두 채우고 D→O→R→A 순서를 검사합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
새 컴퓨터가 주소를 받는 DHCP DORA — 답안을 만드는 확인 순서
- Discover: Client에서 server들을 향한 broadcast.
- Offer: Server가 IP, subnet mask, gateway, DNS, lease time을 제안.
- Request: Client가 선택한 server와 IP를 알림.
- Acknowledge: Server가 임대를 확정.
네트워크에서 누가 누구에게 무엇을 보내는가 — 답안을 만드는 확인 순서
- 송신자와 수신자를 먼저 적는다.
- 출발지·목적지 IP와 port를 구분한다.
- 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다.
- 응답이 어느 방향으로 돌아오는지 그린다.
OSI 7계층을 역할로 이해하기 — 답안을 만드는 확인 순서
- 1 Physical: bit를 전기·빛·무선 신호로 전송.
- 2 Data Link: 같은 링크의 frame과 MAC 주소.
- 3 Network: IP 주소와 routing.
- 4 Transport: TCP/UDP와 end-to-end 전달.
- 5~7 Session, Presentation, Application: 대화 관리, 표현·암호화 형식, 사용자 protocol.
숫자와 입력값을 넣어서 한 번 따라가기
새 노트북은 자기 IP와 DHCP server 주소를 모릅니다.
- Client는 server 주소를 모르므로 DHCP Discover를 local broadcast로 보냅니다.
- DHCP server는 제안 IP, lease time, gateway, DNS 설정을 Offer로 보냅니다.
- Client는 선택한 server와 offer를 Request로 알립니다.
- Server는 Ack로 lease를 확정하고 client가 사용할 설정을 보냅니다.
이 예제의 결론 · DHCP는 주소가 없는 시작 상태 때문에 broadcast를 활용하며 DORA 네 단계가 역할별로 나뉩니다.
06 TLS certificate·Domain validation·CA TLS는 올바른 이름과 키를 확인하지 인터넷 경로의 진실을 보장하지 않습니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
TLS certificate가 확인하는 것과 확인하지 않는 것
용어를 보기 전에 장면부터 잡아 봅시다. 건물 등기와 열쇠가 맞는지는 확인하지만 그 건물 안 가게가 좋은 물건을 파는지까지 보증하는 것은 아닌 것과 같다.
이제 그 장면에 실제 이름을 붙이면 Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.
머릿속에서 순서대로 움직이면 URL의 hostname과 certificate의 SAN 이름을 비교한다. → CA signature와 trust chain을 확인한다. → Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명한다. → Domain control과 사람·회사에 대한 도덕적 신뢰를 구분한다.
CA의 HTTP domain validation challenge
용어를 보기 전에 장면부터 잡아 봅시다. 집 소유를 확인하려고 임의의 문구를 현관에 붙이라고 했는데, 검사관이 가는 길을 공격자가 가짜 집으로 바꾸면 공격자가 문구를 보여 줄 수 있는 상황이다.
이제 그 장면에 실제 이름을 붙이면 CA는 certificate를 발급하기 전에 신청자가 domain을 통제하는지 확인한다. HTTP challenge에서는 CA가 무작위 token을 주고 신청자가 해당 domain의 정해진 URL에 token을 올리게 한다. CA가 DNS로 domain IP를 찾고 HTTP로 token을 읽으면 통제권이 있다고 판단한다. 공격자가 CA의 확인 traffic을 BGP나 DNS로 자신에게 돌리면 거짓 검증을 시도할 수 있다.
머릿속에서 순서대로 움직이면 공격자가 bob.net certificate를 신청해 challenge token을 받는다. → Token을 자신의 server에 준비한다. → CA가 bob.net을 확인하는 동안 route 또는 DNS를 조작해 CA traffic을 공격자 server로 유도한다. → CA가 token을 보고 통제권을 잘못 인정하면 certificate가 발급될 수 있다.
BGP hijack과 longest-prefix routing
용어를 보기 전에 장면부터 잡아 봅시다. ‘서울로 가는 길’ 안내와 ‘서울 101번 건물로 가는 길’ 안내가 동시에 있으면 101번 건물에는 더 구체적인 두 번째 안내를 따르는 것과 같다.
이제 그 장면에 실제 이름을 붙이면 BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.
머릿속에서 순서대로 움직이면 정상 prefix와 공격자가 광고한 prefix를 비교한다. → 목적지 주소에 두 prefix가 모두 일치하는지 본다. → 일치하면 prefix length가 더 긴 route를 선택한다. → 길이가 같으면 local preference, AS path 등 추가 BGP 정책을 본다.
TERMS FROM ZERO
TLS certificate·Domain validation·CA에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Certificate
domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다.
CA
Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다.
Certificate chain
server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다.
Hostname verification
접속한 domain 이름이 certificate에 허용된 이름과 일치하는지 확인하는 절차입니다.
Domain validation
Certificate 신청자가 그 domain을 제어하는지 CA가 확인하는 절차입니다.
HTTP challenge
CA가 지정한 token을 domain의 특정 HTTP 경로에서 제공하게 하는 검증 방식입니다.
Validation token
신청자가 domain 제어를 증명하기 위해 올바르게 반환해야 하는 일회성 값입니다.
Mis-issuance
권한 없는 주체에게 certificate가 잘못 발급되는 사건입니다.
BGP hijack
잘못되거나 악의적인 route announcement로 traffic이 다른 AS로 향하게 되는 사건입니다.
Longest-prefix match
Router가 목적지 IP를 포함하는 route 중 가장 구체적인 prefix를 우선하는 forwarding 규칙입니다.
Origin AS
BGP path에서 해당 prefix를 최초로 광고한 AS입니다.
RPKI / ROV
어떤 AS가 prefix를 origin으로 광고할 권한이 있는지 검증하는 체계와 절차입니다.
처음부터 설명하면
Browser는 certificate chain, hostname, validity, server의 private-key possession을 확인합니다. BGP로 traffic만 Eve에게 돌려도 Eve가 bob.com의 valid certificate/private key가 없으면 TLS 검증은 실패합니다. 하지만 CA의 HTTP challenge 경로까지 Eve가 가로채 token을 제공하면 잘못된 인증서 발급 위험이 생깁니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
TLS certificate가 확인하는 것과 확인하지 않는 것
Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.
CA의 HTTP domain validation challenge
CA는 certificate를 발급하기 전에 신청자가 domain을 통제하는지 확인한다. HTTP challenge에서는 CA가 무작위 token을 주고 신청자가 해당 domain의 정해진 URL에 token을 올리게 한다. CA가 DNS로 domain IP를 찾고 HTTP로 token을 읽으면 통제권이 있다고 판단한다. 공격자가 CA의 확인 traffic을 BGP나 DNS로 자신에게 돌리면 거짓 검증을 시도할 수 있다.
BGP hijack과 longest-prefix routing
BGP hijack은 권한 없는 AS가 다른 조직의 IP prefix에 도달할 수 있다고 광고해 traffic을 잘못 끌어오는 공격이다. Router는 여러 경로가 있을 때 먼저 목적지 IP와 가장 긴 prefix가 일치하는 longest-prefix match를 적용한다. /28은 /24보다 더 구체적인 작은 범위이므로 겹치는 주소에 대해서는 /28 경로가 선택된다.
쉬운 비유
택시가 잘못된 건물로 데려가도, 문 앞 직원이 올바른 신분증을 못 보여 주면 들어가지 않는 것과 같습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
TLS certificate가 확인하는 것과 확인하지 않는 것
건물 등기와 열쇠가 맞는지는 확인하지만 그 건물 안 가게가 좋은 물건을 파는지까지 보증하는 것은 아닌 것과 같다.
CA의 HTTP domain validation challenge
집 소유를 확인하려고 임의의 문구를 현관에 붙이라고 했는데, 검사관이 가는 길을 공격자가 가짜 집으로 바꾸면 공격자가 문구를 보여 줄 수 있는 상황이다.
BGP hijack과 longest-prefix routing
‘서울로 가는 길’ 안내와 ‘서울 101번 건물로 가는 길’ 안내가 동시에 있으면 101번 건물에는 더 구체적인 두 번째 안내를 따르는 것과 같다.
시험 함정
valid certificate를 ‘사이트가 정직함’ 또는 ‘DNS/BGP 경로가 옳음’으로 확대 해석하지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
TLS certificate가 확인하는 것과 확인하지 않는 것
사기 사이트도 자신이 통제하는 domain에 대해서는 valid certificate를 받을 수 있다.
CA의 HTTP domain validation challenge
공격은 TLS 암호를 직접 깨는 것이 아니라 certificate 발급 전의 domain validation 경로를 속이는 것이다.
BGP hijack과 longest-prefix routing
AS_PATH가 짧다는 이유만 보기 전에 longest-prefix match가 먼저 경로 후보를 결정한다는 점을 확인한다.
답안에 적용
route control, certificate possession, CA challenge control을 별도 조건으로 나눠 confidentiality와 availability 결과를 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
TLS certificate가 확인하는 것과 확인하지 않는 것 — 답안을 만드는 확인 순서
- URL의 hostname과 certificate의 SAN 이름을 비교한다.
- CA signature와 trust chain을 확인한다.
- Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명한다.
- Domain control과 사람·회사에 대한 도덕적 신뢰를 구분한다.
CA의 HTTP domain validation challenge — 답안을 만드는 확인 순서
- 공격자가 bob.net certificate를 신청해 challenge token을 받는다.
- Token을 자신의 server에 준비한다.
- CA가 bob.net을 확인하는 동안 route 또는 DNS를 조작해 CA traffic을 공격자 server로 유도한다.
- CA가 token을 보고 통제권을 잘못 인정하면 certificate가 발급될 수 있다.
BGP hijack과 longest-prefix routing — 답안을 만드는 확인 순서
- 정상 prefix와 공격자가 광고한 prefix를 비교한다.
- 목적지 주소에 두 prefix가 모두 일치하는지 본다.
- 일치하면 prefix length가 더 긴 route를 선택한다.
- 길이가 같으면 local preference, AS path 등 추가 BGP 정책을 본다.
숫자와 입력값을 넣어서 한 번 따라가기
사용자는 `https://bob.com`을 입력했지만 route 공격으로 TCP 연결은 Eve server에 도착합니다.
- Eve는 network route를 바꿔 connection을 자기 server로 받을 수 있습니다.
- Browser는 여전히 URL의 hostname `bob.com`을 기대합니다.
- Eve가 valid bob.com certificate를 보내지 못하면 hostname 또는 chain 검증이 실패합니다.
- 남의 certificate만 복사해도 대응 private key가 없으면 handshake proof를 만들 수 없습니다.
이 예제의 결론 · Routing이 어디로 연결할지 정하고 TLS가 연결된 상대의 hostname/key를 검증합니다. 두 계층의 성공 조건을 분리해야 합니다.
07 Firewall·SPF·Tor의 보호 범위 보안 기술 이름보다 무엇을 안 지키는지가 시험 함정입니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Firewall, port, protocol, data exfiltration
용어를 보기 전에 장면부터 잡아 봅시다. 경비원이 ‘53번 출입문을 쓰는 사람은 모두 전화번호부 업무’라고 믿으면, 공격자는 서류를 전화번호부 상자처럼 꾸며 그 문으로 가져갈 수 있다.
이제 그 장면에 실제 이름을 붙이면 Firewall은 packet의 source, destination, port, protocol, connection state 같은 규칙을 보고 통과 여부를 결정한다. Port 53은 관례상 DNS가 사용하는 번호지만 숫자 자체가 payload가 정말 정상 DNS 질문인지 증명하지 않는다. Data exfiltration은 공격자가 조직 내부의 비밀 데이터를 외부로 빼내는 행위이며, 허용된 DNS query의 이름 부분에 데이터를 인코딩해 보낼 수 있다.
머릿속에서 순서대로 움직이면 Firewall가 확인하는 header와 확인하지 않는 payload를 구분한다. → 공격자가 데이터를 작은 문자열로 인코딩한다. → 그 문자열을 공격자가 통제하는 domain의 subdomain query에 넣는다. → 외부 authoritative server의 log에서 데이터를 복원한다.
메일 주소, envelope, SPF를 구분하기
용어를 보기 전에 장면부터 잡아 봅시다. 편지 겉면에 CEO 이름을 써 놓는 것과 우체국 접수 기록에 어느 발송 지점에서 왔는지는 다르다. SPF는 주로 허용된 발송 지점을 확인한다.
이제 그 장면에 실제 이름을 붙이면 Email에는 사용자가 보는 From header와 SMTP 전달에 사용하는 envelope sender가 따로 있을 수 있다. SPF(Sender Policy Framework)는 수신 서버가 envelope sender domain의 DNS 정책을 조회해 현재 발송 IP가 허용됐는지 검사하는 기술이다. DKIM은 메일 내용에 domain signature를 붙이고 DMARC는 보이는 From domain과 SPF 또는 DKIM의 정렬(alignment) 정책을 적용한다.
머릿속에서 순서대로 움직이면 보이는 From과 envelope MAIL FROM을 구분한다. → 수신 서버가 envelope domain의 SPF record를 조회한다. → 발송 IP가 허용 목록에 있는지 판정한다. → 같은 조직 domain의 허용 계정·서버를 악용하면 SPF만으로 사용자 수준 사칭을 잡지 못할 수 있다.
Tor circuit과 DNS 질문이 어디서 보이는가
용어를 보기 전에 장면부터 잡아 봅시다. 여러 명이 봉투를 한 겹씩 벗겨 전달하는 경로에서 마지막 전달자가 목적지를 찾는다. 출발자가 별도로 동네 전화번호부에 직접 전화하면 목적지를 숨기려던 계획이 깨진다.
이제 그 장면에 실제 이름을 붙이면 Tor는 사용자의 traffic을 entry, middle, exit relay를 거치는 암호화된 circuit으로 전달해 한 지점이 사용자와 목적지를 동시에 알기 어렵게 한다. 일반 웹 domain의 DNS resolution은 보통 exit relay 쪽에서 수행되어 사용자의 로컬 resolver에 직접 새지 않게 해야 한다. 사용자가 Tor 밖의 external resolver를 직접 사용하면 그 resolver는 질문한 domain과 사용자의 네트워크 정보를 볼 수 있는 DNS leak이 생긴다.
머릿속에서 순서대로 움직이면 Browser와 DNS 설정이 Tor를 사용하도록 구성됐는지 확인한다. → 일반 domain은 exit 측 resolution이 이뤄지는지 확인한다. → 직접 외부 resolver로 나가는 packet이 있으면 DNS leak으로 본다. → .onion address는 일반 DNS가 아니라 Tor 내부 방식으로 처리한다.
네트워크에서 누가 누구에게 무엇을 보내는가
용어를 보기 전에 장면부터 잡아 봅시다. IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
이제 그 장면에 실제 이름을 붙이면 네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
머릿속에서 순서대로 움직이면 송신자와 수신자를 먼저 적는다. → 출발지·목적지 IP와 port를 구분한다. → 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다. → 응답이 어느 방향으로 돌아오는지 그린다.
TERMS FROM ZERO
Firewall·SPF·Tor의 보호 범위에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Firewall
traffic의 주소·port·protocol·state 같은 규칙을 보고 허용 또는 차단하는 장치나 software입니다.
Ingress / Egress
Ingress는 들어오는 traffic, egress는 밖으로 나가는 traffic입니다.
Data exfiltration
공격자가 조직 밖으로 비밀 데이터를 빼내는 행위입니다.
Stateful filtering
개별 packet뿐 아니라 연결 상태를 기억해 traffic을 판단하는 방식입니다.
Envelope sender
SMTP 전달 과정에서 반송 주소로 사용되는 발신 domain이며 화면의 From header와 다를 수 있습니다.
SPF
한 domain이 어떤 IP를 자신의 mail sender로 허용하는지 DNS에 게시하는 정책입니다.
Header From
사용자 mail 화면에 주로 표시되는 발신자 주소입니다.
Spoofing
공격자가 다른 주체의 주소나 identity인 것처럼 꾸미는 행위입니다.
Tor circuit
client traffic이 여러 relay를 거치도록 만든 임시 경로입니다.
Entry relay
client IP를 볼 수 있지만 최종 목적지는 직접 알기 어렵게 설계된 첫 relay입니다.
Exit relay
Tor network에서 목적지 server로 traffic을 내보내는 마지막 relay입니다.
DNS leak
Tor로 보내려던 domain 조회가 local resolver 등 다른 경로로 나가 browsing 정보가 노출되는 현상입니다.
Packet
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP address
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
Port
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
Protocol
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
처음부터 설명하면
Firewall은 IP/port/protocol/state 같은 규칙으로 traffic을 허용하거나 막지만 허용된 port 안의 악성 data까지 자동 판별하지 않습니다. SPF는 envelope sender domain의 발송 IP 정책을 확인합니다. Tor는 경로를 분산하지만 resolver와 exit 등 각 관찰자가 보는 metadata는 설정에 따라 다릅니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Firewall, port, protocol, data exfiltration
Firewall은 packet의 source, destination, port, protocol, connection state 같은 규칙을 보고 통과 여부를 결정한다. Port 53은 관례상 DNS가 사용하는 번호지만 숫자 자체가 payload가 정말 정상 DNS 질문인지 증명하지 않는다. Data exfiltration은 공격자가 조직 내부의 비밀 데이터를 외부로 빼내는 행위이며, 허용된 DNS query의 이름 부분에 데이터를 인코딩해 보낼 수 있다.
메일 주소, envelope, SPF를 구분하기
Email에는 사용자가 보는 From header와 SMTP 전달에 사용하는 envelope sender가 따로 있을 수 있다. SPF(Sender Policy Framework)는 수신 서버가 envelope sender domain의 DNS 정책을 조회해 현재 발송 IP가 허용됐는지 검사하는 기술이다. DKIM은 메일 내용에 domain signature를 붙이고 DMARC는 보이는 From domain과 SPF 또는 DKIM의 정렬(alignment) 정책을 적용한다.
Tor circuit과 DNS 질문이 어디서 보이는가
Tor는 사용자의 traffic을 entry, middle, exit relay를 거치는 암호화된 circuit으로 전달해 한 지점이 사용자와 목적지를 동시에 알기 어렵게 한다. 일반 웹 domain의 DNS resolution은 보통 exit relay 쪽에서 수행되어 사용자의 로컬 resolver에 직접 새지 않게 해야 한다. 사용자가 Tor 밖의 external resolver를 직접 사용하면 그 resolver는 질문한 domain과 사용자의 네트워크 정보를 볼 수 있는 DNS leak이 생긴다.
네트워크에서 누가 누구에게 무엇을 보내는가
네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
쉬운 비유
건물 출입문이 53번 창구만 열어 둬도 그 창구를 통해 몰래 메모를 내보낼 수 있습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Firewall, port, protocol, data exfiltration
경비원이 ‘53번 출입문을 쓰는 사람은 모두 전화번호부 업무’라고 믿으면, 공격자는 서류를 전화번호부 상자처럼 꾸며 그 문으로 가져갈 수 있다.
메일 주소, envelope, SPF를 구분하기
편지 겉면에 CEO 이름을 써 놓는 것과 우체국 접수 기록에 어느 발송 지점에서 왔는지는 다르다. SPF는 주로 허용된 발송 지점을 확인한다.
Tor circuit과 DNS 질문이 어디서 보이는가
여러 명이 봉투를 한 겹씩 벗겨 전달하는 경로에서 마지막 전달자가 목적지를 찾는다. 출발자가 별도로 동네 전화번호부에 직접 전화하면 목적지를 숨기려던 계획이 깨진다.
네트워크에서 누가 누구에게 무엇을 보내는가
IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
시험 함정
Port 53은 항상 정상 DNS, SPF는 사람 신원 보증, Tor는 모두에게 완전 익명이라는 절대 표현을 피하세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Firewall, port, protocol, data exfiltration
Port allowlist는 공격 표면을 줄이지만 허용된 protocol을 악용하는 covert channel까지 불가능하게 만들지는 않는다.
메일 주소, envelope, SPF를 구분하기
SPF가 메일 본문이나 개별 사용자 신원을 서명하는 기술이라고 생각하면 안 된다.
Tor circuit과 DNS 질문이 어디서 보이는가
‘Tor를 올바르게 사용한 경우’와 ‘외부 resolver를 직접 사용하도록 잘못 설정한 경우’를 섞지 않는다.
네트워크에서 누가 누구에게 무엇을 보내는가
하나의 port 번호가 그 port를 이용하는 데이터의 의미까지 보장하지는 않는다.
답안에 적용
각 기술에 대해 보호 구간, 확인하는 데이터, 남는 한계를 한 문장씩 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Firewall, port, protocol, data exfiltration — 답안을 만드는 확인 순서
- Firewall가 확인하는 header와 확인하지 않는 payload를 구분한다.
- 공격자가 데이터를 작은 문자열로 인코딩한다.
- 그 문자열을 공격자가 통제하는 domain의 subdomain query에 넣는다.
- 외부 authoritative server의 log에서 데이터를 복원한다.
메일 주소, envelope, SPF를 구분하기 — 답안을 만드는 확인 순서
- 보이는 From과 envelope MAIL FROM을 구분한다.
- 수신 서버가 envelope domain의 SPF record를 조회한다.
- 발송 IP가 허용 목록에 있는지 판정한다.
- 같은 조직 domain의 허용 계정·서버를 악용하면 SPF만으로 사용자 수준 사칭을 잡지 못할 수 있다.
Tor circuit과 DNS 질문이 어디서 보이는가 — 답안을 만드는 확인 순서
- Browser와 DNS 설정이 Tor를 사용하도록 구성됐는지 확인한다.
- 일반 domain은 exit 측 resolution이 이뤄지는지 확인한다.
- 직접 외부 resolver로 나가는 packet이 있으면 DNS leak으로 본다.
- .onion address는 일반 DNS가 아니라 Tor 내부 방식으로 처리한다.
네트워크에서 누가 누구에게 무엇을 보내는가 — 답안을 만드는 확인 순서
- 송신자와 수신자를 먼저 적는다.
- 출발지·목적지 IP와 port를 구분한다.
- 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다.
- 응답이 어느 방향으로 돌아오는지 그린다.
숫자와 입력값을 넣어서 한 번 따라가기
Firewall은 port 53을 허용하고, mail domain은 SPF를 쓰며, Alice는 Tor로 web에 접속합니다.
- Firewall이 UDP/TCP port 53을 허용해도 그 안의 모든 data가 정상 DNS라는 뜻은 아닙니다.
- 공격자는 허용 channel을 이용해 data exfiltration을 시도할 수 있어 application inspection이 별도로 필요할 수 있습니다.
- SPF는 envelope sender domain이 sending IP를 허용했는지 확인합니다.
- SPF 통과는 화면 From의 사람 신원이나 message 내용의 진실을 증명하지 않습니다.
이 예제의 결론 · ‘보안 기술’이라는 이름만으로 효과를 추측하지 말고 정확히 어떤 field와 구간을 검사하는지 물어야 합니다.
이 챕터 문제를 푸는 고정 순서
- 1
등장 주체를 상자에 쓰고 sender→receiver 화살표를 먼저 그립니다.
- 2
각 화살표 위에 packet/message 내용과 source/destination 정보를 적습니다.
- 3
공격자가 볼 수 있는 것, 바꿀 수 있는 것, spoof할 수 있는 것을 표시합니다.
- 4
방어 기술이 보호하는 정확한 구간과 남는 한계를 마지막에 씁니다.
출제·강의 근거 · Gedächtnisprotokoll Networking 62p, Multiple Choice·DNS·BGP·DHCP·OSI·Domain Validation 및 Moodle network exam
17
DDoS는 공격자가 하나의 Opfer가 아니라 여러 Opfer를 동시에 공격하는 DoS의 특수한 형태다. Wahr/Falsch?
DDoS ist eine spezielle Variante des DoS, bei der der Angreifer mehrere Opfer gleichzeitig angreift (statt nur ein Opfer).
문제 풀기18
사기성 Webseite도 gültiges TLS-Zertifikat를 가질 수 있다. Wahr/Falsch?
Auch eine betrügerische Webseite kann ein gültiges TLS-Zertifikat haben.
문제 풀기19
Autonomous System의 BGP-Nachrichten에는 false information이 들어갈 수 있다. Wahr/Falsch?
BGP-Nachrichten von Autonomen Systemen können falsche Informationen enthalten.
문제 풀기20
DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch?
DNS over HTTPS (DoH) verhindert einen DNS-Cache-Poisoning-Angriff auf den Resolver.
문제 풀기21
Firewall가 outgoing ports 중 Port 53만 허용하면 DNS-Anfragen만 통과하므로 data exfiltration은 불가능하다. Wahr/Falsch?
Wenn eine Firewall alle ausgehenden Ports außer Port 53 blockiert, können nur DNS-Anfragen durchkommen und deshalb keine Daten abfließen.
문제 풀기22
attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch?
Ein Angreifer hat ein Mailkonto attacker@example.com und versendet darüber eine Mail mit gespooftem Absender ceo@example.com. Wenn der empfangende Server SPF (Sender Policy Framework) verwendet, erkennt er, dass der Absender gespooft ist.
문제 풀기23
NSEC-Records는 존재하는 Domains를 enumerate/listing하는 데 사용될 수 있다. Wahr/Falsch?
NSEC-Records können zum Auflisten der vorhandenen Domänen verwendet werden.
문제 풀기24
Tor를 korrekt 사용해도 externer Resolver는 사용자가 어떤 Domain에 접속하려는지 안다. Wahr/Falsch?
Wenn Sie korrekt Tor verwenden, weiß Ihr externer Resolver dennoch, mit welcher Domäne Sie sich verbinden wollen.
문제 풀기25
DNS resolver가 tu-darmstadt.de를 resolve하려고 한다. Namensauflösung Ablauf를 sketch하라.
Ein DNS-Resolver versucht tu-darmstadt.de aufzulösen. Skizzieren Sie den Ablauf der Namensauflösung.
문제 풀기26
직후 resolver가 beispiel.de를 resolve한다. 이제 어떤 Nameserver를 contact해야 하는가? 이유를 설명하라.
Direkt im Anschluss löst der Resolver beispiel.de auf. Welche Nameserver muss er nun kontaktieren? Begründen Sie Ihre Antwort!
문제 풀기27
Eve가 Botnetz로 Alice의 server my.server.com을 DNS-Amplification-Angriff로 unerreichbar하게 만들려 한다. Botnetz, DNS-Resolver, Alice server 사이 communication을 표시하고 DNSSEC 사용 시 달라지는지 설명하라.
Eve hat ein Botnetz und möchte es dafür verwenden, Alices Server my.server.com durch einen DNS-Amplification-Angriff unerreichbar zu machen. Zeichnen Sie die Kommunikation zwischen Eves Botnetz, den DNS-Resolvern und Alices Server my.server.com ein. Ändert es etwas am Angriff, wenn DNSSEC verwendet wird?
문제 풀기28
Alice가 DNS query에 대해 'tu-darmstadt.de. 86400 IN MX ...' 형태의 여러 Resource Records를 받았다. 이 records는 무엇을 의미하는가?
Alice erhält auf eine DNS-Anfrage mehrere Resource Records der Form 'tu-darmstadt.de. 86400 IN MX ...'. Was sagen diese Resource Records aus?
문제 풀기29
BGP-Announcements에는 어떤 Informationen이 포함되는가?
Welche Informationen sind in BGP-Announcements (BGP-Ankündigungen) enthalten?
문제 풀기30
AS666이 AS1의 트래픽을 가로채려 한다. 공격 이름, AS666→AS3에 보낼 BGP announcement, 방어책을 쓰시오.
AS666 möchte den Netzwerkverkehr für AS1 abfangen. Welchen Angriff kann AS666 durchführen? Beschriften Sie den Pfeil AS666→AS3 mit einer passenden BGP-Announcement. Wie kann dieser Angriff verhindert werden?
문제 풀기31
미학습
32
DHCP server D가 있는 network에 새 computer C가 들어와 IP address를 요청한다. DHCP packets를 Reihenfolge대로 쓰고 Sender, Empfänger, Funktion을 table에 채우라.
Ein Netzwerk hat den DHCP-Server D. Ein Computer C ist neu in diesem Netzwerk und fordert eine IP-Adresse an. Tragen Sie in eine Tabelle ein, welche DHCP-Pakete gesendet werden, wer jeweils Sender und Empfänger ist und was die Funktion der einzelnen Pakete ist. Achten Sie auf die Reihenfolge der Pakete.
문제 풀기33
OSI model의 missing Schichten을 올바른 Reihenfolge로 채우라. 7-row table에서 oberste와 unterste는 이미 채워져 있었다.
Ergänzen Sie die fehlenden Schichten des OSI Modells in der richtigen Reihenfolge. Tabelle mit 7 Zeilen, oberste und unterste sind schon ausgefüllt.
문제 풀기34
미학습
35
Eve가 BGP로 Alice를 6.6.6.6에 보내고 bob.net self-signed 인증서를 제시했다. TLS가 실패하는 이유와 Eve가 연결을 성립시키려면 필요한 조건을 설명하시오.
Eve leitet Alice per BGP auf 6.6.6.6 um und zeigt ein selbst signiertes Zertifikat für bob.net. Warum schlägt TLS fehl, und was müsste Eve tun?
문제 풀기36
TLS-Zertifikate를 발급하는 CA SecureDomainCertCA가 fixed domain address에 token을 두는 HTTP-Challenge를 사용한다. Eve는 어떻게 bob.net에 대한 TLS certificate를 받을 수 있는가?
Eine CA SecureDomainCertCA, die TLS-Zertifikate ausstellt, verwendet eine HTTP-Challenge (Ablegen eines Token auf fester Adresse der Domain). Wie kann es Eve schaffen, sich bei dieser CA ein TLS-Zertifikat für bob.net zu holen?
문제 풀기Chapter 3
Web Sicherheit
Multiple Choice · Login-Code · XSS · Phishing
완전 초보자를 위한 1타 강사식 입문 강의
웹 보안은 ‘사용자 입력이 코드로 해석되는 순간’을 찾는 과목입니다
개념이 하나도 없다면 여기서 시작
웹페이지는 Browser가 보내는 HTTP request, Server의 application code, Database query, 다시 Browser로 돌아오는 HTML response가 이어진 결과입니다. 공격자는 입력칸뿐 아니라 URL, cookie, header, 직접 만든 request도 조작할 수 있습니다. 따라서 화면의 필터가 아니라 server에서 입력을 어떤 문맥(context)으로 사용하는지 확인해야 합니다.
01 HTTP request·GET·POST·TLS POST는 숨김 버튼이 아니라 전송 형식입니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Browser, server, HTTP, HTML parser
용어를 보기 전에 장면부터 잡아 봅시다. 같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
이제 그 장면에 실제 이름을 붙이면 Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
머릿속에서 순서대로 움직이면 사용자 입력이 들어오는 source를 찾는다. → 입력이 출력·DB·명령으로 들어가는 sink를 찾는다. → 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다. → 공격 영향과 context에 맞는 방어를 연결한다.
GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가
용어를 보기 전에 장면부터 잡아 봅시다. GET은 엽서 겉면에 비밀번호를 쓰는 것, POST는 봉투 안에 넣는 것에 가깝다. 하지만 봉투 자체가 투명하지 않게 보호되는 역할은 TLS가 한다.
이제 그 장면에 실제 이름을 붙이면 GET request의 parameter는 보통 URL query string에 들어가 browser history, bookmark, 화면, proxy·server access log, Referer에 남을 수 있다. POST는 데이터를 request body에 넣어 URL 노출을 줄이지만 자체적으로 암호화하지는 않는다. 전송 중 내용을 보호하려면 HTTPS/TLS가 함께 필요하다.
머릿속에서 순서대로 움직이면 Login credential을 URL에 넣지 않는다. → POST body로 전송한다. → 전체 연결에 HTTPS를 사용한다. → Server log와 error message에도 credential을 기록하지 않는다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
용어를 보기 전에 장면부터 잡아 봅시다. 처음 만날 때 신분증과 봉인된 절차로 둘만의 회의실 열쇠를 안전하게 정한 다음, 긴 회의 동안에는 그 열쇠로 빠르게 문을 여닫는 것과 같다.
이제 그 장면에 실제 이름을 붙이면 TLS는 HTTPS 연결에서 통신 상대를 확인하고 전송 내용을 보호하는 프로토콜이다. 공개키 암호(asymmetric cryptography)는 공개키와 개인키가 달라 키 교환과 서명에 편리하지만 큰 데이터를 처리하기에는 상대적으로 느리다. 대칭키 암호(symmetric cryptography)는 양쪽이 같은 비밀키를 사용하며 빠르다. 그래서 실제 TLS는 인증과 세션키 합의에 공개키 기술을 사용하고, 이후 데이터에는 빠른 대칭키 암호를 사용하는 hybrid 방식이다.
머릿속에서 순서대로 움직이면 Browser가 server의 certificate와 domain name을 검증한다. → Handshake에서 양쪽이 session key를 합의한다. → Application data는 합의된 대칭키로 빠르게 보호한다. → 암호화가 계산 시간을 없애거나 거래 내용을 절대적으로 안전하게 만들지는 않는다.
TERMS FROM ZERO
HTTP request·GET·POST·TLS에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
HTTP request
Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.
HTTP response
Server가 status, headers, body를 담아 client에 돌려주는 message입니다.
Parser / Interpreter
문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다.
Context
같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.
GET
주로 resource 조회에 쓰며 parameter가 URL query에 들어가기 쉬운 HTTP method입니다.
POST
주로 상태 변경이나 form 제출에 쓰며 data를 request body에 담을 수 있는 HTTP method입니다.
URL query
`?name=value` 형태로 URL에 붙는 parameter 부분입니다.
TLS
GET이나 POST와 별개로 전송 구간을 암호화하고 server를 인증하는 protocol입니다.
TLS
Browser와 server 사이 통신의 기밀성·무결성 및 server 인증을 제공하는 protocol입니다.
Hybrid encryption
공개키 기법으로 key를 합의하거나 보호하고, 실제 대량 데이터는 빠른 대칭키 암호로 처리하는 조합입니다.
Session key
한 연결이나 제한된 기간 동안 실제 application data 암호화에 사용하는 대칭 key입니다.
Handshake
암호 suite와 key material을 정하고 상대를 인증하는 TLS 연결 초기 단계입니다.
처음부터 설명하면
GET parameter는 URL에 들어가 history, log, bookmark, Referer 등에 남기 쉽습니다. POST는 body에 값을 넣지만 그 자체로 암호화하지 않습니다. Login secret은 POST와 TLS를 함께 사용해야 전송 중 노출을 줄일 수 있습니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Browser, server, HTTP, HTML parser
Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가
GET request의 parameter는 보통 URL query string에 들어가 browser history, bookmark, 화면, proxy·server access log, Referer에 남을 수 있다. POST는 데이터를 request body에 넣어 URL 노출을 줄이지만 자체적으로 암호화하지는 않는다. 전송 중 내용을 보호하려면 HTTPS/TLS가 함께 필요하다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
TLS는 HTTPS 연결에서 통신 상대를 확인하고 전송 내용을 보호하는 프로토콜이다. 공개키 암호(asymmetric cryptography)는 공개키와 개인키가 달라 키 교환과 서명에 편리하지만 큰 데이터를 처리하기에는 상대적으로 느리다. 대칭키 암호(symmetric cryptography)는 양쪽이 같은 비밀키를 사용하며 빠르다. 그래서 실제 TLS는 인증과 세션키 합의에 공개키 기술을 사용하고, 이후 데이터에는 빠른 대칭키 암호를 사용하는 hybrid 방식이다.
쉬운 비유
GET은 엽서 겉면, POST는 봉투 안쪽에 쓰는 것과 비슷하지만, TLS가 없으면 봉투 자체가 투명할 수 있습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Browser, server, HTTP, HTML parser
같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가
GET은 엽서 겉면에 비밀번호를 쓰는 것, POST는 봉투 안에 넣는 것에 가깝다. 하지만 봉투 자체가 투명하지 않게 보호되는 역할은 TLS가 한다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
처음 만날 때 신분증과 봉인된 절차로 둘만의 회의실 열쇠를 안전하게 정한 다음, 긴 회의 동안에는 그 열쇠로 빠르게 문을 여닫는 것과 같다.
시험 함정
‘POST를 쓰면 password가 암호화된다’고 쓰지 마세요. method와 channel encryption은 별개입니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Browser, server, HTTP, HTML parser
입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가
POST만 쓰면 네트워크에서 비밀번호가 암호화된다고 생각하면 안 된다.
TLS가 대칭키와 공개키를 함께 사용하는 이유
HTTPS가 오직 asymmetric cryptography만 사용한다거나, certificate가 있는 사이트는 정직한 상점이라고 단정하면 안 된다.
답안에 적용
URL/history/log/Referer 노출을 말하고 대안으로 POST over TLS를 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Browser, server, HTTP, HTML parser — 답안을 만드는 확인 순서
- 사용자 입력이 들어오는 source를 찾는다.
- 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
- 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
- 공격 영향과 context에 맞는 방어를 연결한다.
GET과 POST, 그리고 TLS는 각각 무엇을 바꾸는가 — 답안을 만드는 확인 순서
- Login credential을 URL에 넣지 않는다.
- POST body로 전송한다.
- 전체 연결에 HTTPS를 사용한다.
- Server log와 error message에도 credential을 기록하지 않는다.
TLS가 대칭키와 공개키를 함께 사용하는 이유 — 답안을 만드는 확인 순서
- Browser가 server의 certificate와 domain name을 검증한다.
- Handshake에서 양쪽이 session key를 합의한다.
- Application data는 합의된 대칭키로 빠르게 보호한다.
- 암호화가 계산 시간을 없애거나 거래 내용을 절대적으로 안전하게 만들지는 않는다.
숫자와 입력값을 넣어서 한 번 따라가기
Username `alice`, password `BlueHorse!7`을 server에 보냅니다.
- GET form은 `/login?user=alice&password=BlueHorse!7`처럼 secret을 URL에 넣을 수 있습니다.
- URL은 browser history, server/proxy log, bookmark, Referer 등에 남기 쉽습니다.
- POST는 값을 body로 옮겨 URL 노출을 줄이지만 packet 내용을 암호화하지 않습니다.
- HTTP 위의 POST만 사용하면 network observer가 body를 읽을 수 있습니다.
이 예제의 결론 · GET/POST는 HTTP message 배치와 의미를, TLS는 network 전송 보호를 결정합니다.
02 Authentication·Authorization·Role 누구인지 확인하는 것과 무엇을 해도 되는지는 다릅니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
보안이란 무엇을 지키는 것인가
용어를 보기 전에 장면부터 잡아 봅시다. 봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
이제 그 장면에 실제 이름을 붙이면 컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
머릿속에서 순서대로 움직이면 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다. → 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다. → 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
Browser, server, HTTP, HTML parser
용어를 보기 전에 장면부터 잡아 봅시다. 같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
이제 그 장면에 실제 이름을 붙이면 Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
머릿속에서 순서대로 움직이면 사용자 입력이 들어오는 source를 찾는다. → 입력이 출력·DB·명령으로 들어가는 sink를 찾는다. → 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다. → 공격 영향과 context에 맞는 방어를 연결한다.
TERMS FROM ZERO
Authentication·Authorization·Role에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Asset
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
Confidentiality
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
Integrity
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
Availability
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
HTTP request
Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.
HTTP response
Server가 status, headers, body를 담아 client에 돌려주는 message입니다.
Parser / Interpreter
문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다.
Context
같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.
처음부터 설명하면
Authentication은 사용자가 누구인지 확인하고, authorization은 인증된 사용자가 어떤 작업을 할 수 있는지 결정합니다. DB의 role 값을 browser가 보내는 대로 믿지 말고 server가 session과 정책을 기준으로 검사해야 합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
보안이란 무엇을 지키는 것인가
컴퓨터 보안은 막연히 ‘안전하게 만들기’가 아니라 지켜야 할 성질을 구분하는 일에서 시작한다. 기밀성(Vertraulichkeit, confidentiality)은 허가받지 않은 사람이 내용을 읽지 못하게 하는 것, 무결성(Integrität, integrity)은 내용이 몰래 바뀌지 않았음을 확인하는 것, 진위성(Authentizität, authenticity)은 상대나 데이터의 출처가 주장과 맞는지 확인하는 것이다. 서비스가 필요할 때 계속 동작하는 성질은 가용성(Verfügbarkeit, availability)이라고 한다.
Browser, server, HTTP, HTML parser
Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
쉬운 비유
회사 출입증으로 신원을 확인해도 모든 방에 들어갈 권한이 생기는 것은 아닙니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
보안이란 무엇을 지키는 것인가
봉투에 넣어 내용을 가리는 것은 기밀성, 봉인 스티커로 개봉 여부를 확인하는 것은 무결성, 발신인의 도장을 확인하는 것은 진위성, 우체국이 문을 열어 편지를 계속 전달하는 것은 가용성에 가깝다.
Browser, server, HTTP, HTML parser
같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
시험 함정
Login 성공을 admin 권한의 증거로 사용하거나 hidden field의 role을 신뢰하지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
보안이란 무엇을 지키는 것인가
TLS, 암호화, 서명, hash처럼 익숙한 단어가 나오더라도 그 기술이 제공하지 않는 목표까지 확대해서 쓰면 안 된다.
Browser, server, HTTP, HTML parser
입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
답안에 적용
identity check와 server-side role/permission check를 별도 단계로 적습니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
보안이란 무엇을 지키는 것인가 — 답안을 만드는 확인 순서
- 문제에서 숨김, 변조 탐지, 신원 확인, 서비스 중단 중 무엇을 묻는지 찾는다.
- 한 기술이 네 목표를 모두 자동으로 제공한다고 가정하지 않는다.
- 공격자가 무엇을 할 수 있는지와 지켜야 할 목표를 한 문장씩 분리한다.
Browser, server, HTTP, HTML parser — 답안을 만드는 확인 순서
- 사용자 입력이 들어오는 source를 찾는다.
- 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
- 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
- 공격 영향과 context에 맞는 방어를 연결한다.
숫자와 입력값을 넣어서 한 번 따라가기
Alice는 정상 login 후 `/documents/42`의 ID를 Bob 문서 ID 77로 바꿉니다.
- Password나 MFA 검증으로 Alice라는 identity가 확인됩니다.
- Server는 Alice identity를 session에 연결합니다.
- Alice가 URL ID를 77로 바꿔도 그 값은 client-controlled input일 뿐 권한 증거가 아닙니다.
- Server는 문서 77의 owner와 Alice의 permission을 매 request마다 확인해야 합니다.
이 예제의 결론 · ‘누구인가’와 ‘이 resource에 이 action을 해도 되는가’는 별도의 질문입니다.
03 XSS·Output encoding 문자열이 Browser에서 HTML/JavaScript로 실행되는 문제
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
XSS와 output encoding을 처음부터 이해하기
용어를 보기 전에 장면부터 잡아 봅시다. 설문 답변 칸에 쓴 문장을 사회자가 그대로 읽어야 하는데, 답변이 무대 지시문으로 해석되어 조명과 문을 조작하는 상황과 같다.
이제 그 장면에 실제 이름을 붙이면 Cross-Site Scripting(XSS)은 공격자 입력이 피해자 browser에서 신뢰된 사이트의 HTML 또는 JavaScript로 해석되어 실행되는 취약점이다. Reflected XSS는 request의 입력이 곧바로 response에 반사되는 형태다. 방어의 핵심은 출력 위치에 맞는 output encoding으로 특별한 문자를 데이터로만 해석하게 만드는 것이다.
머릿속에서 순서대로 움직이면 $_GET 같은 사용자 입력 source를 찾는다. → echo처럼 HTML response에 쓰는 sink를 찾는다. → HTML body, attribute, URL, JavaScript 중 context를 판별한다. → 해당 context용 encoding과 안전한 template API를 적용한다.
Browser, server, HTTP, HTML parser
용어를 보기 전에 장면부터 잡아 봅시다. 같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
이제 그 장면에 실제 이름을 붙이면 Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
머릿속에서 순서대로 움직이면 사용자 입력이 들어오는 source를 찾는다. → 입력이 출력·DB·명령으로 들어가는 sink를 찾는다. → 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다. → 공격 영향과 context에 맞는 방어를 연결한다.
TERMS FROM ZERO
XSS·Output encoding에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
XSS
공격자 입력이 victim browser에서 data가 아니라 HTML 또는 JavaScript code로 실행되는 취약점입니다.
Source
공격자 입력이 들어오는 URL, form, database record 같은 시작점입니다.
Sink
입력이 HTML이나 script로 해석될 수 있는 위험한 사용 지점입니다.
Output encoding
출력 context에서 특수문자가 code 문법이 아니라 data로 표현되도록 변환하는 방어입니다.
HTTP request
Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.
HTTP response
Server가 status, headers, body를 담아 client에 돌려주는 message입니다.
Parser / Interpreter
문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다.
Context
같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.
처음부터 설명하면
XSS는 attacker-controlled input이 response에 들어가 Browser가 이를 data가 아니라 HTML/JavaScript code로 해석할 때 발생합니다. 핵심 방어는 출력 위치에 맞는 context-sensitive encoding이며 CSP는 추가 방어층입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
XSS와 output encoding을 처음부터 이해하기
Cross-Site Scripting(XSS)은 공격자 입력이 피해자 browser에서 신뢰된 사이트의 HTML 또는 JavaScript로 해석되어 실행되는 취약점이다. Reflected XSS는 request의 입력이 곧바로 response에 반사되는 형태다. 방어의 핵심은 출력 위치에 맞는 output encoding으로 특별한 문자를 데이터로만 해석하게 만드는 것이다.
Browser, server, HTTP, HTML parser
Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
쉬운 비유
게시판 이름 칸에 적은 글이 명찰로 인쇄되지 않고 작업 지시서로 실행되는 상황입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
XSS와 output encoding을 처음부터 이해하기
설문 답변 칸에 쓴 문장을 사회자가 그대로 읽어야 하는데, 답변이 무대 지시문으로 해석되어 조명과 문을 조작하는 상황과 같다.
Browser, server, HTTP, HTML parser
같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
시험 함정
입력에서 `<script>`만 지우는 blacklist나 client-side validation만으로 해결했다고 쓰지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
XSS와 output encoding을 처음부터 이해하기
SQL injection 방어인 prepared statement를 XSS의 직접 해결책으로 쓰거나 client-side filter만 믿으면 안 된다.
Browser, server, HTTP, HTML parser
입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
답안에 적용
source → sink/output context → 실행 가능한 payload 종류 → impact → context-aware encoding 순서로 답합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
XSS와 output encoding을 처음부터 이해하기 — 답안을 만드는 확인 순서
- $_GET 같은 사용자 입력 source를 찾는다.
- echo처럼 HTML response에 쓰는 sink를 찾는다.
- HTML body, attribute, URL, JavaScript 중 context를 판별한다.
- 해당 context용 encoding과 안전한 template API를 적용한다.
Browser, server, HTTP, HTML parser — 답안을 만드는 확인 순서
- 사용자 입력이 들어오는 source를 찾는다.
- 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
- 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
- 공격 영향과 context에 맞는 방어를 연결한다.
숫자와 입력값을 넣어서 한 번 따라가기
Server가 `<div>검색: USER_INPUT</div>`에 사용자의 검색어를 그대로 연결합니다.
- 공격자는 URL query에 HTML 문법을 포함한 값을 넣습니다.
- Server가 이를 encoding 없이 response HTML의 `<div>` 안에 붙입니다.
- Browser HTML parser는 입력을 글자가 아니라 새 element와 event handler로 해석할 수 있습니다.
- 실행된 script는 victim이 보고 있는 site origin의 권한으로 request를 보내거나 화면을 바꿀 수 있습니다.
이 예제의 결론 · XSS는 ‘나쁜 문자열’ 문제가 아니라 attacker input이 어떤 browser context의 parser에 도달했는가의 문제입니다.
04 SQL Injection·Prepared statement 입력값이 SQL 문장의 구조를 바꾸는 문제
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
SQL injection과 prepared statement
용어를 보기 전에 장면부터 잡아 봅시다. 주문서의 이름 칸에 ‘주문 취소하고 금고 열기’라고 썼을 때 직원이 그것을 이름이 아니라 새 지시로 실행하는 문제다. Prepared statement는 이름 칸을 끝까지 데이터 칸으로 고정한다.
이제 그 장면에 실제 이름을 붙이면 SQL은 database에 질문하는 언어다. 프로그램이 SQL 문자열과 사용자 입력을 단순히 이어 붙이면 입력의 따옴표나 연산자가 데이터가 아니라 SQL 문법으로 해석될 수 있다. 이것이 SQL injection이다. Prepared statement는 SQL 구조를 먼저 고정하고 사용자 값은 별도 parameter로 전달해 값이 명령 문법이 되지 못하게 한다.
머릿속에서 순서대로 움직이면 $_GET, $_POST 같은 입력 source를 찾는다. → SQL 문자열 연결 또는 interpolation 지점을 찾는다. → 입력이 query 구조를 바꿀 수 있는지 확인한다. → Prepared statement와 bound parameter로 구조와 값을 분리한다. → Database account 권한도 최소화한다.
Browser, server, HTTP, HTML parser
용어를 보기 전에 장면부터 잡아 봅시다. 같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
이제 그 장면에 실제 이름을 붙이면 Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
머릿속에서 순서대로 움직이면 사용자 입력이 들어오는 source를 찾는다. → 입력이 출력·DB·명령으로 들어가는 sink를 찾는다. → 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다. → 공격 영향과 context에 맞는 방어를 연결한다.
TERMS FROM ZERO
SQL Injection·Prepared statement에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
SQL query
Database에 조회·삽입·변경 등을 요청하는 SQL 문장입니다.
SQL injection
공격자 입력이 SQL data가 아니라 query 구조와 명령으로 해석되는 취약점입니다.
Prepared statement
SQL 구조를 먼저 고정하고 사용자 값을 별도 parameter로 전달하는 방식입니다.
Parameter binding
입력값을 SQL syntax와 분리된 data slot에 연결하는 과정입니다.
HTTP request
Browser나 client가 server에 method, path, headers, body를 담아 보내는 message입니다.
HTTP response
Server가 status, headers, body를 담아 client에 돌려주는 message입니다.
Parser / Interpreter
문자열을 HTML, JavaScript, SQL, shell 같은 문법으로 해석하는 구성요소입니다.
Context
같은 문자가 어느 문법의 어느 위치에 놓였는지를 뜻하며 올바른 encoding 방법을 결정합니다.
처음부터 설명하면
문자열 연결로 query를 만들면 사용자 입력의 따옴표와 SQL syntax가 query 구조에 섞일 수 있습니다. Prepared statement는 SQL 구조를 먼저 고정하고 입력을 parameter value로 따로 전달합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
SQL injection과 prepared statement
SQL은 database에 질문하는 언어다. 프로그램이 SQL 문자열과 사용자 입력을 단순히 이어 붙이면 입력의 따옴표나 연산자가 데이터가 아니라 SQL 문법으로 해석될 수 있다. 이것이 SQL injection이다. Prepared statement는 SQL 구조를 먼저 고정하고 사용자 값은 별도 parameter로 전달해 값이 명령 문법이 되지 못하게 한다.
Browser, server, HTTP, HTML parser
Browser는 사용자의 client 프로그램이고 web server는 request를 받아 response를 만드는 프로그램이다. HTTP request에는 method, URL, header, body가 있고 response에는 status, header, body가 있다. Browser는 response body를 단순 글자가 아니라 HTML, JavaScript 같은 문법으로 해석(parse)한다. 외부 입력이 처음 들어오는 곳을 source, 그 입력이 실제 기능에 사용되는 위험한 도착점을 sink라고 부른다. 따라서 입력이 어느 문법 위치와 sink에 들어가는지가 보안에 매우 중요하다.
쉬운 비유
주문서의 이름 칸에 ‘모든 주문을 취소하라’는 명령을 써도 직원이 이름으로만 처리해야 합니다. 문자열 연결은 이를 명령으로 읽는 실수입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
SQL injection과 prepared statement
주문서의 이름 칸에 ‘주문 취소하고 금고 열기’라고 썼을 때 직원이 그것을 이름이 아니라 새 지시로 실행하는 문제다. Prepared statement는 이름 칸을 끝까지 데이터 칸으로 고정한다.
Browser, server, HTTP, HTML parser
같은 기호도 일반 편지 본문에서는 글자지만 계산식 칸에서는 연산자로 읽힌다. Browser도 입력이 HTML text, attribute, script 중 어디에 들어갔는지에 따라 다르게 해석한다.
시험 함정
HTML escaping은 XSS 문맥의 방어이며 SQL parser를 위한 근본 해결책이 아닙니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
SQL injection과 prepared statement
따옴표를 몇 개 치환하는 blacklist나 client-side validation만으로 해결하려 하지 않는다.
Browser, server, HTTP, HTML parser
입력 문자열 자체만 보고 취약점을 이름 붙이지 말고 source에서 sink까지 실제 흐름을 추적한다.
답안에 적용
vulnerable concatenation line, attacker input, changed query, impact, parameterized query를 한 묶음으로 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
SQL injection과 prepared statement — 답안을 만드는 확인 순서
- $_GET, $_POST 같은 입력 source를 찾는다.
- SQL 문자열 연결 또는 interpolation 지점을 찾는다.
- 입력이 query 구조를 바꿀 수 있는지 확인한다.
- Prepared statement와 bound parameter로 구조와 값을 분리한다.
- Database account 권한도 최소화한다.
Browser, server, HTTP, HTML parser — 답안을 만드는 확인 순서
- 사용자 입력이 들어오는 source를 찾는다.
- 입력이 출력·DB·명령으로 들어가는 sink를 찾는다.
- 그 sink를 어떤 parser가 어떤 context로 읽는지 확인한다.
- 공격 영향과 context에 맞는 방어를 연결한다.
숫자와 입력값을 넣어서 한 번 따라가기
Application이 `SELECT * FROM users WHERE name='` + input + `'`처럼 query를 만듭니다.
- 정상 입력 `alice`는 `WHERE name='alice'`라는 의도한 조건을 만듭니다.
- 공격 입력의 quote는 문자열을 일찍 닫고 뒤의 SQL operator가 query 구조에 참여하게 할 수 있습니다.
- Database parser는 application이 만든 한 문자열만 보므로 어느 부분이 data였는지 알 수 없습니다.
- 결과적으로 조건 우회나 의도하지 않은 row 접근이 발생할 수 있습니다.
이 예제의 결론 · 근본 방어는 특수문자 추측 삭제가 아니라 SQL 구조와 data를 API 수준에서 분리하는 것입니다.
05 Password storage·Salt·Slow KDF 비밀번호는 복호화해서 꺼내 보는 값이 아닙니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Password를 저장하지 않고 검증값을 저장하는 법
용어를 보기 전에 장면부터 잡아 봅시다. 비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
이제 그 장면에 실제 이름을 붙이면 Server는 사용자의 plaintext password를 다시 읽을 필요가 없다. 가입할 때 각 사용자마다 무작위 salt를 만들고 password와 함께 느린 password KDF에 넣어 나온 hash와 salt만 저장한다. 로그인 때 입력 password로 같은 계산을 수행해 비교한다. Argon2id, bcrypt, scrypt, PBKDF2 같은 KDF는 반복 계산과 memory 사용으로 대량 추측을 비싸게 만든다.
머릿속에서 순서대로 움직이면 사용자마다 고유한 random salt를 생성한다. → Password와 salt를 느린 KDF에 넣는다. → Salt, KDF parameter, 결과 hash를 저장한다. → 로그인 시 검증 API로 비교하고 role authorization은 별도로 확인한다.
Hash는 암호화가 아니라 고정 길이 지문이다
용어를 보기 전에 장면부터 잡아 봅시다. 수많은 책을 짧은 서가 번호로 압축해 표시하면 언젠가 같은 번호가 겹친다. 좋은 hash는 공격자가 원하는 겹침을 일부러 찾기 매우 어렵게 만든다.
이제 그 장면에 실제 이름을 붙이면 Cryptographic hash function은 길이가 제각각인 입력을 정해진 길이의 digest로 바꾼다. 같은 입력은 같은 digest를 만들지만 digest에서 원문을 되찾기는 어려워야 한다. 서로 다른 두 입력이 같은 digest를 만드는 상황을 collision이라고 한다. 입력 가능성은 사실상 무한하고 출력 종류는 유한하므로 collision은 수학적으로 반드시 존재하며, 보안 목표는 collision이 전혀 없게 하는 것이 아니라 현실적인 시간에 찾기 어렵게 하는 것이다.
머릿속에서 순서대로 움직이면 출력 길이는 입력 문장 길이가 아니라 알고리즘이 정한 bit 수로 고정된다. → Preimage resistance는 digest에서 원문을 찾기 어려운 성질이다. → Collision resistance는 서로 다른 두 입력의 같은 digest를 찾기 어려운 성질이다. → MD5처럼 실용적인 collision 공격이 알려진 알고리즘은 보안 용도로 사용하지 않는다.
TERMS FROM ZERO
Password storage·Salt·Slow KDF에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Password hash / KDF
Password 검증을 위해 의도적으로 비용을 높여 만든 단방향 계산 결과입니다.
Salt
사용자마다 새로 만드는 공개 random 값으로 같은 password도 서로 다른 저장 결과를 만들게 합니다.
Cost parameter
Password 추측 한 번에 필요한 시간·memory 비용을 조절하는 설정입니다.
Offline guessing
공격자가 유출된 database를 자기 장비에서 server 제한 없이 시험하는 공격입니다.
Hash function
임의 길이 입력을 고정 길이 digest로 바꾸는 단방향 함수입니다. 암호화처럼 복호화 key가 있는 기능이 아닙니다.
Digest
Hash function의 고정 길이 출력으로, 데이터의 짧은 지문처럼 사용됩니다.
Collision
서로 다른 두 입력이 같은 digest를 만드는 경우입니다. 출력 공간이 유한하므로 존재 자체는 피할 수 없습니다.
Preimage resistance
주어진 digest를 만드는 입력을 현실적인 시간에 찾기 어려워야 한다는 성질입니다.
처음부터 설명하면
Server는 plaintext password나 복호화 가능한 형태 대신 사용자별 random salt와 느린 password KDF 결과를 저장합니다. Login 때 같은 계산을 다시 해 비교합니다. Argon2id, bcrypt, scrypt, PBKDF2가 대표적입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Password를 저장하지 않고 검증값을 저장하는 법
Server는 사용자의 plaintext password를 다시 읽을 필요가 없다. 가입할 때 각 사용자마다 무작위 salt를 만들고 password와 함께 느린 password KDF에 넣어 나온 hash와 salt만 저장한다. 로그인 때 입력 password로 같은 계산을 수행해 비교한다. Argon2id, bcrypt, scrypt, PBKDF2 같은 KDF는 반복 계산과 memory 사용으로 대량 추측을 비싸게 만든다.
Hash는 암호화가 아니라 고정 길이 지문이다
Cryptographic hash function은 길이가 제각각인 입력을 정해진 길이의 digest로 바꾼다. 같은 입력은 같은 digest를 만들지만 digest에서 원문을 되찾기는 어려워야 한다. 서로 다른 두 입력이 같은 digest를 만드는 상황을 collision이라고 한다. 입력 가능성은 사실상 무한하고 출력 종류는 유한하므로 collision은 수학적으로 반드시 존재하며, 보안 목표는 collision이 전혀 없게 하는 것이 아니라 현실적인 시간에 찾기 어렵게 하는 것이다.
쉬운 비유
정답 자체가 아니라 정답을 전용 기계에 넣었을 때 나오는 느린 검증 결과만 보관하는 방식입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Password를 저장하지 않고 검증값을 저장하는 법
비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
Hash는 암호화가 아니라 고정 길이 지문이다
수많은 책을 짧은 서가 번호로 압축해 표시하면 언젠가 같은 번호가 겹친다. 좋은 hash는 공격자가 원하는 겹침을 일부러 찾기 매우 어렵게 만든다.
시험 함정
SHA-256(password)처럼 빠른 일반 hash만 쓰면 offline guessing이 너무 빠릅니다. Salt는 비밀이 아니며 사용자마다 달라야 합니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Password를 저장하지 않고 검증값을 저장하는 법
일반적인 빠른 hash 한 번만 사용하거나 모든 사용자에게 같은 salt를 쓰면 대량 추측과 미리 계산한 table 공격에 약하다.
Hash는 암호화가 아니라 고정 길이 지문이다
collision-free라는 절대 표현과 collision-resistant라는 계산적으로 찾기 어렵다는 표현을 구분해야 한다.
답안에 적용
per-user random salt + slow password KDF + cost parameter + constant-time verification을 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Password를 저장하지 않고 검증값을 저장하는 법 — 답안을 만드는 확인 순서
- 사용자마다 고유한 random salt를 생성한다.
- Password와 salt를 느린 KDF에 넣는다.
- Salt, KDF parameter, 결과 hash를 저장한다.
- 로그인 시 검증 API로 비교하고 role authorization은 별도로 확인한다.
Hash는 암호화가 아니라 고정 길이 지문이다 — 답안을 만드는 확인 순서
- 출력 길이는 입력 문장 길이가 아니라 알고리즘이 정한 bit 수로 고정된다.
- Preimage resistance는 digest에서 원문을 찾기 어려운 성질이다.
- Collision resistance는 서로 다른 두 입력의 같은 digest를 찾기 어려운 성질이다.
- MD5처럼 실용적인 collision 공격이 알려진 알고리즘은 보안 용도로 사용하지 않는다.
숫자와 입력값을 넣어서 한 번 따라가기
두 사용자가 모두 `BlueHorse!7`을 쓰지만 Alice salt는 `A91F`, Bob salt는 `72BC`입니다.
- Registration 때 server는 Alice와 Bob에게 서로 다른 random salt를 생성합니다.
- Alice는 `KDF(password, A91F, cost)`, Bob은 `KDF(password, 72BC, cost)`를 계산합니다.
- Password가 같아도 salt가 달라 stored output은 달라집니다.
- Database에는 salt, KDF 종류·cost, output을 저장하며 plaintext password는 저장하지 않습니다.
이 예제의 결론 · Salt는 같은 password의 결과 재사용을 막고, slow KDF는 각 추측 비용을 높입니다. 두 기능은 서로 대체하지 않습니다.
06 Password strength·Online/Offline guessing 복잡해 보이는 패턴보다 길고 예측하기 어려운 것이 중요합니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
강한 password를 공격자 관점에서 평가하기
용어를 보기 전에 장면부터 잡아 봅시다. 자물쇠 번호가 길어도 1234567890이면 공격자는 첫 시도에 가깝게 맞힌다. 짧은 장식보다 선택의 예측 불가능성이 중요하다.
이제 그 장면에 실제 이름을 붙이면 Password strength는 사람이 보기에 복잡한지가 아니라 공격자가 몇 번의 추측으로 맞힐 가능성이 높은지로 평가한다. 12345 같은 순서, 사전 단어, 이름과 연도 조합, 여러 사이트에서 재사용한 password는 먼저 시도된다. 길고 예측하기 어려운 고유 passphrase나 password manager가 만든 무작위 password가 유리하다.
머릿속에서 순서대로 움직이면 Common password list와 사전 단어 여부를 본다. → 이름+연도, 키보드 배열, 숫자 순서 같은 pattern을 찾는다. → 길이와 무작위성, 사이트별 고유성을 확인한다. → 저장 방식의 KDF 강도와 사용자가 고른 password 강도를 별도로 평가한다.
Password를 저장하지 않고 검증값을 저장하는 법
용어를 보기 전에 장면부터 잡아 봅시다. 비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
이제 그 장면에 실제 이름을 붙이면 Server는 사용자의 plaintext password를 다시 읽을 필요가 없다. 가입할 때 각 사용자마다 무작위 salt를 만들고 password와 함께 느린 password KDF에 넣어 나온 hash와 salt만 저장한다. 로그인 때 입력 password로 같은 계산을 수행해 비교한다. Argon2id, bcrypt, scrypt, PBKDF2 같은 KDF는 반복 계산과 memory 사용으로 대량 추측을 비싸게 만든다.
머릿속에서 순서대로 움직이면 사용자마다 고유한 random salt를 생성한다. → Password와 salt를 느린 KDF에 넣는다. → Salt, KDF parameter, 결과 hash를 저장한다. → 로그인 시 검증 API로 비교하고 role authorization은 별도로 확인한다.
TERMS FROM ZERO
Password strength·Online/Offline guessing에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Password entropy
공격자 관점에서 password가 얼마나 예측 불가능한지를 나타내는 정도입니다.
Dictionary attack
흔한 단어와 알려진 변형 규칙을 우선 시험하는 password 추측 공격입니다.
Credential stuffing
다른 site에서 유출된 username/password 조합을 재사용해 login하는 공격입니다.
MFA
Password 외에 별도의 factor를 요구해 password 하나의 유출만으로 login하기 어렵게 하는 인증 방식입니다.
Password hash / KDF
Password 검증을 위해 의도적으로 비용을 높여 만든 단방향 계산 결과입니다.
Salt
사용자마다 새로 만드는 공개 random 값으로 같은 password도 서로 다른 저장 결과를 만들게 합니다.
Cost parameter
Password 추측 한 번에 필요한 시간·memory 비용을 조절하는 설정입니다.
Offline guessing
공격자가 유출된 database를 자기 장비에서 server 제한 없이 시험하는 공격입니다.
처음부터 설명하면
12345나 king2026은 흔한 순서와 단어+연도 패턴이라 쉽게 추측됩니다. Online attack은 server rate limit/MFA의 영향을 받고, DB가 유출된 offline attack은 저장 방식의 KDF 비용이 핵심입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
강한 password를 공격자 관점에서 평가하기
Password strength는 사람이 보기에 복잡한지가 아니라 공격자가 몇 번의 추측으로 맞힐 가능성이 높은지로 평가한다. 12345 같은 순서, 사전 단어, 이름과 연도 조합, 여러 사이트에서 재사용한 password는 먼저 시도된다. 길고 예측하기 어려운 고유 passphrase나 password manager가 만든 무작위 password가 유리하다.
Password를 저장하지 않고 검증값을 저장하는 법
Server는 사용자의 plaintext password를 다시 읽을 필요가 없다. 가입할 때 각 사용자마다 무작위 salt를 만들고 password와 함께 느린 password KDF에 넣어 나온 hash와 salt만 저장한다. 로그인 때 입력 password로 같은 계산을 수행해 비교한다. Argon2id, bcrypt, scrypt, PBKDF2 같은 KDF는 반복 계산과 memory 사용으로 대량 추측을 비싸게 만든다.
쉬운 비유
문 끝에 느낌표 하나를 붙여도 공격자의 사전에 이미 있는 패턴이면 강해지지 않습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
강한 password를 공격자 관점에서 평가하기
자물쇠 번호가 길어도 1234567890이면 공격자는 첫 시도에 가깝게 맞힌다. 짧은 장식보다 선택의 예측 불가능성이 중요하다.
Password를 저장하지 않고 검증값을 저장하는 법
비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
시험 함정
특수문자 포함 여부만으로 강도를 판정하거나 online lockout이 유출 DB의 offline guessing을 막는다고 쓰지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
강한 password를 공격자 관점에서 평가하기
특수문자 하나나 최신 연도를 붙였다는 이유만으로 strong이라고 단정하지 않는다.
Password를 저장하지 않고 검증값을 저장하는 법
일반적인 빠른 hash 한 번만 사용하거나 모든 사용자에게 같은 salt를 쓰면 대량 추측과 미리 계산한 table 공격에 약하다.
답안에 적용
길이, 예측 가능성, 재사용, 공격 형태를 평가하고 password manager와 MFA를 함께 제안합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
강한 password를 공격자 관점에서 평가하기 — 답안을 만드는 확인 순서
- Common password list와 사전 단어 여부를 본다.
- 이름+연도, 키보드 배열, 숫자 순서 같은 pattern을 찾는다.
- 길이와 무작위성, 사이트별 고유성을 확인한다.
- 저장 방식의 KDF 강도와 사용자가 고른 password 강도를 별도로 평가한다.
Password를 저장하지 않고 검증값을 저장하는 법 — 답안을 만드는 확인 순서
- 사용자마다 고유한 random salt를 생성한다.
- Password와 salt를 느린 KDF에 넣는다.
- Salt, KDF parameter, 결과 hash를 저장한다.
- 로그인 시 검증 API로 비교하고 role authorization은 별도로 확인한다.
숫자와 입력값을 넣어서 한 번 따라가기
공격자는 무작위 전체 공간보다 유출 목록, 사전 단어, 연도, `!` 추가 규칙을 먼저 시험합니다.
- 공격자는 `password`, 이름, 팀명 같은 흔한 단어 목록을 먼저 시험합니다.
- 그다음 현재 연도와 `!`, 대문자 첫 글자 같은 인간의 흔한 변형 규칙을 붙입니다.
- `king2026!`는 길어 보여도 이 규칙 앞쪽에 있어 빠르게 맞을 수 있습니다.
- Online attack은 server rate limit·lockout·MFA로 속도가 제한됩니다.
이 예제의 결론 · 강도는 특수문자 개수가 아니라 공격자의 추측 순서에서 얼마나 뒤에 있는지로 봐야 합니다.
이 챕터 문제를 푸는 고정 순서
- 1
공격자가 조작할 수 있는 입력 source를 모두 찾습니다.
- 2
입력이 HTML, JavaScript, SQL, shell 중 어느 parser/context에 도달하는지 표시합니다.
- 3
취약한 줄과 실제 impact를 연결합니다.
- 4
문맥에 맞는 구체적 방어 API와 server-side 검사를 씁니다.
출제·강의 근거 · Gedächtnisprotokoll Web Sicherheit 54p, PHP Beispiel 및 Moodle Web-/Softwaresicherheit exam
37
SameSite 속성은 cross-site 요청에 cookie가 전송되는 것을 막는다.
Das SameSite-Attribut verhindert, dass ein Cookie bei Cross-Site-Anfragen mitgesendet wird.
문제 풀기38
HttpOnly cookie는 오직 브라우저의 JavaScript 환경 안에서만 읽을 수 있게 한다.
Das HttpOnly-Cookie-Attribut veranlasst, dass ein Cookie nur im Browser innerhalb der JavaScript Umgebung gelesen werden kann.
문제 풀기39
parameterized query는 SQL injection에 효과적인 server-side 방어다.
Parameterisierte Queries (stored procedures) sind ein effektiver serverseitiger Schutz gegen SQL-Injection.
문제 풀기40
SOP는 script가 기본적으로 임의의 다른 domain 데이터를 읽도록 허용한다.
Die Same-Origin Policy (SOP) erlaubt es Skripten standardmäßig, Daten von beliebigen anderen Domänen auszulesen.
문제 풀기41
SSRF는 server가 내부 resource에 권한 없는 요청을 보내도록 만드는 공격이다.
Bei SSRF wird ein Server dazu gebracht, unautorisierte Anfragen an interne Ressourcen zu stellen.
문제 풀기42
HSTS는 CSRF를 완전히 막는 장치다.
HSTS ist ein Mechanismus, der Cross-Site Request Forgery (CSRF) Angriffe vollständig unterbindet.
문제 풀기43
SRI hash는 CDN에서 읽은 script의 integrity를 확인하는 데 사용된다.
Ein SRI Hash wird verwendet, um die Integrität von Skripten zu validieren, die über ein CDN geladen werden.
문제 풀기44
CSP는 웹페이지가 신뢰할 script, style, data source를 정의한다.
Die Content Security Policy (CSP) definiert, welche Skripte, Styles und Datenquellen eine Webseite als vertrauenswürdig eingestuft sind.
문제 풀기45
웹서버로 login 정보를 전송할 때 어떤 위험이 있는가?
Welches Risiko besteht bei der Datenübertragung zum Webserver?
문제 풀기46
미학습
47
password 없이 admin으로 login하려면 user field에 어떤 값을 넣는가?
Welchen Wert muss ein Angreifer in das Feld user eingeben, um sich ohne Passwort als admin anzumelden?
문제 풀기48
data output 취약점의 줄 번호와 위험을 설명하시오.
Identifizieren Sie die betroffene Codezeile der Schwachstelle in der Datenausgabe und warum diese gefährlich ist.
문제 풀기49
표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?
Nennen Sie zwei Folgen der Passwortspeicherung in der Tabelle und wie man sie verbessern kann.
문제 풀기50
기능을 유지하면서 login.php를 안전하게 하는 변경 두 가지는?
Nennen Sie zwei Änderungen an login.php, die zur Sicherheit beitragen, ohne die gewünschte Funktionalität zu beeinflussen.
문제 풀기51
표에 있는 사용자 password 선택을 평가하고 근거를 쓰시오.
Wie beurteilen Sie die Wahl der Passwörter der Benutzer in der Tabelle? Begründen Sie kurz.
문제 풀기52
피해자–서버–공격자 사이 persistent XSS의 흐름을 설명하시오.
Beschreiben Sie den Ablauf eines persistenten XSS-Angriffs mit Opfer, Server und Angreifer.
문제 풀기53
persistent XSS와 reflected XSS의 차이 및 성공 후 가능한 공격은?
Was ist der Unterschied zwischen persistentem und reflektiertem XSS? Was kann ein Angreifer danach tun?
문제 풀기54
미학습
55
post-quantum encryption으로 phishing을 막을 수 있는가?
Kann Phishing mit Post-Quantum-Verschlüsselung von Daten verhindert werden?
문제 풀기56
하위 domain 관리자가 언제 blog 방문자의 session cookie를 읽을 수 있고 무엇을 할 수 있는가?
Ein Administrator von weihnachtsfeier2023.mega-corp.com: Wann kann er Session-Cookies von Blogbesuchern lesen und was kann er damit machen?
문제 풀기Chapter 4
Security Engineering
Multiple Choice · C Code Audit · Software/Hardware · Forensik
완전 초보자를 위한 1타 강사식 입문 강의
소프트웨어 보안은 ‘입력이 프로그램의 경계를 넘는 곳’을 찾는 과목입니다
개념이 하나도 없다면 여기서 시작
프로그램은 외부 입력을 memory buffer에 넣고, library function이나 operating system에 전달합니다. 입력의 길이와 의미를 잘못 믿으면 memory corruption이나 command execution이 생깁니다. Forensics에서는 반대로 데이터를 바꾸지 않고 어떻게 수집·분석했는지를 증명해야 합니다.
01 C memory·Buffer boundary 배열은 자동으로 늘어나지 않습니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
C의 buffer와 length 없는 sprintf
용어를 보기 전에 장면부터 잡아 봅시다. 10칸짜리 서랍에 30개 물건을 밀어 넣으면 옆 서랍의 물건까지 밀어내는 것과 같다. C는 자동으로 벽을 만들어 막아 주지 않는다.
이제 그 장면에 실제 이름을 붙이면 C의 char array는 정해진 크기의 연속된 memory 공간이다. Buffer에 들어갈 문자열 길이를 확인하지 않고 sprintf로 쓰면 경계를 넘어 인접 memory를 덮을 수 있다. 이를 buffer overflow라고 하며 crash, data corruption, 경우에 따라 code execution으로 이어질 수 있다. snprintf는 최대 길이를 받지만 반환값과 null termination 조건도 확인해야 한다.
머릿속에서 순서대로 움직이면 목적지 buffer 크기를 확인한다. → 공격자가 제어하는 문자열의 최대 길이를 확인한다. → Format 후 필요한 길이가 buffer보다 큰지 계산한다. → Bounded API와 반환값 검사, 명시적 길이 검증을 적용한다.
TERMS FROM ZERO
C memory·Buffer boundary에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Buffer
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Boundary / Bounds
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
Null terminator
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
Stack frame
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
Buffer overflow
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
처음부터 설명하면
C의 char buffer는 정해진 바이트 수만 가집니다. 더 긴 데이터를 쓰면 옆 memory를 덮을 수 있고 crash, data corruption, control-flow hijack으로 이어질 수 있습니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
C의 buffer와 length 없는 sprintf
C의 char array는 정해진 크기의 연속된 memory 공간이다. Buffer에 들어갈 문자열 길이를 확인하지 않고 sprintf로 쓰면 경계를 넘어 인접 memory를 덮을 수 있다. 이를 buffer overflow라고 하며 crash, data corruption, 경우에 따라 code execution으로 이어질 수 있다. snprintf는 최대 길이를 받지만 반환값과 null termination 조건도 확인해야 한다.
쉬운 비유
10칸짜리 서랍에 20개 물건을 억지로 넣어 옆 서랍의 내용까지 밀어내는 상황입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
C의 buffer와 length 없는 sprintf
10칸짜리 서랍에 30개 물건을 밀어 넣으면 옆 서랍의 물건까지 밀어내는 것과 같다. C는 자동으로 벽을 만들어 막아 주지 않는다.
시험 함정
입력이 문자로만 이루어졌는지가 아니라 목적 buffer의 실제 크기와 null terminator 공간을 확인해야 합니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
C의 buffer와 length 없는 sprintf
sprintf의 format string이 고정되어 있어도 출력 전체 길이가 제한되지 않으면 overflow가 생길 수 있다.
답안에 적용
destination size, attacker-controlled length, overwrite 대상, impact를 순서대로 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
C의 buffer와 length 없는 sprintf — 답안을 만드는 확인 순서
- 목적지 buffer 크기를 확인한다.
- 공격자가 제어하는 문자열의 최대 길이를 확인한다.
- Format 후 필요한 길이가 buffer보다 큰지 계산한다.
- Bounded API와 반환값 검사, 명시적 길이 검증을 적용한다.
숫자와 입력값을 넣어서 한 번 따라가기
`char name[8]` 바로 뒤에 `int is_admin = 0`이 놓였다고 단순화해 봅시다. 입력은 `ABCDEFGHIJKL` 12글자이고, C는 배열 경계를 자동으로 검사하지 않는다고 가정합니다.
- 입력의 A부터 H까지 8글자는 `name[0]`부터 `name[7]`까지 정상 범위에 들어갑니다.
- 아홉 번째 I를 쓸 때부터 `name`의 경계를 벗어납니다. C는 여기서 자동으로 멈추거나 예외를 던져 주지 않습니다.
- I, J, K, L 네 바이트는 옆 memory를 덮습니다. 실제 배치는 compiler와 platform에 따라 다르지만 다른 변수·pointer·control data가 대상이 될 수 있습니다.
- 옆의 `is_admin` 값이 우연히 0이 아닌 값으로 바뀌면 논리 결과가 달라질 수 있고, return address가 손상되면 crash나 control-flow hijack 가능성이 생깁니다.
이 예제의 결론 · 핵심은 ‘긴 입력이 위험하다’가 아니라 ‘목적지의 실제 바이트 수보다 더 많이 쓰는 순간 인접 memory가 공격자 입력의 영향을 받는다’는 것입니다.
02 sprintf·길이 제한 출력 문자열보다 목적 buffer가 작을 수 있습니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
C의 buffer와 length 없는 sprintf
용어를 보기 전에 장면부터 잡아 봅시다. 10칸짜리 서랍에 30개 물건을 밀어 넣으면 옆 서랍의 물건까지 밀어내는 것과 같다. C는 자동으로 벽을 만들어 막아 주지 않는다.
이제 그 장면에 실제 이름을 붙이면 C의 char array는 정해진 크기의 연속된 memory 공간이다. Buffer에 들어갈 문자열 길이를 확인하지 않고 sprintf로 쓰면 경계를 넘어 인접 memory를 덮을 수 있다. 이를 buffer overflow라고 하며 crash, data corruption, 경우에 따라 code execution으로 이어질 수 있다. snprintf는 최대 길이를 받지만 반환값과 null termination 조건도 확인해야 한다.
머릿속에서 순서대로 움직이면 목적지 buffer 크기를 확인한다. → 공격자가 제어하는 문자열의 최대 길이를 확인한다. → Format 후 필요한 길이가 buffer보다 큰지 계산한다. → Bounded API와 반환값 검사, 명시적 길이 검증을 적용한다.
TERMS FROM ZERO
sprintf·길이 제한에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Buffer
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Boundary / Bounds
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
Null terminator
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
Stack frame
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
Buffer overflow
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
처음부터 설명하면
sprintf는 결과 길이를 목적 buffer 크기에 맞춰 제한하지 않습니다. snprintf처럼 최대 크기를 전달하고 return value로 truncation을 확인하거나 동적 크기 계산을 사용해야 합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
C의 buffer와 length 없는 sprintf
C의 char array는 정해진 크기의 연속된 memory 공간이다. Buffer에 들어갈 문자열 길이를 확인하지 않고 sprintf로 쓰면 경계를 넘어 인접 memory를 덮을 수 있다. 이를 buffer overflow라고 하며 crash, data corruption, 경우에 따라 code execution으로 이어질 수 있다. snprintf는 최대 길이를 받지만 반환값과 null termination 조건도 확인해야 한다.
쉬운 비유
주소 라벨 프린터에 종이 폭을 알려 주지 않고 무한히 긴 주소를 인쇄시키는 것과 같습니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
C의 buffer와 length 없는 sprintf
10칸짜리 서랍에 30개 물건을 밀어 넣으면 옆 서랍의 물건까지 밀어내는 것과 같다. C는 자동으로 벽을 만들어 막아 주지 않는다.
시험 함정
stack canary나 ASLR은 exploit을 어렵게 하는 완화책이지 unsafe write를 제거하는 근본 수정이 아닙니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
C의 buffer와 length 없는 sprintf
sprintf의 format string이 고정되어 있어도 출력 전체 길이가 제한되지 않으면 overflow가 생길 수 있다.
답안에 적용
취약 호출, buffer 크기, 가능한 초과 길이, bounded API와 return-value check를 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
C의 buffer와 length 없는 sprintf — 답안을 만드는 확인 순서
- 목적지 buffer 크기를 확인한다.
- 공격자가 제어하는 문자열의 최대 길이를 확인한다.
- Format 후 필요한 길이가 buffer보다 큰지 계산한다.
- Bounded API와 반환값 검사, 명시적 길이 검증을 적용한다.
숫자와 입력값을 넣어서 한 번 따라가기
`char out[16]; sprintf(out, "Hello %s", name);`에서 `name = "Christopher"`라고 해 봅시다. 초보자는 사용자 이름 길이만 세기 쉽지만 결과 문자열 전체와 마지막 null terminator를 세어야 합니다.
- `Hello `는 H, e, l, l, o, 공백으로 이미 6바이트를 사용합니다.
- `Christopher`는 11바이트이므로 화면에 보이는 내용만 합쳐도 6 + 11 = 17바이트입니다.
- C 문자열 끝을 표시하는 `\0`도 1바이트 필요하므로 실제 필요한 공간은 18바이트입니다.
- `out`은 16바이트뿐이므로 2바이트가 경계를 넘어 인접 memory에 쓰입니다. `sprintf`는 `out`의 크기를 모르므로 스스로 중단할 수 없습니다.
이 예제의 결론 · buffer 계산식은 ‘고정 출력 길이 + 변하는 입력의 최대 길이 + null terminator 1’입니다. 함수 이름만 `snprintf`로 바꾸는 것이 아니라 반환값과 잘림의 의미까지 검사해야 합니다.
03 system()·Command injection 데이터가 shell 문법으로 다시 해석되는 순간
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
system()과 shell command injection
용어를 보기 전에 장면부터 잡아 봅시다. 배달 주소 칸에 ‘서울; 창고 문도 열어라’라고 썼는데 프로그램이 세미콜론 뒤 문장까지 새 업무 지시로 처리하는 상황이다.
이제 그 장면에 실제 이름을 붙이면 system()은 문자열을 운영체제 shell에 명령으로 전달한다. 사용자 입력을 그 문자열에 직접 붙이면 세미콜론, 파이프, 명령 치환 같은 shell metacharacter가 데이터가 아니라 추가 명령으로 해석될 수 있다. 이것이 command injection이다. 가능하면 shell을 거치지 않고 허용된 프로그램과 argument를 분리해 실행해야 한다.
머릿속에서 순서대로 움직이면 외부 입력 source를 찾는다. → 입력이 system, popen, shell=True 같은 command sink에 도달하는지 본다. → Shell 문법 문자가 명령 구조를 바꿀 수 있는지 확인한다. → Shell 없는 process API와 고정 allowlist argument를 사용한다. → 실행 계정 권한을 최소화한다.
TERMS FROM ZERO
system()·Command injection에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Shell
명령 문자열을 해석해 program을 실행하고 pipe·redirection 같은 문법을 처리하는 command interpreter입니다.
`system()`
문자열을 shell에 넘겨 command로 실행하는 C library 함수입니다.
Metacharacter
`;`, `|`, `&&`처럼 shell에서 단순 글자가 아니라 문법 역할을 하는 문자입니다.
Command injection
공격자 data가 shell syntax로 해석되어 의도하지 않은 command를 실행하게 되는 취약점입니다.
처음부터 설명하면
system()은 문자열을 shell command로 해석합니다. 사용자 입력을 문자열에 붙이면 shell metacharacter가 원래 명령의 구조를 바꿀 수 있습니다. 가장 좋은 방어는 shell을 거치지 않고 고정된 executable과 분리된 argument API를 사용하는 것입니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
system()과 shell command injection
system()은 문자열을 운영체제 shell에 명령으로 전달한다. 사용자 입력을 그 문자열에 직접 붙이면 세미콜론, 파이프, 명령 치환 같은 shell metacharacter가 데이터가 아니라 추가 명령으로 해석될 수 있다. 이것이 command injection이다. 가능하면 shell을 거치지 않고 허용된 프로그램과 argument를 분리해 실행해야 한다.
쉬운 비유
검색어를 직원에게 전달했는데 직원이 검색어 안의 문장을 새 업무 지시로 실행하는 상황입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
system()과 shell command injection
배달 주소 칸에 ‘서울; 창고 문도 열어라’라고 썼는데 프로그램이 세미콜론 뒤 문장까지 새 업무 지시로 처리하는 상황이다.
시험 함정
공백이나 몇 개 특수문자 blacklist만으로 모든 shell syntax와 encoding 우회를 막을 수 있다고 단정하지 마세요.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
system()과 shell command injection
일부 문자만 escape하는 방식은 shell 종류와 인코딩에 따라 우회될 수 있으므로 구조적으로 shell을 제거하는 편이 안전하다.
답안에 적용
attacker input → string concatenation → shell parsing → command execution impact → shell 제거 순서로 답합니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
system()과 shell command injection — 답안을 만드는 확인 순서
- 외부 입력 source를 찾는다.
- 입력이 system, popen, shell=True 같은 command sink에 도달하는지 본다.
- Shell 문법 문자가 명령 구조를 바꿀 수 있는지 확인한다.
- Shell 없는 process API와 고정 allowlist argument를 사용한다.
- 실행 계정 권한을 최소화한다.
숫자와 입력값을 넣어서 한 번 따라가기
프로그램이 `sprintf(cmd, "echo Willkommen %s", name); system(cmd);`를 실행하고 사용자가 이름으로 `Alice; whoami`를 입력했다고 해 봅시다.
- 정상 입력 `Alice`라면 만들어지는 문자열은 `echo Willkommen Alice`이고 shell은 한 명령으로 해석합니다.
- 공격 입력 `Alice; whoami`를 연결하면 문자열은 `echo Willkommen Alice; whoami`가 됩니다.
- application은 이를 단순 문자열로 만들었지만 `system()`은 전체 문자열을 shell에 넘깁니다.
- shell은 `;`를 첫 명령의 끝으로 읽어 `echo Willkommen Alice`와 `whoami`라는 두 명령을 차례로 실행합니다.
이 예제의 결론 · Command injection은 위험한 글자가 존재해서가 아니라, 공격자 data가 shell이라는 두 번째 해석기(parser)에 도달해 command syntax로 재해석되기 때문에 생깁니다.
04 Fuzzing 많은 이상한 입력을 자동으로 던져 실패를 찾는 동적 분석
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Fuzzing: 이상한 입력을 자동으로 계속 넣어 보는 시험
용어를 보기 전에 장면부터 잡아 봅시다. 문 손잡이를 정상적으로 한 번 돌리는 대신 아주 빠르게, 반대로, 반쯤, 여러 번 돌려 어떤 조작에서 문이 망가지는지 자동 실험하는 것과 같다.
이제 그 장면에 실제 이름을 붙이면 Fuzzing은 프로그램에 매우 많은 비정상·경계·무작위 입력을 자동 생성해 넣고 crash, hang, sanitizer error, assertion failure 같은 이상 동작을 찾는 dynamic testing 기법이다. Seed corpus는 시작 입력 모음이고 mutation은 입력을 변형하는 과정이다. Coverage-guided fuzzer는 새 code path를 실행한 입력을 보존해 더 깊은 상태를 탐색한다.
머릿속에서 순서대로 움직이면 정상적인 seed input을 준비한다. → 입력을 반복해서 mutate하거나 grammar에 맞게 생성한다. → Program을 실행하고 crash, timeout, coverage를 관찰한다. → 실패 입력을 재현하고 가장 작은 testcase로 줄인다. → 원인을 수정한 뒤 그 testcase를 regression test로 남긴다.
TERMS FROM ZERO
Fuzzing에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Fuzzer
많은 test input을 자동 생성·변형하고 target program에 실행하는 도구입니다.
Seed corpus
Fuzzing을 시작할 때 기본 구조를 제공하는 초기 입력 모음입니다.
Mutation
기존 입력의 byte·길이·구조를 변경해 새 test case를 만드는 과정입니다.
Oracle
Crash, sanitizer report, output mismatch 등 실패 여부를 판정하는 관찰 기준입니다.
Coverage
특정 입력이 program code의 어느 부분을 실행했는지 나타내는 정보입니다.
처음부터 설명하면
Fuzzer는 seed input을 반복해서 변형하고 program에 넣어 crash, sanitizer finding, timeout, 새로운 coverage를 관찰합니다. 실패 입력은 재현하고 최소화해 원인을 분석합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Fuzzing: 이상한 입력을 자동으로 계속 넣어 보는 시험
Fuzzing은 프로그램에 매우 많은 비정상·경계·무작위 입력을 자동 생성해 넣고 crash, hang, sanitizer error, assertion failure 같은 이상 동작을 찾는 dynamic testing 기법이다. Seed corpus는 시작 입력 모음이고 mutation은 입력을 변형하는 과정이다. Coverage-guided fuzzer는 새 code path를 실행한 입력을 보존해 더 깊은 상태를 탐색한다.
쉬운 비유
문 손잡이를 정상적으로만 돌리지 않고 빠르게, 반대로, 동시에 누르는 수천 가지 행동을 자동 시험하는 로봇입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Fuzzing: 이상한 입력을 자동으로 계속 넣어 보는 시험
문 손잡이를 정상적으로 한 번 돌리는 대신 아주 빠르게, 반대로, 반쯤, 여러 번 돌려 어떤 조작에서 문이 망가지는지 자동 실험하는 것과 같다.
시험 함정
Fuzzing은 버그가 없다는 formal proof가 아니며 crash 하나가 곧바로 exploit 가능성을 보장하지도 않습니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Fuzzing: 이상한 입력을 자동으로 계속 넣어 보는 시험
Fuzzing이 모든 입력을 증명하거나 취약점이 없음을 보장하지는 않는다. 좋은 oracle, instrumentation, corpus가 필요하다.
답안에 적용
seed → mutate/generate → execute → oracle/observe → reproduce/minimize의 feedback loop를 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Fuzzing: 이상한 입력을 자동으로 계속 넣어 보는 시험 — 답안을 만드는 확인 순서
- 정상적인 seed input을 준비한다.
- 입력을 반복해서 mutate하거나 grammar에 맞게 생성한다.
- Program을 실행하고 crash, timeout, coverage를 관찰한다.
- 실패 입력을 재현하고 가장 작은 testcase로 줄인다.
- 원인을 수정한 뒤 그 testcase를 regression test로 남긴다.
숫자와 입력값을 넣어서 한 번 따라가기
이미지 parser를 시험한다고 합시다. 정상 PNG 3개를 seed corpus로 주고, fuzzer가 파일의 길이 필드와 byte를 자동으로 바꿉니다.
- Fuzzer는 정상 PNG를 그대로 한 번 실행해 기준 behavior와 coverage를 얻습니다.
- 그다음 길이 byte를 10에서 255로 바꾸거나 chunk를 삭제하는 등 수많은 변형 입력을 만듭니다.
- 어떤 입력이 새로운 error-handling branch를 실행하면 coverage feedback을 보고 그 입력을 corpus에 남깁니다.
- 그 입력을 다시 변형한 결과 parser가 buffer 밖을 읽고 AddressSanitizer report와 함께 crash합니다. 이 report가 bug oracle 역할을 합니다.
이 예제의 결론 · Fuzzing의 완성은 ‘무작위 입력을 던짐’이 아니라 seed → 변형 → 실행 → feedback/oracle → 보존 → crash 최소화 → 수정과 회귀 테스트의 반복입니다.
05 Forensic image·Hash·Chain of custody 증거를 안 바꿨다는 사실과 절차를 함께 증명합니다
1타 강사 설명: 어려운 이름보다 장면과 순서를 먼저 잡기
이 개념을 처음 보는 학생이라면 전문 용어를 한 번에 외우려고 하지 마세요. 먼저 어떤 문제가 생겼고, 누가 무엇을 주고받으며, 어느 순간에 보안 문제가 생기는지 일상적인 장면으로 이해한 뒤 마지막에 용어를 붙이면 됩니다.
Digital evidence의 무결성과 chain of custody
용어를 보기 전에 장면부터 잡아 봅시다. 범죄 현장의 물건을 봉인하고 사진과 지문을 남기며, 경찰관 A에서 분석관 B로 넘어갈 때마다 시간과 서명을 기록하는 것과 같다.
이제 그 장면에 실제 이름을 붙이면 Digital forensics는 장치와 파일을 조사해 재현 가능한 증거를 만드는 과정이다. 원본을 직접 분석하면 조사 행위가 metadata나 내용을 바꿀 수 있으므로 write blocker 또는 read-only 방식으로 forensic image를 만들고 복사본을 분석한다. Cryptographic hash는 원본과 image가 같은지 확인하는 지문 역할을 한다. Chain of custody는 누가 언제 어디서 증거를 받아 어떤 행동을 했는지 이어서 기록한 문서다.
머릿속에서 순서대로 움직이면 Evidence ID와 수집 당시 상태를 기록한다. → Write blocker로 원본 변경을 줄이고 bitwise image를 만든다. → 원본과 image의 hash, 도구, 시각을 기록한다. → 모든 인계의 handler, timestamp, purpose, seal state를 기록한다. → Working copy를 분석하고 방법·결과·한계를 보고한다.
Hash는 암호화가 아니라 고정 길이 지문이다
용어를 보기 전에 장면부터 잡아 봅시다. 수많은 책을 짧은 서가 번호로 압축해 표시하면 언젠가 같은 번호가 겹친다. 좋은 hash는 공격자가 원하는 겹침을 일부러 찾기 매우 어렵게 만든다.
이제 그 장면에 실제 이름을 붙이면 Cryptographic hash function은 길이가 제각각인 입력을 정해진 길이의 digest로 바꾼다. 같은 입력은 같은 digest를 만들지만 digest에서 원문을 되찾기는 어려워야 한다. 서로 다른 두 입력이 같은 digest를 만드는 상황을 collision이라고 한다. 입력 가능성은 사실상 무한하고 출력 종류는 유한하므로 collision은 수학적으로 반드시 존재하며, 보안 목표는 collision이 전혀 없게 하는 것이 아니라 현실적인 시간에 찾기 어렵게 하는 것이다.
머릿속에서 순서대로 움직이면 출력 길이는 입력 문장 길이가 아니라 알고리즘이 정한 bit 수로 고정된다. → Preimage resistance는 digest에서 원문을 찾기 어려운 성질이다. → Collision resistance는 서로 다른 두 입력의 같은 digest를 찾기 어려운 성질이다. → MD5처럼 실용적인 collision 공격이 알려진 알고리즘은 보안 용도로 사용하지 않는다.
TERMS FROM ZERO
Forensic image·Hash·Chain of custody에서 처음 만나는 용어
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Digital evidence
사건을 입증하거나 반박하는 데 사용될 수 있는 digital data입니다.
Forensic image
파일만이 아니라 매체의 sector를 bit 단위로 복제한 분석용 image입니다.
Write blocker
원본 저장매체로 write command가 전달되지 않게 막는 장치나 절차입니다.
Chain of custody
누가 언제 어디서 어떤 목적으로 증거를 인수·접근·인계했는지 남기는 연속 기록입니다.
Hash function
임의 길이 입력을 고정 길이 digest로 바꾸는 단방향 함수입니다. 암호화처럼 복호화 key가 있는 기능이 아닙니다.
Digest
Hash function의 고정 길이 출력으로, 데이터의 짧은 지문처럼 사용됩니다.
Collision
서로 다른 두 입력이 같은 digest를 만드는 경우입니다. 출력 공간이 유한하므로 존재 자체는 피할 수 없습니다.
Preimage resistance
주어진 digest를 만드는 입력을 현실적인 시간에 찾기 어려워야 한다는 성질입니다.
처음부터 설명하면
원본 매체는 write blocker로 보호하고 bit-for-bit forensic image를 만들어 분석합니다. 수집 전후 hash로 동일성을 확인하며, 누가 언제 어디서 왜 증거를 다뤘는지 chain of custody에 기록합니다.
아래 용어를 하나씩 분리해서 읽으세요. 한 문장 안에 함께 등장해도 서로 같은 기능은 아닙니다. 각 단어가 가리키는 대상과 역할을 따로 잡은 뒤 다시 연결합니다.
Digital evidence의 무결성과 chain of custody
Digital forensics는 장치와 파일을 조사해 재현 가능한 증거를 만드는 과정이다. 원본을 직접 분석하면 조사 행위가 metadata나 내용을 바꿀 수 있으므로 write blocker 또는 read-only 방식으로 forensic image를 만들고 복사본을 분석한다. Cryptographic hash는 원본과 image가 같은지 확인하는 지문 역할을 한다. Chain of custody는 누가 언제 어디서 증거를 받아 어떤 행동을 했는지 이어서 기록한 문서다.
Hash는 암호화가 아니라 고정 길이 지문이다
Cryptographic hash function은 길이가 제각각인 입력을 정해진 길이의 digest로 바꾼다. 같은 입력은 같은 digest를 만들지만 digest에서 원문을 되찾기는 어려워야 한다. 서로 다른 두 입력이 같은 digest를 만드는 상황을 collision이라고 한다. 입력 가능성은 사실상 무한하고 출력 종류는 유한하므로 collision은 수학적으로 반드시 존재하며, 보안 목표는 collision이 전혀 없게 하는 것이 아니라 현실적인 시간에 찾기 어렵게 하는 것이다.
쉬운 비유
원본 미술품은 봉인하고 정밀 복제품으로 감정하며, 이동할 때마다 담당자와 시간을 인계 장부에 남기는 방식입니다.
비유는 정답 그 자체가 아니라 머릿속에 그림을 만드는 도구입니다. 비유의 사람·물건·행동이 실제 시스템의 어떤 요소와 대응하는지 확인하세요.
Digital evidence의 무결성과 chain of custody
범죄 현장의 물건을 봉인하고 사진과 지문을 남기며, 경찰관 A에서 분석관 B로 넘어갈 때마다 시간과 서명을 기록하는 것과 같다.
Hash는 암호화가 아니라 고정 길이 지문이다
수많은 책을 짧은 서가 번호로 압축해 표시하면 언젠가 같은 번호가 겹친다. 좋은 hash는 공격자가 원하는 겹침을 일부러 찾기 매우 어렵게 만든다.
시험 함정
Hash 하나만으로 수집 절차의 적법성, 담당자, 보관 상태까지 증명할 수는 없습니다.
틀린 문장을 통째로 외우지 마세요. 그 문장이 필요한 조건을 하나 빼먹었는지, 서로 다른 보안 목표를 섞었는지, 또는 보호 범위를 실제보다 넓혀 말했는지 찾아야 처음 보는 변형 문제도 풀 수 있습니다.
Digital evidence의 무결성과 chain of custody
Hash 일치만으로 누가 증거를 다뤘는지나 수집 절차의 법적 신뢰성까지 증명되지는 않는다.
Hash는 암호화가 아니라 고정 길이 지문이다
collision-free라는 절대 표현과 collision-resistant라는 계산적으로 찾기 어렵다는 표현을 구분해야 한다.
답안에 적용
identify → isolate/write block → image → hash → seal/store → custody log → analyze copy → reproducible report 순서로 씁니다.
답안 골격 정의 → 조건 또는 등장 주체 → 작동 순서 → 보안 효과 → 한계·반례 순서로 씁니다. 계산 문제라면 공식 → 값 대입 → 중간 계산 → 결론을 남깁니다.
Digital evidence의 무결성과 chain of custody — 답안을 만드는 확인 순서
- Evidence ID와 수집 당시 상태를 기록한다.
- Write blocker로 원본 변경을 줄이고 bitwise image를 만든다.
- 원본과 image의 hash, 도구, 시각을 기록한다.
- 모든 인계의 handler, timestamp, purpose, seal state를 기록한다.
- Working copy를 분석하고 방법·결과·한계를 보고한다.
Hash는 암호화가 아니라 고정 길이 지문이다 — 답안을 만드는 확인 순서
- 출력 길이는 입력 문장 길이가 아니라 알고리즘이 정한 bit 수로 고정된다.
- Preimage resistance는 digest에서 원문을 찾기 어려운 성질이다.
- Collision resistance는 서로 다른 두 입력의 같은 digest를 찾기 어려운 성질이다.
- MD5처럼 실용적인 collision 공격이 알려진 알고리즘은 보안 용도로 사용하지 않는다.
숫자와 입력값을 넣어서 한 번 따라가기
사건 PC에서 512GB SSD를 압수했습니다. 목표는 파일을 찾는 것뿐 아니라 분석 과정에서 원본을 바꾸지 않았고, 중간에 증거가 바뀌지 않았다는 점을 설명하는 것입니다.
- 현장에서 SSD에 evidence ID E-017을 붙이고 기기 상태, 수집자, 장소, 시각을 사진과 기록으로 남깁니다.
- SSD를 write blocker에 연결합니다. 분석 도구가 metadata나 access time을 원본에 쓰지 못하게 하는 단계입니다.
- 일반 파일 복사가 아니라 할당되지 않은 영역까지 포함하는 bit-for-bit image를 만들고 사용한 tool·version·시간을 기록합니다.
- 원본과 image에 같은 cryptographic hash algorithm을 적용해 `H(original) = H(image)`인지 확인하고 실제 hash 값을 기록합니다.
이 예제의 결론 · Hash는 ‘두 비트열이 같은가’를 강하게 확인하지만 ‘누가 언제 합법적으로 다뤘는가’는 말해 주지 않습니다. 그래서 원본 보호, image, hash, chain of custody, 재현 가능한 보고가 한 세트입니다.
이 챕터 문제를 푸는 고정 순서
- 1
외부 입력이 들어오는 지점과 신뢰 경계를 표시합니다.
- 2
입력이 memory 길이, format string, shell syntax 중 무엇에 영향을 주는지 확인합니다.
- 3
구체적인 impact와 근본 수정 API를 연결합니다.
- 4
Forensics 문제는 원본 보호, image, hash, 인계 기록, 재현 가능한 보고를 시간 순서로 씁니다.
출제·강의 근거 · Gedächtnisprotokoll Software Security·Unsortiert, C code·Forensik·Fuzzing 및 Moodle Buffer Overflow 문제
57
CVE는 일반 취약점 유형과 개발 오류를 분류한다.
CVE klassifiziert allgemeine Schwachstellenarten und typische Fehlerquellen.
문제 풀기58
CWE는 특정 제품의 개별 취약점을 설명한다.
CWE beschreibt konkrete, eindeutig identifizierte Sicherheitslücken in bestimmten Softwareprodukten.
문제 풀기59
off-by-one은 loop/index 경계가 정확히 1 어긋난 오류다.
Ein Off-by-One-Fehler verschiebt eine Schleifen- oder Array/Index-Grenze um genau 1.
문제 풀기60
programmer가 stack canary를 수동으로 끼워 넣는다.
Programmierer fügen Stack Canaries manuell zwischen lokale Variablen und sicherheitskritische Daten ein.
문제 풀기61
JS packing과 binary stripping은 reverse engineering을 어렵게 하는 obfuscation 방법이다.
JavaScript-Packing und Binary Stripping sind Obfuskationsmethoden, die Reverse Engineering erschweren.
문제 풀기62
미학습
63
ATM·차량·IoT 같은 특수 시스템 forensics는 고전 IT forensics 영역에 속하지 않는다.
Forensik für Geldautomaten, Unterhaltungselektronik, Fahrzeugelektronik und IoT gehört nicht zu den Arbeitsgebieten der klassischen IT-Forensik.
문제 풀기64
fuzzing oracle은 program 동작에 대한 feedback을 준다.
Ein Orakel beim Fuzzing gibt Rückmeldung über das Verhalten des Programms.
문제 풀기65
19행 `if (age - 21 < 0)`의 오류·영향·수정을 설명하시오.
Identifizieren Sie den Fehler in Zeile 19 (`if (age - 21 < 0)`) und erklären Sie Auswirkung und Behebung.
문제 풀기66
`system(cmd)` 주변의 오류·영향·수정을 설명하시오.
Identifizieren Sie den Fehler bei `system(cmd)` und erklären Sie Auswirkung und Behebung.
문제 풀기67
stack-based buffer overflow의 작동을 설명하시오.
Beschreiben Sie kurz die Funktionsweise eines Stack-based Buffer Overflow.
문제 풀기68
미학습
69
미학습
70
static analysis와 dynamic analysis의 차이는?
Was ist der Unterschied zwischen statischer und dynamischer Analyse?
문제 풀기71
forensic data collection에서 증거 연쇄의 무결성을 지키는 조치 두 가지를 쓰시오.
Nennen Sie zwei Maßnahmen zur Sicherung der Integrität der Beweiskette bei der forensischen Datensammlung.
문제 풀기