defcon 님의 블로그

DNS(Domain Name Service)란?

DNS(Domain Name Service)는 도메인 이름을 IP주소로 변환해주는 시스템입니다. 인터넷 상에서 컴퓨터들은 서로를 IP 주소(ex. 192.0.2.1)로 식별하지만, 사람이 기억하고 사용하기는 어렵습니다. 그래서 사람이 이해하기 쉬운 도메인 이름(www.google.com)을 IP주소로 바꿔주는 역할을 합니다.

작동 방식

1. 사용자가 브라우저에 www.example.com을 입력
2. 컴퓨터는 DNS서버에 이 도메인의 IP 주소가 뭐야 라고 질의
3. DNS 서버는 해당 도메인의 IP wnthfmf ckwdktj dmdekq
4. 그 IP 주소로 웹사이트에 접속

DNS 계층 구조

1. Root DNS : 가장 상위
2. Top-Level Domain(TLD) : .com, .net, .kr같은 도메인
3. Second-Level Domain : example.com에서 example  qnqns
4. Subdomain : www.example.com에서 www  부분

DNS 쿼리 과정

1. DNS 클라이언트가 로컬 DNS Resolver에게 질의( Recursive Query)

• 사용자가 브라우저에  www.example.com 입력
• OS 또는 애플리케이션은 로컬 DNS 리졸버(일반적으로 ISP나  회사 내부 DNS 서버)에 "이 도메인의 IP주소를 알려줘" 라고 요청
• 요청자가 결과를 바로 원하며, 중간 단계는 관심없음
• 리졸버가 모든 작업을 대신 수행함

2. 로컬 리졸버가 루트 DNS 서버에 질의(반복적 질의)

• 리졸버는 먼저 루트 DNS 서버에 www.example.com의 정보를 요청
• 루트 서버는 직접 IP주소를 주지 않고 TLD 서버(.com)의 주소를 알려줌
• 루트 서버는 직접 해답을 주지 않고, "이걸 처리할 수 있는 서버는 저기야" 하고 경로만 알려줌

3. 리졸버가 권한 DNS 서버에 질의 (반복적 질의)

• 마지막으로 권한 DNS 서버에 http://www.example.com의 IP 주소를 요청
• 이 서버는 실제로 A 레코드(IPv4 주소) 또는 AAAA 레코드(IPv6 주소)를 보유하고 있으며, 요청한 IP 주소를 반환

4. 리졸버가 결과를 클라이언트에 반환

• 로컬 리졸버는 권한 서버에서 받은 IP 주소를 클라이언트에게 전달
• 클라이언트는 그 IP 주소를 이용해 웹 서버에 접속

대표적인 DNS 레코드 종류

DNS  레코드는 도메인 이름과 관련된 정보를 저장하는데이터 항목입니다.

도메인이 어떤 IP 주소를 가지고 있는지 메일서버는 어디인지 별칭은 무엇인지 등 다양한 정보를 표현합니다.

DNS 캐시

• 사용자가 www.example.com에 접속하면, IP 주소를 찾기 위해 DNS 질의 발생
• 이 결과를 일정시간 동안 캐시에 저장
• 동일한 도메인에 다시 접속할 경우, 캐시에 저장된 결과를 재사용하여 DNS 서버에 재질의하지 않음

캐시 저장 위치

TTL(Time To Live)

• TTL은 DNS 응답에 포함된 메타데이터로, 해당 레코드가 캐시에 얼마나 유지될지를 정의합니다.
• 예를 들어, A 레코드의 TTL이 3600 이라면 1시간(3600초)동안 캐시에 저장됩니다.
• TTL이 지나면 캐시는 무효화되고 다시 DNS  서버에 질의합니다.

DNS 캐시의 장점

캐시의 단점 및 주의사항

운영체제별 캐시확인 및 삭제 방법(로컬 캐시)

• Windows

ipconfig /displaydns      # 캐시 보기
ipconfig /flushdns        # 캐시 삭제

• macOS

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

• Linux

sudo systemd-resolve --flush-caches

1. PGP

PGP는 대칭키 암호화와 비대칭키 암호화를 함께 사용하는 하이브리드 암호 시스템입니다.

1991년 필 짐머만(Phil Zimmermann)이 처음 갭잘한 이후 전세계적으로 널리 사용되고 있습니다.

1) 비대칭키암호화(공개키/개인키) 

