오픈소스 암호 라이브러리 비교 및 실무 고려 사항

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

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

Implementation	Software License	Development Language	FIPS 140-2 mode
Botan	Simplified BSD	C++	No
Bouncy Castle	MIT License	Java	No
Crypto++	Boost Software License 1.0, while the individual files in the compilation are all public domain	C++	Yes
libsodium	ISC license	C	No
OpenSSL	Apache Licence 1.0 or 4-Clause BSD Licence	C	No
Libgcrypt	GNU LGPL v2.1+	C	Yes
cryptlib	Sleepycat License and commercial license	C	Yes
Nettle	GNU GPL v2, GNU LGPL v3	C	No
wolfCrypt	GPL v2 and commercial license	C	Yes

[표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 라이선스 등을 비교하여 '소스코드 공개 의무'에 대해 자세히 알아보겠습니다.

종류	배포 시 소스코드 공개 의무 대상	기타
GPL	- 수정된 OSS(Open Souce Software) 소스코드 - 라이브러리 링킹(정적 또는 동적)한 프로그램의 소스코드 - 동일한 프로그램 파일에 포함 시 프로그램 소스코드 - 공유주소 영역 사용 시 프로그램 소스코드 - 플러그인 동적 링킹 시 프로그램 소스코드	* 파이프, 소켓, 커맨드라인 입력값, 독립적 호출(fork, exec)인 경우는 공개 의무 없음
LGPL	- 수정된 OSS 소스코드 - 정적(Static) 링킹한 응용프로그램 오브젝트 파일	* 동적(DLL) 링킹한 경우는 공개 의무 없음
MPL	- 수정된 OSS 소스코드
BSD License	없음
Apache License	없음
Affero GPLv3	- 서버에서 실행되는 소프트웨어 소스코드	* 클라우드서비스(SaaS 등)도 서버의 관련 소스코드를 공개해야 함 [3]

[표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]

(주)LG CNS, (주)NSHC, (주)드림시큐리티, (주)라온시큐어, (주)마크애니, (주)비티웍스, (주)샤코시스템, (주)시큐브, (주)시큐아이, (주)웹케시이노밸류, (주)윈스, (주)유넷시스템, (주)유비앤티스랩, (주)유비엠정보, (주)유비즈코아, (주)잉카인터넷, (주)케이사인, (주)케이엘매트릭스, (주)코스콤, (주)파수닷컴, (주)퓨쳐시스템, (주)한국무역정보통신, (주)한국전자인증, (주)한국정보인증, (주)한컴시큐어, 리턴트루(주), 이니텍(주), 킹스정보통신(주), 펜타시큐리티시스템(주), 한국전력공사, 고려대학교, 국민대학교

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

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

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

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

 

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

 

Implementation	EDH	DH	DSA	RSA	NTRU	DSS	ECC
wolfCrypt	Yes	Yes	Yes	Yes	Yes	Yes	Yes
cryptlib	Yes	Yes	Yes	Yes	No	Yes	Yes
Libgcrypt	Yes	Yes	Yes	Yes	No	Yes	Yes
Bouncy Castle	No	Yes	Yes	Yes	Yes	No	Yes
Crypto++	Yes	Yes	Yes	Yes	No	No	Yes
Nettle	No	No	Yes	Yes	No	No	Yes
libsodium	No	No	Yes	No	No	No	Yes

[표4] Key generation and exchange

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

 

Implementation	MD5	SHA-1	SHA-2	SHA-3	RIPEMD-160
Botan	Yes	Yes	Yes	Yes	Yes
Bouncy Castle	Yes	Yes	Yes	Yes	Yes
Crypto++	Yes	Yes	Yes	Yes	Yes
OpenSSL	Yes	Yes	Yes	Yes	Yes
Libgcrypt	Yes	Yes	Yes	Yes	Yes
cryptlib	Yes	Yes	Yes	Yes	Yes
wolfCrypt	Yes	Yes	Yes	Yes	Yes
Nettle	Yes	Yes	Yes	Yes	Yes
libsodium	No	No	Yes	No	No

[표5] Hash functions

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

 

Implementation	HMAC-MD5	HMAC-SHA1	HMAC-SHA2
Botan	Yes	Yes	Yes
Bouncy Castle	Yes	Yes	Yes
cryptlib	Yes	Yes	Yes
Crypto++	Yes	Yes	Yes
Libgcrypt	Yes	Yes	Yes
Nettle	Yes	Yes	Yes
wolfCrypt	Yes	Yes	Yes
libsodium	No	No	Yes

[표6] HMAC algorithms

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

  

Implementation	AES-128	AES-192	AES-256	AES-CBC	AES-ECB	AES-GCM	AES-CCM	AES-CTR	3DES CBC	Blowfish
cryptlib	Yes	Yes	Yes	Yes	Yes	No	No	Yes	Yes	Yes
Crypto++	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Libgcrypt	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Nettle	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
wolfCrypt	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No
Bouncy Castle[16]	Yes	Yes	Yes	Yes	No	Yes	Yes	Yes	Yes	Yes
libsodium	Yes	No	Yes	No	No	Yes	No	Yes	No	No

[표7] Block ciphers

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

 

Implementation	PKCS #11 device	Intel AES-NI
cryptlib	Yes	No
Crypto++	No	Yes
Libgcrypt	No	Yes
libsodium	No	Yes
wolfCrypt	No	Yes

[표8] Hardware-assisted support

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

 

Implementation	Supported Operating System	Thread safe
cryptlib	AMX, BeOS, ChorusOS, DOS, eCOS, FreeRTOS/OpenRTOS, uItron, MVS, OS/2, Palm OS, QNX Neutrino, RTEMS, Tandem NonStop, ThreadX, uC/OS II, Unix (AIX, FreeBSD, HPUX, Linux, OS X, Solaris, etc.), VDK, VM/CMS, VxWorks, Win16, Win32, Win64, WinCE/PocketPC/etc, XMK	Yes
Crypto++	Unix (OpenBSD, Linux, OS X, etc.), Win32, Win64, Android, iOS, ARM
Libgcrypt	All 32 and 64 bit Unix Systems (GNU/Linux, FreeBSD, NetBSD, MacOS X etc.), Win32, Win64, WinCE and more	Yes
libsodium	OS X, Linux, OpenBSD, NetBSD, FreeBSD, DragonflyBSD, Android, iOS, 32 and 64-bit Windows (Visual Studio, MinGW, C++ Builder), NativeClient, QNX, Javascript, AIX, Minix, Solaris	Yes
wolfCrypt	Win32/64, Linux, Mac OS X, Solaris, ThreadX, VxWorks, FreeBSD, NetBSD, OpenBSD, embedded Linux, WinCE, Haiku, OpenWRT, iPhone (iOS), Android, Nintendo Wii and Gamecube through DevKitPro, QNX, MontaVista, NonStop, TRON/ITRON/µITRON, Micrium's µC/OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, HP/UX	Yes

[표9] Portability

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

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

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

 

5. 사용 용이성 [1]

 

Implementation	Source Code Size(kSLOC = 1000 lines of source code)	Code Lines to Comment Lines Ratio
Bouncy Castle	1359	5.26
cryptlib	241	2.66
Crypto++	159	10.1
Libgcrypt	216	6.27
Nettle	111	4.08
libsodium	14	16
wolfCrypt	39	5.69

[표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