공인인증서, 액티브X와 결별하려면

 IT, 정보보호  Comments Off on 공인인증서, 액티브X와 결별하려면
Aug 222012
 

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120329124248

[지디넷코리아]국내 공인인증서 서비스 환경에서 액티브X를 걷어낼 것으로 기대되는 웹표준화 논의가 수면위로 떠올랐다. 웹표준화기구 W3C의 ‘웹 크립토그래피 워킹그룹(WG)’이 우리나라 인터넷뱅킹 서비스 사용 사례를 지원할 기능 표준화를 논의해온 중간 결과다. (23일자 보도 [단독]“액티브X 없이 공인인증서 쓴다“ 참고)

최근 한국모질라커뮤니티 윤석찬 리더는 이같은 성과에 많은 문의가 쏟아져 관심이 높아진 것은 반갑지만, 앞서 지속된 국내 소수 업계인들의 노력을 인지하고 W3C 대한민국 사무국 등 공식 조직의 체계적인 지원은 찾아보기 어려웠다고 일침을 가했다. 불만이 있다면 이를 바꿔나갈 행동과 관심을 보여 달라는 이야기로 들린다.

그는 29일 개인 블로그를 통해서도 “웹 크립토그래피 WG은 (2008년 이전부터) 꾸준히 얘기한 끝에 성사된 결과인데 몇년간 W3C에서 이를 얘기하고 모질라에 어필하는 동안 일부 보안 업계 전문가들의 지원을 제외하고 W3C 한국 사무국, 회원사, 표준 전문가들의 어떤 관심도 보지 못했다”며 “그간 국내 폐쇄적 인터넷 뱅킹 현실에 말만 많았지 표준 영역에 지속적인 관심을 갖고 행동을 보인 사람은 거의 없었다는 점이 매우 유감”이라고 언급했다.

▲ 현재 국내 보안규정을 따르는 공인인증서 서비스체계가 브라우저 자체 기능으로 구현되지 않는 요건을 강제하기 때문에 액티브X나 플러그인 기술이 반드시 요구되는 상황이다. 차세대 웹표준 기반 인증기술로 이를 지원할 수 있다면 기술적으로는 브라우저 자체 인증서 처리가 가능해진다.

실제로 앞서 언급한 지디넷코리아 보도에 대한 일반인들의 반응을 보면 과거 논의된 내용의 이력에 대해 아는 경우를 찾기 어렵다. 호의적인 입장의 누리꾼은 “이제라도 이런 움직임이 시작돼 다행”이라 말하고, 부정적인 시각일 경우 “기술이 나왔다는 것도 아니고 개발 중이라는 것도 아니고 조직이 생겼다는 수준이냐”고 불평한 것이다.

기술 표준화가 시작됐다고 당장 가만있으면 몇 년 이내에 액티브X 없이 브라우저만 갖고 공인인증서로 인터넷뱅킹 서비스를 이용할 수 있는 게 아니다. 국내 이해당사자간 합의할 사안과 제도적으로 풀어야 할 부분, PC보안과 관련된 사용자 문화 측면의 변화도 함께 이뤄져야 한다. 이에 해당 논의의 이력과 현재 상황과 향후 흐름을 정리했다.

■W3C 웹 크립토그래피 WG가 생기기까지

앞서 지난해말 모질라, 구글, W3C는 액티브X 기반 공인인증체계를 대신할만한 웹기반 인증 기술 확보를 위해 표준 개발에 나섰다. 그 훨씬 이전부터 윤석찬 리더는 개인 자격으로 W3C HTML WG이나 웹앱 WG에 관련 의견 제안과 기술 초안 작성 등 활동을 해오다 모질라가 직접 관심을 보이도록 요청했다고 한다.

이후 2008년 방한한 미첼 베이커 모질라 의장이 액티브X에 묶인 국내 공인인증서 환경의 문제를 인지했고, 2010년 루카스 아담스키 모질라 보안 총괄 책임자와 2011년 안드레아스 갈의 방한을 계기로 모질라 내부의 지원 계획이 구체화됐다. 모질라 내부 프로토타입과 스펙을 만들기 시작한 것이다.

