mir.pe (일반/어두운 화면)
최근 수정 시각 : 2024-08-04 23:10:58

공동인증서/논란 및 사건사고


파일:상위 문서 아이콘.svg   상위 문서: 공동인증서
1. 개요2. 저장 방식과 배포 방식으로 인한 보안상의 문제점3. 위험의 외주화와 보안프로그램의 보안공학적 취약화4. 사용자에게 보안 책임 전가
4.1. 소액결제의 불편함
5. ActiveX 기반 서비스로 인한 운영체제/브라우저의 호환성 문제6. 전자신분증 좌초로 성립된 독자 관행과 안보상의 문제7. 비싸고 유효기간이 짧은 인증서8. 공인인증서 해외 유출 사고9. 공인인증서에 관련된 오해

[clearfix]

1. 개요

국내 공인인증서의 문제는 공인인증서를 개인이 하드나 USB, 핸드폰 등과 같은 별도 저장 장치에 저장해야 한다는 점과 공인인증서를 가동하기 위해 별도의 프로그램이 필요하다는 점, 1년마다 새롭게 계속 반복해서 갱신을 해야 한다는 점, 비밀번호가 영문 숫자 특수문자 합해서 10자리로 매우 길다는 점, 범용인증서가 연 4,400원(10개월)으로 유료라는 점, 물리적으로 저장해서 사용해야 하다 보니 공인인증서를 이동 복사하며 써야 해서 불편하다는 점 등등 많다. 이로 인한 문제점은 다음과 같다.

2. 저장 방식과 배포 방식으로 인한 보안상의 문제점

공인인증서는 아무런 보안이 없는 일반 저장 장치에, 그것도 일반 폴더인 NPKI 폴더에 저장하기 때문에(원래는 웹브라우저에도 저장이 되는 것), 그냥 이 폴더를 복사해 가면 공인인증서를 복사할 수 있다. #[1] 일단 NPKI 폴더 내의 파일을 입수하기만 하면, 공격 대상자가 10자리(최소) 같은 허술한 비밀번호를 사용하면 브루트포스로 암호를 쉽게 알아낼 수 있다. NSA 국정원급은 되어야 풀 수 있지 않나? 생각할 수도 있지만 이런 단순 무차별 대입법은 일반인이 보안에 대한 약간의 지식만 있어도 할 수 있는 수준이다. 널리 퍼진 오해로 '공인인증서는 5회 암호를 틀리면 자동 폐기된다'는 것이 있는데, 이는 공인인증서 시스템 자체에서 구현된 것이 아니라 공인인증서를 쓰는 해당 은행/증권 프로그램에서 '눈 가리고 아웅'하기 위해 구현한 것이라서, 따로 복사해 두거나 암호를 풀기 위한 별도 프로그램을 쓰면 무한대로 입력할 수 있다. 즉, 실제 현실에서 공인인증서 암호 검증 과정에는 서버와의 네트워크 통신이 필요 없다.

특히나 최근의 스마트폰 사용량 급증과 더불어서 이런 공인인증서 폴더의 해킹 사례는 더욱 증가했는데, 개인 핸드폰이 PC보다 보안이 취약하다는 점과 APK 파일을 비롯한 외부 프로그램을 쉽게 설치할 수 있다는 점 때문에[2] 공인인증서 폴더 탈취가 더욱 증가하고 있는 실정이다.[3] 한국인터넷진흥원(KISA)에서도 이와 같은 문제를 인식하여, 보안토큰에 공인인증서를 저장할 것을 권고하고 있다. 기업금융이 아닌 경우 잘 쓰이지는 않지만 USB형태의 토큰이 있다. 이럴 경우 NPKI 폴더의 탈취를 막을 수 있으므로 1번에서 제기된 문제를 해결할 수도 있을 것이다.

복제가 불가능한 IC 카드[4]나 USIM에 인증서를 탑재하고 파일 형식의 인증서를 전면 폐기했으면 이 문제는 간단히 해결되었을 것이다. 사실 이렇게 하면 국내에서는 편의성 때문에 OTP와의 경쟁에서 밀려 사라지긴 했으나 동급의 보안성을 인정받았던 HSM과 구조적으로 별 차이가 없다. 유럽연합 현행 eIDAS 규제의 QES 서명이 이 방식을 취하고 있으며[5] EU 국가에서 신분증을 수령하면 신분증 본체와 함께 PIN1(+PIN2) 그리고 PUK가 담긴 코드표가 동봉되어 나오기에 이 둘만 있으면 인터넷으로 즉각 민원업무를 볼 수 있게 된다. 이 경우도 지원을 위해 추가 플러그인 설치가 필요하단 문제는 피할 수 없는데, 에스토니아의 경우 국가가 직접 단일 전자서명 소프트웨어·앱(DigiDoc4)을 PC·모바일용으로 공개하고 오픈소스로 배포한다. '파일 형식 인증서+10자리 이상 비밀번호'를 유지하기 위해 키로거와 트로이목마를 틀어막지 않으면 모든게 붕괴되는 대한민국이 한심할 지경이다.

