IT반장의 블로그

이 글에서는 자바 암호 패키지인 JCA(Java Cryptography Architecture)와 JCE(Java Cryptography Extension)에 대해서 알아보고, 실무 활용 방법에 대해서 알아보겠습니다.

안녕하세요. IT반장입니다.

최근에 많은 프로그램들이 자바 언어로 만들어지고 있습니다. 서버 프로그램뿐 만 아니라 클라이언트 프로그램도 자바 언어로 프로그래밍 되는 경우가 많습니다. (예, 스프링프레임워크, 안드로이드 등) 그리고 자바 언어에서는 암호화를 위해 JCA(Java Cryptography Architecture)와 JCE(Java Cryptography Extension) 패키지를 제공하고 있습니다. 이 글에서는 암호 프로그래밍에서 쉽게 자주 접하게 되는 JCA와 JCE에 대해서 알아보고 실무 활용 방법을 설명하겠습니다.

1. JCA(Java Cryptography Architecture) [1][2]

• 소개

• JCA는 자바 프로그래밍 언어의 암호화를 위한 프레임워크입니다. JDK1.1 java.security 패키지에 처음 소개되었습니다.
• 'Provider"-based architecture'를 사용하고 암호화, 키 생성 및 관리, 'secure random number' 생성, 인증서 검증 등의 API를 포함하고 있습니다.
• JCA는 구현 독립성/호환성, 알고리즘 확장성을 고려하여 설계되었습니다.
  • 구현 독립성: 보안 기능별 독립된 제공자(provider)로 프로그래밍
  • 구현 호환성: 프로그램들간 추상화된(고정되지 않은) 제공자를 통해서 호환
  • 알고리즘 확장성: 대부분의 알고리즘을 지원하고, 임의의 제공자(provider) 추가 가능
• JDK 1.4 이상에서는 JCE(Java Cryptography Extention)도 기본 포함됩니다.
• 관련 암호 서비스를 정의하고 지원하기 위한 'Provider Framework'(java.security, javax.crypto, javax.crypto.spec, javax.crypto.interfaces 패키지)와 'Provider'(실제 암호 구현 내용이 포함된 Sun, SunRsaSign, SunJCE 패키지)를 제공합니다.

[참고] 기타 JDK 암호 라이브러리

• JSSE(Java Secure Socket Extension): SSL/TLS 기능 제공
• JGSS(Java Generic Security Services): Kerberos, 네트워크 보안 기능 제공
• SASL(Simple Authentication and Security Layer): 네트워크 보안 기능 제공

• 구조

  

  
  

[그림0] MD5 메시지 다이제스트 구현 설명도

[그림0]에서 보듯이 각각의 어플리케이션은 'Provider Framework'를 통해서 각각의 독립적인 'Provider'에 접근해서 암호 기능을 구현할 수 있습니다.

• 키 관리
  • 키와 인증서들의 저장소를 관리하는 'keystore'가 있습니다.
  • java.security.KeyStore 클래스
  • .jks 파일 형태로 구현됨(또는 3DES로 암호화된 .jceks)
  • 어플리케이션은 각각의 'Provider'로부터 개별적인 keystore 구현 가능

     

• 주요 클래스

[표1] JCA 주요 클래스

• 전자서명

[그림1] 전자서명 및 검증 설명도

[소스코드1] 전자서명/검증 예제 소스코드

[그림1]과 [소스코드1]은 간단한 전자서명과 검증 예를 설명하고 있습니다. 위와 같이 JCA에서는 키생성, 전자서명/검증을 위한 API를 제공하고 그 외에 다양한 확장 기능을 제공합니다.

• 암호화

  

  
  

[그림2] 암복호화 설명도

[소스코드2] 암복호화 예제 소스코드

[그림2]와 [소스코드2]는 간단한 대칭키 암호화 예(AES GCM모드)를 설명하고 있습니다. 평문, 대칭키, IV(Initial Vector), ParameterSpec을 설정하고 Cipher.doFinal 메소드를 통해서 암복호화를 할 수 있습니다.

• MAC(Message Authentication Code)

  

[그림 3] MAC 설명도

[소스코드3] MAC 설명도

[그림3]와 [소스코드3]은 MAC(Message Authentication Code)을 설명하고 있습니다. 메시지("Hi There")의 MAC값을 생성하고, 이후 'Secret Key'를 공유하여 MAC값이 동일한지를 비교합니다.

• Generators 와 Factories

  

