5장. 인터넷에서 사람과 정보는 어떻게 관계를 맺을까?

📌 도메인 이름 체계(DNS, Domain Name System)

IPv4든 IPv6든 기억하기 쉽지않다.
그래서 나온 것이 도메인 이름 체계이다.

- DNS는 공개적이고 분권화된 데이터베이스
- 문자 형식의 고유한 이름을 IP 주소, 위치, 기타 데이터(소유자 이름, 연락처 정보, 등록일 및 만료일, 기타 기술 세부 사항 등)과 연결할 수 있다.
- 복잡한 IP 주소 대신 기억하기 쉽고 고유한 단어로 구성된 도메인 이름을 사용한다.

IPv4 : 91.198.174.192
IPv6 : 2620:0:862:ed1a::1
DNS는 위 주소를 사람이 읽을 수 있는 문자로(wikipedia.org) 변환해준다.

DNS는 UDP를 활용해 도메인 검색 요청을 보내고, 요청에 응답한다.

❗ DNS 요청에서 UDP 활용 이유
=> UDP는 연결 지향적이 아닌 프로토콜로, 데이터를 빠르게 전송하는 데 초점이 맞춰져 있다.
=> DNS 요청은 일반적으로 데이터 크기가 작고, 아주 빠른 응답이 필요한데, UDP는 TCP에 비해 연결 설정 과정이 없기 때문에 더 빠르게 작동한다.
=> DNS 요청은 빠르고 간단한 구조를 가진 UDP를 통해 도메인 이름에 대한 정보를 요청하고, 해당 IP 주소를 응답받는다. 

 

🧿 도메인 구성

도메인 이름은 최소 두 부분(섹션)으로 구성되어 있다.
두 섹션은 점으로 구분한다.
점(.) 앞에 오는 것은 차상위(Second Level) 이름이고
점(.) 뒤에 오는 것은 최상위 도메인(TLD, Top Level Domain)이다.

즉 점으로 구분된 이름들은 뒤에 있을수록 더 상위 차원의 영역을 포함한다.

도메인 이름 예시	명칭 공간	관리자	영역
en	호스트 이름	도메인 소유자	서브도메인
.wikipedia	차상위 이름	도메인 대행업체, 도메인 소유자	도메인
.org	최상위 이름	레지스트리 또는 TLD 운영업체	최상위 도메인
.	.	ICANN	루트

◾ 명칭 공간(namespace)
DNS는 통제하는 영역에 따라 계층적 구조로 구성되어 있다.
각 계층마다 당당하고 있는 관리 제어 영역(zone)이 있다.
이것을 명칭 공간이라고 부른다.

👉🏻 서브도메인(호스트).도메인.최상위 도메인(TLD)

👉🏻 en.wikipedia.org

en
- 하위 영역(서브도메인 영역)

- 도메인 소유자는 서브도메인, 서브-서브도메인, 서브-서브-서브도메인 등을 만들 수 있다.
서브도메인을 생성해도 여전히 도메인 체계와 규칙을 유지해야 한다다.
ex) sub1.sub2.example.com이라는 서브도메인이 있다면, example.com이 상위 계층에 있는 도메인임을 명확히 알아볼 수 있어야 한다.

- 관리자는 다양한 목적에 따라 서브도메인(호스트 이름)을 할당할 수 있다.
en은 wikipedia라는 도메인의 영문 버전(en)임을 나타내는 서브도메인
ko는 wikipedia라는 도메인의 국문 버전(ko)임을 나타내는 서브도메인
=> en, ko는 언어를 구분하기 위한 목적으로 서브도메인을 할당한 것

- 도메인 레지스트리나 도메인 관리 대행업체에서 도메인 이름(example.com)은 구매할 수 있지만, 서브도메인(en.example.com)이나 호스트 이름(www, ftp, mail 등)은 따로 구매할 수 없다.
서브도메인은 도메인 소유자가 자유롭게 생성하고 관리할 수 있기 때문이다.

.wikipedia
- 도메인 영역
- 도메인 이름은 국제인터넷주소 관리기구(ICANN, Internet Corporation for Assigned Names and Numbers)에서 도메인 이름 판매를 허가받은 단체 또는 도메인 대행업체(registrar)를 통해 누구나 살 수 있다.
- 도메인 이름을 구매한 사람은 등록자(registrant)가 된다.

.org
- TLD 영역
- .com, .org, .net 등의 일반 최상위 도메인(gTLD, generic Top Level Domain)과 .kr, .jp, .uk 등의 국가 코드 최상위 도메인(ccTLD, country code Top Level Domain)으로 나뉜다.
- 현재 약 300개 정도의 ccTLD와 1,200개가 넘은 gTLD가 존재한다.(gTLD는 증가 추세)
- 각 TLD는 레지스트리(registry)를 통해 기술적인 유지 관리와 서비스를 제공하고 있다.