• 수신자는 공개키(Public Key)를 이메일 발신자에게 제공합니다.
• 발신자는 이 공개키로 이메일을 암호화합니다.
• 수신자는 자신만 가진 개인키(Private Key)로 이메일을 복호화합니다.

2) 대칭키 암호화

• 실제 메시지는 빠른 속도의 대칭키 방식으로 암호화됩니다.
• 이 대칭키 자체를 비대칭키로 다시 암호화하여 함께 전송합니다.

3) 디지털 서명

• 발신자는 메시지의 해시값을 자신의 개인키로 암호화하여 서명을 만듭니다.
• 수신자는 발신자의 공개키로 서명을 검증함으로써, 무결성과 인증을 확보합니다.

PGP 활용

키 관리 방식

PGP는 중앙 인증 기관(CA)를 사용하지 않고 사용자가 서로의 키를 직접 인증하는 웹 오브 트러스트(Web Of Trust) 방식을 사용합니다. 사용자는 자신이 신뢰하는 사람의 키를 서명해줌벼, 이를 통해 간접적인 신뢰구조를 형성합니다.

암호 알고리즘 구성

2. PEM

PEM은 원래 이메일을 암호화하고 서명하는 표준으로 제안되었지만 오늘날 주로 인증서, 키, 암호화 데이터를 저장하고 전송하는 형식으로 사용되고 있습니다.

텍스트 기반의 Base64 인코딩 형식을 사용합니다.

Base64 : 바이너리 데이터 -> ASCII 문자로 변환하는 인코딩 기법

-----BEGIN <LABEL>-----
(base64 encoded data)
-----END <LABEL>-----

3. S/MIME

S/MIME(Secure/Multipurpose Internet Mail Extendsions)는 이메일 메시지의 기밀성, 무결성 인증, 부인방지를 보장하는 암호화 및 디지털 서명 표준입니다.

특히 S/MIME은 PGP와 달리 X.509 인증서를 기반으로 동작하며 표준 이메일 ㅍ포맷인 MIME 위에 보안을 덧붙이는 방식 입니다.

Microsoft Outlook, Apple Mail, thunderbird 등 주요 이메일 클라이언트는 S/MIME을 기본적으로 지원하며, 기업은 내부 CA 또는 외부 CA를 통해 인증서를 배포하고 관리합니다.

이메일 MIME 구조

Content-Type: multipart/signed;
    protocol="application/pkcs7-signature";
    micalg=sha-256;
    boundary="----SignedBoundary"

------SignedBoundary
Content-Type: text/plain; charset="utf-8"

안녕하세요, 이 메일은 서명되어 있습니다.

------SignedBoundary
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMAsG...
(생략된 서명 데이터)

------SignedBoundary--

암호화된 이메일 S/MIME 구조

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
    name="smime.p7m"
Content-Transfer-Encoding: base64

MIIBOwYJKoZIhvcNAQcDoIIBLzCCA...
(암호화된 전체 메시지 - Base64 인코딩)

• 전체 메시지 내용이 암호화된 PKCS#7 형식
• 수신자는 자신의 개인키로 복호화해야 메시지를 볼 수 있음
• 실제 이메일 내용은 복호화 후에만 확인 가능

cron 이란?

리눅스에서 cron은 정기적인 작업을 자동으로 실행할 수 있도록 도와주는 시간 기반의 작업 스케줄러입니다.

시스템관리자나 사용자들이 백업, 로그정리, 자동업데이트 등 반복적인 작업을 자동화할 때 주로 사용합니다.

기본 개념

• cron 데몬은 백그라운드에서 실행되며, 설정된 스케줄에 따라 지정된 명령어를 자동으로 실행합니다.
• 스케줄은 crontab 파일에 등록하며, 사용자별로 설정할 수 있습니다.

crontab 문법

crontab 파일은 다음과 같은 형식으로 작업을 등록합니다.

분 시 일 월 요일 명령어

0 3 * * * /home/user/backup.sh

매일 새벽 3시에 /home/user/backup.sh 실행

crontab 명령어

예제

로그 확인

cron 실행 결과는 일반적으로 메일로 발송되거나 로그파일에 저장됩니다.

• 로그 확인

cat /var/log/cron  # RHEL/CentOS
journalctl -u cron.service  # Debian/Ubuntu

• 출력 리디렉션 예시

* * * * * /home/user/script.sh >> /home/user/log.txt 2>&1