[그림4] Generators와 Factories 설명도

[그림4]에서 보시는 바와 같이 Generator 클래스는 새로운 오브젝트(대칭키 등) 생성을 위한 파라미터를 설정하고, Factory 클래스는 이전에 정의된 오브젝트를 변환할 때 사용됩니다.

• KeyFactory 클래스

  

[그림5] KeyFactory 클래스 설명도

[그림5]에서 보시는 바와 같이 KeyFactory 클래스는 'Key Spec'으로부터 'Key'를 생성하기도 하고, 반대로 'Key'로부터 'Key Spec'을 추출할 수 있습니다. 'Key Spec'에는 'Key'에 대한 정보가 포함되어 있습니다.

• SecretKeyFactory 클래스

  

[그림6] SecretKeyFactory 클래스 설명도

[그림6]에서 보시는 바와 같이 'SecretKeyFactory' 클래스는 'Key Spec'에서 대칭키('Secret Key')를 생성할 수 있고, 대칭키로부터 'Key Spec'을 가져올 수 있습니다.

• KeyPairGenerator 클래스

  

[그림7] KeyPairGenerator 클래스 설명도

[그림7]은 KeyPairGenerator가 두가지 방법으로 공개키/개인키를 생성하는 것을 보여줍니다. 하나는 알고리즘 독립적으로 키를 생성하는 방법이고, 다른 하나는 알고리즘을 정해서 키를 생성하는 방법입니다.

• KeyGenerator 클래스

  

[그림8] KeyGenerator 클래스 설명도

[그림8]은 KeyGenerator 클래스가 대칭키를 생성하는 방법을 보여줍니다. 마찬가지로 알고리즘을 정해서 생성하는 방법과 그렇지 않은 방법이 있습니다.

• KeyAgreement 클래스

  

[그림9] KeyAgreement 클래스 설명도

[그림9]은 Alice와 Bob이 DH 'Key Agreement'를 하는 과정을 보여줍니다. 공개키를 서로 교환하고 'Secret Key'를 생성하여 동일한지를 비교합니다.

• KeyStore 클래스

  

[그림10] KeyStore 클래스

[그림10]는 KeyStore 클래스를 보여줍니다. 신뢰된 인증기관 인증서(Trusted Certificate), 공개키/개인키, 대칭키를 저장/추출할 수 있고, 파일 형태로 저장되는 것을 알 수 있습니다.

2. JCE(Java Cryptography Extension)

JCE는 JCA보다 더 강력한 확장된 보안 기능을 제공합니다. 미국에서 보안상 이유로 2000년 이후에나 해외로 보급되었습니다.[5]

[그림11] JCA와 JCE 구조 설명도

[그림11]에서 보시는 것처럼 JCA(java.security 패키지)와 JCE(javax.crypto 패키지)가 분리되어 있는 것을 알 수 있습니다. JDK1.4 이상부터는 모두 기본으로 포함되어 있습니다.

JCE에 포함되는 클래스는 Cipher, KeyGenerator, SecretKeyFactor, KeyAgreement, MAC 등입니다.

여기서 SUN JCE와 BouncyCastle 을 비교하겠습니다. [3][4]

[표2] JCA/JCE 와 BouncyCastle 비교

[표2]에서 보시는 것처럼 BouncyCastle이 더 많은 알고리즘 지원 및 호환성이 좋은 것을 알 수 있습니다. 특히, 국산암호알고리즘 SEED를 지원하므로 더 많은 곳에 사용할 수 있습니다.[4]

※ '암호알고리즘사용제한' 제거 설정

- [참고8]에서 정책 파일을 다운로드하고, zip 압축을 푼 후에, local_policy.jar, US_export_policy.jar 파일을 $JAVA_HOME/jre/lib/security 에 복사하면 됩니다. [6][7][8]

※ 자바암호패키지(JCA/JCE)는 JDK1.4이상에서 기본으로 포함되어 있기 때문에 별도의 설치 방법이나 활용 방법을 설명하지 않습니다.

이번 글에서는 JAVA에서 기본으로 지원하는 암호 패키지인 JCA와 JCE에 대해서 알아보았습니다. 기본적인 키생성, 암호화, 전자서명 등은 JCA/JCE로 가능합니다. 하지만 JDK별로 호환이 안 되는 경우가 있고, 많은 알고리즘을 지원하지 않기 때문에 BouncyCastle 등의 암호 패키지를 사용하는 것이 좋겠습니다.

참고 목록