.
- 루트 영역
- DNS 루트 서버는 ICANN에서 관리하고 있다.
- 현재 지구에는 13개의 루트 서버가 있다.
- 여기서 모든 최상위 도메인에 해당하는 레지스트리를 호스팅한다.
- 루트 영역은 여러 개의 자율 및 이중 루트 서버를 사용해 DNS의 복원력을 유지하고 있다.

📍 도메인 이름 레지스트리

ICANN에서 TLD를 관리하기 위해 적용하는 데이터베이스이다.
=> ex) 최상위 도메인(TLD, Top-Level Domain)인 .com, .net, .org 같은 도메인들은 레지스트리가 관리한다.
=> 이 역할은 보통 ICANN(인터넷 관리 기구)에서 조율하며, 레지스트리는 도메인 이름의 데이터베이스를 유지하고, 관련 정책을 관리한다.

📍  국가 레지스트리

보통 정부 기관과 연관되어 ccTLD(국가별 최상위 도메인)을 관리한다.
=> 국가마다 **ccTLD(국가별 최상위 도메인)**를 관리하는 기관이 있다.
ㆍ.kr(한국) → 한국인터넷진흥원(KISA)
ㆍ.jp(일본) → 일본 인터넷 레지스트리(JPRS)

📍 레지스트리

구매자 또는 도메인 대행업체가 각자의 TLD 영역에 따라 도메인을 소유 또는 판매하는 데 필요한 조건을 정의하는 역할을 한다.
=> 도메인 이름을 구매자(소유자) 또는 도메인 대행업체(레지스트라)에 판매하거나 할당할 때 필요한 규칙을 정한다.
ex) 어떤 사람이 example.kr을 구매하고 싶으면, 한국의 ccTLD를 관리하는 기관의 정책에 따라 등록해야 한다.
ex) 특정 도메인은 제한이 있을 수도 있다.(정부 도메인인 .gov는 일반인이 등록 불가)

🧿 도메인 이름은 어떻게 IP 주소로 변환될까?

도메인 이름으로 접속하면 DNS는 그 이름을 IP 주소로 변환해 준다.
=> DNS에는 해당 서비스가 호스팅되는 IP 주소의 검색 방법을 정의하는 프로토콜이 있다.
 
- 브라우저의 주소창에 en.wikipedia.org를 입력하면 브라우저는 DNS 서버에 DNS 요청을 생성한다.
- 인터넷 서비스 공급자는 기본적으로 자신의 클라이언트가 도메인 이름을 검색하고 그 이름에 해당하는 IP 주소를 보내주는 DNS 서버를 운영한다.
- DNS를 요청하면, 도메인 이름에 해당하는 IP 주소를 검색해서 브라우저가 en.wikipedia.org의 내용에 관한 요청을 인터넷에 이쓴ㄴ 올바른 서버로 보내도록 한다.

- 홈 라우터가 IP 주소를 할당하고 이를 컴퓨터에 보낼 때는 도메인 이름을 IP 주소로 변환할 수 있는 DNS 서버 주소도 함께 보낸다.
- 이 주소는 홈 라우터의 주소일 수도 있고, DNS 검색을 수행하는 이름 서버(name server)일 수도 있다.
- 이것을 로컬 DNS 변환기(local DNS resolver)라고 부른다.

내가 인터넷 브라우저에 도메인 이름을 입력하면, 브라우저는 로컬 DNS 변환기에 해당 도메인 이름의 IP 주소를 문의한다.
로컬 DNS 변환기가 주소를 모르는 경우에는 최상위 계층 서버(루트 서버)에 다시 문의한다.
최상위 계층 서버(루트 서버)도 모른다면 로컬 DNS 변환기에 최상위 도메인 서버(TLD)의 IP 주소를 알려준다.
TLD에서도 알 수 없는 주소는 해당 도메인 이름에 IP 주소를 부여하는 도메인의 서버 IP 주소를 알려준다.
최종적으로 로컬 DNS 변환기는 이 IP 주소를 내가 쓰는 브라우저로 보내서 해당 사이트에 접속할 수 있게 해준다.

📍 요약

브라우저
=> 로컬 DNS
=> 최상위 계층 서버(루트 서버)
=> 최상위 도메인 서버(TLD) 
=> 로컬 DNS 변환기에 최상위 도메인 서버(TLD)의 IP 주소를 알려준다.
=> 해당 도메인 이름에 IP 주소를 부여하는 도메인의 서버 IP 주소를 알려준다.
=> 최종적으로 로컬 DNS 변환기는 이 IP 주소를 내가 쓰는 브라우저로 보내서 해당 사이트에 접속할 수 있게 해준다.

◾ 캐시(caches)
DNS 요청을 처음 생선한 뒤에는 브라우저, 컴퓨터, ISP 모두가 이 정보를 각자 저장해서 
나중에 같은 DNS 요청이 오면 더욱 빠르게 처리할 수 있는데
이것을 캐시(caches)라고 부른다.
캐시는 기존 정보들이다.

🧿 DNS 보안 확장(DNSSEC)
DNS는 DNS 검색 과정에서 제어권을 빼앗기기 쉽다.
이때 제어권을 탈취한 공격자는 사용자를 유해 웹사이트로 유도해서 아용자 이름과 비밀번호 같은 개인 정보를 수집할 수 있기 때문에 주의해야 한다.