리눅스 작업스케줄러 cron이 정보보호 관점에서 중요한 이유

1. 자동화된 보안 작업 수행

• 보안 패치 자동화
  • 정기적으로 보안 업데이트 스크림ㅂ트를 실행하여 시스템을 최신 상태로 유지 가능
    • 취약점 노출 시간 최소화
• 로그 백업 및 분석
  • 로그파일을 주기적으로 수집, 백업 또는 정리하여 보안감사를 위한 증적 보존 가능
• 데이터 암호화 및 전송
  • 중요한 파일을 자동 암호화하거나 외부 서버로 안전하게 전송하는 작업 자동화 기능

2. 악용될 경우 보안 위협 요소

• 백도어로 악용 가능
  • 공격자가 crontab에 악성 명령어를 등록하면 지속적인 악성행위가 자동 실행됨
    ex. reverse shell,  정보 탈취 스크립트 등
• 탐지 우회
  • cron은 백그라운드에서 조용히 작동하기 때문에 운영자도 눈치채기 어려움
  • 타임 기반으로 실행되므로 흔적 없이 정기적으로 활동 가능
• 권한문제
  • 루트 권한으로 실행되는 cron 작업은 시스템에 치명적인 영향을 줄 수 있음
    • 설정 실수 또는 권한 오용 시 전면적인 시스템 훼손 가능

정보보호 관점에서의 cron 관리 포인트

nmap이란?

nmap은 네트워크 보안 및 관리에서 널리 사용되는 오픈소스도구로 주로 포트스캐닝, 호스트 탐지, 서비스 및 운영체제 식별, 취약점 진단 등에 사용됩니다.

강력하면서도 유연하게 구성이 가능하고 보안전문가 뿐만 아니라 시스테 ㅁ관리자도 자주 활용합니다.

nmap의 주요 기능

대표적인 nmap 사용 예시

1. 기본 포트 스캔

nmap 192.168.0.1

대상 호스트의 TCP 포트 상태를 기본적으로 확인합니다.

2. 범위 스캔

nmap 192.168.0.1-50

여러 호스트에 대해 동시에 스캔합니다.

3. 서비스 버전 탐지

nmap -sV 192.168.0.1

4. 운영체제 탐지

nmap -O 192.168.0.1

5. Nmap Scripting Engine 사용 예

nmap --script=vuln 192.168.0.1

알려진 취약점 스크립트를 이용해 간단한 취약점 진단을 수행합니다.

포트 스캔 방식의 종류

기본 스캔 옵션

탐지 및 식별 옵션

Nmap 스크립트 엔진(NSE)

스텔스 스캔 

기본 원리(TCP 3-Way Handshake)

정상적인 TCP 연결은 다음의 3단계를 거칩니다.

1. 클라이언트 -> 서버 : SYN
2. 서버 -> 클라이언트 : SYN-ACK
3. 클라이언트 -> 서버 : ACK

스텔스 스캔 방식(SYN Scan)

1. 클라이언트 -> 서버 : SYN
2. 서버 -> 클라이언트:
   • SYN-ACK -> 포트 열림 ( Open)
   • RST -> 포트 닫힘( Closed)
3. 클라이언트 -> 서버 :
   • 응답없이 RST를 보내 세션을 종료(세션 완성 안함)

즉, 연결을 완전히 수립하지 않기 때문에 흔적이 덜 남고 IDS나 로그 시스템에서 정상적인 연결로 보이지 않을 수 있음

주요 스텔스 스캔 옵션

nmap -sS 192.168.0.1          # SYN 스텔스 스캔
nmap -sF 192.168.0.1          # FIN 스캔
nmap -sN 192.168.0.1          # NULL 스캔
nmap -sX 192.168.0.1          # Xmas 스캔
nmap -sA 192.168.0.1          # ACK 스캔

/etc/passwd

/etc/passwd 파일은 리눅스 및 유닉스 계열 운영체제에서 사용자 계정정보를 저장하는 텍스트파일입니다. 각 사용자의 로그인 정보를 포함하고 있으며 시스템이 로그인 요청을 처리할 때 참고합니다.

파일 형식

이 파일은 콜론으로 구분된 여러 필드로 구성되어 있다. 각 줄을 하나의 사용자 계정을 나타냅니다.

username:password:UID:GID:comment:home_directory:shell

각 필드에 대한 설명

