(공인)인증서는 두가지 기능이 있습니다. 하나는 보안접속을 하는 기능입니다. 다른 한 기능은 거래 내역을 서명하는 기능입니다.

보안접속만 하면 된다면, 아예 플러그인이 필요 없습니다. 보안접속만이 문제된다면 웹브라우저에 당연히 포함된 모듈(프로그램)로 구현하면 됩니다(https 접속: 익명 사용자 SSL/TLS 접속이건, 사용자 인증 SSL/TLS 접속이건 간에). 그러나, 거래 내역을 전자서명하는 기능은 별도의 플러그인이 필요합니다(액티브X가 되었건, 서명된 자바 애플렛이건, 파이어 폭스 확장이건 간에). 따라서, 보안접속에 더하여, 거래의 구체적 내역을 고객이 전자서명하는 행위가 과연 얼마나 안전에 도움이 되는가 하는 점이 문제로 됩니다.

지금까지의 “당연한 전제”는, 거래 내역을 전자서명하면 나중에 고객이 그 거래를 부인(repudiate)할 수 없게 된다는 것입니다. 그러나, 과연 그런지를 꼼꼼히 따져 볼 필요가 있습니다.

고객이 문제의 거래를 “부인(자신이 한 것이 아니라거나, 자신이 한 거래와는 내용이 다르다는 주장)”할 수 있느냐 없느냐는 기술적 측면과 법적 측면을 모두 살펴보아야 합니다:

• “기술적으로는” 고객의 개인키를 가진 자가 아니면, 그 전자서명을 생성하는 것이 (지금의 컴퓨팅 파워로는) 사실상 불가능하기 때문에, 전자서명이 있으면 고객이 거래를 부인하기 어렵게 되는 것이 맞습니다.
• 그러나, 실제로 금융사고가 생기는 이유는 고객의 인증서와 개인키 파일이 이미 유출되어 공격자가 입수하였기 때문입니다. 따라서 “고객의 개인키 없이는 고객의 전자서명을 생성하기 매우 어렵다”는 기술적 주장은 법정에서는 아예 논쟁 거리로도 되지 않습니다. 이미 고객의 개인키가 유출된 상태에서 고객 모르게 거래가 이루어지기 때문에 분쟁이 발생하는 것입니다.

그 뿐 아니라, 현재와 같이 “복사 가능한 형태”로 저장되는 (공인)인증서는 유출될 가능성이 매우 높다는 사실은 모든 보안전문가들이 당연히 전제로 삼는 사실입니다. 키보드 보안 프로그램 설치를 강제 하는 이유도, 인증서 개인키 파일이 이미 유출되었을 가능성이 높기 때문입니다. 개인키가 유출되지 않는다면, 아무리 키로거로 비밀번호를 알아내 본들, 전자서명을 할 수는 없습니다. 그러나, 키로거를 고객의 컴퓨터에 몰래 설치하여 비밀번호 입력값을 빼가는 수준까지 고객의 컴퓨터를 장악한 공격자가 유독 고객의 인증서 개인키만은 건드리지 않고 가만히 두는 “예의”를 지킬 것으로 기대할 수는 없을 것입니다.

요컨대, 고객의 컴퓨터에 키로거가 설치되는 지경에 오면, 비밀번호 뿐 아니라, 인증서 개인키 파일까지도 당연히 공격자가 입수할 수 있게 됩니다. 이 상황에서 전자서명이 이루어지면, 고객은 그 거래를 부인할 것이고, 그 경우에 법원은 “개인키 없이는 전자서명을 만들 수 없다는 기술적 주장”은 아예 고려조차 할 필요가 없습니다. 유일한 쟁점은 개인키 유출에 고객의 과실이 어느정도 있었는지 뿐입니다.