이를 예방하기 위해 IETF는  DNS 프로토콜에 'DNS 보안 확장 프로토콜'이라는 것을 추가했다.
DNSSEC(DNS Security Extensions)라고 부른다.
누군가 DNS의 데이터를 위변조하는 것을 차단하는 기능이다.

DNSSEC는 데이터를 보내기 전에 DNS 데이터에 전자 서명 값을 첨부하고, DNS 변환기에 수신 데이터를 검증할 수 있는 장치를 마련한다.
DNSSEC는 이 전자 서명에 신뢰성을 부여하기 위해 신뢰 체인(trust chain)을 활용한다.

◾ 신뢰 체인을 생성하는 과정
ICANN은 루트 영역에 서명하는 키를 소유하고, 이 키를 TLD 레지스트리에 게시한다.
그러면 TLD 영역의 운영자는 자신의 키를 ICANN에 보낸다.
도메인소유자 역시 자신의 키를 생성한 다음 이를 도메인 대행업체에 업로드하고,
도메인 대행업체는 도메인 소유자의 키를 TLD 영역 운영자에게 전달한다.
TLD 영역 운영자는 도메인 소유자의 키에 서명하고 이를 DNS에 게시한다.
DNS를 검색할 때 DNSSEC를 시행하면 위와 같은 방식을 거쳐 각각의 검색 결과를 검증하고 신뢰할 수 있다.

🧿 HTTPS를 통한 DNS(DOH)
DNSSEC는 신뢰 체인을 구축해서 DNS 요청을 검증하지만 정보 프라이버시를 보호하기는 어렵다.
DNS 요청들을 각각 구분하고 식별할 수 있기 때문이다.
IETF 커뮤니티는 프라이버시 문제를 해결할 목적으로 HTTPS를 통한 DNS(DOH, DNS over HTTPS)라는 새로운 DNS 프로토콜을 개발했다.

DOH는 DNS 요청을 ISP의 로컬 DNS 변환기에 보내는 대신 HTTPS(HTTP + TLS)에서 암호화된 연결을 사용해서 애플리케이션이나 사용자가 선택한 DNS 변환기에 접속한다.
그 덕분에 로컬 ISP처럼 접속에 관여하는 중개자라도 DNS 요청을 식별할 수 없다.
반면 사용자는 신뢰할 수 있는 DNS 공급자를 식별할 수 있게 된다.
결과적으로 사용자에게 더 많은 프라이버시를 보장해 줄 수 있다.

HTTPS의 자세한 메커니즘은 처음 듣는 사람이 많겠지만 HTTPS 자체는 인터넷을 하면서 흔히 접해봤기 때문에 그리 낯선 용어가 아니다.
그만큼 널리 사용되는 프로토콜이라서 도메인 차단으로 검열하기가 매우 어렵다.
단, 이는 DOH 변환기가 모두 같은 엔티티(entity, 동일 속성으로 구성되는 개체)에 속하지 않고 분권화되어 있어야 가는하다.
같은 엔티티에 있으면 자체적으로 검열이 가능하기 때문이다.

 

 

 

📌 하이퍼텍스트 전송 규약(HTTP, Hypertext Transfer Protocol)

- HTTP는 하이퍼 텍스트를 교환하거나 전송할 때 사용하는 프로토콜
- 하이퍼텍스트란 하이퍼링크(hyperlink)라는 논리적 링크를 사용해서 다른 노드의 콘텐츠를 참조하기 위해 구조화된 텍스트이다.
- 일상에서 웹사이트를 연결할 때마다 인터넷 주소에 'http://'를 사용하는데, HTTP는 월드 와이드 웹(www)에서 데이터 통신을 할 수 있는 기반 역할을 한다.
- HTTP는 기본적으로 클라이언트-서버 모델을 사용하는 요청-응답 프로토콜이다.
=> 사용자가 웹사이트 방문할 때, 클라이언트는 서버에 HTTP 요청 메시지를 보낸다.
=> HTML, 이미지 등의 리소스를 제공하는 서버는 클라이언트에 응답 메시지를 회신한다. 응답에는 완료 상태, 요구받은 콘텐츠 등의 요청 관련 정보가 포함되어 있다.
- HTTP는 응용 계층에서 작동한다.
- 최상위 차원에서 웹 브라우저와 웹 서버가 서로 이해하고 소통할 수 있게 돕는 언어(프로토콜)이라는 뜻이다.

◾ 전송 계층 프로토콜(TCP)의 사용
- 하위 차원인 실제 데이터 전송은 전송 계층 프로토콜(TCP)로 이루어진다.
- 서버가 응답할 때는 요청할 때 사용한 것과 같은 TCP 연결로 HTTP 데이터를 다시 보낸다.
- 이러한 HTTP 응답을 통해 메시지 본문을 회신한다.
- 이 메시지에는 요청된 데이터나 콘텐츠(HTML 페이지, 이미지, 동영상, 파일 등)가 포함되어 있다.
- 응답 속에는 데이터를 설명하는 HTTP 헤더가 추가되어 있다.