이에 따라 지난해 5월부터 초기 API를 개발하고 일차 구현과 테스트를 진행, 8월에는 W3C WebCrypto API 커뮤니티 그룹을 열어 의견 수렴, 11월 W3C 티팩(TPAC) 회의 상정을 통한 표준 워킹그룹 발족이 이뤄졌다.

■파이어폭스, 웹킷 계열에 구현-테스트

지난주까지 해당 WG에 속한 회원사들간 의견이 모였고, 이변이 없다면 다음달부터 웹표준 영역에 국내 인터넷뱅킹 등을 고려한 기능들이 1차, 2차로 나뉘는데 우선순위에 따라 구현될 예정이다. 우선순위가 높은 1차 영역은 이미 파이어폭스를 만드는 모질라의 게코(Gecko)엔진과 구글이 크롬에, 애플이 사파리에 탑재한 웹킷(Webkit)엔진에 구현중이다.

윤석찬 리더에 따르면 1차 영역에 키 생성, 암호화, 복호화, 디지털서명 생성과 유효성 확인, 메시지 인증과 키 이동, 난수 발생, 싱글 세션 키 생성과 저장 기능이 포함된다. 2차 영역에 TLS 세션 기반 로그인과 로그아웃, 키 생성과 데이터 보호, 키 내보내기와 가져오기, 키 정보 확인과 키 발급, 인증 서비스상의 선택과 폐기와 이에 기반한 전자서명과 암호화 기능이 포함된다.

그는 “1차 기능은 WG이 만들어질 때 기본적으로 제안돼 있던 영역이고 모질라에서 제안한 웹 기반 암호화, 서명을 위한 싱글 세션 기반 구현체 ‘DOMCrypt’가 이미 있어 2차 기능을 수행할 수 있는 기초가 된다”고 설명했다.

현존하는 데스크톱과 모바일 브라우저 대부분이 1차 영역 기능을 지원하기는 어렵지 않을 전망이다. 1차 기능은 브라우저 엔진을 개발하면서 구현 가능한 수준이다. 그런데 2차 기능 일부 항목은 운영체제(OS)와 동작 플랫폼마다 따로 만들어야 할 경우도 있다. 브라우저가 2차 기능까지 지원해야 국내 환경에 맞는 인증서 서비스를 위한 최소한의 기술적 가능성이 열린다.

W3C 웹 크립토그래피 WG에 후순위로 국내 인증서 환경을 반영할 여지가 생긴 것은 사실이지만, 손 놓고 있으면 알아서 표준화해 준다는 얘기가 아니다. 국내 이해당사자의 노력여하와 꾸준한 업계 관심이 요구된다.

■향후 활동 방향과 남은 과제

WG의 1차 목표는 ‘DOMCrypt API’를 표준화해 2개 이상의 브라우저에서 구현과 테스트를 병행하는 것이다. 이 동안 여러 사례를 수집해 2차 기능에 대한 표준 작업 제안이 요구된다. 이를 위해 앞서 윤석찬 리더가 DOM Crypt, 로그인 로그아웃, 서명, 외부단말기 제공 내용을 포함해 만든 ‘Web Crypto API’ 초안이 일부 발췌된다. 구글과 모질라의 엔지니어들도 구현을 위한 의견을 나누는 중이다.

국내서도 W3C 웹 크립토그래피 WG에 액티브X를 대체할 수 있는 인증서 처리기능 표준화 활동을 본격화한다. 윤석찬 리더의 초안으로 시작된 모질라의 기존 구현체를 발전시키는 것이다.

윤석찬 리더에 따르면 한국인터넷진흥원(KISA) 전자인증팀이 국내 공개키기반구조(PKI) 인증서 서비스 기술 업체들 의견을 수렴중이다. 또 KISA는 다음주 6개월(4~9월)간 예산 4천만원짜리 용역과제 ‘웹표준 기반 공인인증서비스 개발’ 공고를 낼 예정이다. 웹 크립토그래피 WG 활동 요구사항과 국내 서비스를 위해 필요한 부분에 대해 모질라 구현체에 코드를 공헌하는 내용이다. 과제 수행 결과를 두고 봐야겠지만 이를 완수하는 것만으로 모든 장벽을 걷어낼 수는 없을 듯하다.

