Eraser

Eraser

[Security] PKI

13 분 소요


들어가며

세상 모든 것은 신뢰 기반으로 돌아간다. 화폐도, 법도, 모든 거래가 약속과 신뢰 위에 성립된다.

현실 세계의 신뢰

은행 창구에서는 신분증으로, 부동산 계약에서는 등기부등본으로, 공항에서는 여권으로 신원을 확인한다. 명품 가방은 정품 인증서로, 약품은 식약처 승인 마크로 진위를 확인한다. 회사 출입에는 사원증이, 의료 기록 열람에는 의사 면허가 필요하다.

디지털 세계의 신뢰

디지털 세계도 마찬가지다.

  • “이것이 진짜인가?” → 서버 인증서, 코드 서명
  • “당신이 누구인가?” → 클라이언트 인증서, SSH 키, OAuth
  • “권한이 있는가?” → RBAC, IAM, ServiceAccount
  • “변조되지 않았는가?” → 디지털 서명, 해시 검증
  • “언제 만들어졌는가?” → 타임스탬프

신뢰 체계의 본질

신뢰 체계의 본질은 신뢰의 근원이 있고, 그 근원이 보증한 것을 우리는 믿는다는 것이다.

현실 세계 디지털 세계
정부 (신뢰의 근원) Root CA (신뢰의 근원)
신분증 발급 인증서 발급
화폐 발행 암호화 보장
법률 집행 신원 검증

현실에서 “이 종이가 만 원의 가치가 있다”는 집단적 믿음이 있듯이, 디지털 세계에서는 “이 공개키가 google.com의 것이다”라는 집단적 믿음이 있다.


PKI는 디지털 세계에서 신뢰를 구축하기 위한 인프라다.


PKI란

개념

PKI(Public Key Infrastructure)는 공개키를 안전하게 배포하고 관리하기 위한 체계다.

필요성: 중간자 공격의 예방

공개키 배포 시 해당 공개키가 정말 상대방의 것인지 검증할 수 없다면, 공격자가 자신의 공개키를 대신 전달하여 통신을 가로챌 수 있다. 이것이 중간자 공격(MITM, Man-in-the-Middle Attack)이다.

구체적으로, 클라이언트가 서버의 공개키를 받았을 때 이 공개키가 정말 해당 서버의 것인지 확인할 방법이 없다면, 공격자가 중간에서 자신의 공개키를 클라이언트에게 전달하고, 서버에게는 자신이 클라이언트인 것처럼 행세할 수 있다. 클라이언트는 공격자의 공개키로 데이터를 암호화하여 전송하고, 공격자는 이를 복호화한 뒤 다시 서버의 공개키로 암호화하여 전달한다. 이렇게 되면 클라이언트와 서버는 안전하게 통신한다고 믿지만, 실제로는 모든 데이터가 공격자를 거쳐간다.

중간자 공격 시나리오

[정상적인 통신]
클라이언트 ←──────────→ 서버
        (서버의 공개키)

[중간자 공격]
클라이언트 ←──────→ 공격자 ←──────→ 서버
       (공격자 공개키)  (공격자가 서버로 위장)
  1. 클라이언트가 서버 공개키를 요청
  2. 공격자가 중간에서 자신의 공개키를 클라이언트에게 전달
  3. 클라이언트는 공격자의 공개키로 데이터 암호화
  4. 공격자는 자신의 개인키로 복호화하여 내용 확인
  5. 공격자가 다시 서버의 공개키로 암호화하여 서버에 전달
  6. 클라이언트와 서버는 안전하다고 믿지만, 모든 데이터가 공격자를 거침

PKI의 해결책

PKI는 신뢰할 수 있는 CA가 “이 공개키는 이 주체의 것이 맞다”고 보증하는 인증서를 발급함으로써 이 문제를 해결한다.


구성 요소

CA (Certificate Authority)

인증서에 서명하여 공개키의 소유자를 보증하는 기관이다.

인증서 (Certificate)

