E2E 암호화, JWT

1. E2E 암호화 (End-to-End Encryption)

정의

E2E 암호화는 통신의 양 끝에서만 데이터를 해독할 수 있도록 하는 암호화 방식이다.
즉, 메시지를 보내는 사용자와 받는 사용자만 내용을 볼 수 있고 그 사이를 전달하는 서버조차 내용을 알 수 없다.

데이터는 송신자 단말에서 암호화되고, 수신자 단말에서만 복호화
중간 서버는 단순히 암호화된 데이터만 전달

일반 암호화와 E2E 암호화 차이

구분                                                             일반 HTTPS (TLS)                          E2E 암호화

암호화 구간	클라이언트 ↔ 서버	클라이언트 ↔ 클라이언트
서버 내용 확인 가능 여부	가능	불가능
복호화 위치	서버	수신자 단말
예시	웹사이트 로그인	메신저

핵심 차이

• HTTPS: 전송 중 보호
• E2E: 전송 + 서버까지 포함해서 완전 보호

동작 원리

E2E는 보통 비대칭키 암호화 + 대칭키 암호화를 함께 사용

1. 사용자 B는 공개키를 가지고 있음
2. 사용자 A는 메시지를 생성
3. A는 B의 공개키로 메시지를 암호화
4. 서버는 암호화된 데이터만 전달
5. B는 자신의 개인키로 복호화

 

실제 구현에서는 성능 때문에 다음 구조를 사용함

1. 세션 키(대칭키) 생성
2. 메시지는 대칭키로 암호화 (빠름)
3. 세션 키는 공개키로 암호화
4. 수신자는 개인키로 세션 키 복호화 → 메시지 복호화

2. 중요한 이유

1) 서버도 내용을 볼 수 없음

일반 서비스에서는 서버가 데이터를 평문으로 볼 수 있다.

 

하지만 E2E에서는 (사용자 → (암호문) → 서버 → (암호문) → 사용자)의 형태로, 서버는 단순 전달자일 뿐이다.

2) 내부자 공격 방지

• 관리자
• 개발자
• 해커 (서버 침입 시)

→ 모두 데이터 내용을 볼 수 없다

3) 데이터 유출 피해 최소화

DB가 탈취 당해도 암호화된 데이터만 존재, 해독 불가능

 

3. E2E 암호화의 한계와 취약점

 

1) 키 관리 문제

E2E의 핵심은 누가 어떤 키를 가지고 있느냐이다. 즉, 공격자가 공개키를 바꿔치기하면 메시지를 중간에서 가로채 복호화가 가능해진다. 공개키 신뢰 검증 부족, 키 교환 과정이 안전하지 않은 경우 해당 문제가 발생할 수 있다.

대응

• 키 지문 확인
• QR 코드 인증
• 신뢰 기반 키 검증

 

2) Endpoint(단말) 취약점

E2E는 전송 중은 안전하지만, 단말 자체가 뚫리면 무력화된다.

예시

1. 사용자의 스마트폰에 악성코드 감염
2. 복호화된 메시지를 그대로 탈취

 

 

3) 메타데이터 노출

E2E는 내용은 숨기지만, 누가 누구에게 보냈는지·언제 보냈는지·얼마나 자주 통신하는지는 보호받지 못한다.

예시

A ↔ B 메시지 내용은 모름
하지만 A가 B에게 하루 100번 연락 등, 횟수는 알 수 있음

 

4) 백업/복구 문제

E2E 구조에서는 서버가 내용을 모르기 때문에 비밀번호를 잊어버리면 데이터 복구가 불가능하다.

대응

• 클라이언트 측 암호화 백업
• 별도 복구 키 제공

---

4. JWT 정의

정의

JWT(JSON Web Token)는 두 당사자 사이에서 정보를 JSON 객체 형태로 안전하게 전달하기 위한 간결하고 URL-safe한 토큰 형식이다. RFC 7519에서 정의되어 있으며, 토큰 안에는 사용자 ID, 권한, 만료 시간 같은 정보가 claim 형태로 담긴다.

JWT는 보통 Header, Payload, Signature로 구성된다.

<Header . Paload . Signature 형태>
xxxxx.yyyyy.zzzzz

구성                                         요소 역할

Header	토큰 타입, 서명 알고리즘 정보
Payload	사용자 정보, 권한, 만료 시간 등 claim
Signature	토큰이 위조되지 않았는지 검증하는 서명