향후 액티브X를 대신할 정도의 기술적 진전이 이뤄져도 몇가지 문제가 남는다. 이에 대해 윤석찬 리더는 ▲브라우저가 인증서를 다루는 표준 방식과 맞지 않게 사용자가 공인인증서 비밀키를 암호화고 그 저장경로를 노출시키는 국내 체계 ▲표준화 이후 웹기반 서비스에 대한 외부 공격 시나리오 대응 ▲인증서 탈취 대응책으로 제기됐던 국내 보안 토큰 사용 필요성 ▲일회용비밀번호(OTP) 등 오프라인 인증수단을 요구하는 상황이 불분명한 국내 보안 정책, 4가지를 꼽았다.

 Posted by at 9:35 PM

인증서, 개인키 암호 이용의 안전성

 IT, 정보보호  Comments Off on 인증서, 개인키 암호 이용의 안전성
Aug 222012
 

인증서 암호, 다시 생각하기

흔히 “인증서 암호”라고 부르지만, 실은 인증서 ‘개인키 암호’입니다. 인증서 자체는 누구나 읽을 수 있는 파일입니다.
인증서(개인키) 사용시에는 반드시 암호 입력을 요구해야 한다? 그럴까요? 인증서/개인키 파일은 보통의 파일과는 달리 “키 저장소”(key storage)에 저장된 상태에서만 이용이 가능하도록 원래 설계된 것입니다. 그럴 이유가 있습니다. 개인키를 달랑 암호화한 다음, 일반 파일처럼 저장해 둔 상태에서 인증서/개인키를 사용할 경우(우리 공인인증서가 바로 이런 식입니다), 유저는 (1)해당 파일을 선택하고 (2)그 개인키 파일을 읽어들이는데 필요한 암호를 입력해야 됩니다. 공인인증 플러그인이 바로 이런 식의 UI를 유저에게 제시하고 있지요(인증서를 선택하고, 인증서 암호를 입력하라는 식).

서버들이 “모두” 정직하면 이 방법도 별 문제는 없습니다. 유저가 선택한 개인키 파일, 유저가 입력한 암호값을 서버가 슬쩍 챙기는 못된 짓을 하지 않을 것이기 때문입니다. 하지만 정직하지 않은 서버라면 이런 UI를 이용해서 유저의 인증서/개인키와 개인키 암호를 챙기는 것은 너무나 쉽습니다. (

ㅋㅋ) 서버가 이짓을 하는지 유저가 확인하는 것도 어렵습니다. 인증서 암호를 입력하기 전에 “웹페이지 소스보기”를 매번 하는 유저도 없고, 서버가 플러그인 형태로 이짓을 하면 유저가 확인할 방법도 없습니다. 잔말 말고 “그냥 서버를 믿으라”는 황당한 설계 칸셉트.

반면에 “키 저장소”에 보관된 인증서 개인키를 이용할 경우, 유저가 개인키 암호를 입력할 일도 없고 유저 개인키가 유저의 컴퓨터를 떠나서 서버로 날아가는 일도 없습니다. 물론 키 저장소에 보관된 개인키를 사용하는 전(前) 단계로서 웹브라우저가 유저에게 암호를 요구하도록 유저가 스스로 설정할 수도 있지만, 이 암호(웹브라우저 암호)는 개인키 암호가 아닙니다.

키 저장소는 보안토큰이나 스마트카드에 하드웨어적으로 구현할 수도 있고(HSM), 소프트웨어적으로 구현할 수도 있습니다(MSCrypto Keystore, 애플 Keychain, Gnome keyring, 오페라의 key store 등). 이들 키 저장소는 세련된 방법으로 파일을 보호하며, 소프트웨어적으로 구현된 키 저장소 파일은 유저도 모르는 암호, 유저가 로그인 하는 순간 매번 새롭게 생성되어 시스템 memory 에 저장된 암호, 주기적으로 자동 변경되는 암호 등 각 키 저장소 유형마다 나름 훌륭한 방식으로 보호되고 있으므로 공격자가 그 파일을 복제해 가본들 이용할 수도 없습니다.