예시

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
user1:x:1000:1000:홍길동:/home/user1:/bin/bash

주요 사항

• 이 파일은 모든 사용자가 읽을 수 있다(644 권한)
• password  필드는 보안을 위해 x로 대체되며, 실제 암호 해시값은 /etc/shadow에 저장됩니다.
• UID가 0이면 슈퍼 유저(root) 권한을 가집니다.
• UID가 1000 이상이면 일반 사용자 계정입니다.
• 시스템 계정(ex. daemon, bin, nobody)은 로그인하지 못하게 보통 /usr/sbin/nologin 셸을 사용합니다.
• /etc/passwd 파일 자체는 암호를 포함하지 않지만 여전히 조작될 경우 심각한 보안 위협이 됩니다.
• 실수로 수정하지 않도록 vipw 명령어를 사용하여 안전하게 편집하여야 한다.

/etc/shadow

/etc/shadow 파일은 리눅스 및 유닉스 시스템에서 사용자 계정의 암호(비밀번호) 정보를 저장하는 보안파일입니다. 이 파일은 /etc/passwd 보다 더 민감한 정ㅂ모를 포함하므로 접근이 제한됩니다.

/etc/shadow 파일 개요

• 목적 : 각 사용자 계정의 암호 해시값 및 만료 정보를 저장
• 권한 : 보통 -rw-r-----, 소유자 root, 그룹 shadow

ls -l /etc/shadow
-rw-r----- 1 root shadow 1234 Jun  3 10:00 /etc/shadow

파일 형식

콜론으로 구분된 필드로 구성

username:password:last_change:min:max:warn:inactive:expire:reserved

예시

user1:$6$sdf9SdFj2K$1dUeJz...:19123:0:99999:7:::
daemon:*:19000:0:99999:7:::

password 필드의 포맷

$id$salt$hashed_password

알고리즘 식별자($id)

대부분의 현대 리눅스 배포판은 SHA-512($6$)를 기본으로 사용합니다.

$6$G7WvEtgL$XSnX0MZKmWR5fb7wgy...JELN9EPsqxv1h3ujA19nHDnI3A1

• $6$ -> SHA-512 알고리즘
• G7WvEtgL -> salt (8자리 이상, 시스템에 따라 다름)
• XSnX0MZK... -> SHA-512 해시 결과

pwconv, pwunconv 명령어

pwconv, pwunconv는 리눅스에서 비밀번호 정보를 /etc/passwd와 /etc/shadow 사이에서 동기화하거나 변환하는데 사용되는 명령어입니다.

pwconv

• /etc/passwd -> /etc/shadow로 비밀번호 정보를 이동
• /etc/passwd에 저장된 암호필드를  x로 변경
• /etc/shadow 파일을 생성하거나 갱신

pwunconv

• /etc/shadow에 있던 암호 해시값을 /etc/passwd로 다시 이동
• /etc/shadow 시스템 비활성화
• Shadow password system을 비활성화

2> /dev/null은 유닉스/리눅스 쉘에서 자주 사용되는 리디렉션(Redirection) 문법입니다.

기본 개념

표준 입출력(Stream)

유닉스 계열 운영체제에서는 프로그램 실행 시 다음과 같은 3가지 기본 스트림이 자동으로 생성됩니다.

기본 리디렉션 문법

• 출력 리디렉션( > )

echo "Hello" > output.txt

"Hello"라는 출력을 output.txt 파일에 저장(기존내용은 덮어씀)

• 출력 덧붙이기( >> )

echo "More text" >> output.txt

기존 output.txt에 "More text"를 추가함(덮어쓰기 X)

• 에러 리디렉션( 2> )

ls not_exist_file 2> error.log

에러 메시지를 error.log 파일에 저장

• 표준 입력 리디렉션( < )

wc -l < file.txt

file.txt 파일을 표준 입력처럼 사용해서 wc -l 명령어에 전달

2> /dev/null의 해석

• 2 : 표준 오류(stderr)을 의미합니다.
• > : 리디렉션 연산자입니다. "어디론가 보내라"는 의미입니다.
• /dev/null : 특수한 장치 파일로, 모든 데이터를 버리는 쓰레기통입니다. 여기에 쓰여진 데이터는 사라짐

즉, 2 > /dev/null의 의미는 표준 오류 스트림(에러 메시지)를 /dev/null로 보내서 버려라 입니다. 즉, 에러메시지를 화면에 출력하지 않고 없애버리는 것입니다.