공개키와 소유자 정보, CA의 서명을 포함한 문서. 대부분 X.509 형식을 사용한다.

  • X.509: ITU-T에서 정의한 표준으로, 인터넷 PKI에서 사실상 표준
  • OpenPGP: PGP/GPG에서 사용하는 형식 (이메일 암호화 등)

웹 브라우저와 HTTPS에서는 주로 X.509를 사용한다.

신뢰 저장소 (Trust Store)

신뢰할 수 있는 CA Root 인증서 목록. 브라우저와 운영체제에 사전 내장되어 있다. 다음과 같은 위치에서 확인해 볼 수 있다.

  • Linux: /etc/ssl/certs/ca-certificates.crt
  • Windows: certmgr.msc → Trusted Root Certification Authorities
  • macOS: Keychain Access → System Roots

CRL/OCSP

폐기된 인증서 목록 또는 인증서 상태 확인 프로토콜이다.

  • CRL (Certificate Revocation List): 폐기된 인증서 목록
  • OCSP (Online Certificate Status Protocol): 인증서 상태 확인 프로토콜


PKI의 본질적 역할

PKI의 본질적 역할은 신원 확인과 무결성 보장이다. 다양한 분야에서 활용된다.

분야 검증 대상 목적
코드 서명 소프트웨어 개발자 신원, 무결성
이메일 서명 발신자 신원, 위조 방지
문서 서명 계약서 법적 효력
VPN 네트워크 엔드포인트 터널 인증
블록체인 거래 소유권 증명
IoT 디바이스 기기 진품 확인
의료 기기 명령 발신자 안전성
전자여권 신분증 위조 방지
타임스탬프 시간 존재 증명


PKI 구분

PKI는 크게 공개 PKI와 사설 PKI로 구분된다.

비교표

구분 공개 PKI 사설 PKI
신뢰 기반 브라우저/OS 사전 내장 Root CA 조직 내부에서 수동 배포
운영 주체 상업적 CA (DigiCert, Let’s Encrypt) 각 조직/시스템 (Kubernetes, 기업)
사용 사례 공개 웹사이트, 이메일 서명, 코드 서명 내부망, VPN, IoT, 마이크로서비스


공개 PKI

공개 PKI는 인터넷 전체의 신뢰 체계다. 우리가 매일 사용하는 HTTPS 웹사이트의 인증서는 모두 공개 PKI를 통해 발급되고 검증된다. DigiCert, Let’s Encrypt 같은 상업적 CA가 운영하며, 브라우저와 OS에 사전 내장된 Root CA를 신뢰의 근원으로 한다.

계층적 CA 체계

공개 PKI는 계층적 구조로 운영된다.

pki-infra

출처: https://www.keyfactor.com/education-center/what-is-pki/

  • Root CA: 최상위 CA로, 오프라인에 보관된다.
  • Intermediate CA: 중간 CA로, 실제 운영을 담당한다.
    • Root CA가 서명
  • End Entity Certificate: 최종 사용자나 서버의 인증서다.
    • Intermediate CA가 서명

실제 운영 예시: DigiCert

DigiCert는 CA 회사로, Root CA 1개와 여러 Intermediate CA들을 운영한다. Root CA는 오프라인에 보관되며 Intermediate CA에만 서명하고, 실제 웹사이트 인증서 발급은 Intermediate CA가 담당한다.

DigiCert Global Root CA (Root CA - 자체 서명, 브라우저 사전 내장)
├── DigiCert SHA2 Secure Server CA (Intermediate CA)
│   ├── www.google.com
│   ├── www.github.com
│   └── api.example.com
├── DigiCert SHA2 Extended Validation CA (Intermediate CA)
│   ├── www.paypal.com
│   └── www.bank.com
└── DigiCert TLS RSA SHA256 2020 CA1 (Intermediate CA)
    └── *.cloudflare.com


운영 원칙

Root CA 보호

Root CA는 PKI 신뢰 체계의 최상위 근원이다. Root CA가 유출되면 전체 인터넷 신뢰 체계가 붕괴되기 때문에, 물리적으로 격리된 오프라인 환경의 HSM(Hardware Security Module)에 보관한다. 예를 들어, DigiCert의 Root CA는 미국 유타주 솔트레이크시티의 보안 시설에 있고, Let’s Encrypt의 ISRG Root X1은 물리적으로 분산된 여러 HSM에 보관된다.