◾ HTTP 요청과 응답
HTTP 요청
- 헤더 : 요청 리소스, 브라우저 등
- 본문 : 양식 데이터 또는 빈값

HTTP 응답
- 헤더 : 상태 코드, 콘텐츠 유형 등
- 본문 : 요청 리소스 콘텐츠

◾ HTTP 헤더
- HTTP는 HTTP 헤더에 요청 및 응답에 관한 정보를 모두 저장하고 브라우저와 웹 서버는 이 헤더를 읽어서 사용한다.
- 사용자에게는 헤더가 보이지 않지만, 클라이언트와 서버 사이에서 다양한 유형의 정보(반환되는 데이터 유형, 디바이스 운영체제, 사용 중인 브라우저 유형, 요청된 콘텐츠 유형 등)를 전송하는 데 매우 중요한 요소이다.
- 헤더와 함께 요청의 결과에 대한 HTTP 상태 코드를 함께 전달하기도 한다.


- HTTP는 프라이버시에 민감하지 않다.
- ISP가 제어하는 라우터, 중개 디바이스, 사용자가 방문하는 웹사이트는 HTTP 헤더와 발신 및 대상 IP 주소는 물론, 응답 데이터까지 HTTP를 통해 전송되는 모든 정보를 읽고 수절할 수 있다.
- HTTP 자체는 암호화되지 않기 때문이다.

 

 

 

📌 보안 HTTP: HTTPS

- HTTP의 단점을 보완하고자 프라이버시와 보안 기능을 강화한 HTTPS(보안 HTTP, Secure HTTP)가 등장했다.
- HTTPS는 데이터를 보호하기 위해 메시지(본문과 헤더)를 암호화하지만, IP 주소(발신지와 목적지 정보)는 암호화하지 않기 때문에 네트워크 상에서 통신이 가능하다.
- HTTPS는 하이퍼텍스트 전송 규약 보안(Hypertext Transfer Protocol Secure)이라고도 불리는데, 암호화 프로토콜인 전송 계층 보안(TLS, Transport Layer Security)이라는 방법을 사용해 HTTP 연결을 보호한다는 뜻이다.

◾ HTTPS로 운영한다.
- HTTPS 운영은 웹사이트가 보안 연결을 제공할 수 있도록 설정된 인증서와 서버 환경에 달려 있다.
- 리디렉션을 통해 HTTP로 접속한 클라이언트 트래픽을 HTTPS로 자동 전환할 수 있으며, 이는 웹사이트 보안을 강화하는 중요한 설정이다.

 

 

 

📌 전송 계층 보안(TLS)

◾ TLS 주요 기능
- 전송 중인 데이터의 프라이버시 확보
- 통신 노드의 ID 검증
- 데이터 분실 또는 변조를 예방하는 메시지 무결성 점검

◾ TLS 핸드셰이크
- HTTPS 통신을 시작하기 전에, 클라이언트와 서버는 TLS 핸드셰이크를 통해 인증서를 검증하고 비밀 키를 공유하여 안전한 연결을 설정해야 한다.

1. 클라이언트가 서버에 연결 요청
- 이때 사용할 암호화 방식과 랜덤 데이터를 보낸다.
2. 서버가 인증서 전송
- 서버는 자신의 디지털 인증서를 클라이언트에게 전송한다.
- 이 인증서는 서버의 신원을 증명하며, 공개키와 인증 기관(CA)의 서명이 포함되어 있다.
3. 클라이언트가 인증서 검증
- 클라이언트는 서버를 신뢰할 수 있는지 인증서를 검증한다.
- 서버 인증서를 신뢰할 수 있는 인증 기관(CA) 목록과 대조하여 서버가 실제로 신뢰할 수 있는지 검증한다.
4. 비밀 키 교환
- 클라이언트와 서버는 비밀 키를 교환하기 위해 공개키 암호화 또는 키 교환 알고리즘을 사용하여 비밀 키를 생성하고 공유한다.
5. 핸드셰이크 완료
- 클라이언트와 서버가 동일한 비밀 키를 공유하게 되면, 핸드셰이크 과정이 완료된다.
- 양 노드의 연결이 설정되고 비밀 키를 공유하면 이 둘 사이에서 교환되는 모든 데이터가 암호화된다.

◾ TLS의 활용
- 웹사이트 이메일, 채팅 등 다양한 곳에서 광범위하게
- QUIC과 DOH도 TLS를 기본으로 사용한다.

◾ TLS의 인증
- TLS는 신뢰할 수 있는 제3자 조직인 인증 기관(CA, Certificate Authorities)를 활용한다.
- 웹사이트 운영자가 CA에 요청을 하면, CA는 웹사이트의 정보를 확인하고, 해당 웹사이트에 대한 디지털 인증서를 발급한다.
- 인증서에는 서버 이름, 소유자 ID, 공개키 사본, CA 암호화 서명 등의 정보가 들어있다.