활용 예시

ls not_exist_file 2> /dev/null

• ls not_exist_file 은 존재하지 않는 파일을 보려고 해서 에러가 발생합니다.
• 2> /dev/null 덕분에 에러 메시지는 화면에 나타나지 않습니다.

확장 사용 : &>, >/dev/null 2>&1

command > /dev/null 2>&1

• > /dev/null : 표준 출력(stdout)을 버림
• 2>&1 : 표준 오류(stderr)를 표준 출력(stdout)과 동일한 곳으로 보냄(즉, /dev/null)
• 결론 : 모든 출력(정상 + 에러)을 전부 버림

size_t란?

size_t는 부호없는 정수형(unsigned integer type)으로 표준 라이브러리에서 메모리크기나 개수를 나타내기 위해 사용하는 타입니다.

stddef.h, stdio.h, stdlib.h, string.h 등의 다양한 헤더파일에서 사용되며, 그 정의는 다음과 같습니다.

typedef unsigned int size_t; //시스템에 따라 다름

하지만 실제 정의는 컴파일러와 시스템 아키텍처에 따라 달라지며, 32bit 시스템에서는 unsigned int, 64bit 시스템에서는 unsigned long 혹은 unsigned long long 일 수 있습니다.

주요 사용 예시 :

• malloc, calloc, realloc 등의 함수에서 메모리 크기를 인자로 받을 때
• sizeof 연사자의 겨로가 타입
• 문자열 관련 함수(strlen, memcpy, memset)에서 크기나 길이를 나타낼 때

size_t length = strlen("hello");
void* ptr = malloc(sizeof(int) * 10);

size_t를 사용했을 때의 장점

1. 플랫폼 독립성

• 32bit/64bit 환경에 따라ㅏ 자동으로 적절한 크기의 타입이 설정됨
• 크로스 플랫폼 코드를 작성할 때 유리

2. 메모리 크기 표현에 최적화

• 메모리 크기와 관련된 연산에서는 부호가 필요 없기 때문에 unsigned로 정의된 size_t가 적절
• 음수가 될 수 없는 값을 표현할 때 안전

3. 오버플로우 방지에 비교적 유리

• 배열 크기나 인덱스의 최대값까지 안전하게 표현 가능(signed 보다 큰 값 표현 가능)

4. 표준 라이브러리와의 일관성

• malloc, strlen, sizeof 등과의 타입 호환성이 맞지 않아서 경고나 오류없이 사용 가능

size_t의 단점 및 주의점

1. 부호가 없으므로 음수 표현 불가

• int 처럼 -1 같은 음수를 표현할 수 없음
• 예를들어, 오류를 -1로 반환하는 로직에는 사용할 수 없음

size_t result = -1 // 이 경우 result는 매우 큰 수가 됨

2. 부등호 비교시 버그 유발 가능

• int와 혼합된 연산 또는 비교 시 예기치 않은 결과 발생 가능

iont a = -5;
size_t b = 10;
if(a < b) // 경고없이 참이지만, 논리적으로 이상할 수 있음

3. 디버깅 시 혼란

• 출력할 때 %zu를 사용해야 ㅎ마ㅕ, 잘못 출력하면 값이 이상하게 보일 수 있음

printf("%zu\n", size_var); // 올바른 방법

4. 이식성이 있으나, 직관성은 떨어짐

• 초보자 입장에서 unsigned int와 달리 직관적으로 이해하기 어려울 수 있음

OCSP란?

Online Certificate Status Protocol은 디지털 인증서의 실시간 유효성 검증을 위한 인터넷 프로토콜입니다. 기존의 CRL(Certificate Revocation List) 방식이 가지는 단점을 보완하기 위해 만들어졌습니다.

RFC 6960에서 표준으로 정의되었으며, 주로 웹 브라우저, 메일 클라이언트, VPN 클라이언트 등에서 사용됩니다.

OCSP의 필요성

• 기존 방식 : CRL의 한계
  • CRL은 CA에서 정기적으로 폐기된 인증서를 목록으로 배포
  • 수백 KB ~ 수 MB 이상인 경우도 있어 다운로드 시간이 오래 걸림
  • 폐기된 인증서 정보가 반영되기 까지 시간 지연 발생
  • 네트워크 부하 및 클라이언트 자원 소비 증가