운영 방식도 극도로 제한적이다. Root CA는 연 1-2회만 켜서 Intermediate CA에 서명하고, 접근 시에는 다중 인증과 물리적 보안 절차를 거쳐야 하며, 모든 접근 기록이 감사된다.

Root CA의 인증서(공개키 포함)는 공개되어 브라우저와 OS에 사전 설치되어 있다. 하지만 Root CA의 개인키는 절대 공개되지 않으며 최강 수준의 보안으로 보호된다.

Intermediate CA 운영

Intermediate CA는 실제 인증서 발급을 담당한다. Root CA와 달리 온라인 상태로 운영되며, Root CA의 서명을 받아 신뢰성을 확보한다.

이러한 계층 구조의 장점은 위험 분산이다. Intermediate CA가 유출되어도 해당 CA만 폐기하고 Root CA는 안전하게 유지할 수 있다. Root CA를 다시 발급하려면 전 세계 모든 브라우저와 OS를 업데이트해야 하지만, Intermediate CA는 새로 발급하고 Root CA가 서명하면 된다.


인증서 발급 프로세스

공개 PKI에서 HTTPS용 도메인 인증서를 발급받는 프로세스는 상업 CA (유료)와 Let’s Encrypt (무료) 모두 본질적으로 동일하다. 차이는 자동화 여부와 검증 수준이다.

상업 CA의 수동 발급 프로세스 (DigiCert 등)

1단계: CSR 생성

CSR(Certificate Signing Request)에는 인증서에 들어갈 정보들이 포함된다:

  • CN (Common Name): 도메인 이름 (예: example.com)
  • O (Organization): 조직명
  • OU (Organizational Unit): 부서명
  • L (Locality): 도시
  • ST (State): 주/도
  • C (Country): 국가
  • 공개키
# 개인키 생성
openssl genrsa -out example.key 2048

# CSR 생성 (대화형으로 위 정보들 입력)
openssl req -new -key example.key -out example.csr

2단계: CA 검증

CA(DigiCert 등)가 CSR에 적힌 정보들을 검증한다:

인증서 유형에 따라 검증 수준이 다르다:

  • DV (Domain Validation): 도메인 소유권만 검증
    • HTTP 챌린지
      • CA: “http://example.com/.well-known/acme-challenge/abc123에 특정 파일을 업로드하세요”
      • 고객: 파일 업로드
      • CA: 확인 후 인증서 발급
    • 다른 방법
      • DNS 챌린지: TXT 레코드 추가
      • 이메일 챌린지: admin@example.com으로 인증 링크 발송
  • OV (Organization Validation): 조직 실재 검증
    • DV 검증 + 사업자등록증 확인
    • 조직이 실제로 존재하고 운영 중인지 확인
  • EV (Extended Validation): 확장 검증
    • OV 검증 + 법적 실체의 물리적 존재와 운영 확인
    • 가장 엄격한 검증 (주소창에 회사명 표시)

3단계: 인증서 발급

검증이 완료되면 CA는 CSR의 정보(도메인, 조직, 공개키 등)를 기반으로 인증서를 생성하고 Intermediate CA의 개인키로 서명한다.

# Intermediate CA로 서명 (CA 측에서 수행)
openssl x509 -req -in example.csr \
  -CA intermediate.crt -CAkey intermediate.key \
  -CAcreateserial -out example.crt -days 365

# 발급된 인증서(example.crt)에는 다음이 포함됨:

이렇게 발급된 인증서(example.crt)에는 다음의 정보가 포함된다:

  • CSR에서 온 정보들 (CN, O, OU, L, ST, C, 공개키)
  • 발급자 정보 (Intermediate CA)
  • 유효기간
  • CA의 디지털 서명

4단계: 웹서버 설치

발급받은 인증서(.crt)와 1단계에서 생성한 개인키(.key)를 웹서버에 설치한다.