하다 못해 공인인증서 저장 시 자신이 원하는 디렉터리에 저장하고, 사용시에도 자신이 원하는 폴더에서 공인인증서 파일을 불러올 수 있다면 지금보다는 보안이 나았을 것이다. 모호함을 통한 보안(STO)이긴 하지만, 좀 더 많은 사람이 하드 디스크 드라이브가 아닌 USB 메모리에라도 보관할 것이기 때문이다. TrueCrypt 등 암호화된 볼륨에 저장하면 좀 더 안전하게 사용할 수 있다. 윈도우즈 XP에서는 C:\\Program Files\\NPKI 에 저장되었고, 윈도우즈 7 이상에서는 \%homepath\%\\AppData\\LocalLow\\NPKI 에 저장되는데, AppData는 숨김 폴더인 데다가 경로도 여러 번 거쳐서 들어가야 해서 USB 메모리로 복사하기도 힘들다. 그래서 사람들이 USB 메모리에 저장해놓고 쓰기보다는 컴퓨터 HDD에 저장해놓고 사용하기를 선호한다. 관리를 어떻게 하느냐에 따라 다르지만 일반적으로 HDD보다 USB 메모리가 보안상 더 낫다. USB 메모리는 기본적으로 해킹에 안전한 콜드 스토리지기 때문이다. 물론 컴퓨터 관리자가 컴맹이라면 콜드 스토리지조차도 위험하다. 인증서 프로그램의 숫자부터가 소비자에게 부담을 줄 정도로 많고 이를 노리는 피싱용 가짜 프로그램도 있기 때문이다.

요즘에는 각 은행마다 네이버같이 아이디와 비밀번호를 입력하여 로그인한 뒤 은행 계좌를 조회할 수 있게 해놓았지만, 이체를 할 때는 공인인증서를 요구하게 되어 결국 이 방식도 한계가 있다. 그래서 간편비밀번호 또는 지문과 같은 생체정보 인식으로 로그인을 할 수 있게 하는 방법도 나오고 있다.

유럽연합의 eIDAS에서는 전자서명을 각각 QES, AdES/QC, AdES, 비표준 4종류로 분류한다. 이 중 QES는 부인방지와 동시에 기업의 입증책임이 생략되는만큼 별도 장치에 보관하는 것이 강제되며 보통 신분증에 내장되거나 수령 후 별도로 발급받아야 된다. 가입국이 아닌 후보국들도 유럽의 법제에 맞추는 경향이 짙은데 우크라이나 신분증 PIN2를 입력해 QES 인증 전자서명이 가능하다.

3. 위험의 외주화와 보안프로그램의 보안공학적 취약화

저장 방식에 대해서는 통계적으로 따져볼 때 맞다고 보기 어렵다고 주장하기도 한다. 2013년 경찰청에서 발표한 신종 금융 범죄[6] 피해에 따르면 총 발생 건수는 33,763건인데, 거기서 실제적으로 단말기가 털린 메모리 해킹의 경우에는 463건에 불과하기 때문이다. 이는 1%가 약간 넘는 수치인데, 페이팔은 한 달 부정 결제액의 추산을 3~5%로 하는 것을 고려해볼 때 이 주장은 설득력이 떨어지는 것으로 보인다. 그러나 솔루션의 구조에 대해서는 잘못되었다고 볼 여지가 있다. 공인인증서를 사용하기 위해 깔리는 공인인증서 보안 솔루션이 보안공학적[7]으로 두 가지 큰 문제를 낳기 때문이다.

첫 번째 문제는 보안에 대한 전문 지식이 부족한 사용자에게 보안을 일정 부분 책임질 것을 강요한다는 점이다.[8][9] 결국 사회적으로 중요한 것은 금융 범죄를 얼마나 줄일 수 있는가이다. 당연히 더 많은 인력과 전문성을 확보할 수 있는 기업들이 보안을 책임지는 것이 맞다. 메모리가 해킹 당하든 스미싱을 당하든 금융 범죄가 일어났다는 사실에는 변함이 없으며, 단말기가 털리지 않았다고 문제 없다고 하는 것은 보안을 책임져야 할 사람들이 주워담는 면피성 발언에 지나지 않는다. 하지만 사용자 PC에 보안 솔루션을 깔았다는 이유로 법적 싸움에서 은행 및 오픈마켓 등은 '할 일을 다 했으니 책임이 없다'라는 판결이 나오기 쉽고, 그만큼 기업들은 보안에 자체적으로 투자하지 않고 단순 외주로 돌려버리게 된다. 귀찮고 위험한 걸 외주 비정규직으로 돌리는 위험의 외주화가 여기서도 나타나는 것이다. 결국 이 부분은 대한민국 보안에 대한 정책기조의 문제다. 해킹으로 뚫릴 것을 어느 정도 예상하고, 사후 보상까지 고려하는 외국과는 달리 우리나라에서는 뚫리지 않는 상황을 가정하고 정책기조를 만들었기 때문이다. 기업이 최선의 노력을 다했어도 보안이 뚫렸다면 이것을 한계점으로 보는 것이다.