◾ 문제점
- TLS 신뢰 방식은 취약한 점이 많다.
- CA 자체가 훼손될 수 있고 강제로 위조 인증서가 발급될 수도 있다.
- 클라이언트 애플리케이션이 이를 수락하면서 다양한 속임수에 넘어갈 가능성도 높다.

🧿 서버 이름 표시(SNI, Server Name Indication)
서버는 한 IP 주소에 여러 개의 웹사이트나 서비스를 호스팅하는 경우가 많다.
서버는 클라이언트가 요청할 때마다 해당 웹사이트에 맞는 인증서를 보내줘야 하는데
서버는 어떤 웹사트의 인증서를 보내야 하는지 알 수 없다.

👉🏻 SNI는 여러 개의 웹사이트나 서비스를 하나의 IP 주소에서 호스팅하는 서버 환경에서, 클라이언트가 요청하는 웹사이트에 맞는 TLS 인증서를 선택할 수 있도록 도와주는 기능이다.

클라이언트는 TLS 핸드셰이크의 초기 단계에서 호스트 이름을 SNI 필드를 통해 서버에 전달하고
서버는 이 호스트 이름을 바탕으로 적합한 SSL 인증서를 선택하여 클라이언트에게 제공한다.

SNI가 없으면, 서버는 기본적으로 하나의 인증서만 제공할 수밖에 없으며, 여러 도메인을 안전하게 호스팅하려면 IP 주소나 포트를 구분해야 했다.
SNI는 하나의 IP 주소에서 여러 도메인을 안전하게 운영할 수 있게 해주는 중요한 기술이다.

 

 

 

📌 암호(Cryptography)

초기 인터넷은 개방적이고 상호 운용이 가능한 구조로 설계되었니다.
다양한 장치와 시스템들이 서로 자유롭게 연결되고 정보를 주고받을 수 있게 하려는 목적이었지만, 이런 개방적인 접근 방식은 보안상 큰 취약점을 안고 있었다.

인터넷은 처음에는 보안에 대한 큰 고려 없이 설계되었기 때문에, 인터넷을 통해 전송되는 정보는 쉽게 해킹되거나 노출될 수 있었다.
이를 보안하고자 인터넷 엔지니어들은 서버와 네트워크 인프라를 강화하는 등의 초기 보안 체계를 구축하였다.
ex) 데이터 전송 시 암호화 기술을 적용하거나, 서버와 클라이언트 간의 안전한 통신을 보장하려는 노력이 있었다.

하지만 이러한 노력에도 불구하고, 대규모 감시 활동이나 표적 공격 등의 위협으로부터 사용자의 프라이버시를 보호하는 데는 여전히 부족한 부분이 많았다.
서비스를 안전하게 보호하는 것과 사용자 개인 정보를 지키는 것 사이에서 균형을 맞추는 것이 매우 어려운 문제이기 때문이다.
(보안과 프라이버시라는 두 가지 목표는 때때로 충돌한다.)

ex) 
보안을 강화하려면 데이터의 접근성을 제한해야 할 수 있는데, 이런 제한은 사용자 프라이버시와 충돌할 수 있다.
반대로, 프라이버시를 보호하려면 데이터를 암호화하거나 사용자의 정보를 최소화하는 등의 방법을 사용해야 하는데, 이런 방법들이 보안 체계와 상충할 수 있다.
따라서 현대의 암호화 기술과 보안 체계는 이 두 가지 목표 사이에서 균형을 맞추는 방식으로 발전해 나가고 있다.

🧿 암호 기법
암호(cryptography)는 통신 보안을 확보하기 위해 활용한다.
일반적으로는 '서명'과 '암호화'라는 두 가지 암호 기법이 사용된다.

◾ 데이터 서명
데이터가 가짜라는 것을 확인하는 한 가지 방법은 데이터에 암호로 서명을 하는 것이다.
서명은 수학적인 방식으로 남긴다.
이것을 인증(authentication)이라고 한다.

데이터 서명 방식은 사용자나 기계가 서로 통신하고 수ㆍ발신 데이터를 인증하는 수많은 암호 절차에 널리 쓰인다.
채팅, 메시지, 이메일, 패킷, 심지어는 서명 그 자체에도 사용된다.(즉, 서명을 인증하는 용도로 사용되는 서명이다.)
말 그대로 온갖 데이터에 암호화된 서명을 할 수 있다.

ex)
발신자는 메시지나 파일을 인증하기 위해 디지털 지문을 추가해서 데이터에 자신의 서명을 남긴다.
수신자는 자신이 가진 발신자의 지문 사본과 원본을 대조할 수 있다.
지문이 훼손되거나 원본과 다르게 변조되었다면 수신자는 이 데이터가 진본인지 확신할 수 없다.

📍  인증(Authentication)
식별 가능한 정보로 서비스에 등록된 유저의 신원을 입증하는 과정
=> 신원 인증

📍   인가(Authorization)
인증된 사용자에 대하여 자원의 접근권한을 확인하는 것
=> 접근 인가

 