# Nginx 설정 예시
server {
    listen 443 ssl;
    server_name example.com;
    
    ssl_certificate /path/to/example.crt;        # 공개키 포함된 인증서
    ssl_certificate_key /path/to/example.key;    # 개인키
}

이제 브라우저가 HTTPS로 접속하면 서버는 이 인증서를 전송하고, 브라우저는 CA 서명을 검증하여 신뢰를 확립한다.


Let’s Encrypt의 자동 발급 프로세스 (무료)

Let’s Encrypt는 2016년에 등장한 무료 인증서 발급 서비스다. 상업 CA와의 핵심 차이는 완전 자동화다. 수동으로 CSR을 생성하고 검증받는 대신, ACME(Automated Certificate Management Environment) 프로토콜을 사용하여 모든 과정이 자동으로 진행된다.

구조

ISRG Root X1
├── Let's Encrypt R3 (RSA Intermediate)
│   └── example.com (90일 만료)
└── Let's Encrypt E1 (ECDSA Intermediate)
    └── blog.example.com (90일 만료)

ACME 프로토콜과 Certbot

ACME 프로토콜은 인증서 발급/갱신을 자동화하는 표준 프로토콜이다. Certbot은 ACME 클라이언트의 대표적인 구현체로, 명령어 하나로 인증서 발급부터 설치까지 자동으로 수행한다.

# Certbot 실행
certbot certonly --nginx -d example.com

내부 동작은 아래와 같다:

  1. 계정 키 생성 (최초 1회)
  2. CSR 자동 생성
  3. HTTP/DNS 챌린지 자동 수행
  4. 인증서 자동 다운로드 및 설치
  5. Nginx 자동 재시작

자동 갱신

Let’s Encrypt 인증서는 90일마다 만료되지만, cron으로 자동 갱신을 설정할 수 있다.

# cron 등록 (매일 자정에 만료 임박 인증서 갱신)
0 0 * * * certbot renew --quiet

주요 공개 CA 비교

CA 검증 수준 프로세스 유효기간 갱신 가격 특징
Let’s Encrypt DV만 자동화 (ACME) 90일 자동 무료 개인, 스타트업, 오픈소스
DigiCert DV/OV/EV 수동 1년 수동 $200+/년 엔터프라이즈급, 보증 제공
GlobalSign DV/OV/EV 수동 1년 수동 $150+/년 다양한 제품군
Sectigo DV/OV/EV 수동 1년 수동 $50+/년 저가형
GoDaddy DV/OV 수동 1년 수동 $70+/년 도메인 등록과 통합


사설 PKI

사설 PKI는 조직 내부에서 운영하는 독립적인 PKI 시스템이다. 공개 PKI와 달리 Root CA를 직접 생성하고, 조직 내부에서만 신뢰한다. Kubernetes 클러스터, 기업 내부망, VPN, IoT 기기 등 외부 인터넷에 노출되지 않는 환경에서 사용된다.

비용이 들지 않고 완전한 통제가 가능하지만, Root CA를 직접 관리해야 하는 책임이 따른다.

구조 예시

Company Root CA (자체 서명)
├── HR Department Intermediate CA
│   ├── 직원 A 인증서 (스마트카드)
│   ├── 직원 B 인증서
│   └── 직원 C 인증서
├── IT Department Intermediate CA
│   ├── intranet.company.local
│   ├── gitlab.company.local
│   └── jenkins.company.local
└── IoT Device Intermediate CA
    ├── 센서 001
    ├── 센서 002
    └── 게이트웨이


운영 도구

OpenSSL (수동 관리)

# 1. Root CA 생성
openssl genrsa -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key \
    -sha256 -days 3650 -out rootCA.crt

# 2. 서버 개인키 생성
openssl genrsa -out server.key 2048

# 3. CSR 생성
openssl req -new -key server.key -out server.csr

# 4. 인증서 발급
openssl x509 -req -in server.csr \
    -CA rootCA.crt -CAkey rootCA.key \
    -CAcreateserial -out server.crt -days 365

HashiCorp Vault (자동화)

# 1. PKI Secret Engine 활성화
vault secrets enable pki

# 2. Root CA 생성
vault write pki/root/generate/internal \
common_name="Company Root CA" \
ttl=87600h