두 번째 문제는 보안 솔루션( 보안프로그램)을 제공하는 기업들이 불신을 키운다는 점이다. 많은 사용자들이 치를 떠는 N프로텍트 같은 경우를 보면 쉽게 알 수 있을 것이다. 이놈을 깔면 프로그램 설정이 이상하게 바뀌고, 키보드 입력이 제대로 되지 않으며, 심지어 운영 체제를 죽이기까지 한다. 기본적으로 한 컴퓨터에 종류가 같은 보안 프로그램을 두 개 이상 설치함을 권장하지 않는다.[10] 그런데 다른 신뢰성이 높은 백신이나 방화벽이 많이 있음에도 불구하고 특정 제품군을 깔도록 강제하는 것은 좋은 상품을 선택할 권리를 막는 것이고, 이는 실제로 우리나라의 전체적 보안 상황에 악영향을 미치는 것이다. 특히 이렇게 단일 프로그램을 깔도록 만들면 크래커 입장에서는 해당 제품 제조사만 해킹하면 되기 때문에[11] 해킹하는 것마저 쉬워진다. 문제는 은행과 같은 금융 인터넷뱅킹 뿐 아니라 정부24라던가, 대법원전자민원센터 같이 인터넷 상에서 문서를 뽑는 등의 전자정부 서비스를 이용할 때도 보안 프로그램을 덕지덕지 깔아야 한다는 것이다.

온라인 거래에서 본인을 인증하는 수단을 마련한다는 기본 발상 자체는 그리 나쁘지 않았다고 볼 수도 있으나, 지나치게 세세한 부분까지 법으로 규제를 한 점. 특히나 해킹 이후의 사후 대처에 대한 고민을 충분히 하지 않고서 지나치게 친기업적인 정책 제안을 그대로, 생각 없이 받아들인 결과 현재와 같은 인터넷 환경이 조성되었다고 할 수 있다.

그리고 공인인증서의 가장 큰 문제로 지적되는 부분은 프로그램이 사용자로 하여금 보안의식을 포기하도록 강요한다는 점이다. 외부 설치 프로그램이 나타나면 무조건적으로 확인도 하지 않고 확인을 누르는 루틴이 생겨도 관공서도 보안회사도 나몰라라하는 것이다. 국내 인터넷 환경은 지나친 ActiveX의 남용과 더불어 ActiveX를 설치하지 않으면 진행이 되지 않기 때문에 익스플로러를 오래 사용한 사람이라면 습관적으로 확인 버튼을 눌러버린다. 컴퓨터에 관심을 갖지 않는 일반 사용자가 ActiveX 컨트롤러 개발 회사를 얼마나 알까? 기본적으로 ActiveX를 설치하겠냐는 물음에 '아니요'를 누르면 결제가 안 된다. 그러니 설치하겠냐는 물음이 뜨면 조건반사적인 예를 누르게 되고, 결국 잘 알지도 못하는 프로그램을 무작정 설치 및 실행해버리도록 민관합동으로 방조해온 시스템이 오늘날의 공동인증서다. 보안 솔루션으로 위장하기 이렇게 쉬웠으니 실시간으로 유출 피해가 나는 것은 당연지사다. 전자서명을 시행하는 나라 중 '서명 절차 자체'를 사기업 애플리케이션에 맡기고 정부부처는 감독만 하는 사례는 찾아보기 매우 어렵다. 관할부서가 웹사이트를 통해 직접 프로그램을 배포하는 경우가 일반적이다.

이런 문제에 더욱 불을 붙이는 건 법원과 정부의 대응이다. 사고가 터졌을 때 법원에서 가장 먼저 확인하는 것은 기업에서 보안 솔루션을 완벽하게 갖추었는지이다. 특히나 개인이 해킹과 같은 문제를 당했다면, 기업에서 지정한 절차를 지켰음에도 해킹을 당했음을 완벽히 증명해야 한다.[12] 따라서, 기업에서는 이런 책임을 면피하기 위해 공인인증서 외에도 안전하게 사용할 수 있도록 외부 프로그램들의 설치를 강요하고 있는 게 현실이다. 당연히 이런 보안 프로그램의 설치는 초기에는 어느 정도 안전성을 확보해주나, 기업에서 면피용으로 대충 설치해놓고 업데이트를 안 하면 정반대가 된다. 쉽게 설명하자면 백신을 사놓고 1년간 업데이트를 안 하는 것이다!!! 그야말로 끔찍한 상황.[13]

특히 회사마다 이런 보안 솔루션 ActiveX의 적용 방식이 다른 만큼, 자기들끼리 버전이 달라 서로가 서로를 공격하는 막장도 높은 상황까지 보이기도 한다. 그럼에도 이 문제를 해결해야 할 기업은 예산이 없다는 변명 하에 투자를 하지 않고 있고[14], 이를 철저히 감시해야 할 정부 역시 예산 문제와 인력 문제를 이유로 들며 제대로 감시하지 않고 있다. 이현령비현령[15]의 뫼비우스의 띠와도 같은 상황. 취지는 좋았어도 이러한 추태는 공인인증서 보안에 심각한 위해가 되지 않을 수 없다.