• 개선 방식 :OCSP의 장점
  • 클라이언트는 특정 인증서의 상태만 요청
  • 응답크기가 매우 작음(수백 바이트 ~ 수 KB)
  • 실시간 상태 확인 가능
  • 서버-클라이어트간 빠른 통신

OCSP의 작동 원리

• 주요 참여자
  • OCSP Client : 인증서 상태를 확인하고자 하는 주체(ex. Web Browser)
  • OCSP Responder : 인증서 상태 정보를 제공하는 서버(CA가 직접 운영하거나 위임)
  • CA : 인증서를 발급하고 상태 정보를 OCSP Responder에 전달
• 요청/응답 흐름
  1. 클라이언트가 받은 인증서의 상태를 확인하고자 함
  2. 해당 인증서의 Authority Information Access (AIA) 확장에서 OCSP URL 확인
  3. OCSP 요청 생성(인증서 일련번호 포함)
  4. OCSP 서버(Responder)에 요청 전송(보통 HTTP)
  5. 서버가 다음 중 하나의 응답 변환
     • good : 인증서 유효
     • revoked : 인증서 폐기됨
     • unknown : 상태 알 수 없음
  6. 클라이언트는 이 정보를 기반으로 연결을 계속하거나 중단

CertID: 0x1234ABCD
Status: good
This Update: 2025-05-31 10:00:00
Next Update: 2025-05-31 12:00:00
Signature: (CA 서명)

보안강화 : OCSP Stapling

• OCSP는 실시간 서버 조회가 필요하므로 다음과 같은 문제점이 발생
  • OCSP 서버 장애 -> 인증 실패
  • 프라이버시 이슈 : 누가 어떤 사이트에 접속했는지 추적 가능
  • 지연 발생 : HTTPS 연결 성능 저하

이러한 문제를 해결하기 위하여 OCSP Stapling 기능이 도입되었다.

• 개념
  • 웹서버가 미리 OCSP  응답을 가져와 자신의 TLS 인증서와 함께 스테이플해서 클라이어트에게 전달
  • 클라이언트는 OCSP 서버에 직접 요청하지 않고도 상태 확인 가능
• 장점
  • 빠른 연결(OCSP 서버 연결 불필요)
  • 프라이버시 보호
  • CA부하 감소

OCSP vs CRL 비교 정리

실무 활용 예시

• 웹 브라우저 : HTTPS 접속 시 OCSP로 인증서 상태 확인
  (Chrome, Firefox, Edge 등 대부분 OCSP 또는 Stapling 지원)
• 메일 클라이언트 : S/MIME 인증서 검증
• VPN 클라이언트 : 사용자 인증서 상태 확인
• 서버 인증 : 인증서 폐기 되었는지 판단하여 연결 거부
  
  

자체 OCSP 서버를 구현하기 위한 구성 요소

구현방식

1. OpenSSL 기반 OCSP Responder

• OpenSSL에는 간단한 OCSP 서버 기능이 내장되어 있음
• 테스트용 또는 내부 환경에 적합

openssl ocsp \
  -port 2560 \
  -index index.txt \
  -CA ca.crt \
  -rsigner ocsp-cert.pem \
  -rkey ocsp-key.pem \
  -text

• index.txt : CA에서 발급한 인증서 상태DB
• ocsp-cert.pem : OCSP 응답에 사용할 인증서(CA가 발급한 OCSP 전용 인증서)

2. EJBCA

• JAVA 기반의 완전한 오픈소스 PKI 서버
• OCSP 기능 포함
• 대규모 배포 및 고급 설정 가능

3. Dogtag Certificate System

• RedHat이 주도하는 PKI 솔루션
• OCSP 포함

PKI(Public Key Infrastructure)란?

PKI는 암호화 기술을 이용해 디지털보안을 제공하는 체계입니다.

주로 인터넷과 같은 개방된 네트워크에서 신원확인, 데이터무결성보장, 기밀성 유지, 부인방지 기능을 제공하기 위해서 사용됩니다.

비대칭키 암호화 기술을 기반으로 하며, 공개키와 개인키의 쌍을 사용하여 보안을 제공합니다.

• 공개키(Public Key) : 누구나 접근 가능한 키
• 개인키(Private Key) : 소유자만 알고 있는 비밀키

PKI는 이 키쌍을 신뢰할 수 있는 방식으로 관리하고, 디지털 인증서를 통해 공개키가 특정 사용자 또는 조직에 속해있음을 보증합니다.