# 3. Role 생성 (자동 발급 규칙)
vault write pki/roles/server \
    allowed_domains="company.local" \
allow_subdomains=true \
  max_ttl=720h

# 4. 인증서 발급 (자동화)
vault write pki/issue/server \
  common_name="app.company.local"

Microsoft AD CS

Windows 도메인 환경에서 자동 인증서 포를 제공한다. 그룹 정책으로 클라이언트에 자동 설치 가능하다.


PKI 신뢰 체인 검증

브라우저 HTTPS 접속 시

1단계: 인증서 체인 수신

서버는 브라우저에게 자신의 인증서(github.com)와 Intermediate CA 인증서(DigiCert TLS Hybrid ECC SHA384 2020 CA1)를 함께 전송한다. Root CA 인증서는 브라우저에 이미 내장되어 있으므로 전송하지 않는다.

2단계: 검증 프로세스

브라우저는 다음을 순서대로 검증한다. github.com 인증서가 Intermediate CA로 서명되었는지, Intermediate CA가 Root CA로 서명되었는지, 그 Root CA가 브라우저 신뢰 저장소에 있는지 확인한다. 또한 인증서 만료일이 유효한지, 인증서가 폐기되지 않았는지(CRL/OCSP), 인증서의 도메인 이름이 실제 접속한 도메인과 일치하는지도 확인한다.

3단계: 결과 표시

pki-safe-connection 검증이 성공하면 브라우저는 주소창에 자물쇠 표시를 보여준다. 반면 검증이 실패하면 사용자에게 경고를 표시한다.

주요 검증 실패 케이스는 다음과 같다.

  • 자체 서명 인증서(Self-signed): Root CA가 브라우저 신뢰 저장소에 없어서 “연결이 안전하지 않음” 경고 표시
  • 만료된 인증서(Expired): 유효 기간이 초과되어 “인증서 만료됨” 경고 표시
  • 중간 인증서 누락(Chain Error): 서버가 Intermediate CA 인증서를 함께 전송하지 않아 체인이 불완전할 때 “인증서 체인 오류” 발생


인증서 폐기 관리

CRL (Certificate Revocation List)

CRL은 CA가 주기적으로 폐기된 인증서 목록을 발행하면, 클라이언트가 이를 다운로드하여 확인하는 방식이다. 단순하지만 폐기된 인증서가 많아질수록 목록의 크기가 커져 다운로드와 검증에 시간이 오래 걸린다는 단점이 있다.


OCSP (Online Certificate Status Protocol)

OCSP는 CRL의 단점을 보완하기 위해 등장했다. 클라이언트가 OCSP 서버에 실시간으로 “이 인증서가 유효한가요?”라고 요청하면, OCSP 서버가 “유효함”, “폐기됨”, “알 수 없음” 중 하나로 응답한다. CRL처럼 큰 목록을 다운로드할 필요가 없어 빠르다.

하지만 심각한 프라이버시 문제가 있다. 클라이언트가 어떤 사이트에 접속했는지 CA가 알 수 있기 때문이다. 사용자의 브라우징 패턴이 제3자(CA)에게 노출되어 프로파일링, 감시, 상업적 목적으로 악용될 수 있고, 정부 요청 시 특정 사용자의 접속 기록을 제공할 수도 있다.


OCSP Stapling

OCSP Stapling은 OCSP의 프라이버시 문제를 해결한다. 기존 OCSP는 클라이언트가 CA의 OCSP 서버에 직접 요청하여 CA가 사용자를 추적할 수 있었다. 반면 OCSP Stapling은 웹서버가 주기적으로 OCSP 서버에 요청하여 응답을 받아두고, 클라이언트에게 인증서와 함께 OCSP 응답을 전달한다. 클라이언트는 CA에 직접 요청하지 않으므로 프라이버시가 보호되고, CA 서버의 부하도 감소하여 성능이 향상된다.

Nginx에서는 다음과 같이 설정할 수 있다.

# Nginx OCSP Stapling 설정
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/chain.pem;


PKI 실제 사용 사례