개인이 공인인증서의 문제점을 보완하기 위해 추가적으로 부담하는 비용 역시 부담으로 작용할 수 있다. 보안 토큰이 약 5천원 정도의 돈을 내고 은행에서 사야 하는 단점이 있는 것은 물론,[16] nProtect라든지, XecureWeb 등의 프로그램이 거래 이후에도 컴퓨터의 자원을 차지하고 있는 것 역시 문제다. 이런 프로그램이 보안이 필요한 상황에서만 작동하고 종료되면 큰 문제가 없는데 그렇지가 않으니 구라 제거기같은 일괄삭제 프로그램의 수요도 만만치 않은 상황이다.

4. 사용자에게 보안 책임 전가

한국에서는 흔히 말하는 Zero Liability가 사실상 제대로 적용되지 않고, 여러 언론 보도를 통한 실태를 보았을 때 공인인증서는 전적으로 사용자에게 책임을 전가하기 위한 악습이 맞다.

바로 위 문단에서 언급한 판례 1, 판례 2을 두고 공인인증서 옹호론자들은 '어쨌든 보상을 받지 않았느냐? 그러므로 Zero Liability가 제대로 적용되는 것이 맞다. 공인인증서의 문제가 아니다'라고 하고 있는데, 정작 이것이 법원 판례라는 것은 망각하고 있다. 은행이 사용자 책임을 주장하며 보상을 회피했기 때문에 법원까지 가서 판결받은 것이다. 즉, 한국에서는 금융 사고가 발생했을 때 이를 법원까지 끌고 가야 겨우 보상을 받을 수 있다는 것이다. 거기에다가 법원에 소를 제기하기 위한 각종 비용[17]까지 포함하면 금융 사고에 대한 금융사 책임 입증을 위해 이런 개고생을 해야 한다는 것이다.

그렇다면 언론 보도에서 공인인증서를 어떻게 표현하는지 보자.

노컷뉴스.
보안 키를 관리하지 못한 소비자 책임일까, 아니면 해킹된 공인인증서로 인출해준 은행 책임일까?

비대면 거래인 인터넷 뱅킹이나 모바일 뱅킹에서는 개인정보와 금융정보, 특히 공인인증서와 보안카드 등을 사용해야 한다. 하지만 개인이 PC와 집 열쇠와 같은 공인인증서를 제대로 관리하지 못했다는 이유로 금융사고 대부분의 책임은 금융소비자들에게 돌아가 제대로 보상을 받지 못하는 것이 현실이다.

금융사는 탈취된 공인인증서와 개인정보라 하더라도 비대면 본인확인 절차를 거쳤다면 사실상 면책된다. 책임은 대부분 공인인증서를 관리하지 못한 소비자 탓으로 돌아간다. 2014년 정부가 공인인증서 의무화를 폐지했지만 금융사들이 공인인증서를 포기하지 않는 이유다.

공인인증서는 표준 암호화 기술인 공개키기반구조(PKI)를 활용해 보안성이 높지만 사용자 관리 측면에서 해킹되거나 외부에 노출될 가능성이 크다. 금융사고 피해자들은 금융사들이 공인인증서 시스템만 요구하고 다른 인증 시스템에 대한 선택권은 주어지지 않고 있다고 지적한다. 이때문에 금융사고 책임을 소비자가 져야 하는 불합리한 구조를 깨뜨려야 한다는 주장이 계속되고 있다.

경기일보
하지만 소비자 일각에서는 카카오뱅크 등 인터넷은행이 생기자 뒤늦게 시중 은행들이 움직인다는 지적이 나온다. 2015년 공인인증서 의무사용제도가 폐지됐지만 시중은행 홈페이지 등에서 온라인 거래를 하려면 공인인증서를 발급받아야 하고 매년 인증서 유효기간을 갱신해야 한다. 계속 공인인증서를 고집해오다 강력한 경쟁자가 나타나자 대응에 나선다는 비판이다.

한 금융권 관계자는 그동안 은행이 공인인증서를 고집해온 이유에 대해 “금융사고가 발생하면 은행이 책임지지 않기 위해 공인인증서를 사용하는 것”이라고 주장했다. 사용자가 인증서를 PC나 공공장소의 PC에 보관했다가 인증서가 유출돼 사고가 나면 은행이 책임질 의무가 없다.

데일리한국
한 전산업계 인사는 “금융결제원은 수익을 얻고 금융위와 금감원은 공인인증서 정책을 유지하면서 이에 따른 권한을 누리고 있다”며 “공인인증서 제도 덕택에 은행은 면피하고, 보안 업체는 보안 프로그램을 팔고 있다”고 말했다.

이어 “공인인증서 시스템이 요구하는 보안 정책을 수립하면 사고가 나도 책임 지지 않기 때문에 우리나라 모든 인터넷 기업이 덕을 보고 있다”고 덧붙였다.

이렇게 '공인인증서는 사용자에게 보안 책임을 전가하기 위한 수단'이라고 성토하는 언론 보도는 넘쳐나지만, '그렇지 않다, 그건 오해다'라는 보도는 결코 존재하지 않는다. 따라서 'Zero Liability' 운운하며 공인인증서를 옹호하는 것은 호도에 불과하다.

공인인증서는 보안 관리를 인증서의 보관처럼 사실상 개인에게 하도록 하고 있으며, 여기에 은행이 보안 프로그램 서비스를 제공하고 있으니 보안사고가 터져도 은행 입장에서는 보안 조치를 할 만큼 했으니 결국 개인의 부주의로 인한 사고로 떠넘길 수 있다. 결국엔 은행들의 책임 회피 수단으로 악용되고 있는 것.

