웹표준기반공인인증서비스 도입및구현기술안내서 2014. 9. 버전 1.0
목차 소개 1 웹표준기반공인인증서비스 1 공인인증서발급 3 공인인증서저장 7 공인인증서이용 13 웹서비스의보호 16 맺음말 21 부록 1. 보안토큰연동메시지규격 22 참고자료 25
소개 공인인증서는인터넷등온라인환경에서인증및전자서명용도로다양한분야에사용되고있다. 하지만공인인증서발급과이용을위해필요한소프트웨어가액티브X와같은웹브라우저플러그인으로제공됨으로인해많은이슈를야기하게되었다. 웹브라우저플러그인은웹브라우저의기능을확장시켜주는장점을제공하였지만, 호환성및보안성을저하시키는주범으로지목되었고웹브라우저업체또한플러그인을웹표준으로대체하려는노력을하고있다. 이에웹브라우저플러그인으로인해발생했던공인인증서비스호환성, 편의성등문제점을개선하고자웹브라우저플러그인을사용하지않고웹표준구현기술만을활용하는공인인증서발급및이용기술개발을추진하게되었다. 웹표준기반공인인증서비스 웹표준기반공인인증서비스란웹브라우저자체의확장기능을배제하고 W3C가제정한웹관련표준구현기술만을활용하여공인인증서를이용할수있도록구성한서비스를의미한다. 웹표준으로구현된공인인증서발급및이용서비스에대한일반적인모델은 [ 그림 1] 과같이표현될수있다. [ 그림 12] 웹표준기반공인인증서비스모델예시 1
기존에웹브라우저플러그인이처리하던공인인증서관련기능은 HTML5, 자바스크립트등웹표준구현기술로구현되어웹브라우저가담당하게됨으로써사용자는웹브라우저접속만으로공인인증서를이용할수있도록이용환경이구성된다. 웹표준으로구현된공인인증서비스는각종공인인증서저장매체와의연동을통해공인인증서의안전한저장및이용편의성을제공한다. 웹표준기반공인인증서비스를위해서는공인인증기관은공인인증서발급을별도통신채널과프로토콜을사용하지않고웹브라우저만으로발급할수있도록시스템을갖추고, 전자거래, 전자민원등이용기관은발급 저장된공인인증서를이용하여전자서명문을생성할수있도록웹페이지내에기능을구현하여야한다. 또한공인인증기관및보안업체는안전한공인인증서저장을위해다양한저장매체를도입하고웹표준과연동하여야한다. 2
공인인증서발급 기존에웹브라우저플러그인을통해발급하던공인인증서를웹표준구현기술만으로발급하기위해서는공인인증기관의발급시스템과프로토콜의변경, 클라이언트인웹브라우저에서의발급기능구현이필요하다. 공인인증기관은 HTTP를통해발급할수있도록발급방식을변경하고, 웹브라우저에서는전자서명키쌍과인증서요청양식의생성, 응답을처리하여저장하는기능등을구현하여야한다. 1. 서버측면 공인인증기관은웹브라우저만으로공인인증서를발급하기위해서는발급시스템에대한변경이필요하다. 공인인증서의발급과관리는발급시스템과클라이언트간의요청과응답을위한메시지를통해이루어지며, 이때메시지는특정프로토콜이아닌 HTTP( 또는 HTTPS) 를통해전송되어야한다. HTTP Transfer for the CMP 기존공인인증서발급시스템을활용하고웹표준을적용할수있는방법은 HTTP Transfer for the Certificate Management Protocol 를준용하는것이다 [RFC6712]. 공인인증서발급 관리와관련한모든요청과응답은 HTTP를통해 PKI 메시지로처리가능하며기존발급시스템의활용또한가능하다. [RFC6712] 를준용하기위해서, CMP(Certificate Management Protocol) 메시지는반드시 HTTP를사용하여야하며 HTTP/1.0, HTTP/1.1을모두지원해야한다. 또한 GET이아닌 POST방식만을사용하여메시지를전송하여야한다. PKIMessage를전송하는동안 HTTP 헤더의콘텐츠타입으로 application/pkixcmp으로설정하여야한다. DER 인코딩 [ITU.X690.1994] 된 PKIMessage[RFC4210] 는 HTTP POST 요청의본문에담아보내며 HTTP 요청이성공하면서버는 HTTP 응답에 CMP 응답메시지를담아보낸다. 이경우 HTTP 응답코드는 200이어야하며요청성공과관련한다른응답코드 (2XX) 는이경우사용해선안된다. 이와관련한더상세한표준내용은 [RFC6712], [RFC4210] 등의표준문서를참고하면된다. CSR 등발급방법 CMP 를 HTTP 를통해전송하는방법이외에도 SSL 인증서발급시이용되는 CSR(Certificate Signing Request), HTML5 keygen 태그를활용한방법등이있다 [PKCS10][Keygen]. 3
2. 클라이언트측면 웹브라우저에서공인인증서발급기능을구현하기위해서는전자서명키쌍생성, 전자서명생성 검증, 개인키암호화, 전자서명대상원문의축약등을위해암호화알고리즘구현과인증서요청및응답메시지처리등을위한기능구현이필요하다. 자바스크립트암호알고리즘구현 웹표준구현기술만으로공인인증서발급및이용이가능하기위해서는자바스크립트를 사용하여암호라이브러리를개발하거나 W3C에서표준화하고있는웹암호 API(Web Cryptography API) 를사용하여개발하는방법이있다. 공인인증서발급및이용에필요한암호라이브러리및 ASN.1 등을자바스크립트만으로 구현한다수의오픈소스가존재하며, 필요시다음과같은오픈소스를참조할수있다. SJCL (Stanford Univ.): http://bitwiseshiftleft.github.io/sjcl/ Crypto-js (Google): http://code.google.com/p/crypto-js/ MSR JavaScript Cryptography Library (Microsoft) : http://research.microsoft.com/en-us/downloads/29f9385d-da4c-479a-b2ea-2a7bb335d727/ Forge (Digital Bazaar): http://digitalbazaar.com/forge/ PidCrypy (Versaneo): https://www.pidder.de/pidcrypt/ CMP 요청및응답메시지처리공인인증서발급을위해서는암호라이브러리외에도기존 TCP 방식으로구현되어있는 CMP를 HTTP 방식으로전송하도록구현해야한다. 아래는웹표준을사용해서구현한 CMP의일부이다. CMP 요청을위한 PKIMessage는 Base64 인코딩되어 POST 데이터로서버에전송된다. CMP 응답또한 Base64 디코딩하여메시지를처리한다. self.ir(refnum, authcode, function(asn) { if (asn instanceof cmp.error) { resultcallback(asn); return; data = asn1.toder(asm).getbytes(); HTTPTransfer.send( self.url.irip, HTTPTransfer.pkiReq, data, function(version, flags, messagetype, result) { if (version instanceof cmp.error) { resultcallback(version); return; 4
try { self.decodemessage(result); catch (ex) { resultcallback(new cmp.error(ex)); return; if (!cmp.testissue) doconf(resultcallback); else { resultcallback(self.certandkey); ); // end of send irip ); // end of ir 웹암호 API 활용 웹암호 API의경우현재표준규격제정이진행중이며, 일부최신웹브라우저에는관련 기능이탑재되어있어사용이가능하며아래의웹사이트에서웹암호 API에대한정보를 얻을수있다. 인터넷익스플로러 : http://msdn.microsoft.com/ko-kr/library/ie/dn265046(v=vs.85).aspx 크롬 : https://goo.gl/ovgtrq https://code.google.com/p/chromium/issues/detail?id=245025 파이어폭스 : https://bugzilla.mozilla.org/show_bug.cgi?id=865789, https://nightly.mozilla.org/ 사파리 ( 웹킷 ): https://bugs.webkit.org/show_bug.cgi?id=122679, http://nightly.webkit.org/ 아래와같이웹암호 API를사용하여전자서명키쌍을생성할수있다. var subtle = window.crypto.subtle; var publickey; var privatekey; var extractable = false; var algorithmkeygen = { name: "RSASSA-PKCS1-v1_5", moduluslength: 2048, publicexponent: new Uint8Array([0x01, 0x00, 0x01]), // Equivalent to 65537 hash: { name: "SHA-256", ; 5
subtle.generatekey(algorithmkeygen, extractable, ['sign']).then( function(e) { publickey = new crypto.key(e.publickey); privatekey = new crypto.key(e.privatekey); resultcallback ( { publickey: publickey, privatekey: privatekey );, function(e) { resultcallback(new crypto.error(e)); ); 생성된키쌍을이용하여전자서명을수행하는것은다음과같다. var subtle = window.crypto.subtle; var algorithmsign = { name: "RSASSA-PKCS1-v1_5" ; plain = crypto.util.stringtoarraybuffer(input); Subtle.sign(algorithmSign, privkey, plain.buffer).then( function(e) { resultcallback(crypto.util.arraybuffertostring(e));, function(e) { resultcallback(new cryoto.error(e)); ); 웹암호 API 에관한보다상세한내용은 W3C 페이지를참고할수있다 [WebCrypto]. 6
공인인증서저장 웹브라우저플러그인기반의기존환경에서는주로하드디스크와이동식디스크내의 /NPKI/ 디렉토리하에공인인증서가저장되었다. 하지만웹표준환경에서는파일시스템에대한접근이자유롭지않기때문에기존방식으로저장하는것은어렵다. 웹표준방식으로공인인증서를발급받은후저장할수있는저장매체는웹브라우저내의웹저장소, 보안토큰, 소프트토큰, 스마트인증등이있다. [ 그림 13] 공인인증서저장매체 1. 웹스토리지 (Web Storage) HTML5의웹스토리지 (Web Storage) 는 HTML5 표준으로웹사이트의데이터를웹브라우저에저장할수있는새로운자료구조로기존쿠키 (Cookie) 의단점을개선하기위해개발되었다 [WebStorage]. 현재웹스토리지는모든웹브라우저에서지원가능하며저장된데이터는서버로전송되지않는다. [ 그림 14] 웹스토리지 HTML5에서는웹스토리지로두개의객체를제공한다. 하나는세션단위로데이터를저장하는세션스토리지 (Session Storage) 와만료기간이없는로컬스토리지 (Local Storage) 이다. 세션스토리지는데이터가영구적으로저장되지않아웹브라우저종료시데이터가삭제 7
되며저장된데이터에대해서는탭브라우징, 새창에서도서로별개로취급한다. 로컬스토리지는명시적으로지우지않는한영구적보관이가능하다. 웹스토리지는동일출처정책 (Same-Origin Policy, SOP) 에따라해당도메인 (Origin) 만이접근가능한저장소이다. 이는프로토콜, 호스트, 포트중하나라도다르면별도의공간으로인식한다는것을의미한다. 저장가능한데이터의용량은보통 Origin당약 5MB까지가능하며 5MB를넘어설경우, QUOTA_EXCEEDED_ERR 오류가발생하고추가공간을요구할수없다. 문자열 (UTF-16) 만저장가능하며 Object 타입을저장하는경우 tostring() 을호출한형태로저장된다. 로컬스토리지는 window 객체의 localstorage 컬렉션을통해저장및조회가가능하다. 데이터는 key/value 쌍으로구성되며아래와같이 setitem() 과 getitem() 으로값을저장하거나가져올수있다. key와 value 모두 string으로저장되며 setitem() 은기존아이템이있을경우덮어쓰고, getitem() 으로값을찾지못하는경우에러를발생하지않고 null을리턴한다. 웹스토리지는클라이언트디바이스에직접저장되고네트워크로전송되지않기때문에네트워크레벨에서는안전할수있다. 웹스토리지는물리적으로는파일로저장되며, 사용자계정하위디렉토리에저장된다. 페이지가로드되기전에웹브라우저는물리적으로저장되어있는데이터를읽어메모리에올려둔다. 웹브라우저개발자도구등을통해웹스토리지에저장된데이터접근이가능하며, 수정및삭제가가능하다. [ 그림 15] 로컬스토리지에공인인증서저장예 공인인증서와개인키를웹스토리지에저장하고자하는경우, 세션스토리지는데이터가영구적으로저장되지않아사용이어렵다. 로컬스토리지의경우에도사용자가웹브라우저메뉴등을통해삭제하거나웹브라우저개발도구등을통해임의수정이가능하다. 따라서웹스토리지에공인인증서를저장하는경우추가적인암호화, 사용자인증등보안수단을강구하여야한다. 또한물리적으로는사용자계정하위디렉토리에파일로저장되며웹암호 8
API 로생성된 Key 객체의경우저장되지않아웹암호 API 를이용하는경우데이터변환 등주의가필요하다. 2. 인덱싱된데이터베이스 (IndexedDB) 웹스토리지가용량이작고구조화된데이터를다루기엔부족하기때문에웹브라우저에서많은양의구조화된데이터를영구적으로저장하여검색및이용할수있도록만든 HTML5 API가인덱싱된데이터베이스 (IndexedDB) 이다. 현재 IE 8, 9 버전및하위버전은지원되지않는다. IndexedDB는기본적으로자바스크립트객체 (Object) 를저장하며기존 RDBMS( 관계형데이터베이스관리시스템 ) 와는다르게 Object Store를만들고자바스크립트를통해저장한다. SQL과는개념이비슷하나쿼리대신 Index를사용하는것이차이점이다. 웹스토리지와마찬가지로동일출처정책에따라해당도메인만접근가능한저장소이다. 개개의데이터항목의크기나데이터베이스자체의크기제한을두지않지만, 브라우저는저장용량제한을둘수도있다. [ 그림 16] IndexedDB 에공인인증서저장예 웹스토리지와마찬가지로클라이언트디바이스에직접저장되고네트워크로는전송되지않는다. IndexedDB 또한웹브라우저개발도구에서저장된데이터에대한열람및삭제가가능하다. 따라서웹스토리지와마찬가지로안전한저장을위해서는추가적인암호화, 사용자인증등다양한보안수단을강구하여야한다. 웹암호 API를이용하는경우, 키객체저장이가능한 IndexedDB를저장소로이용할수있다. IndexedDB에웹암호 API를이용해생성된키객체등을저장하는경우웹스토리 9
지와는달리별도의데이터변환등이필요치않다. 웹브라우저내에공인인증서를저장하는경우 IndexedDB 가지원되는경우에는웹암호 API 적용등을고려하여웹스토리지보다는 IndexedDB 를우선적으로사용할것을권고한다. 3. W3C 파일 API 공인인증서의발급과저장에 W3C 웹표준의파일 API를사용할수있다 [FileAPI]. 발급받은공인인증서와개인키를 [PKCS12] 로변환한후 mime-type을 application/x-pkcs12 로설정하여사용자단말기로다운로드할수있으며, 사용자는다운로드된 [PKCS12] 파일.p12 또는.pfx 파일을웹브라우저에서이용할수있다. mime-type 설정을이용한다운로드방식이외에도 W3C File Writer API를이용할수있으나, 현재표준화가진행중에있어일부웹브라우저에서만한정적으로지원되고있다 [FileWriter]. File Writer API를이용하는경우사용자가파일다이얼로그박스로파일을선택하는것보다웹브라우저를이용하여비교적자유롭게.p12, pfx 파일을처리할수있다. 또한웹브라우저의드래그앤드롭기능과결합하여사용자단말기의파일시스템에 [PKCS12] 로저장한인증서를웹브라우저에서편리하게이용할수있다 [Drag&Drop]. 드래그앤드롭은대부분의웹브라우저에서지원가능하며, 이용페이지에서전자서명이요구되는경우 [PKCS12] 파일을사용자가드래그앤드롭으로이용페이지에넣고비밀번호를입력함으로써전자서명처리가가능해진다. 파일형태로공인인증서와개인키를저장하여이용하는경우, 파일에대한관리를전적으로사용자가함으로인한불편함등이발생할수있으며, 복사 유출 분실등에대한위험이여전히존재한다. 4. 보안토큰 (HSM) 보안토큰은하드웨어장치내에서공인인증서를생성및저장하고전자서명을수행하는 USB 인터페이스를갖춘개인용휴대저장매체를말한다. 보안토큰은하드웨어칩기반으로공인인증서및개인키를보관하고전자서명등암호연상기능을수행함에따라전자서명생성요청에대해보안토큰은내부의개인키를이용하여전자서명을생성하고결과값만을보안토큰외부로전달한다. 결과적으로공인인증서와관련한모든연산을보안토큰칩내부에서수행함으로써개인키에대한유출위험이없다. 보안토큰을이용하기위해서는표준 API를사용하여야한다 [PKCS11]. 따라서하드웨어장치에대한드라이버프로그램과이용을위한표준 API의설치가필요하다. 또한웹페이지내데이터에대해전자서명하기위해서는웹브라우저와의연동이필요하다. 10
현재별도소프트웨어없이웹브라우저자체만으로보안토큰하드웨어매체와웹브라우저간에연동하는것은불가능하다. 이와관련한표준제정논의가진행되고있으나현재로서는별도의소프트웨어설치가필요하며, 웹브라우저플러그인을설치하고이용하거나로컬서버로작동하는별도소프트웨어를설치하는방법, 연동을위한별도의외부서버를활용하는방법등이있다. 본가이드라인에서는플러그인, 외부서버이용은배제하고로컬서버를활용하는방법에대해기술한다. 로컬서버방식은웹브라우저가로컬PC에설치된소프트웨어에접속하여전자서명을요청하고응답을처리하는방식이다. 유럽에서많이사용되고있는 e-id에서도이와같은방식으로 e-id 카드리더기와웹브라우저간연동을처리한다 [e-id]. 사용자 PC에설치되어웹브라우저와연동되는보안토큰클라이언트소프트웨어는단일소프트웨어로구현될수있으며, 다음과같이편의상여러개의모듈로나뉠수있다. 보안토큰클라이언트 : 단일소프트웨어또는모듈로구현된보안토큰을이용하기위해필요한온전한형태의클라이언트프로그램을칭함클라이언트프로그램 : 보안토큰클라이언트의부분또는모듈로써웹브라우저와의통신을담당하는부분을칭함클라이언트구동프로그램 : 보안토큰하드웨어매체와의연결을담당하는부분을칭함사용자인터페이스 (UI) : PIN 입력등사용자에게필요한인터페이스제공 [ 그림 17] 보안토큰과웹브라우저간연동모델 웹브라우저는보안토큰클라이언트에 HTTP( 또는 HTTPS) 접속후 JSON 타입의명령어를 전달함으로써보안토큰을이용한공인인증서비스를제공하게된다. 로컬서버와통신하기 위한포트는 8443 포트를사용하며, XMLHTTPRequest( 이하 XHR) 등을활용한다. target.contentwindow.postmessage(json-message, https://127.0.0.1:8443); 웹브라우저와보안토큰클라이언트간의통신메시지형식은부록 1 에기술되어있다. 11
5. 소프트토큰 (Software HSM) 공인인증서를안전하게저장 이용하는보안토큰과같은물리적하드웨어매체가작동하는방식을소프트웨어로구현한것이소프트웨어방식의보안토큰즉, 소프트토큰이다. 소프트토큰을웹브라우저와연동하기위해서는보안토큰과동일한연동방식을이용할수있으며, 별도의연동방식을이용할수도있다. 6. 스마트인증 (Mobile HSM) 스마트인증은스마트폰과같은모바일기기의 USIM, ese 등보안모듈을모바일통신을통해 PC와같은타기기에연결하여전자서명생성키등비밀정보를안전하게저장및보관하고키생성및전자서명생성등을처리하는하드웨어와소프트웨어를총칭하는것이다. 기존스마트인증서비스는보안토큰인터페이스와동일하게만들고웹브라우저플러그인을통해서비스가되었으나, 플러그인없이동작하기위해서는별도의연동방법이필요하다. HTML5 WebRTC를활용한방법, 외부의서버를통한방법등다양한연동방법이가능하다 [WebRTC]. 스마트인증의일반적인절차는다음과같다. 1. 사용자는웹페이지에서스마트인증을통해전자서명을요청한다. 2. 서버또는웹페이지에서스마트앱으로연결을요청하고서명하고자하는데이터를전송한다. 3. 사용자는스마트앱을통해전자서명을생성하여제출한다. [ 그림 18] 스마트인증이용절차예시 12
공인인증서이용 웹브라우저를통해발급된인증서를이용하기위해서는각저장매체에저장된인증서목록을조회하고해당인증서를이용하여전자서명문을생성하는기능의구현이필요하다. 하지만웹의보안정책, 동일출처정책으로인해브라우저내의웹스토리지에저장된인증서를이용하는경우제약이발생한다 [RFC6454]. 이에본가이드라인에서는웹스토리지에공인인증서를발급 저장한경우동일출처 (Same-Origin) 과교차출처 (Cross-Origin) 환경에서공인인증서를이용하는방법을기술한다. 1. 동일출처환경에서의공인인증서이용 동일출처정책은한출처 (Origin) 에서로드된문서나스크립트가다른출처자원과상호작용을하지못하도록제한하는보안정책이다. 두웹페이지의프로토콜, 호스트, 포트가동일하면동일출처 (Same-Origin) 이며, 하나만달라져도다른출처로처리된다. 공인인증서저장매체로웹스토리지를이용하는경우는동일출처정책영향을받게되며, 이로인해공인인증서를발급한웹사이트 ( 이하발급사이트 ) 와공인인증서를이용하는웹사이트 ( 이하이용사이트 ) 가상이한경우발급된공인인증서를조회 이용하지못하는제약사항이발생한다. 따라서동일출처환경으로만공인인증서발급과이용을제한하거나, 동일출처환경에서발급된공인인증서를타웹사이트에서이용할수있는기능을제공할수있다. 이경우웹스토리지에발급된인증서를 [PKCS12] 형식의파일로내보내고타웹사이트에서해당파일을불러와사용하는등다양한방안이이용될수있다. 공인인증서의발급과저장이 [PKCS12] 로이루어지고, 이용사이트에서 [Drag&Drop] 으로공인인증서가이용되는경우, 동일출처및교차출처여부와관계없이이용이가능하나공인인증서의저장및관리에대해사용자의주의가필요하다. [ 그림 19] Same-Origin 환경에서의공인인증서이용 13
2. 교차출처환경에서의공인인증서이용 웹메시징 (Web Messaging) HTML5의웹메시징은기존 HTML에없던메시지통신방식으로 HTML5에서새로추가되었다 [WebMessage]. 이는일반적인 Windows API에서사용하던메시지이벤트를이용하는방식과거의동일한형태이다. 웹메시징을이용하는일반적인방식은다음과같다. 1. postmessage() 를이용하여메시지를목표의메시지큐에넣는다. 2. dispatch를통하여메시지큐에서메시지를뽑아서목표에전달한다. 3. onmessage 이벤트핸들러에서메시지를받아서처리한다. [ 그림 20] Web Messaging 메시지통신기능 웹메시징은 cross-document messaging 과 channel-messaging 두가지방식이있으며, postmessage 메소드의정의는다음과같다. windows.postmessage(message, targetorigin, [ports]); message : 송신메시지 targetorigin: 목적지도메인, 메시지수신도메인지정, 특정도메인이아닌경우 * 지정 ports: 메시지포트 ( 생략가능 ) 웹메시징을활용한공인인증서이용발급사이트와이용사이트가다른교차출처환경하의이용사이트에서발급사이트의웹스토리지에발급된공인인증서를이용하기위해서 Web Messaging 표준이활용될수있다. 발급사이트와이용사이트간에 postmessage 통신을통해발급사이트에서생성된전자서명문을이용사이트에전송함으로써공인인증서를이용할수있다. [ 그림 21] 과같이이용기관A는발급페이지로부터공인인증서를발급받아저장하고있고, 이용기관B는이용페이지만있는경우, 웹메시징을활용한공인인증서이용방법은다음과 14
같다. 1. 이용기관B는이용기관A에인증서목록을요청한다. 2. 이용기관A는정당한요청여부를검증한후이용기관B에인증서목록을전송한다. 3. 사용자는이용기관B에서사용할인증서를선택한후비밀번호를입력한다. 4. 이용기관B는이용기관A에선택한인증서, 비밀번호와서명원문을전송한다. 5. 이용기관B는전자서명을수행하고전자서명문을이용기관B로전송한다. 6. 이용기관B는서버로전자서명문을전송한다. 위의이용절차에서이용기관A와이용기관B간의통신은모두웹브라우저내에서웹메시징을통해서이루어지며, 외부서버등으로전송되지않는다. [ 그림 21] 공인인증서상호연동 15
웹서비스의보호 웹표준으로구현되는공인인증서발급및이용기능은웹취약점에대한보호, 자바스크립트소스에대한보호등콘텐츠보호기능을필요로한다. 또한공인인증서를웹브라우저내에저장하는경우피싱, 파밍등에대한대비가필요하다. 이와같은보안위협에대처하기위해서아래와같은보호수단을적용할수있다. 1. 자바스크립트샌드박스 샌드박스는외부로부터들어온프로그램이보호된영역에서동작해시스템이부정하게조작되는것을막는보안형태이며웹브라우저에서자바스크립트를실행할때도역시샌드박스환경에서실행된다. 최근의웹사이트들은자신의웹페이지에트위터, 페이스북등이제공하는콘텐츠를 iframe을이용하여통합제공하고있다. 이러한사용자경험은웹사이트보안에문제점을야기할수있다. iframe 태그의 sandbox 속성은 iframe 내에삽입된페이지에다음과같은추가적인제한을걸수있다. 실제존재하는않는도메인 (Origin) 에속한것으로간주플러그인실행금지자바스크립트사용금지폼요소에의한페이지호출금지 이러한샌드박스제한은너무엄격한것이기때문에 allow-script( 자바스크립트허용 ), allow-same-origin( 동일도메인에소속된리소스이용 ) 등의속성값설정을통해샌드박스 제한을완화할수있다. 2. 웹콘텐츠보호 (W3C CSP) 웹콘텐츠의변경을통한악의적인공격행위에대응하기위해서는기본 SSL을통한채널암호화이외에도다음항목에대한대응이필요하다. 악의적인 HTML 태그삽입 (iframe, Object, Embed 등 ) 악의적인 Layer 삽입 Script에대한 Cross Domain Include를악용한공격 하이퍼링크에대한위변조 사용자입력으로변경되지않는 Hidden 속성의 Input value 에대한변경 16
HTML5 표준의 CSP(Content Security Policy) 는 XSS(Cross Site Scripting) 와데이터끼워넣기 (Data Injection) 같은공격을감지하거나경감시키기위해서보안층 (Security Layer) 을추가한것이다. 이런류의공격은정보를갈취하거나악성코드를유포시키려는등의모든목적을위해이용된다. [ 그림 22] 콘텐츠보안정책 (CSP) CSP는하위호환성에중점을둬서디자인되어이것을지원하는서버에지원하지않는브라우져가잘작동되고그반대도가능합니다. CSP를지원하지않는브라우저는 CSP를무시하고, 단순히웹콘텐츠에대한표준동일출처정책을기본값으로해서평소대로작동합니다. 웹사이트가 CSP 헤더를제공하지않으면마찬가지로브라우저들은동일출처정책표준을사용합니다. CSP는웹서버에 Content-Security-Policy HTTP를설정하는것만큼쉽게설정할수있다. Content Security Policy을설정하는것은어떤정책을실행하게할것인지를결정하는것을포함하고이런정책실행부분을 Content-Security-Policy 헤더를사용해서정책을실행하게설정하는것이다. 3. 자바스크립트코딩 자바스크립트가웹브라우저캐쉬에저장되지않도록 HTTP 헤더에캐쉬를방지할수있도록설정하여야한다. 이를위해 HTTP 1.1에서지원되는 Cache-Control 헤더, HTTP 1.0의 Pragma: No-Cache 헤더를설정하면된다. <HTML><HEAD> <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <META HTTP-EQUIV="Expires" CONTENT="-1"> </HEAD><BODY> </BODY> </HTML> 17
자바스크립트는접근수정자 (private, public, protected) 를제공하지않기때문에, 기본적으로모든객체의속성 ( 변수, 메서드 ) 은 public이다. 변수나메소드를외부에서접근할수없는 private으로만들기위해서클로져 (Closure) 가사용하여유사하게구현할수있다. 자바스크립트코드를최적화하기위해다음과같은도구들을사용할수있다. Google Closure : https://developers.google.com/closure/ YUI Compressor : http://yui.github.io/yuicompressor/ UglifyJS : https://github.com/mishoo/uglifyjs JSLine : http://jslint.com/ Packer : http://dean.edwards.name/packer/ 또한중요데이터를담은변수를더이상사용하지않는경우, 즉시값을초기화하여악용되지않도록하여야한다. 자바스크립트는변수에대한명시적인타입이없고, 변수에값을할당함으로써초기화한다. 함수내의지역변수는함수가끝날때변수에 null값할당, return 값이있는함수에서는 finally에서해당변수에 null값할당등을통해변수에대한메모리해제가가능하다. 4. 자바스크립트동적로딩 근래의웹페이지들은 Ajax(Asynchronous Javascript and XML) 이사용자에게편리한 UI를제공함에따라더욱많은기능들을 Ajax으로적용하고있는추세이다. 이에따라하나의페이지를구성하는데필요한자바스크립트모듈의개수도증가하게되었고, 자바스크립트모듈개수와크기의증가는웹브라우저가웹페이지를로딩하는데걸리는시간이지연되는문제를발생시킨다. 또한해당페이지에서는전혀사용되지않는데도불구하고모든자바스크립트를로딩하는문제도있다. 이러한문제를해결하기위한방법이자바스크립트파일을동적으로로딩하여필요한경우에만사용하도록할수있다. 동적으로자바스크립트를로딩하는방법중하나는 script 태그를자바스크립트코드내에서직접생성하는것으로 script 태그를생성하고 src에로딩할주소를넣음으로서로딩하게된다. script 태그를사용하지않고자바스크립트를로딩하는방법으로 XHR을사용하는방법이있다. XHR을이용하여서버에파일을요청한후요청한파일을응답으로받은다음이를 eval() 함수를사용하여로딩하는것이다. 이외에도 iframe이나 document.write() 를이용하는등자바스크립트를동적으로로딩하기위한다양한방법들이존재한다. 18
5. 자바스크립트난독화 (Obfuscation) 자바스크립트는일반적으로클라이언트측언어로사용되기때문에소스코드가공개되는단점을가지고있다. 개발된소스코드를도용당할문제및숨기고자하는로직이나알고리즘이그대로드러나는문제등이있다. 난독화 (Obfuscation) 는프로그래밍언어로작성된코드에대해읽기어렵게만드는작업이다. 프로그램에사용된아이디어나알고리즘등을숨기고자하는경우사용되며, 프로그램의일부또는전체를변경한다. 난독화는코드의가독성을낮추어역공학 (Reverse Engineering) 에대비하는것으로무단복제등을방지할수있다. 또한난독화는보안장비를우회하려는악성코드에서도많이사용되고있는추세이다. 난독화기법으로는변수명등문자열을다른문자열로대체하여사람이해석하기어렵게하는방법, 소스코드를잘게잘라변수에저장했다가재조합하는방법, eval() 함수, XOR 8bit ASCII 인코딩을이용하는방법등다양한방법이있으며, 나름의장단점을가진다. 일부난독화기법은소스를해독하기어렵게하는기능이외에도웹브라우저개발도구에서디버깅이어렵게하거나, 코드의유효기간설정, Injection 공격등에대한자체대응기능등다양한기능을포함하고있으므로이러한기능을적절히활용함으로써자바스크립트소스를보호할수있다. 자바스크립트코드난독화는소스코드보호를위한최소한의요구사항이며소스코드보호를위한다양한보호수단과함께사용되어야한다. 6. 자바스크립트암호화 (Javascript Encryption) 자바스크립트이외에자바스크립트소스를보호하기위한방법으로소스코드암호화를고려할수있다. 자바스크립트코드를암호화하기위해서는웹브라우저에서암호화를위한키를생성하고서버와키를안전하게공유함으로써자바스크립트코드를암호화할수있다. 이와관련한일반적인절차는아래와같다. 웹브라우저에서자바스크립트를암호화하기위한암호화키생성서버의공개키로암호화키를암호화하여전송서버는해당자바스크립트코드를암호화하여웹브라우저에전송웹브라우저에서는암호화키를이용하여자바스크립트복호화후이용 하지만자바스크립트특성상웹브라우저에서정상적인서비스이용을위해서는반드시복호화 되어야하고복호화된자바스크립트코드, 암호화키등의값은웹브라우저개발자도구 19
등을통해노출될수있다. 따라서자바스크립트암호화는일반적인데이터암호화와는달리 웹서버 - 웹브라우저간의통신구간에서만제한적으로보안을제공한다고볼수있다. 암호알고리즘은 AES, SEED 등블록암호알고리즘을이용할수있다. 7. 자바스크립트무결성확인 자바스크립트는웹브라우저에서해석되어실행되는인터프리터언어의특징으로인해웹브라우저개발도구등에서모든소스코드가노출되는것이외 DOM 객체에대한위변조, 자바스크립트의변조등이가능하다. 이러한자바스크립트소스코드에대한위변조는보안문제로이어지며, 이를방지하기위해서는자바스크립트실행시소스코드가변조되지않았는지무결성을검사해야한다. 자바스크립트무결성검사방식은서버측면검사 (Server-side Integrity Test) 와클라이언트측면검사 (Client-side Integrity Test) 로나누어진다. 서버측면검사 : 서버에서콘텐츠배포시해당콘텐츠에대한무결성정보 (hash 등 ) 를포함하여배포하고, 클라이언트에서다음페이지요청시또는주기적으로서버에검증요청을하는방식이다. 무결성검증을위한정보가서버에있고, 서버가최종검사의주체라는점에서상대적으로보안이우수하지만, 검증요청에대한부가적인통신이필요하고, 동적인페이지인경우콘텐츠무결성정보의생성이복잡해진다는단점이있다. 클라이언트측면검사 : 콘텐츠배포시클라이언트에서무결성정보를생성하고, 이를실시간또는주기적으로검사하는방식이다. 무결성에문제가없는경우별도의통신이필요하지않지만, 무결성을검사하는모듈이클라이언트에있기때문에해당모듈에대한추가적인보안수단이필요하다. 이외에 Web Crypto API 이용이가능한경우, localstorage 등웹브라우저내저장소에자바스크립트소스코드를저장한후해쉬를통해무결성을검증하는방법이 W3C 표준화과정에서사용례로써논의되고있다. 20
맺음말 웹표준기반공인인증서비스는운영체제, 웹브라우저, 단말기에상관없이웹을통해공인인증서를발급받아이용하고자하는모든서비스에적용가능하다. 공인인증서이용방식을웹표준으로구현함으로써사용자가별도의공인인증서소프트웨어를설치하지않아도되므로이와관련한이용불편, 접근성및보안문제등이해소될것이다. 더나아가서는데스크톱PC, 스마트폰, 스마트TV 등웹브라우징이가능한모든환경에서공인인증서를이용할수있는환경이만들어지게될것으로기대된다. 다만웹을통해서비스되고웹표준구현기술인자바스크립트를이용함으로인해발생할수있는웹취약점관련한보안문제에대해서는적절한대비가필요하다. 21
부록 1. 보안토큰연동메시지규격 웹브라우저와보안토큰클라이언트간의메시지형식은다음과같다. 1. 토큰목록요청 요청메시지 { messagenumber:0, sessionid:"string", operation:"gettokenlist" 예시 ) messagenumber:0,sessionid:"a1234",operation:"gettokenlist" 응답메시지 { messagenumber:0, sessionid:"string", operation:"gettokenlist", resultcode:1234, resultmessage:"ok", list:[ { tokenidentifier:number, tokenname:"string ] 예시 ) messagenumber:0, sessionid:"a1234",operation:"gettokenlist", resultcode:0, resultmessage: ok, { tokenidentifier: 1234, tokenname:"kisatoken 2. 인증서목록요청 요청메시지 { messagenumber:0, sessionid:"string", operation:"getcertificatelist" 예시 ) messagenumber:0,sessionid:"a1234",operation:"getcertificatelist" 응답메시지 22
{ messagenumber:0, sessionid:"string", operation:"getcertificatelist", resultcode:1234, resultmessage:"ok", list:[ { subject:"utf8 dn", issuer:"utf8 dn", serial:"hexa string", validfrom: "long time", validto: "long time", certidentifier: "number", keyidentifier: "number" ] 예시 ) messagenumber:0, sessionid:"a1234",operation:"getcertificatelist", resultcode:0, resultmessage: ok, { subject: 홍길동, issuer: 한국인증,serial: 12345, validfrom: 1234567, validto: 9876543,certIdentifier: 1234,keyIdentifier: 3456 3. 인증서획득 요청메시지 { messagenumber:0, sessionid:"string", operation:"getcertificate", certidentifier: "number" 예시 ) messagenumber:0,sessionid:"a1234"operation:"getcertificate",certidentifier: 12345 23
응답메시지 { messagenumber:0, sessionid:"string", operation:"getcertificate", resultcode:1234, resultmessage:"ok", certificate:"base64 string" 예시 ) messagenumber:0,sessionid:"a1234",operation:"getcertificatet", resultcode:0, resultmessage: ok, certificate: MzA4MDEyMzRh... YmNkMTIzNA== 4. 전자서명생성 요청메시지 { messagenumber:0, sessionid:"string", certidentifier:"number", keyidentifier:"base64 string", type:"pkcs#1_hash or pkcs#1_content or cms_hash or cms_content tobesigned:"base64 string" 예시 ) messagenumber:0,sessionid:"a1234", operation:"generatesignature, certidentifier:"b9876", keyidentifier: 7ZmN6ri464+Z, type: cms_hash", tobesigned:"7kce7j6q7isc66qflg== 응답메시지 { messagenumber:0, sessionid:"string", operation:"generatesignature", resultcode:1234, resultmessage:"ok", signature:"base64 string" 예시 ) messagenumber:0, sessionid:"a1234",operation:"generatesignature", resultcode:0, resultmessage: ok, certificate: c2lnzw5kigrhdge= 24
5. 키생성 요청메시지 { messagenumber:0, sessionid:"string", operation:"generartekeypair", algorithm:"rsa", modularlength:2048, purpose:"cmp" 예시 ) messagenumber:0, sessionid:"a1234", operation:"generartekeypair, algorithm: RSA, modularlength:2048, purpose:"cmp" 응답메시지 { messagenumber:0, sessionid:"string", operation:"generatekeypair", resultcode:0, resultmessage:"ok", publickey:"base64 string", keyidentifier:"base64 string" 예시 ) messagenumber:0,sessionid:"a1234", operation:"generartekeypair, resultcode:0, resultmessage: ok, publickey:"mza4mjk4nzy1ndmymq==", keyidentifier:" 7ZmN6ri464+Z" 6. 인증서삽입및키매칭 요청메시지 { messagenumber:0, sessionid:"string", operation:"pushcertificate", keyidentifier:"base64 string", certificate:"base64 string", 예시 ) messagenumber:0, sessionid:"a1234", operation:"pushcertificate keyidentifier:" 7ZmN6ri464+Z", certificate: MzA4Mn...h5ejEyMzQ= 응답메시지 25
{ messagenumber:0, sessionid:"string", operation:"pushcertificate", resultcode:0, resultmessage:"ok", certidentifier:"number" 예시 ) messagenumber:0, sessionid:"a1234", operation:"pushcertificate resultcode:0, resultmessage: ok, certidentifier:"b2345" 26
참고자료 [CryptoJS] Google, JavaScript implementations of standard and secure cryptographic algorithms, https://code.google.com/p/crypto-js/, CryptoJS 3.1 [CSP] W3C, Content Security Policy 1.0, http://www.w3.org/tr/csp/, 2012 [CSP2] W3C, Content Security Policy Level 2, http://www.w3.org/tr/csp2/, 2014 [Drag&Drop] [e-id] W3C, HTML5, Drag and Drop http://www.w3.org/tr/html5/editing.html#dnd, 2014 BSI TR-03112 Das ecard-api-framework, https://www.bsi.bund.de/de/publikationen/technischerichtlinien/tr03112/in dex_htm.html, 2014 [FileAPI] W3C, File API, http://www.w3.org/tr/fileapi/. 2013 [FileWriter] W3C, File API: Writer, http://www.w3.org/tr/file-writer-api/, 2014 [HTML5] W3C, HTML5, http://www.w3.org/tr/html5/, 2014 [IndexedDB] W3C, Indexed Database API, http://www.w3.org/tr/indexeddb/, 2013 [ITU.X690.1994] ITU-T, Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1994 [Keygen] [MSRCRYPTO] W3C, HTML5 keygen element, http://www.w3.org/tr/html5/forms.html#the-keygen-element, 2014 Microsoft Research, MSR JavaScript Cryptography Library, v1.2, http://research.microsoft.com/en-us/downloads/29f9385d-da4c-479a-b2ea- 2a7bb335d727/, 2014 [PKCS1] RSA Laboratories PKCS#1, RSA Cryptography Standard v2.1, 2001 [PKCS5] RSA Laboratories PKCS#5, Pasword-Based Cryptography Standard v2.0, 1999 [PKCS8] RSA Laboratories PKCS#8, Private-Key Information Syntax Standard, 1993 [PKCS10] RSA Laboratories PKCS#10, Certification Request Syntax Specification, 2000 [PKCS11] RSA Laboratories PKCS#1, Cryptographic Token Interface Standard v2.1, 2001 [PKCS12] RSA Laboratories PKCS#12, Personal Information Exchange Syntax Standard v1.0, 1999 27
[RFC2511] [RFC4210] IETF, RFC 2511, Internet X.509 Certificate Request Message Format, March 1999 IETF, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), 2005 [RFC6454] IETF, The Web Origin Concept, 2011 [RFC6712] [Sandbox] [SCJL] IETF, Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP), 2012 W3C, HTML5 Sandboxing, http://www.w3.org/tr/html5/browsers.html#sandboxing, 2014 Stanford University, Stanford Javascript Crypto Library, http://crypto.stanford.edu/sjcl/, 2009 [WebCrypto] W3C, Web Cryptography API, http://www.w3.org/tr/webcryptoapi/, 2014 [WebMessage] W3C, HTML5 Web Messaging, http://www.w3.org/tr/webmessaging/, 2012 [WebRTC] W3C, WebRTC 1.0: Real-time Communication Between Browsers, http://www.w3.org/tr/webrtc/, 2013 [WebStorage] W3C, Web Storage, http://www.w3.org/tr/webstorage/, 2013 [XHR] [XHR2] W3C, XMLHttpRequest Level 1, http://www.w3.org/tr/xmlhttprequest/, 2014 W3C, XMLHttpRequest Level 2, http://www.w3.org/tr/xmlhttprequest2/, 2014 28