그러나 이처럼 시스템 어디엔가 “기계적으로 저장”된 암호보다는 유저의 머리 속에만 기억된 암호가 더 안전하다고 생각하실 분도 있겠지요. 그러나 과연 그럴까요? 기계적으로 저장된 암호는 유저가 입력할 필요가 없지만, 유저가 기억하는 암호는 유저가 입력해야 합니다. 바로 이것 때문에 유저 입력값을 가로채려는 키보드 해킹 시도가 있고, 이걸 막으려고 키보드 보안 플러그인 사용을 강제하려는 것입니다.

그러나, 모든 웹사이트가 키보드 보안 플러그인을 사용하는 것도 아니고, 이메일 암호, 온갖 웹사이트 회원가입 암호(이들 모든 암호 입력값은 키로거가 설치된 경우라면 모두 유출됩니다) 등과 인증서 암호가 동일한 경우가 대부분입니다. 그 뿐 아니라, 위에서 말씀드린 식으로 서버가 유저에게 “인증서를 선택하고 암호를 입력하세요”라는 UI를 태연하게 제시하고 post method로 개인키와 개인키 암호를 챙겨가는 사회공학적 공격 앞에는 모든 것이 무너져 내리게 되어 있습니다.

키 저장소에 저장된 상태에서만 인증서를 이용하게 하면 이런 여러 공격으로부터 더 나은 보호가 가능할 뿐 아니라, 키보드 보안 플러그인이 아예 필요 없게 됩니다(유저가 인증서 암호를 입력하지 않기 때문).

표준적 방법으로(인증서 암호 입력 없이) 인증서 로그인을 하게 할 경우, 서비스 제공자는 유저가 인증서 로그인에 성공했다고 해서 당장 계정 접근을 허용할 것이 아니라, 인증서와는 무관한 다른 암호를 “추가로” 요구하여 계정 접근을 허용하면 될 것입니다(진정한 의미의 2-factor authentication). https://openweb.or.kr/cert/auth 을 방문하시면, 이런 방법이 예시되어 있습니다. 공격자가 이 “추가적 암호”를 가로채 본들, 유저의 개인키 파일을 입수하지 못하면 소용이 없고, 키 저장소에 보관된 유저의 개인키 파일을 입수하는 일은 매우 어렵다는 점은 위에서 말씀 드렸습니다.

인증서 개인키를 암호화할 필요가 있는 유일한 경우는, 개인키를 키 저장소에서 끄집어 내어 다른 컴퓨터로 이동할 경우, 그 이동 과정에 필요한 인증서+개인키 통합 파일(*.p12 또는 *.pfx)을 보호하기 위한 경우 뿐입니다. 바로 이런 이유로 이들 양식의 파일을 생성할 경우에는 암호가 없으면 아예 이들 파일이 생성되지 않도록 spec 자체가 그렇게 설계되어 있는 것입니다.

인증서와 개인키를 (1)굳이 키 저장소 바깥에 꺼내 놓고 (2)개인키를 암호화한 다음, (3)인증서를 이용할 때 마다 개인키암호를 입력하게 하고, (4)그 입력값을 보호한답시고 키보드 보안플러그인 사용을 강요하는 “독특한” 한국방식이 “더 안전”할 거라는 발상은 재고의 여지가 있습니다. 키 저장소를 벗어나는 순간, 인증서 개인키/개인키 암호가 탈취될 위험은 대폭 증가됩니다. 인증서 개인키가 탈취될 위험에 대처하려고 설계된 것이 키 저장소인데, 왜 이것을 사용하지 않는지 잘 이해가 안되는 군요.

무슨 암호건, 자꾸 자주 입력하게 하면 더 안전해 질까요?

 Posted by at 7:48 PM