1. 코드 서명

Windows 실행 파일

Microsoft가 서명한 Visual Studio Installer.exe는 Microsoft Corporation의 서명 인증서와 DigiCert CA 정보를 포함한다. Windows는 설치 시 이를 자동으로 확인하여 “확인된 게시자: Microsoft Corporation”이라고 표시한다. 반면 서명이 없는 unknown_program.exe를 실행하면 “알 수 없는 게시자” 경고가 표시된다.

macOS 앱 공증

개발자는 codesign --sign "Developer ID Application" MyApp.app 명령으로 앱에 서명하고, xcrun notarytool submit MyApp.zip으로 Apple에 공증을 제출한다. 사용자가 앱을 실행하면 macOS는 “Apple이 확인했으며 악성 소프트웨어가 없습니다”라고 표시한다.

Android APK

개발자가 개인키로 APK에 서명하면 Google Play가 이를 검증한다. 앱 설치 시 Android 시스템은 “같은 개발자가 서명한 앱인가?”를 확인하여 업데이트의 진위를 보장한다.


2. 이메일 서명 및 암호화

S/MIME

S/MIME(Secure/Multipurpose Internet Mail Extensions)는 이메일 보안을 제공한다. 발신자는 이메일을 작성할 때 자신의 개인키로 서명하여 위조를 방지하고, 수신자의 공개키로 암호화하여 기밀성을 보장한다. 수신자는 발신자의 공개키로 서명을 검증하여 진짜 발신자인지 확인하고, 자신의 개인키로 복호화하여 내용을 확인한다.

기업 임원 간 기밀 메일, 법률 문서 전송, 의료 기록 전송(HIPAA 준수) 등에 사용된다.

PGP/GPG

PGP(Pretty Good Privacy)와 GPG(GNU Privacy Guard)는 S/MIME와 유사한 목적을 가지지만, CA 없이 개인 간 신뢰 관계(Web of Trust)를 기반으로 동작한다. 주로 오픈소스 커뮤니티, 개인 간 암호화 통신, 소프트웨어 배포 검증에 사용된다.

# 공개키 생성
gpg --gen-key

# 문서에 서명
gpg --sign document.txt

# 암호화
gpg --encrypt --recipient alice@example.com file.txt

# 서명 검증
gpg --verify document.txt.sig

Linux 패키지 서명(apt, yum), Git 커밋 서명, 내부 고발자 제보(ProtonMail) 등에 사용된다.


3. 문서 서명 (PDF Digital Signatures)

전자 계약서

전자 계약서는 당사자 A와 B가 각자의 개인키로 전자서명하고, 공인 TSA(Time Stamping Authority)가 타임스탬프를 서명한다. 검증 시에는 누가 서명했는지(공개키로 확인), 서명 후 변조되었는지(해시 비교), 언제 서명했는지(타임스탬프)를 확인할 수 있다.

한국은 공인전자서명법, 미국은 ESIGN Act, EU는 eIDAS Regulation으로 법적 효력을 부여한다. DocuSign, Adobe Sign, 전자세금계산서, 부동산 계약 등에 실제로 사용된다.


4. VPN 및 네트워크 보안

IPsec VPN

본사와 지사 사이에 IPsec 터널을 구성할 때, 양쪽 엔드포인트는 인증서로 상호 인증한다. 인증서는 터널 양쪽 엔드포인트의 신원을 확인하고, 대칭키 교환을 안전하게 수행하는 역할을 한다.

WPA2-Enterprise (Wi-Fi 보안)

WPA2-Enterprise 환경에서는 직원 노트북이 클라이언트 인증서를 소지하고 회사 Wi-Fi에 접속을 시도하면, RADIUS 서버가 인증서를 검증하여 접속을 허용하거나 거부한다.


5. 블록체인 및 암호화폐

Bitcoin/Ethereum

비트코인과 이더리움에서 사용자 지갑은 개인키(비밀번호처럼 보관)와 공개키(주소, 계좌번호)로 구성된다. 거래 시 개인키로 거래에 서명하면 네트워크가 공개키로 검증하여 “이 주소의 주인이 진짜 이 거래를 승인했는가?”를 확인한다.