◾ 암호화(encryption)
암호화는 서명 대신 아예 비밀 메시지를 쓰는 방식이다.
원래는 그대로 읽을 수 있는 텍스트를 바로 읽을 수 없도록 암호문(ciphertext)으로 변환하는 작업이다.
반대로 암호문을 평문(plaintext)으로 바꾸는 작업을 복호화(decryption)라고 한다.
이와 같은 메시지 암호화 및 복호화 과정을 암호화 알고리즘 또는 암호(cipher)라고 부른다.

단순한 암호화 알고리즘은 각 글자를 정해진 숫자만큼 뒤에 있는 알파벳으로 치환하는 것이다.
시프트(shift)되는 매개변수를 키(key)라고 한다.
이 키를 알아야 복호화 작업을 수행할 수 있다.

ex) 카이사르 암호(Caesar cipher)
ABCDEFGHIJKLMNOPQRSTUVWXYZ
↓ 키 = 4글자 시프트
DEFGHIJKLMNOPQRSTUVWXYZABC

위의 경우에는 알파벳을 4글자 앞으로 옮기는 것이 키다.

A <=> D
B <=> E
C <=> F

평문 : I'll be there at 5.
암호문 : M'pp fi xlivi ex 5.


누군가가 이 키를 쉽게 유추할 수 있다면 메시지를 복호화하기도 쉽다.
키를 유추하는 작업은 보통 컴퓨터가 자동으로 수행한다.
올바른 키가 나올 때까지 수많은 경우의 수를 시도한다.

따라서 최신 암호화 알고리즘에서는 컴퓨터로도 키를 유추하는데 적어도 수년이 걸릴 정도의 복잡한 수학 문제를 활용해서 키를 만든다.
ex) 정수를 곱하는 작업(97×13,395＝1,299,315)은 매우 쉽지만, 반대로 계산 결과만 보고 원래의 두 정수를 찾기는 매우 어렵다.(1,299,315÷x＝y)

최신 암호화 알고리즘은 크게 두 가지 방식이 있다.
대칭키 알고리즘과 비대칭키 알고리즘

◾ 대칭형 암호(symmetric cryptography)
발신자가 암호를 푸는 비밀 키와 수신자가 암호를 푸는 비밀키를 똑같은 것으로 사용하는 방식

◾ 비대칭형 암호(asymmetric cryptography)
언제나 두 가지 유형의 키(공개키, 개인키)를 사용하는 방식
공개키로 암호화된 데이터는 오직 그에 대응하는 개인키로만 복호화할 수 있다.
한쪽만 개인키를 소유하고 있어 비대칭이라는 이름이 붙었다.
공개키 암호(public key cryptography)라고도 부른다.

ㆍ개인키(Private Key)
- 해당 암호화 시스템의 소유자만 알고 있는 비밀 키
- 서명과 데이터 복호화에 사용
- 중요한 점은 개인키는 외부에 노출되지 않으며, 오직 소유자만 가지고 있어야 한다는 것

ㆍ공개키(Public Key)
- 누구나 접근할 수 있고 배포할 수 있는 키
- 해당 개인키에 대응되는 키로, 그 개인키를 가진 사람만 해당 공개키로 암호화된 데이터를 복호화할 수 있다.
👉🏻 A의 공개키를 여러 사람이 알고 있어도, A만이 그 공개키로 암호화된 데이터를 자신의 개인키로 복호화할 수 있다.

ex) A가 B에게 보낼 메시지를 암호화하려면 B의 공개키를 사용해서 메시지를 암호화한다.
이렇게 암호화된 메시지는 B만이 자신의 개인키로 복호화할 수 있다.
ex) 반대로 A가 메시지에 서명을 하고 싶다면 A의 개인키로 서명을 한다. 이 서명은 A의 공개키를 통해 검증할 수 있다.
만약 다른 사람이 A의 공개키로 서명을 검증할 수 있다면, 그 메시지는 A가 보낸 것임을 확인할 수 있다.

비대칭형 암호를 사용하는 애플리케이션 중에는 수신자가 개인키 외에 암호 문구(passphrase)를 추가로 쓰는 것도 있다.
혹시 개인키가 유출되더라도 다른 사람이 그 개인키를 활용하지 못하게 하는 방법이다.

❗ 암호화와 서명 과정은 데이터 패킷 교환에서 패킷 데이터와 전소으이 신뢰성, 무결성, 진본성을 보장하는 데 꼭 필요한 절차이다.

🧿 전송 암호화(transport encryption)
- 데이터를 네트워크를 통해 전송할 때, 데이터를 암호화하여 제3자가 데이터를 엿보거나 탈취하지 못하도록 보호하는 기술

◾ 전송 암호화를 구현하는 대표적인 프로토콜은 TLS
- TLS는 HTTPS(HTTP over TLS)처럼 웹 브라우저와 서버 간의 통신을 암호화할 때 주로 사용되고, 데이터를 암호화하여 네트워크 상의 중간 노드(라우터, ISP 등)가 통신 내용을 볼 수 없게 한다.
- TLS는 중간에 네트워크를 중계하는 다른 노드가 있더라도 네트워크의 시작점과 끝점(종단점) 간의 통신만 암호화한다.
- 사용자에게 TLS를 제공할지 하지 않을지는 서버나 서비스 제공업체가 결정한다.
- 사용자가 스스로 TLS를 쓸 수 있는 방법은 없다.