[1] https://en.wikipedia.org/wiki/Java_Cryptography_Architecture

[2] http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html

[3] https://blog.idrsolutions.com/2016/08/which-security-implementation-should-i-use-bouncy-castle-or-jca/

[4] http://bouncycastle.org/specifications.html

[5] https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States

[6] http://opensourceforgeeks.blogspot.kr/2014/09/how-to-install-java-cryptography.html

[7] http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#importlimits

[8] http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

문서 이력

- v1.00(2016.09.01) : 최초 등록

이 글에서는 오픈소스 소프트웨어 암호 라이브러리 종류와 특징에 대해서 알아보고, 실무에서 효과적으로 사용할 수 있는 암호 라이브러리에 대해서 알아보겠습니다.

 오픈소스 암호 라이브러리 종류 및 특징

[표1] 오픈소스 암호 라이브러리 종류 및 특징 [1]

1) 라이선스

[표1]은 '위키디피아 오픈소스 암호 라이브러리 비교 사이트'[1]에서 핵심적인 내용만 발췌한 것입니다. 보시면 아시겠지만, 오픈소스 암호라이브러리를 사용할 때 우선적으로 고려해야 하는 것은 '소프트웨어 라이선스' 입니다. 왜냐하면 '오픈소스 소프트웨어 라이선스'는 그 종류에 따라 관련 소프트웨어의 소스코드를 공개해야 하는 의무가 있기 때문입니다. (예를 들면, A라는 네트워크 프로그램을 개발하여 서비스하고 있었는데, 일부 암호 기능이 필요해서, GPL 라이선스를 가진 오픈소스 암호라이브러리를 포함(링킹)하여 프로그램을 수정하고 배포하였다면, A라는 네트워크 프로그램 전체 소스코드를 공개해야 합니다. 회사의 핵심 자산인 소스코드를 모두 공개해야 될 수 도 있습니다.)

따라서 오픈소스 소프트웨어에서 요구하는 의무사항 중에서 '소스코드 공개 의무'는 확실히 확인해야 합니다. [표1]에서 보시면 노란색으로 표시된 라이선스(Simplified BSD, MIT License, Boost Software License 1.0, ISC license, Apache Licence 1.0, 4-Clause BSD Licence)는 '소스코드 공개 의무'가 없습니다. 하지만 빨간색으로 표시된 라이선스(Sleepycat License, GNU GPL v2)는 해당 오픈소스와 같이 패키징(소스코드 포함, 수정, 링킹)된 제품의 모든 소스코드를 공개해야 합니다. 녹색으로 표시된 LGPL 라이선스는 라이브러리를 동적 링킹(DLL)하여 사용하면 '소스코드 공개 의무'가 없습니다.

여기서 GPL, LGPL, MPL, BSD, Apache 라이선스 등을 비교하여 '소스코드 공개 의무'에 대해 자세히 알아보겠습니다.

[표2] 오픈소스 소프트웨어 라이선스 소스 코드 공개 의무 [2]

위 [표2]를 보시면 GPL 라이선스는 완전 독립적(파이프, 소켓, 커맨드라인 입력값, fork, exec)으로 사용하지 않는 한 배포하는 프로그램의 소스코드를 모두 공개해야 합니다. 따라서 GPL 라이선스의 오픈소스는 독립적으로 사용이 가능하거나 또는 프로그램을 배포하지 않고 내부적으로 사용할 때에만 소스코드 공개 의무가 없습니다.

LGPL 라이선스는 수정된 OSS소스코드와 정적(Static) 링킹한 프로그램의 오브젝트 파일을 공개해야 합니다. 동적(DLL) 링킹한 경우는 공개 의무가 없습니다. 따라서 LGPL 라이선스도 대부분의 개발에서 라이선스 위반 없이 소스코드를 공개하지 않아도 충분히 활용할 수 있습니다.

MPL 라이선스는 수정된 OSS 소스코드만 공개하면 되고, BSD 라이선스, Apache 라이선스는 공개 의무가 없습니다.

이렇듯 오픈소스 소프트웨어를 사용해서 배포할 경우에, '소스코드 공개 의무'를 가지는데, AGPL(Affero GPLv3) 라이선스는 소프트웨어를 배포하지 않고 서버에서만 구현하여 동작하더라도 서버 프로그램의 소스코드를 모두 공개하도록 요구하고 있습니다. AGPL라이선스는 특히 주의해야 합니다.