4.1. 소액결제의 불편함

또한 비교적 소액 결제에서도 공인인증서를 무분별하게 남용하는 것 또한 문제이다. 현행 제도법상으로 30만원 이하는 소액 결제로 취급되어 공인인증서 없이 결제가 가능하나(대표적으로 스마트폰 영화 예매나 기차, 버스 예매 등) 대부분의 회사에서는 결제 금액이 얼마인지 예상되지 않는다는 이유로 결제 과정에서 공인인증서 결제 관련 플러그인에 강제로 연결시킨다. 당연히 기업 입장에서는 관리와 유지에서의 유용성 때문에 그렇지만, 이러한 보안 조치는 얼마 되지도 않는 거래에서 역시 많은 절차를 요구하므로 몹시 피곤한 방식이다. 이 부분에 대해선 기업이 조속히 해결해줘야 하나 귀찮다는 이유로 놔두고 있다. 아무리 소액결제 금액을 50만원으로 늘려도, 결국 금융사나 인터넷 쇼핑몰에서 해주지 않으면 그만인 것이다! 결국 기업이 소비자의 요구를 충족해서 개선해 줄 의지가 얼마나 있느냐에 달린 문제.

5. ActiveX 기반 서비스로 인한 운영체제/브라우저의 호환성 문제

공인인증서를 사용 가능하게 하는 모듈 상당수를 보안 업체가 개발하는데 대부분이 ActiveX 기반이며, 사용자에게 관리를 맡긴다는 것. 공인인증서 기반기술 자체가 ActiveX 기반이 아니기 때문에 해외에서 인증 기술을 사용하는 국가에서는 플러그인 없는 인증 서비스를 제공하고 있으며, 한국에서도 공인 인증 기관을 중심으로 플러그인 없는 공인인증 서비스를 제공하고 있지만 금융기관 등에서는 방화벽, 가상 키보드 등과 패키지로 ActiveX 기반 공인인증 서비스를 제공한다.

다시 말해 마이크로소프트 사에서 만든 윈도 운영체제에서 Internet Explorer를 이용하지 않고서는 공인인증서를 사용할 수 없는 것처럼 인식되는 경우가 많다. 대한민국에서는 대부분 사람들이 윈도우/IE로 인터넷을 사용했었기 때문에 이 문제에 대해 지적하는 사람들은 극소수였으나, 스마트폰 도입 이후로는 언론사에서도 까기 시작했다. 결국 이러한 문제가 지속적으로 제기되어서 현재는 정부에서도 크로스 브라우징 지원 권고가 이루어지고 있으며, Java 애플릿이나 어도비 플래시를 이용하는 결제 시스템이 도입되고 있기는 하지만, 아직 이용할 수 있는 곳도 많지 않고 이용 중 문제가 생기는 경우도 종종 발생한다. 그리고 현재 크롬 등의 다른 브라우저를 사용하는 사람도 상당히 많아져서, 지적을 받게 되었다. 최근에는 크롬 등 인터넷 익스플로러 이외의 브라우저로 인터넷뱅킹을 이용할 수 있게 되었지만 확장 프로그램을 추가로 설치를 요구하는 경우도 있어서 울며 겨자 먹기로 익스플로러로 인터넷 뱅킹을 하는 경우도 있다.

하필 ActiveX를 이용하는 이유는 여러 가지가 있는데, 첫째는 공인인증서가 처음 나오기 시작할 때에는 SSL(Secure Sockets Layer)[18]56비트 암호키만 이용할 수 있었기 때문이다. 당시 미국에서 수출 제한을 두어 이용할 수 없었기 때문. 이 때문에 당시 최신 브라우저였던 IE 4.0은 40비트 암호화 버전과 128비트 암호화 버전이 있었는데, 해외 다운로드는 40비트 암호화 버전만 가능했다. 56비트는 너무 허술했기 때문에 좀 더 복잡하고 안전한 키를 이용하기 위해 독자적인 암호화 방식인 SEED를 이용하였다. 그리고 SEED를 웹 브라우저에서 직접 지원하질 않으니 플러그인을 통해서 이용하는 수밖에 없었는데 하필 선택한 게 ActiveX다.[19]

이후 미국의 암호화 수출 제한은 풀렸으나, 이미 ActiveX와 SEED를 이용하는 시스템이 너무 퍼져버렸고 그대로 고착화되었다. 또한 다른 브라우저들의 저조한 이용[20]과 기업들의 게으름으로 인해 익스플로러 이외에서 공인인증서를 이용할 수 있는 시스템은 오랫동안 제대로 개발되지 않았다.

결국 2010년에 와서야 방송통신위원회에서 ActiveX를 퇴출시킬 것[21]이라 발표하면서, 공인인증서를 어떤 방식으로 뜯어고칠 것인가에 대해 관심이 집중되었다. 일단 임시방편으로 조금 사용자가 많은 일부 웹 브라우저에서 오픈뱅킹을 시작했고, 스마트폰 전용 뱅킹도 추가되었다.

