KISA 무선단말기에서의 공인인증서 저장 및 이용 기술규격
관련해서
좀더 자세히 살펴보니 몇가지 문제점(?)이 보인다.
문서 위치는 다음 링크 참조 : http://bit.ly/cBvjC6
[공인인증서 관리 소프트웨어]
문서의 첫장에 나오는 개요에서 다음과 같이 기술하고 있다.
"본 규격은 무선단말기에서의 공인인증서비스 상호연동성 확보 및 이용 편의성을 고려하여 무선단말기내 공인인증서 관리 소프트웨어의 요구사항을 정의한다."
즉 "공인인증서 관리 소프트웨어"에 대한 기술규격이고
PureWeb에서는 유효하지 않은 규격이다.
[아이폰의 경우 동작구조]
다른 무선단말기는 자세히 살펴보지 않았고
아이폰에 대한 기술 부록4를 자세히 살펴보았다.
아이폰 공인인증서 App은 다음 두가지 기능을 가지고 있다.
"공인인증서 저장기능"
"공인인증서 획득기능"
공인인증서 저장기능은 다른 App에 존재하는 공인인증서를 아이폰의 공인인증서 App으로 보내서 저장하는 방식에 대한 것이고
공인인증서 획득기능은 다른 App에서 공인인증서가 필요할 경우 "공인인증서 App"을 호출하여 인증서를 획득하는 방식에 대한 것이다.
기업은행 App을 가정하여 동작방식을 순서대로 열거해보면
(공인인증서 저장기능 이용시)
1) 유저가 기업은행 App을 호출(ibkapp이라고 가정)
2) 유저가 공인인증서 저장을 위해서 "공인인증서 내보내기" 메뉴를 App에서 호출
3) 공인인증서 App을 호출하기 위해서는
kisa-cert-exchange://?cmd=certpush&caller_url_scheme=ibkapp&callback=01&cert=base64(pfx)
의 링크가 사용된다.
4) 이후 공인인증서 App이 실행되고 인증서를 불러들여 저장해두고 처리가 끝나면ibkapp://?cmd=certpush&callback=01&result=00
으로 결과를 return한다.
(공인인증서 획득기능 이용시)
1) 유저가 기업은행 App을 호출(ibkapp이라고 가정)
2) 해당 App에는 공인인증서가 없어서 공인인증서를 가져와야한다.
3) 공인인증서 가져오기 메뉴를 호출하면
kisa-cert-exchange://?cmd=certget&caller_url_scheme=ibkapp&callback=01
의 링크로 공인인증서 App을 호출한다.
4) 공인인증서 App은 어딘가(?)로 공인인증서를 내보내고
ibkapp://?cmd=certget&callback=01&result=00&cert=base64(pfx)
으로 결과를 return한다.
[반쪽짜리 공인인증서 App]
공인인증서 사용을 위해서는
공인인증서 신규발급, 재발급, 갱신등의 행위가 꼭 필요한데
이런 행위는 여전히 Windows IE ActiveX에서만 가능하며
기술규격은 공인인증서의 사용에 대해서만 정의하고 있다.
즉 아이폰에서 사용하더라도 여전히 ActiveX는 필요하다는 의미.
향후 공인인증서 App에서 인증서 신규발급, 재발급, 갱신등이 지원된다는 의미는 달라질 수 있음.
그러나 지금 현재는 여전히 반쪽짜리임.
[피싱(Phishing)에 취약한 공인인증서 App]
공인인증서 App을 호출하기 위해서 Custom URL Scheme을 이용한다.
현재 "kisa-cert-excange"라고 명시해두었는데
이 구조를 국가 인프라에 도입해서 이용하는것은 상당히 아주 위험하다.
아래 몇가지 예를 들어보았는데 위험성에 대해서 판단해보시길
1. 일반 웹사이트를 통한 피싱(Phishing)
해커가 http://trust.me 라는 해킹사이트를 운영한다고 가정해당 사이트에는 다음 링크를 포함하고 있음.
<a href=kisa-cert-exchange://?cmd=certget?caller_url_scheme=http://trust.me&callback=01>Login</a>
아이폰으로 접속한 유저가 "Login"버튼을 누르면 공인인증서 App이 실행되고 인증서 내보내기 절차를 진행.
내보낸 인증서는 어딘가(?)에 가 있을것이고
해커는 인증서를 그 어딘가(?)에서 가져온다.
2. 해킹 App을 통한 피싱
또다른 경우는
해커가 공인인증서 App과 동일한 Custom URL Scheme을 가지는 피싱 App을 올려두고 기술규격 Spec에 맞게 반응하도록 구성하였다면
유저가 은행 뱅킹 App을 실행하고 인증서 내보내기를 실행하는 순간
KISA 공인인증서 App이 실행되는것이 아니고 해커가 준비한 App이 실행되어 공인인증서를 해커 서버로 탈취해갈 수 있다.
App등록이 통제되는 상황에서는 아주 희박한 경우이겠지만 Jailbroken iphone에서는 가능성이 없지 않다.
Custom URL Scheme이 중복되면 iPhone에서는 가장 나중에 설치된 App이 호출된다.
3. 의도하지 않은 선량한 앱에 의한 피싱
만일 선량한 다른 개발자가 의도하지는 않았지만my.specialapp.kisa-cert-exchange 라고 URL Identifier를 기록했다면
이 App도 역시 kisa-cert-exchange://... 에 반응하여 호출된다.
유저는 공인인증서 App이 호출되기를 기대하였지만 엉뚱한 App이 호출될 가능성이 존재하는것이다.
[Gateway Server에 대한 규격 부재]
기술규격에는 명시되어 있지만
App to App으로 데이터를 전송하기 위해서는 Gateway Server가 필요하다.
이미 기업은행이나 하나은행 App에서 그러한 구조를 취하고 있다.
공인인증서 App에서 내보내기한 공인인증서(Private Key를 포함)가 어딘가로 전달되는데
이곳이 어디인지, 어떻게 관리되어야하는지등이 명확하게 표현되어 있지 않다.
결국 나의 공인인증 개인키가 아이폰 어플에서 공인인증서가 필요로 할때마다 외부로 나갔다 들어오는 과정을 반복하는데
의도적으로 숨기는것인지아니면 아직 규격을 정한만한 사항이 아니라는건지 궁금하다.
아주 핵심적인 규격 하나가 빠져있어서
현재의 기술규격 자체도 반쪽짜리 규격이다.
[투명한 논의과정 부재]
KISA 내부에서 어떤 논의 과정을 거쳐 이런 규격이 제정되었는지
회의록이라도 볼 수 있으면 좋겠다.
[References]
Custom URL Scheme관련해서는 아래 URL들을 참조하세요.
http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
http://www.handleopenurl.com