따라서, “기술적으로는” 전자서명이 부인방지 기능이 있다고 하지만, 실제로는 아무리 전자서명이 된 거래라 하더라도, 고객은 자신의 개인키가 유출되어 누가 그것으로 거래했다는 주장을 펴기 때문에, 결국에는 전자서명이 부인방지 기능을 보장해 주는 것은 전혀 아닙니다.

고객의 컴퓨터가 허술하면, 인증서 개인키 파일은 공격자가 당연히 복사해 올 수 있으므로, (공인)인증서만으로는 아무런 보안책도 되지 못합니다. ‘비밀번호’만이 유일한 장벽이고, 바로 그렇기 때문에 국내 금융권은 키보드 보안에 그렇게 집착하는 것입니다. 개인키는 이미 유출되었지만, 개인키 비밀번호라도 제대로 지켜보자는 것이 바로 키보드 보안 프로그램의 “존재 이유”입니다. 키보드 보안에 집착한다는 사실 자체가 곧, 인증서 어쩌구 아무리 해본들, 실제로는 “비밀번호”가 주는 이상의 보안을 고객에게 제공할 수 없다는 점을 보안업체들이 스스로 잘 알고 있기 때문입니다. 결국, 유일한 “관문”은 개인키 “비밀번호”로 집중됩니다.

PKCS#11 형태로 저장되는 (공인)인증서와 비교하면, 이점은 더욱 분명히 드러납니다. 이 양식(cryptographic token)의 인증서는 복사가 불가능(unextractable)하게 지정할 수 있습니다. 여기 참조. 이 경우에는 아무리 개인키 비밀번호가 유출, 노출되어 본들, 물리적으로 그 매체 자체(스마트 카드 등의 형태로 존재합니다)를 입수하지 않는 이상 고객의 개인키를 공격자가 입수할 수 없으므로, 고객의 전자서명을 만들어 낼 수가 없습니다. 이 양식의 인증서를 사용할 경우에는 키보드 보안 프로그램이 필요없게 되는 셈입니다. 그 외의 경우는 인증서 자체가 보안에 도움이 된다기 보다는 개인키 암호가 비밀로 유지되느냐가 거의 모든 것을 결정하는 셈입니다.

따라서, PKCS#11 형태의 인증서가 아니라면, “보안에 관한 한”, 그리고 “부인방지 효과”를 실제로 거둘 수 있느냐는 오직 “비밀번호”에 달려 있습니다. 실제로도, 인증서를 사용하는 유럽 각국, 캐나다 등의 경우, 우리 나라와 같은 저장 방식과 저장위치에 저장되는 인증서를 사용하는 곳은 없습니다.

이상을 표로 요약하면 다음과 같습니다:

지난 10년 가까이 우리 금융권이 채택한 방식은 붉게 표시된 부분으로 설명됩니다. 처음에는 공인인증서가 마치 모든 것을 해결해 줄 것처럼 착각하고 그것만 채택하다가, 점점 사고가 터지니까, 보안카드를 도입하고, 이제는 키보드 보안 프로그램 설치에 거의 “올인”하다 시피 매달리고 있습니다.

(복사 가능한 형태로 저장되는) 인증서는 애초에 단순 비밀번호(그것도 static 비밀번호) 이상의 보안을 실제로는 전혀 제공하지 못하는 것이었다는 것을 뒤늦게 깨달은 셈입니다. 보안에는 실제로 별 도움이 되지 않는 인증서를 사용하기 위하여 모든 뱅킹 고객들이 “몸살”을 앓아 왔고, 서비스의 범용성이 치명적으로 제약되어온 셈입니다. 인증서로 전자서명하는 플러그인을 판매하는 업체들에게는 적지 않은 도움이 되었겠지만…

OTP 생성기 또는 Server-generated OTP가 가지는 “상대적 장점들”을 전향적으로 검토할 때가 되지 않았나 생각합니다. 어차피 비밀번호에 모든 것을 거는 형국이라면, 그 비밀번호라도 안전하게(매번 똑같이 static 하게 입력하지 않도록) 운용하는 것이 필요하지 않을까요?