다만 웹 기반 시스템을 실제 금융권에서 찾아보기는 아직 어려운 실정이고, 저 오픈뱅킹이라는 것 상당수가 사실 ActiveX와 상당히 유사한 NPAPI에 의존한다는 게 문제다. 파이어폭스, 크롬, 사파리 등 IE 제외한 상당수가 NPAPI를 지원했으나 2013년 12월 예정인 크롬을 시작으로 크롬과 파이어폭스에서 지원이 종료된다.[22]

2014년 9월 23일. 금감원에서 전자상거래 결제 간편화를 발표하였다.

또한 정부는 공인인증서를 HTML5 기반으로 바꾸기 위한 작업도 진행한다고 한다. 하지만 은행들이 웹 기반 공인인증서의 보안성을 의심하고 있고, IE7/IE8 등의 구형 웹브라우저까지 지원할 것을 요구하느라 난항을 겪는 상태라고 한다.[23] #

바로 아래에서 언급되는 다소의 장점들도, 어디까지나 윈도 이용자들을 기준으로만 했을 경우이며, 당연히 리눅스 macOS 이용자들에게는 전혀 해당 사항이 없다. 브라우저의 호환성 문제는 어느 정도 해결되었으나 운영체제의 호환성 문제는 여전히 제자리걸음이다.

6. 전자신분증 좌초로 성립된 독자 관행과 안보상의 문제

파일:상세 내용 아이콘.svg   자세한 내용은 주민등록증 문서
6.2.1번 문단을
부분을
참고하십시오.
파일:상세 내용 아이콘.svg   자세한 내용은 주민등록증 문서
6.4.3번 문단을
부분을
참고하십시오.
주민등록증은 문서를 보면 알겠지만 ICAO Doc 9303 규격 만족은 고사하고 '전자적으로 인식 가능한 수단'이 없다. 그렇기 때문에 마땅히 신분증인 주민등록증이 할 일을 못해서 공동인증서로 땜질한다는 느낌을 지울 수 없는데, 이는 공인인증서가 성립된 주요 원인으로 전자주민등록증 무산이 있고 전자주민등록증 무산의 원인은 국민의 반대 뿐만이 아닌 행정안전부와 행정안전부의 전신들의 태도가 있기 때문이다.

1996년 내무부는 전자주민등록증 도입안을 내놓으면서 도입에 따른 특장점만 주로 부각했다. 그러나 시대의 변화에 따라 대두되는 개인정보보호에 대해서는 제대로 된 여론 설득을 못 했으며 이는 결과적으로 큰 반발만 불러오고 말았다. 지금도 그렇지만 당시에도 주민등록증은 종이쪼가리에 불과하면서도 인감증명서 탈취가 가능할 정도로 소셜 엔지니어링에 극도로 취약했다는 사실도 불을 지피는데 일조하기도 했다. 결국 1999년 주민등록증 개편에는 전자칩이 그대로 빠지고 말았는데 전산화를 위해서는 전자적 인증수단이 없어서는 안되니 공인인증서라는 이름으로 정보통신부와 함께 대체수단을 만든 것이다.

그러나 21세기 들어 대세는 전자신분증 도입으로 기울었으며, 2022년 기준 110개국 이상이 자국 신분증에 ICAO Doc 9303 규격을 채용하고 있다. 이에 아울러 물리적 분리라는 장점을 최대한 활용해 편의성보다 개인정보보호를 최대한 보장해주는 방향으로 정착된 상태다. 전자신분증을 책임지는 인쇄업계도 매출을 올려야 먹고 사는 만큼 이를 최대한 준수하는 편이며, 이는 한국조폐공사가 제작하는 키르기스스탄 신분증도 포함된다. 21세기 들어서는 현행 주민등록증보다 안전하면서도 편의를 보장하는 방법이 많이 쌓여있으며, 유럽연합만 봐도 절대다수가 표준 전자신분증과 QES 전자서명을 지원한다. 이들과 비교하면 공동인증서는 주민등록증하고 따로 놀기 때문에 두 개를 동시에 관리해야 하는 번거로움이 있다는 걸 알 수 있다.

공동인증서는 개별 규격에서 국제표준을 채용하나 '전자서명 절차 전반'은 국제표준과 척을 쌓고 있다. 이는 가령 구조적 문제나 절차상 하자가 발생해도 행정안전부가 단독으로 해결할 필요가 있다는 뜻이며, QES같은 표준 전자서명과는 다르게 외부로부터의 피드백 또한 어려워 비용상승의 우려가 있다. 대한민국은 70년간 주적 북한의 위협을 받아온 휴전국으로서 이러한 독자규격 관철은 대단히 위험하다. 2022년 대한민국-폴란드 방산계약도 대한민국산 무기가 NATO와 상당수 호환된다는 이유로 채택되었으며 이는 대한민국 무기의 설계사상이 부품고갈 원천차단을 기저에 두고 있기 때문이다. 이는 오프라인이 아닌 온라인이라고 해도 변하지 않는다. 대한민국은 물리적 위협 뿐만이 아닌 사이버 위협도 동시에 받고 있으며 최악에는 온라인 공격으로 공권력 소모와 역량 고갈에 직면할 우려가 있다. 대한민국은 일관적으로 주적의 위협을 저지하는 정책을 전개해왔으며 공동인증서 제도도 이러한 맥락을 이어 이에 맞는 보안유지에 협조할 필요가 있다. 유럽연합도 나라마다 다르지만 의무적 신분증도 있고 개인번호도 부여되는 나라가 대다수이다. 이들도 항상 러시아 간첩과 공작원에 시달리고 있으며 유럽연합에서 제정한 통합 전자신분증[24]과 eIDAS 규제는 이러한 고뇌의 산물이기도 하다. 대한민국도 동맹국과 동일한 규격을 채택하면 주적 북한으로부터의 사이버 안보위협을 사전에 차단 혹은 인지할 수 있으며 이는 온전히 행정안전부의 의지에 달려있다.