PKI와의 차이점은 CA가 없다는 것(탈중앙화)이고, 공개키 자체가 신원이므로 별도 검증이 불필요하다.


6. IoT 디바이스 인증

스마트홈

스마트 도어락은 제조사가 출하 시 인증서를 내장하고, 앱 연결 시 인증서로 검증한다. 사용자 앱은 “이 도어락이 진짜 삼성 제품인가?”를 인증서로 확인하여 신뢰한다.

자동차 V2X 통신

자율주행차 A가 차량 인증서를 가지고 “앞차가 급정거” 메시지를 브로드캐스트하면, 자율주행차 B는 메시지 서명을 검증하여 “이 메시지가 진짜 차에서 온 것인가?”를 확인한다.


7. 의료 기기

심장 박동기, 인슐린 펌프 같은 의료 기기는 의사 태블릿의 인증서를 검증하여 “이 명령이 진짜 의사에게서 왔는가?”를 확인한 후 실행한다. 목적은 해커가 무선으로 기기를 조작하지 못하게 하는 것이다.


8. 정부 신원 확인

전자여권 (ePassport)

전자여권의 칩에는 개인정보(이름, 사진 등), 국가가 서명한 디지털 서명, 공개키가 저장되어 있다. 출입국 심사대는 칩 데이터를 읽고, 국가 공개키로 서명을 검증하여 “이 여권이 위조되지 않았는가?”를 확인한다.

전자주민등록증

한국 전자주민등록증은 공인인증서 기능을 내장하여 정부24 로그인과 전자서명이 가능하다.


9. 클라우드 인프라

AWS Instance Identity

EC2 인스턴스는 AWS가 발급한 인증서로 다른 AWS 서비스에 접근할 때 신원을 증명한다. S3 버킷은 “이 요청이 진짜 내 EC2에서 온 것인가?”를 인증서로 검증한다.

Kubernetes Workload Identity

Pod는 ServiceAccount 토큰(JWT, 공개키로 서명됨)으로 API Server를 호출하면, API Server가 토큰 서명을 검증하여 “이 Pod가 정말 ‘sa-admin’ 권한이 있는가?”를 확인한다.


10. 시간 증명 (Timestamping)

RFC 3161 타임스탬프

RFC 3161 타임스탬프는 중요 문서의 해시를 생성하여 TSA(Time Stamping Authority)에 전송하고, TSA가 서명한 타임스탬프를 받는다. 나중에 분쟁 시 “이 문서가 2024년 1월 1일에 존재했다”를 증명할 수 있다. 특허 출원 증명, 감사 로그(변조 방지), 계약서 날짜 증명 등에 사용된다.


11. 게임 및 DRM

Steam, PlayStation Network

Steam, PlayStation Network는 게임 실행 파일에 개발사가 서명하고 플랫폼이 검증하여 “정품인가? 변조되었는가?”를 확인한다.

NFT 및 디지털 자산

디지털 아트 NFT는 작가가 개인키로 서명하고, 소유권 이전 시 서명을 검증한다.


맺으며

PKI는 암호학과 사회학의 교차점이다. PKI는 기술이지만, 그 역할은 인류가 수천 년간 구축해 온 신뢰 체계의 디지털 버전이다.

물리적 신뢰 체계 ↔ 디지털 신뢰 체계

현실 세계 디지털 세계
정부 신분증 디지털 인증서
화폐 암호화폐 (서명)
계약서 날인 디지털 서명
공증인 Certificate Authority
인감 개인키
도장 날인 전자서명

신뢰의 본질

신뢰 없이는 거래가 불가능하다. PKI는 신뢰를 확장 가능하게 만드는 기술이다.

현실에서 우리는 “이 종이가 만 원의 가치가 있다”는 집단적 믿음을 갖고, 디지털 세계에서는 “이 공개키가 google.com의 것이다”라는 집단적 믿음을 갖는다.

신뢰의 본질은 변하지 않았다. 다만 그것을 구현하는 방식이 디지털로 옮겨왔을 뿐이다.



hit count

댓글남기기

참고