◾ 전송 암호화의 한계
하지만 전송 암호화 방식에는 한계가 있다.
1. 의심스러운 인증 기관(CA)의 인증서 수락 위험
TLS는 신뢰할 수 있는 인증 기관(CA)이 발급한 인증서를 통해 서버의 신뢰성을 보장하는데
만약 악의적인 공격자가 신뢰할 수 없는 CA를 통해 유효한 인증서를 발급받으면, 사용자는 이를 합법적인 서버 인증서로 착각할 수 있다.
이렇게 되면 데이터가 공격자에게 노출될 위험이 있다.

2. 발신자가 연결을 완벽히 통제하지 못하는 경우
TLS는 주로 한 연결 간의 데이터 전송을 암호화하는데, 사용자가 다른 서비스와 데이터를 교환할 때, 두 서비스 간의 연결 수준이 동일하지 않으면 데이터가 충분히 보호되지 않을 수 있다.
예시) A 사용자가 TLS로 암호화된 이메일 서비스(X)를 사용하고, B 사용자가 다른 이메일 서비스(Y)를 사용한다면, X와 Y 서비스 간의 데이터 전송이 동일한 수준으로 암호화되지 않을 수 있다.

3. 데이터 저장의 한계
TLS는 전송 중인 데이터만 암호화하며, 전송이 완료된 이후 데이터는 암호화되지 않기 때문에, 서버에 저장된 데이터는 외부 공격에 노출될 가능성이 있다.

4. 중간자 공격(MITM, Man In the Middle attack)
공격자가 네트워크 통신을 가로채고, 자신이 수신자인 척하며 데이터를 탈취하거나 조작할 수 있다.

🧿 종단 간 암호화(E2EE, End-to-End Encryption)
데이터가 발신자에서 수신자까지 전달되는 동안 중간 과정의 누구도 데이터를 읽거나 수정할 수 없도록 설계된 암호화 방식
데이터는 오직 발신자와 수신자 간에만 해독할 수 있다.
중간에 위치한 서버, 네트워크 관리자, 심지어 서비스 제공자도 데이터를 읽을 수 없다.

◾ 전송 암호화가 가장 취약한 두 가지 시나리오
1. 네트워크 트래픽 관찰
전송 암호화를 사용하면 데이터의 내용을 보호할 수 있지만, 트래픽 메타데이터(예: 통신 주체, IP 주소, 사용자의 위치 정보)는 여전히 노출될 수 있다.
공격자는 트래픽을 분석해 누가 누구와 통신하고 있는지 또는 통신 빈도와 같은 민감한 정보를 알아낼 수 있다.
=> 해결책 : 익명성 보장
사용자는 트래픽 메타데이터를 숨기기 위해 익명성 네트워크를 사용해야 한다.

Tor 네트워크: IP 주소를 숨기고 네트워크 트래픽을 여러 노드를 거쳐 전달하여 사용자의 익명성을 보장한다.
VPN : 사용자의 IP 주소를 대체하여 통신 주체와 위치를 숨긴다.
익명 브라우저 : 트래커 차단, 브라우징 히스토리 보호 등을 통해 메타데이터 노출을 최소화한다.

2. 중개 서버에 저장된 데이터의 노출
전송 암호화는 전송 과정에서만 데이터를 보호한다. 그러나 데이터가 서버에 도달한 이후에는 보호되지 않는다.
ex) 이메일이 메일 서버에 저장되면 서버 관리자, 사법 기관, 또는 해커가 서버에 접근해 데이터를 읽을 수 있다.
이런 문제는 문제는 이메일, 채팅 기록, 클라우드 파일 등 데이터가 서버에 저장되는 대부분의 애플리케이션에 공통적으로 발생한다.
=> 해결책 : 종단 간 암호화(E2EE)
종단 간 암호화(E2EE)는 데이터가 발신자의 디바이스에서 암호화되고, 수신자의 디바이스에서만 복호화되도록 한다.
중간에 있는 서버는 데이터 내용을 볼 수 없다.
서버는 암호화된 데이터만 전달하며, 해독할 수 없다.

메신저 : Signal, WhatsApp 같은 E2EE 기반 앱은 메시지를 암호화하여 서버 관리자나 네트워크 관찰자가 내용을 읽을 수 없도록 한다.
E2EE 이메일 서비스 : ProtonMail, Tutanota는 이메일 데이터를 서버에 저장하기 전 암호화하여 안전성을 높인다.

◾ 가장 많이 활용되는 종단 간 암호화 알고리즘
- 더블 래칫(Double Ratchet) 알고리즘
시그널(Signal, 미국의 사생활 보호 메신저 애플리케이션) 같은 최신 메신저 앱에 많이 쓰이는 알고리즘