7. 비싸고 유효기간이 짧은 인증서

절대다수의 공인인증서는 유효 기간이 고작 1년밖에 되지 않으며, 만료일 30일 전이 되어야만 갱신이 가능해진다. 그리고 범용인증서는 1년 4,400원을 요구하며 자영업 등 일부 분야에서 필수적으로 활용된다. 그나마 은행용이나 증권용 등 목적별로 발급받는다면 돈을 들이지 않고 발급받을 수는 있지만, 본래 용도와 개인 행정업무 외에는 쓸 수 있다는 보장이 없어 결국에는 범용인증서를 찾아야 한다. 이를 외국의 사례에 대입하면 전자적 신분증명과 전자서명에 10년마다 44,000원이 필요하다는 의미이며, 44,000원은 일부 국가의 여권 수수료에 맞먹는다. 신분증명만으로 이렇게 비싼 비용을 징수하는 사례는 한국보다도 소득이 더 높은 홍콩이나 노르웨이에서나 찾아볼 수 있으며, 소득 대비로 환산하면 대한민국 국민이 지는 비용은 사실 부당하다고 볼 수밖에 없다.

절대다수의 기관이 유효기한 1년치의 인증서만 발급한다는 점은 큰 불편함을 자아낸다. 2023년 기준 3년 13,200원에 제공하는 기관도 있지만 금융인증서에 대항하는 성격으로 나온거지 원래는 전부 1년마다 갱신해야 했다. 보통 해외에서는 2~5년 유효한 증명서를 발급하며, 수수료는 무료이거나 신분증 발급수수료를 받되 인증서 발급에는 별도징수를 하지 않는다.


8. 공인인증서 해외 유출 사고

개인의 공인인증서 7천여 개가 해외로 유출된 것으로 알려졌다. 관련 기사.

한국인터넷진흥원(KISA)의 보도 자료에 따르면, 악성코드를 이용한 유출 시도로 추정되는데, 공격 서버 IP를 차단하고 피해자에게 유출 사실을 알리는 것으로 조치를 취했다고 한다. 현재 보도된 것과 관련한 피해 사실은 없는 것으로 밝혀졌다. 보도 자료.

아예 공인인증서를 노리는 파밍 바이러스가 존재한다. 금용감독원 팝업창을 띄우고 보안카드와 비밀번호를 누르도록 유도하는데 이에 낚이지 말자. 모든 정보를 입력하는 순간 정보가 다 유출된다.

9. 공인인증서에 관련된 오해