PKI의 주요 구성 요소

1. CA(Certificate Authority, 인증 기관)

• 역할
  • CA는 공개키 인증서를 발급, 서명, 관리하는 가장 핵심적인 기관입니다. 사용자나 시스템이 제출한 공개키에 대해 신원을 확인한 후 이를 디지털 인증서로 만들어 서명합니다. 이 인증서는 해당 공개키가 특정 개인, 조직, 도메인 등에 속함을 증명합니다.
• 상세 기능
  • 디지털 인증서 생성 및 서명
  • 인증서 갱신 및 폐기
  • 신뢰 체계 형성(루트 CA, 중간 CA 체계)
  • 정책(CPS : Certification Practice Statement) 관리
• 예시
  • 상업용 CA : DigiCert, GlobalSign, Sectigo
  • 공공기관 CA : 한국정보인증, KISA 루트 CA
  • 오픈소스 루트 CA : Let's Encrypt

2. RA(Registration Authorith,  등록기관)

• 역할
  • RA는 CA의 위임을 받아 인증서 요청자의 신원을 검증하는 기관입니다. CA가 인증서를 발급하기 전에 RA가 사용자 또는 시스템의 신원과 정보를 확인하고 그 결과를 CA에 전달합니다.
• 상세 기능
  • 인증서 신청 접수 및 사용자 신원 확인
  • 신원확인 절차 수행(여권, 주민등록증, 도메인 소유권 확인 등)
  • CSR(Certificate Signing Request) 처리
  • CA와의 통신을 통한 발급 요청
• 비고
  • RA는 보통 별도의 기관이 될 수 있고 CA 내부에 통합될 수도 있음
  • 대규모 조직에서는 내부 RA를 통해 인증서 자체를 관리

3. Ceritificate(디지털 인증서)

• 역할
  • 디지털인증서는 공개키와 해당 소유자의 정보를 포함하며, CA의 디지털 서명이 포함되어 있어 인증서의 무결성과 신뢰성을 보장합니다. 이를 통해 해당 공개키가 누구의 것인지 신뢰할 수 있습니다.

4. CRL(Ceritificate Revocation List, 인증서 폐지 목록)

• 역할
  • CRL은 폐기된 인증서들의 목록입니다. 인증서가 유효기간 내라도, 유출되었거나 사용 중단되었을 경우에는 신뢰할 수 없게 됩니다. 이런 인증서를 리스트에 올려서 수신자가 확인하고 무효 인증서를 거를 수 있게 합니다.
• 상세 기능
  • 인증서의 유효성 검증 시 사용
  • 주기적으로 CA가 업데이트함
  • 인증서 일련번호 깁만 목록 제공
• 한계
  • 최신 CRL 확인을 위한 시간 지연
  • 해결책 : OCSP(Online Ceritificate Status Protocol) 사용 -> 실시간 검증 가능

5. PKI 사용자(Entity)

• 역할
  • PKI를 사용하는 사람, 소프트웨어, 디바이스 등을 통칭합니다. 이들은 CA로부터 발급받은 인증서를 사용하여 암호화, 서명, 인증 등의 작업을 수행합니다.
• 예시
  • 사용자의 이메일 클라이언트(S/MIME 사용)
  • 웹 서버(HTTPS 적용을 위한 SSL 인증서 사용)
  • IoT 장비(기기간 인증 및 보안 통신)
  • 기업의 VPN 클라이언트(사용자 인증을 위해 인증서 사용)
• 종류
  • End-entity : 최종 사용자, 서버, 클라이언트 등
  • Application : 소프트웨어 모듈 또는 웹 서비스 등

6. Repository(저장소)

• 역할
  • 인증서와 CRL 등 관련 정보를 저장하고 사용자 및 시스템이 이를 검색하고 검증할 수 있게 해주는 저장소 역할을 합니다. 일반적으로 인터넷에 공개되어 누구나 접근할 수 있도록 설정됩니다.
• 내용물
  • CA의 루트 인증서 및 중간 인증서
  • 사용자 인증서
  • CRL(또는 OCSP Responder 정보)
  • 인증서 정책 문서(CPS 등)

인증서의 구성 요소

디지털 인증서는 보통 X.509 표준을 따릅니다. 주요 항목은 다음과 같습니다.

• 사용자 이름, 이메일 주소, 조직 등 식별 정보
• 공개키
• 인증서 발급자 정보(CA)
• 유효기간
• 일련번호
• 서명 알고리즘
• CA의 디지털 서명