- OpenPGP/GPG
보통 이메일이나 파일 및 폴더 암호화에 쓰인다.
OpenPGP를 사용해서 이메일을 암호화할 때는 주로 비대칭 암호화 방식이 활용된다.
통신 파트너에게는 공개키를 공유한다.

🧿 저장 상태 데이터 암호화
지금까지 학습한, 네트워크를 통해 전송되는 데이터에 대한 암호화 방식뿐만 아니라
사용자가 제어할 수 없는 서버(클라우드 등)에 저장되어 이동하지 않는 데이터의 보안을 유지하는 암호화 방식도 중요하다.

암호화/복호화 암호 체계는 다양한 방식으로 작동하지만 기본적으로 키를 활용해서 입력 내용을 암호화된 출력 내용으로 또는 그 반대 방향으로 변환한다.

자신만이 데이터를 읽을 수 있도록 하려면 비밀번호가 필요한 고유 키를 생성하는 암호화 소프트웨어를 사용하면 된다.
이 키를 가지고 필요할 때 데이터를 복호화할 수 있다.

🧿 순방향 비밀성(Forward secrecy)
- 네트워크 통신 보안에서 중요한 개념으로, 암호화된 데이터를 더욱 안전하게 보호하기 위한 메커니즘
- 발신자와 수신자가 주고받는 암호화된 데이터가 나중에라도 복호화되지 않도록 설계된 보안 기능
- 발신자와 수신자의 장기 암호화 키가 훼손되더라도 과거의 통신 데이터를 복호화할 수 없다.

◾ 순방향 비밀성을 확보하는 방법
각 통신 또는 패킷 교환 시마다 하나 또는 여러 개의 연결되지 않은 단기 세션 키를 임의로 생성한다.
이 키는 전송할 당시에만 유효하다.
따라서 이 키로는 나중에 암호화된 메시지를 복호화할 수 없다.

◾ 순방향 비밀성 활용
IPSec, TLS 버전 1.3, OTR(Off-the-Record, 인터넷 메신저 서비스 대화 내용을 암호화하는 프로그램), 더블 래칫 알고리즘, 시큐어 셀(SSH, Secure Shell), Tor 등에 포함되어 있다.

 

 

 

📌 암호화 제한

암호는 암호화와 복호화를 수학적으로 더욱 안전하게 만들고자 하는 학문이자 프로세스
But
수학과 숫자는 불변하는 믿음직한 암호화 도구이지만
정책 규제, 프로토콜 자체의 기술적 약점, 프로그래밍 실수 또는 연산능력의 발전으로 보안과 프라이버시에 쓰이는 암호가 취약해질 수 있다.

공격자는 더욱 뛰어난 컴퓨터를 사용해서 암호화를 깨고 암호를 유추하는 시간을 단축할 수 있다.
몇몇 나라에서는 국내에서 암호화를 사용하는 것을 법적으로 제한하고 있다.
암호화기술의 수출입은 많은 나라에서 금지하고 있는 사항이다.

암호화를 풀어내기보다는 암호 프로토콜 자체를 무력화하는 것에 집중하는 전략도 있다.
미국국가안보국(NSA, National Security Agency)은 의도적으로 취약한 암호화를 표준화해서 암호화 프로토콜과 알고리즘에 개입하려고 했다.
이처럼 암호화를 취약하게 만드는 방법을 백도어(backdoor)라고 한다.
백도어는 '앞문'으로 들어가는 강력한 암호 키 대신 정식 절차를 거치지 않고 '뒷문'으로 우회해서 접근하는 것을 말한다.

🧿 중간자
사용자인 우리는 인터넷 프로토콜이 작동하는 방식을 잘 알지 못한다.
경로상 공격자(On Path Attack)나 중간자(MITM, Man In the Middle 또는 Machine in The Middle)는 이처럼 프로토콜 작동 방식이 잘 알려져 있지 않다는 점을 악용해 사용자 디바이스를 교란한다.

 

중간자 공격

◾ 중간자 공격
발신자가 수신자에게 메시지를 보낼 때, 공격자가 메시지를 중간에서 가로채는 것
공개키 암호가 이메일이나 채팅 애플케이션에 사용되는 경우에는 사용자가 첫 번쨰 메시지를 교환하기 전에 통신 상대방의 키를 검증하는 절차를 거치면 MITM으로부터 자신을 보호할 수 있다.

전송 암호화(HTTPS를 통해 웹사이트와 통신할 때 등)에 관한 MITM 공격은 수동으로 서버인증서를 확인하는 과정을 거쳐 막을 수 있다.

인터넷뱅킹에서는 2차 인증 채널을 제공하는 방식으로 사용자를 보호한다.
👉🏻 모바일 거래 인증번호(mTAN, Mobile Transaction Authentication Number)를 사용해 작업을 확인하도록 한다.
👉🏻 이중 인증(2FA, Two-Factor Authentication)이라고 부른다.

* 경로상 공격자
https://www.cloudflare.com/ko-kr/learning/security/threats/on-path-attack/

 

 

 

---

 

출처
읽자마자 IT 전문가가 되는 네트워크 교과서