중요한 점은 JWT는 기본적으로 암호화가 아니라 인코딩된 구조라는 것이다. 서명된 JWT는 위조 여부를 검증할 수 있지만, payload 내용 자체는 Base64URL 디코딩으로 확인할 수 있다. 따라서 비밀번호, 주민번호, 카드번호 같은 민감정보를 JWT payload에 넣으면 안 된다.

5. JWT 사용 예시

JWT는 주로 인증(Authentication)과 인가(Authorization)에 사용된다.

대표적인 흐름은 다음과 같다.

1. 사용자가 ID/PW로 로그인
2. 서버가 사용자 정보를 확인
3. 서버가 JWT 발급
4. 클라이언트가 JWT 저장
5. 이후 API 요청마다 Authorization 헤더에 JWT 포함
6. 서버는 JWT 서명을 검증하고 사용자 식별

사용                                                       상황 이유

REST API 인증	매 요청마다 사용자 식별 가능
모바일 앱 인증	세션 쿠키보다 토큰 전달 방식이 편리
마이크로서비스	여러 서비스 간 사용자 claim 전달 가능
Stateless 인증	서버가 세션을 저장하지 않아도 됨

6. JWT의 주요 취약점

JWT 자체가 위험하다기보다는, 검증·보관·만료·권한 확인을 잘못 구현할 때 취약점이 발생한다.

1) 서명 검증 누락

가장 심각한 문제 중 하나는 서버가 JWT의 서명을 검증하지 않고 payload만 디코딩해서 신뢰하는 경우다. OWASP는 JWT 취약점 중 대표적인 문제로, 단순 디코딩 함수와 검증 함수를 혼동하는 사례를 지적한다.

취약한 방식은 다음과 같다.

jwt.decode(token)
이 방식은 토큰 내용을 읽을 뿐, 위조 여부를 확인하지 않는다.

안전한 방식은 다음과 같다.
jwt.verify(token, secretOrPublicKey)

2) 약한 서명 키 사용

HMAC 방식의 JWT는 서버가 가진 secret key로 서명한다. 이 key가 너무 짧거나 예측 가능하면 공격자가 brute force로 key를 알아내 토큰을 위조할 수 있다.

예를 들어 secret이 다음처럼 단순하면 위험하다.

secretpasswordmykeyjwt123
대응하려면 충분히 긴 랜덤 키를 사용해야 한다.

3) 알고리즘 혼동 공격

JWT header에는 어떤 알고리즘으로 서명했는지 나타내는 alg 값이 들어간다.

{
"alg": 
"HS256"
,
"typ": 
"JWT"
}

 

서버가 이 값을 무조건 신뢰하면 공격자가 알고리즘을 조작해 검증을 우회할 수 있다. 과거에는 alg: none을 허용하거나, 비대칭키 알고리즘과 대칭키 알고리즘을 혼동하는 구현 문제가 자주 언급되었다.

이를 해결하기 위해서는, 서버에서 허용할 알고리즘을 고정해야 한다. 또한 토큰 header의 alg 값을 그대로 신뢰하면 안 된다.

4) 만료 시간 미설정 또는 과도하게 긴 만료 시간

JWT는 한 번 발급되면 서버 세션처럼 쉽게 폐기하기 어렵다. 만료 시간이 없거나 너무 길면 탈취된 토큰이 오래 사용될 수 있다.

JWT payload에는 보통 exp claim을 넣는다.

{
"sub": "user123",
"role": "user",
"exp": 1710000000
}

 

대응 방안은 다음과 같다.

Access Token은 짧게 유지, Refresh Token은 별도로 관리, Refresh Token은 서버 저장소 또는 안전한 저장소에서 폐기 가능하게 설계하는 것이다.

5) 토큰 탈취

JWT가 브라우저 localStorage에 저장되어 있으면 XSS 공격으로 탈취될 수 있다. 반대로 쿠키에 저장하면 CSRF 대응이 필요하다.

저장                                                                  위치 위험

localStorage	XSS에 취약
Cookie	CSRF에 주의 필요
Memory	새로고침 시 유지 어려움

보안성이 중요한 서비스에서는 일반적으로 다음을 함께 고려한다.

HttpOnly Cookie
Secure 옵션
SameSite 옵션
짧은 Access Token 만료 시간
Refresh Token rotation
XSS 방어
CSRF 방어