PKI작동원리

1.인증서 발급과정

1. 사용자가 인증서를 요청(CSR : Certificate Signing Request 생성)
2. RA가 사용자의 신원을 확인
3. CA가 확인된 사용자에게 인증서 발급
4. 사용자는 자신의 공개키가 포함된 인증서를 받음

2. 데이터 암호화 및 복호화

• 기밀성(Confidentiality): 송신자가 수신자의 공개키로 암호화 -> 수신자는 자신의 개인키로 복호화
• 무결성 및 부인방지(Integrity & Non-repudiation) : 송신자가 자신의 개인키로 서명 -> 수신자가 송신자의 공개키로 서명 검증

3. 인증서 검증

1. 인증서를 수신하면, 인증서에 서명한 CA의 공개키로 서명을 검증
2. 인증서의 유효기간을 확인
3. CRL이나 OCSP를 통해 인증서 폐지 여부 확인

PKI가 제공하는 보안기능

PKI의 실제 활용 예시

• HTTPS / SSL 인증서 : 웹사이트의 신원을 보장하고 안전한 통신 제공
• 전자서명 : 문서 위변조 방지 및 서명자 신원 확인
• 이메일 암호화(S/MIME) : 이메일 기밀성과 무결성 보장
• VPN 및 무선 네트워크 인증
• IoT 기기 인증 및 통신 보안

GMAC은 Galois Message Authentication Code의 약자로 주로 GCM(Galois/Counter Mode)이라는 블록암호 운영모드에서 사용하는 인증 코드 생성 방식입니다.

GMAC는 데이터의 무결성과 진위확인을 위해 사용됩니다.

GCM에서 암호화는 하지 않고 인증만 수행하는 경우를 GMAC이라고 부릅니다.

GMAC 동작과정

GMAC은 기본적으로 블록암호 알고리즘과 Galois 필드(GF(2^128))에서의 수학 연산을 기반으로 합니다. 아래는 GMAC 동작과정을 간단하게 설명한 것입니다.

입력값

1. 비밀키(K) : 블록암호 알고리즘에 사용하는 키
2. 초기화 벡터(IV) : Nonce, 길이는 일반적으로 96비트
3. 인증할 메시지(A) : 암호화하지 않고 인증만 수행할 데이터

동작절차

• 해시 서브키(H) 생성
  • 블록암호 알고리즘으로 128비트의 0 블록을 암호화하여 해시키 H = K(0128)를 생성
  • 이 키는Galois 필드 연산에 사용됩니다.
• GHASH 함수 준비
  • GMAC의 핵심은 GHASH라는 함수이니다.
  • GHASH는 해시 키 H와 입력 메시지 A를 Galois 필드에서 곱셈 및 덧셈하여 해시값을 만듭니다.
  • 메시지 A는 128bit 블록으로 패딩되어 처리됩니다.
• Y0 생성(IV 처리)
  • 96bit IV의 경우 Y_0 = IV || 0x00000001
  • 그 외의 경우 GHASH를 사용하여  Y_0 계산
• 태그 생성
  • GHASH 결과 S를 얻은 후 Tag = K(Y_0) ⊕ S 계산
  • 이 최종 결과가 GMAC 태그입니다. 이 값은 메시지의 무결성을 보장합니다.

function GMAC(Key, IV, AAD):
    # 1. 해시 서브키 H 계산
    H := AES_Encrypt(Key, 0^128)

    # 2. IV 처리 → 초기 counter 블록 Y₀ 계산
    if length(IV) == 96 bits:
        Y0 := IV || 0x00000001
    else:
        Y0 := GHASH(H, [], IV)  # IV를 GHASH로 처리하여 Y0 생성

    # 3. AAD에 대한 해시 계산
    S := GHASH(H, AAD)

    # 4. 최종 태그 계산
    Tag := AES_Encrypt(Key, Y0) ⊕ S

    return Tag

보조함수 GHASH

function GHASH(H, AAD):
    X := 0^128  # 초기값

    # AAD를 128비트 블록으로 나눔 (패딩 포함)
    AAD_blocks := split_and_pad(AAD, 128)

    for block in AAD_blocks:
        X := (X ⊕ block) × H  # 곱셈은 GF(2^128) 상에서 수행

    return X

GCM과 GMAC의 입력 구성