[1] 그래서 공인인증서를 PC나 노트북, 휴대폰에 각각 복사해놓으면 공인인증서 폴더가 있는 모든 기기에서 사용이 가능하다. 단, 공인인증서 기간이 만료되어 갱신하거나, 재발급하거나 하면 나머지 공인인증서 폴더는 효력을 상실하므로 다시 복사해서 붙여넣기 해야 한다. [2] 사실 이런 문제는 공인인증서 애플리케이션을 제대로 안 만들어서 발생하는 것이다. 안드로이드나 iOS는 샌드박스화되어 있어 내부저장소 앱 전용 공간에 넣어두면 유출되기 쉽지 않다. PC에서 하듯 외부 저장소에 파일을 꺼내놓으니 문제지. 이 때문에 앱간 파일 접근이 원천적으로 차단된 iOS가 조금이나마 보안상 나은 편이다. [3] 그나마 2024년 현 시점에서는 안드로이드 정책상 공동인증서를 앱별로 분리 저장하고 있어 타 앱의 공동인증서 탈취가 어렵게 되었다. [4] ISO/IEC 14443에서 정하는 Type A, Type B 등이 있다. MIFARE Classic 방식은 사실상 퇴출되었으며 해당 규격을 채용한 payOn 후불교통카드가 같이 들어있으면 위험할수 있다. [5] QES 전자서명은 부인방지가 법적으로 보장되고 부인측이 입증책임을 져야 한다. 이는 공인인증서의 목표이기도 했다. [6] 스미싱, 파밍, 메모리 해킹, 메신저 피싱 4가지이다. [7] 보안공학이라는 개념은 보안과는 다르다. Security의 상위개념으로, Risk management와 같은 실질적인 위협이 발생한 이후의 대처까지도 고려하기 때문이다. [8] 사용자는 보안 솔루션만 설치하면 되니 문제 없냐고 볼 수도 있지만, 이를 노리고 보안 솔루션과 비슷하게 보이는 프로그램을 설치하도록 유도할 수 있다. 사용자가 이 프로그램이 보안 솔루션인지, 해킹 시도인지 파악해야 한다는 점에서 사용자에게 보안을 떠넘기는 것이다. 당장 네이버라도 가서 백신 같은 거 추천해달라는 글이 얼마나 많은지 찾아보라. 전 국민을 대상으로 찾아보면 보안에 대한 개념이 전무한 사람이 매우 많다. [9] 또한 강제적으로 깔리는 보안 솔루션 자체의 신뢰성에도 문제를 제기해볼 수 있다. 이에 대해서는 후술. [10] 보안 프로그램은 그 특성상 운영체제 자체를 건드리는데, 두 개 이상이 운영체제를 건드리면 불안정성이 높아지기 때문이다. [11] 실제로 공인인증과 관련된 소프트포럼의 업데이트 서버가 해킹되어 전국적 피해를 본 사건이 있다. 3.20 전산망 마비사태 문서로. 수많은 공인인증 솔루션 제공 업체들이 얼마나 영세하고 또 스스로 보안에 취약한 지를 여실히 드러내주는 사건이다. [12] [전자금융사고] 금융소비자 불법이체 사고 발생 시, “금융회사의 과실” 판단기준 동향 및 금융소비자 대응방안 (V1.0) 서울중앙지법 2011가단468047, 서울중앙지법 2012단42481. [13] 물론 과장을 상당히 섞은 것이다. 보안 취약점에 관련한 한국인터넷진흥원(KISA)과 금융감독원의 권고안은 자주 내려오고, 그런 사항들에 대한 반영은 빠른 시간 안에 이루어진다. 하지만 이 과정 속에서 함께 유지 관리를 해주어야 하는 사이트들에 대해서는 인력과 시간, 돈의 부족이라는 핑계로 처리가 늦고, 이 사이에 공백이 발생하는 것이다. [14] 이와 같은 변명이 얼마나 많은 해킹 사고를 불러일으켰는지 생각해보자. 물론 대부분은 공인인증서나 개인 결제 부분이 아니라 사이트 취약점이나 내부 공모자의 소행이긴 했지만. [15] 귀에 걸면 귀걸이, 코에 걸면 코걸이. [16] 다른 본인 인증 수단인 OTP 역시 발급받기 위해서는 만원 가량의 돈을 내야 한다. [17] 변호사비 등 금전적 비용, 소송에 들어가는 개인의 시간적 비용, 그리고 피해를 인정하려 하지 않을 피고-금융사-측이 항소, 상고까지 할 것이므로 이는 3배 이상 늘어난다. [18] 통신정보 보호 프로토콜을 의미한다. 현재는 이것의 상위호환 격인 TLS를 주로 사용한다. [19] 공인인증서가 처음 나온 것은 Windows XP와 IE6이 출시된 2001년이고, ActiveX가 처음 나온 것은 96년이다. 또한 공동인증서에서 쓰기 위해 한국 내에서 표준형으로 만든 SEED가 97년부터 개발을 시작해서 99년에 완성되었다. 따라서 SEED 개발 시기에는 ActiveX가 최신시스템이 맞다. Java 기반은 너무 느려서 대체품으로 부적합했고. 따라서 이걸 선택한 것이 잘못이라고 볼 수는 없다. 당시 ActiveX는 당대 인터넷 표준 취급을 받던 마이크로소프트가 내놓은 최신 시스템이었고, 마이크로소프트의 위상을 고려할 때 앞으로 구축될 인터넷 환경도 ActiveX 기반이 될 것이고, 일단 내놓은 시스템을 방치하지는 않겠거니라고 상식적으로 판단했을 터이다. 그러나 숱한 보안 문제로 인해 방치를 넘어 현재는 개발사가 손수 없애려고 벼르고 있다. 아무 변화도 주지 않는 것은 핑계거리가 없는 엄연히 잘못된 것이다. 끊임 없이 변화하는 IT 시장에서 변화를 주지 못했다는 것은 숨을 쉬지 않는 것이나 다름없다. [20] 그런데 저조한 이용 원인 중 전자상거래 결제가 안 되는 것을 빼놓을 수 없을 것이다. 이로 인해 이용률이 더 떨어지는 악순환이 계속되었다. [21] 자발적으로 나온 결정이 아니라 마이크로소프트가 '우린 ActiveX 지원 못하니까 알아서 해라' 라는 발표가 나온 다음에 부랴부랴 나온 결정이었다. [22] 그리고 NPAPI가 하던 기능은 구글이 개선시킨 PPAPI(Pepper Plugin API)에서 구현하게 된다. 따라서, PPAPI를 이용해 코드를 전부 다시 짜야 할 것이다. 참고로 NPAPI Netscape Plugin Application Programming Interface의 약자로, 넷스케이프 2.0부터 구현되었기 때문에 ActiveX만큼이나 오래된 기술이다. [23] 2017년 현재 대부분 사람들이 Windows 7 Internet Explorer 9 이상을 쓴다. 다만 아직 Windows XP를 사용하는 곳도 몇 군데 있고, 또한 HTML5 기반으로 짜려면 IE11과의 호환성도 고려해 봐야 한다. [24] Regulation (EU) 2019/1157.