JCE 암호화 트러블 슈팅

📌 개요

JDK 버전 변경으로 인한 Cipher 암/복호화 길이 오류가 발생한 트러블슈팅에 관한 사례로

여러 방안을 토대로 협의하여 문제를 해결한 구조를 정리한 글이다.

---

🔍 문제 상황

• 고객사 JDK 버전이 6 ➔ 8로 업그레이드됨.
• 자사 암호화 모듈은 JDK6 기반(아마 128bit 이하 키 길이를 전제로 설계)으로 작성됨.
• JDK8u161 이후 버전부터는 기본적으로 고급 키 길이(예: 256bit) 를 쓰려면 제약이 걸려 있어서,
• 실행 시 에러 발생:

javax.crypto.IllegalBlockSizeException: Illegal key size or default parameters

 

---

🧐 원인 분석

• JCE 기본 정책(Policy) 때문이다.
• 기본적으로 Oracle JDK는 미국 수출 규제 때문에 강한 암호화(256bit 이상)를 막아놓았어.
• JDK6, JDK7, JDK8(JDK8u161 이전까지) 모두 “기본적으로”는 128bit까지만 허용했어.
• 256bit 이상을 쓰려면 “Unlimited Strength Jurisdiction Policy Files” 를 따로 설치해야 했어.

☝️ 정리: 기본 정책 = “128bit까지만 허용”, 256bit 쓰려면 JCE Policy 파일 교체 필요.

 

---

🤔 해결 방법 고민

방법	내용	장단점
1. JCE Policy 파일 교체	$JAVA_HOME/jre/lib/security/ 안에 있는 local_policy.jar, US_export_policy.jar 파일을 “Unlimited Strength” 버전으로 교체	- 간단함 - JDK 업데이트 시 다시 해야 함 - 서버 관리 정책에 따라 제약될 수 있음
2. java.security 파일 수정	$JAVA_HOME/jre/lib/security/java.security 파일의 crypto.policy 설정을 unlimited로 수정 (JDK8u161 이후 가능)	- JDK8u161 이상부터 지원 - 따로 JAR 교체 필요 없음 - 환경 설정만으로 가능
3. 암호화 로직 수정	아예 키 사이즈를 128bit 이하로 맞추거나, 키 생성 로직을 수정	- 코스트 큼 (코드 수정, 재배포 필요) - 시스템 전체 영향 고려해야 함 - 장기적으로는 안전함

1번은 내부 시스템에서만 사용할 때 따로 관리가 가능하다면 JDK를 분리하여 적용가능

• 말그대로 파일만 교체하면 해결이 된다. 다만, 고객사와 협의를 통해 사용여부를 선택해야한다.
• $JAVA_HOME/jre/lib/security 폴더에
  • local_policy.jar
  • US_export_policy.jar
• 파일 크기가 작은 경우 (2~3KB) ➔ 기본 정책
• 파일 크기가 큰 경우 (6KB 이상) ➔ Unlimited 정책
• 코드로 확인하는 방법

import javax.crypto.Cipher;

public class CryptoPolicyCheck {  
  public static void main(String[] args) throws Exception {  
    int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");  
    System.out.println("Max AES Key Length: " + maxKeyLen + " bits");  
  }  
}

출력 예시

• 128 ➔ JCE 제한 정책이 적용된 상태 (기본)
• 256 ➔ Unlimited Strength 정책 적용 완료 상태

2번 보안 감사 때, 설정 부분의 이슈가 발생할 수 있음으로 주의가 필요

• 가장 쉬운 방법이지만 운영상에서 쉽게 적용하기는 어려움
• $JAVA_HOME/jre/lib/security/java.security에 crypto.policy=unlimited 항목 존재 여부와 값 확인 (JDK8u161 이후 가능)3번 유지보수 관점에서 가장 안전

 

3번 유지보수 관점에서 가장 안전

• 기존 코드가 “128bit만” 고정으로 기대하고 있었다면, 키 길이에 따라 동적으로 로직을 처리하도록 리팩토링 필요.
• 키 길이(128, 192, 256)를 입력 받아 동적으로 Key 생성 및 암복호화 처리

👍 해결

여러 고객사에서 제품 설치시 유사한 사례가 많았고 고객과의 미팅을 통해 해결방안을 제시하고 각각 다르게 적용되었다.

• 프로젝트 남은 기간 + 관리 영역 확대 등을 고려해서 결정
• 과도기 시점에 대부분 JDK를 분리하여 기본 정책을 사용 → 관리 포인트가 증가는 하지만 가장 빠른 해결임
• 이후 JDK자사 내부적으로 JCE의 암호화 코드 키 길이를 유연하게 적용하기 위한 리팩토링하여 적용

---

🫵 추가로 알아야 할 것

• JDK 버전별로 정책 적용 방식이 달라짐:
  • JDK 8u161부터는 기본으로 Unlimited Strength 포함됨. 단, java.security 파일 설정 필요.
  • JDK 11 이상부터는 아예 기본이 “unlimited”야. 추가 설치나 설정이 필요 없음.
• Oracle JDK, OpenJDK 차이:
  • OpenJDK는 예전부터 제한이 없거나, 설치 방식이 다를 수 있어. (OpenJDK는 수출 규제를 신경 덜 씀.)
• 암호화 수출 규제(Crypto Export Control) 배경 이해:
  • 미국 정부가 “강한 암호화는 무기”로 취급해서, 수출 통제를 걸었었어.
  • 그래서 자국 내 사용은 256bit 가능, 수출용은 128bit까지만 허용했었음.
  • 이게 2015~2016년에 규제 완화되면서 Oracle도 정책을 풀기 시작했어.
• Java Cipher의 암호화 알고리즘에 따라 키 길이 범위가 다름

---

🇺🇸 여담: ActiveX와 익스플로러, 암호화 수준 얘기

“미국은 높은 bit 암호화, 해외는 낮은 bit 암호화 → 한국 IE는 낮아서 ActiveX 도배했다”
이거 사실 일부 맞고, 일부 과장이야.

 

✅ 맞는 부분

• 과거 미국은 암호화 소프트웨어 수출 제한을 했다. 그래서 브라우저(IE, Netscape)도 미국판, 해외판 따로 있었어.
• 해외판 브라우저는 낮은 암호화 수준(40bit, 56bit SSL)만 제공했다.
• 한국은 강한 암호화가 필요한 금융/공공 사이트가 많았는데, 브라우저 자체 보안이 약했음.

✅ 과장된 부분

• ActiveX 도배의 주 원인은 “암호화 부족” 때문만은 아님.
• 공인인증서(본인확인), 전자서명 모듈 설치를 위한 표준 인터페이스가 없어서,
  • 금융기관들이 각자 ActiveX로 모듈 설치를 강제하게 된 거야.
• 즉, “보안이 약해서 ActiveX를 깔았다“기보다는,
  “운영체제(OS) + 브라우저의 기능 부족 + 규제(공인인증서 의무화)가 원인이었어.

정리:

• 미국 수출 규제 때문에 해외판 IE 보안이 약했던 건 맞아.
• 그렇지만 한국 ActiveX 문제는 브라우저 암호화 때문만은 아니고, 인증 인프라 부재 + 정부 규제 영향이 더 컸다.

---

🚀 정리 요약

트러블슈팅 관점 요약

• 문제 인식: JDK 업그레이드 후 AES 256bit 키 에러 발생
• 원인: JCE 기본 정책(128bit 제한) 때문
• 해결 방안
  • (JDK8u161 미만) Policy 파일 교체
  • (JDK8u161 이상) java.security 설정 수정
  • (장기) 코드 수정하여 키 길이 제한 없음