[그림1] 오픈소스 소프트웨어 '소스코드 공개 의무' 설명도

[그림1]을 보시면 LGPL, MPL, BSD, Apache 라이선스가 자사의 프로그램 소스코드를 공개하지 않고 오픈소스를 사용할 수 있음을 쉽게 알 수 있습니다. GPL, APGL의 경우에는 오픈소스를 사용하면 자사의 프로그램까지 GPL, AGPL 라이선스 바뀌고 소스코드를 공개해야 함을 알 수 있습니다.

따라서 오픈소스 암호 라이브러리의 라이선스를 고려하면 Botan, Bouncy Castle, Crypto++, libsodium, OpenSSL, Libgcrypt 등이 용이하게 사용할 수 있는 오픈소스 암호 라이브러리라고 할 수 있습니다.

2) 개발 언어

두 번째 고려사항은 개발 언어 입니다. 자사 프로그램의 개발 언어를 고려하여 '오픈소스 암호 라이브러리'를 선택하시면 되겠습니다. [표1]에서 보시면 Java를 지원하는 라이브러리는 Bouncy Castle이 유일함을 알 수 있습니다. 물론 JNI(Java Native Interface)를 사용해서 C언어 라이브러리를 Java로 사용할 수 있게 할 수는 있지만 시간과 인력이 필요하겠습니다. 자사 프로그램이 Java로 구현되어 있다면 Bouncy Castle 라이브러리 사용하고, C++ 또는 C인 경우에는 다른 암호 라이브러리를 사용하면 되겠습니다.

추가적으로 아마존에서는 OpenSSL을 단순하게 만든 'S2N'이라는 C언어 암호 라이브러리를 배포하고 있습니다. [4][5] 또한 아마존 'AWS Encryption SDK for java'를 제공하고 있습니다. [6] Apache2.0 라이선스를 따르고 있습니다. 아마존 AWS 서비스를 사용하거나 단순하게 구현하고자 할 때 고려할 수 있겠습니다.

또한 구글에서 공개한 오픈소스 암호 라이브러리 'keyczer' 라는 라이브러리도 있습니다. Python, Java, C++을 지원하기 때문에 Python등 으로 구현하고자 할 때 고려할 수 있겠습니다. Apache 2.0 라이선스를 따릅니다. [7]

이 외에도 운영체제 또는 프로그래밍 언어 등에서 기본으로 제공하는 암호 라이브러리 들이 있습니다. 성능과 호환성, 관리 용이성, 개발 용이성 등을 고려하여 암호 라이브러리를 선택해야 하겠습니다.

3) 안전성

오픈소스 암호 라이브러리의 안전성 관련해서는 FIPS-140-2 인증을 받았는지 고려해야 합니다. [8] [9] [10] FIPS-140-2는 미국립표준기술연구소(NIST)와 캐나다통신보안국(CSE)에서 만든 '암호모듈에 대한 보안 요구 사항'입니다. 참고 [8]에 인증 받은 기업 목록과 제품명을 확인할 수 있습니다.(Libgcrypt는 Redhat에서 인증 받은 것임을 알 수 있습니다.) 따라서 위 목록에 포함된 제품이면 안정성이 검증된 제품이라고 할 수 있습니다.

국내에서는 국가정보원에서 관리하는 '암호모듈 검증기준'(KS X ISO/IEC 19790)이 있습니다. (KCMVP, 'Cryptographic Module Validation Program' 라고 합니다.) 검증 기준 대상은 국산암호알고리즘(ARIA, SEED, LEA, HIGHT)을 기준으로 관련 해시 알고리즘, 전자서명 알고리즘 등이 대상입니다. 국가∙공공기관은 인증 받은 국산 암호 알고리즘 라이브러리를 사용해야 하기 때문입니다. [11]

[표3] 국가 암호 검증 라이브러리 인증 업체

[표3]에서 보는 바와 같이 현재 32개 회사 또는 기관이 암호 라이브러리 검증을 받은 상태입니다. [11] 국가∙공공기관은 기관간 통신을 위해서는 기준('국가∙공공기관 암호 사용 기준', 대외비)에 따라 국산암호알고리즘과 인증된 제품을 사용해야 합니다. 또는 KISA에서 배포하는 국산암호알고리즘 소스코드를 이용해서 라이브러리를 구현하여 인증을 받아야 합니다. [12] 하지만 이 방법은 시간과 비용이 필요 합니다. 최근에 검증 기준 대상이 단순화 되어 이전보다 빠르게 인증을 받을 수 있겠으나 확인이 필요하겠습니다.

