RSA 키 쌍은 비대칭 암호화의 기반입니다 — SSH 접근, TLS 인증서, JWT 서명, 코드 서명에 사용됩니다. 이 가이드에서는 RSA의 작동 방식, 올바른 키 크기와 형식을 선택하는 방법, 서버에 데이터를 전송하지 않고 브라우저에서 완전히 키를 생성하는 방법을 설명합니다.
RSA 키 쌍의 작동 방식
RSA는 비대칭 알고리즘입니다: 키 쌍은 수학적으로 연결된 두 개의 키로 구성됩니다.
- 공개 키 — 자유롭게 공유할 수 있습니다. 누구나 데이터 암호화나 서명 검증에 사용할 수 있습니다.
- 개인 키 — 비밀로 유지하세요. 데이터 복호화나 서명 생성에 사용합니다.
보안은 큰 반소수의 인수분해가 어렵다는 점에 의존합니다. 공개 키에서 개인 키를 복구하려면 수백 자리의 수를 인수분해해야 하는데, 현재 하드웨어로는 계산적으로 불가능합니다.
키 쌍은 두 개의 큰 소수 p와 q에서 함께 생성됩니다. 공개 키에는 모듈러스 n = p × q와 공개 지수(보통 65537)가 포함됩니다. 개인 키에는 p, q, 효율적인 복호화에 사용되는 파생 값이 포함됩니다.
키 크기 선택
| 크기 | 보안 수준 | 사용 사례 |
|---|---|---|
| 1024비트 | 깨짐 — 사용하지 마세요 | 레거시만 |
| 2048비트 | ~112비트 보안 | 범용, TLS, SSH |
| 4096비트 | ~140비트 보안 | 고보안 시스템, 장기 인증서 |
2048비트가 안전한 기본값입니다. 오늘날 사실상 모든 애플리케이션에 충분한 보안을 제공하며 모든 주요 시스템(GitHub SSH, Let’s Encrypt, AWS KMS)에서 허용됩니다.
4096비트는 키가 10년 이상 데이터를 보호하거나 조직 정책이 요구할 때 적합합니다. 트레이드오프는 느린 암호화 연산입니다 — 4096비트 키로의 RSA 서명/검증은 2048비트보다 약 4배 오래 걸립니다.
NIST는 적어도 2030년까지 2048비트 RSA를 권장합니다. 장기적 관점으로 설계되는 새 시스템에는 3072비트가 합리적인 중간점입니다.
키 형식 설명
PEM (Privacy Enhanced Mail)
가장 일반적인 형식 — ASCII 헤더로 감싼 Base64 인코딩 DER 구조:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
-----END PUBLIC KEY----------BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEA...
-----END PRIVATE KEY-----PEM 파일은 컨텍스트에 따라 .pem, .key, .crt, .pub 확장자를 사용합니다. OpenSSL, nginx, 대부분의 SSH 클라이언트, AWS Certificate Manager가 기대하는 형식입니다.
JWK (JSON Web Key)
주로 OAuth 2.0과 JOSE(JSON Object Signing and Encryption)에서 웹 컨텍스트에 사용되는 JSON 표현:
{
"kty": "RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFb...",
"e": "AQAB",
"alg": "RS256",
"use": "sig"
}JWK 세트(JWKS)는 OIDC 아이덴티티 공급자가 JWT 검증을 위한 공개 키를 게시하는 데 사용됩니다. RSA로 서명된 JWT를 발행하는 API를 구축하는 경우, 클라이언트가 토큰 검증에 사용하는 JWKS 엔드포인트를 게시합니다.
PKCS#1 vs PKCS#8
오래된 도구는 -----BEGIN RSA PRIVATE KEY-----(PKCS#1 형식)를 출력합니다. 현대 도구는 -----BEGIN PRIVATE KEY-----(PKCS#8 형식, 알고리즘 독립적 래퍼)를 선호합니다. 둘 다 RSA 키 자료를 포함하며, 차이는 인코딩 래퍼입니다. 대부분의 현대 라이브러리는 둘 다 허용합니다.
브라우저에서 RSA 키 생성
모든 계산은 Web Crypto API를 사용해 브라우저에서 실행됩니다. 개인 키는 머신에서 나가지 않습니다 — 서버가 수신하지 않으며, 페이지 로딩 후 오프라인에서도 작동합니다.
단계:
- 키 크기 선택 (2048 또는 4096비트)
- 출력 형식 선택 (PEM 또는 JWK)
- 생성 클릭 — 키 쌍이 즉시 표시됨
- 각 키를 복사해 안전하게 저장
보안 주의: 생성된 개인 키를 양식, 웹 서비스, 클라우드 콘솔에 절대 붙여넣지 마세요. 개인 키는 키체인, 시크릿 매니저, 또는 HSM에 저장해야 합니다.
실제 사용 사례
SSH 키 인증
생성된 개인 키를 OpenSSH 형식으로 변환하거나(도구가 지원하는 경우) ssh-keygen으로 직접 생성합니다:
ssh-keygen -t rsa -b 4096 -C "your@email.com"공개 키는 서버의 ~/.ssh/authorized_keys에 들어갑니다. 개인 키는 ~/.ssh/id_rsa에 보관합니다.
프로그래밍 방식 접근(CI/CD, 배포 키)에는 RSA 2048이 표준입니다. GitHub, GitLab, Bitbucket 모두 RSA 배포 키를 지원합니다.
TLS 인증서
TLS 인증서는 공개 키를 포함하는 서명된 문서입니다. CA에서 인증서를 받으려면:
# 개인 키 생성
openssl genrsa -out private.key 2048
# CSR (인증서 서명 요청) 생성
openssl req -new -key private.key -out request.csr
# CA가 CSR에 서명하고 인증서를 반환개인 키는 서버에 남습니다. 인증서(공개 키 포함)는 브라우저로 전송됩니다.
RSA로 JWT 서명
RS256(RSA + SHA-256)은 일반적인 JWT 서명 알고리즘입니다. API 서버는 개인 키로 토큰에 서명하고, 클라이언트는 공개 키로 검증합니다:
// Node.js — 서명
import jwt from 'jsonwebtoken';
import fs from 'fs';
const privateKey = fs.readFileSync('private.key');
const token = jwt.sign({ sub: 'user123', role: 'admin' }, privateKey, {
algorithm: 'RS256',
expiresIn: '1h'
});
// 검증 (공개 키 또는 JWKS 엔드포인트로)
const publicKey = fs.readFileSync('public.key');
const payload = jwt.verify(token, publicKey, { algorithms: ['RS256'] });RS256은 여러 서비스가 토큰을 독립적으로 검증해야 할 때 HS256(공유 비밀)보다 선호됩니다 — 각 서비스에는 공개 키만 필요합니다.
코드 서명
패키지 레지스트리와 업데이트 시스템은 RSA로 아티팩트에 서명합니다. 사용자는 설치 전에 서명을 검증합니다:
# 파일 서명
openssl dgst -sha256 -sign private.key -out signature.bin artifact.tar.gz
# 검증
openssl dgst -sha256 -verify public.key -signature signature.bin artifact.tar.gz클라이언트 측 생성이 중요한 이유
많은 온라인 도구는 서버에서 키 쌍을 생성하고 HTTPS를 통해 개인 키를 보냅니다. 이것은 보안 문제입니다:
- 서버가 개인 키의 복사본을 가짐
- 개인 키가 네트워크를 경유함
- 서버가 무엇을 로그에 기록했는지 확인할 수 없음
Web Crypto API를 사용한 브라우저 기반 생성기는 이 세 가지 문제를 모두 피합니다. 키 쌍은 JavaScript 런타임에서 완전히 생성되며, 개인 키는 브라우저에서 계산되어 전송되지 않습니다.
개인 키 안전하게 저장
- 개발 환경:
~/.ssh/또는 로컬 시크릿 파일에 저장,.gitignore로 git에서 제외 - 프로덕션: 관리형 시크릿 서비스 사용 — AWS Secrets Manager, HashiCorp Vault, Azure Key Vault
- 고보안: 하드웨어 보안 모듈(HSM) 또는 클라우드 KMS(AWS KMS, GCP Cloud KMS) — 키는 하드웨어 경계를 벗어나지 않음