그리고 국가∙공공기관이라 하더라도 대외적인 업무에 상호 연동을 위해서는 AES 등 국제표준암호 알고리즘을 사용해야 할 수 있습니다. 이 경우에는 '오픈소스 암호 라이브러리'를 사용할 수 있고, FIPS-140-2 인증을 받은 라이브러리를 사용하는 것이 좋겠습니다.

일반 회사의 경우에도 FIPS-140-2 검증을 받은 '오픈소스 암호 라이브러리'를 사용하는 것이 더 안전하겠습니다만, FIPS-140-2 인증을 받지 않았다고 해서 '안전하지 않다'고 말할 수 없습니다. 인증을 받지 않은 오픈소스도 많은 사용자들의 참여로 안전성이 확보되어 있으며, 추가적인 보안 방법(wrapping 등)으로 안전하게 사용할 수 있습니다.

4. 지원 알고리즘 및 하드웨어 [1]

[표4] Key generation and exchange

[표4]에서는 지원하는 '키 생성 및 교환 알고리즘'을 보여주고 있습니다. 많이 사용하는 알고리즘은 DH, DSA, RSA, ECC 등 입니다.

[표5] Hash functions

[표5]에서는 지원하는 해시 함수를 보여주고 있습니다. 많이 사용하는 알고리즘은 MD5, SHA-1, SHA-2, REPEMD-160 등 입니다.

[표6] HMAC algorithms

[표6]에서는 지원하는 HMAC 알고리즘을 보여주고 있습니다. 대부분 지원을 하기 때문에 문제 없겠습니다.

[표7] Block ciphers

[표7]에서는 지원하는 블록 암호 알고리즘을 보여주고 있습니다. 많이 사용하는 알고리즘은 AES 와 3DES입니다.

[표8] Hardware-assisted support

[표8]에서는 하드웨어 지원 목록을 보여주고 있습니다. 관련 하드웨어 가속이나 장치 연동이 필요한 경우에 고려하면 되겠습니다.

[표9] Portability

[표9]에서는 지원되는 운영체제를 보여주고 있습니다. UNIX, Windows 계열을 대부분 지원하며, 모바일(WinCE, Android, IOS) 운영체제 지원 여부도 확인을 해서 선택하면 좋겠습니다.

라이브러리의 특성에 따라 지원하는 알고리즘과 하드웨어가 조금씩 다른 것을 알 수 있습니다. 위 사항들을 고려하여 해당 프로젝트에 적합한 라이브러리를 선택해야 합니다.

wolfCrypt, cryptlib, Libgcrypt, Bouncy Castle, Crypto++ 암호 라이브러리는 다양한 알고리즘과 하드웨어를 지원하는 것을 알 수 있습니다. lisodium 암호 알고리즘은 많은 알고리즘을 지원하지는 않지만 경량화되어 있다고 볼 수 있습니다.

5. 사용 용이성 [1]

[표10] Code Size

[표10]은 소스코드의 크기와 소스코드 비율을 보여줍니다. Bouncy Castle라이브러리가 소스코드 크기가 가장 크고, Crypto++와 libsodium 라이브러리가 소스코드에 비해 설명이 적은 것을 알 수 있습니다. 소스코드 크기가 크면 개발 시 복잡성이 증가하고, 설명이 적으면 이해도가 떨어지기 때문에 적절히 선택하면 좋겠습니다.

참고 목록

[1] https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries

[2] http://korea.gnu.org/people/chsong/copyleft/osswlg.pdf

[3] https://www.olis.or.kr/ossw/license/license/detail.do?lid=1069&mapcode=010068&currentPage=

[4] https://blogs.aws.amazon.com/security/post/TxCKZM94ST1S6Y/Introducing-s2n-a

[5] https://github.com/awslabs/s2n

[6] https://aws.amazon.com/ko/blogs/korea/how-to-use-the-new-aws-encryption-sdk-to-simplify-data-encryption-and-improve-application-availability/

[7] https://github.com/google/keyczar

[8] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm

[9] http://csrc.nist.gov/publications/PubsFIPS.html

[10] http://meshnet.co.kr/index.php?pgurl=board/bd_write&brno=25&member=&mode=V&wrno=208&page=1&head=&stype=&skey=

[11] http://www.nis.go.kr/AF/1_7_3_2.do

[12] https://seed.kisa.or.kr/iwt/ko/index.do