소프트웨어 보안심사 법제

2007.02.23 글쓴이 youknowit

“국정원이 SEED 알고리즘 사용을 사실상 강제하고 있다”는 말은 근거 없는 견해라는 점을 아래에서 설명드리겠습니다.

현행 법제에서 보안 관련 소프트웨어 심사는 크게 세가지로 나누어 볼 수 있습니다:

국정원의 암호모듈 검증은 “국가용 암호모듈”에 대한 것입니다. 국회, 법원, 행정기관 등이 내부적으로 사용하거나, 대국민 행정업무에 사용하는 암호모듈(서버용과 클라이언트 용을 모두 포함)에 대한 검증입니다. 전자정부의 서버측 암호화 관련 모듈, 전자정부 서비스를 이용하는 국민이 사용하는 클라이언트용 모듈에 대한 검증이 그 예입니다. 우체국도 ‘국가기관’이므로, 우체국이 사용하는 암호모듈은 국정원이 심사합니다. 다만, 모듈에 한할 뿐, 소프트웨어의 형상이나, UI에 관한 심사는 아닙니다.

금융감독원의 보안성 심의는 전자금융감독규정 시행세칙 제32조에 의한 것으로, 금융기관이 도입하는 “보안장비 및 암호프로그램 등 정보보호시스템”에 대한 심사입니다. 금융기관에 접속하는 “고객이 사용하는 소프트웨어”까지 금융감독원이 심사할 권한이 있는지는 잘 모르겠습니다.

KISA가 수행하는 공인인증기관의 시설 및 장비에 대한 심사는, 공인인증시스템(인증기관과 등록대행기관 내부에서 사용되는 서버측 소프트웨어)과 가입자 설비(공인인증용 클라이언트 소프트웨어)에 대한 것입니다.

예를 들면, 다음과 같습니다.

전자 정부나 우체국의 경우: “국가용 암호모듈”에 해당하므로, 국정원의 심사를 받아야 합니다. 서버측, 클라이언트 측 모두에 대한 심사이기는 하지만, 모듈에 한할 뿐, UI나 소프트웨어의 형상에 대한 심사는 아닙니다.

은행의 경우: 시중은행은 모두 금융결제원의 등록대행기관(RA)이기도 합니다. 따라서, 등록대행업무(공인인증 업무) 수행에 필요한 소프트웨어는 금융결제원의 주기적 점검을 받아야 하고(전자서명 인증업무 지침 제28조), 나머지 금융업무 수행에 사용되는 암호프로그램은 금융감독원의 심사를 받아야 합니다.

그러나, 고객이 사용하는 공인인증용 클라이언트 소프트웨어(공인인증서 이용에 필요한 플러그인 등)는 금융감독원이 심사할 권한도 없습니다. 오직 전자서명법 상의 감독관청(현재 행정안전부)가 전자서명법령에 정한 절차에 따라 심사를 하고, “심사를 받은 소프트웨어를 사용하여 공인인증업무가 수행되어야 합니다”.전자서명 인증업무 지침 제24조.

공인인증서 처리를 위한 ActiveX콘트롤은 전자서명법이 말하는 “가입자 설비”의 일종입니다. 따라서 KISA의 심사지원을 받아 행정안전부 장관이 이 소프트웨어를 심사하고, 심사를 받은 클라이언트 소프트웨어는 공인인증기관이 코드 사인을 하여 배포합니다. 국내 5개 공인인증기관 중, 금결원을 제외한 나머지 4 곳은 모두 그렇게 하고 있습니다.

이 세가지 심사 제도 중, SEED 알고리즘 사용을 ‘강제’하는 규정은 아무데도 없습니다. 공인인증용 가입자 설비에 대한 기술 규격(2.2) 중, SEED가 언급되는데, 이 기술 규격은 ‘보안접속’과는 상관이 없고, 오직 인증서 개인키를 ‘저장’할 때 사용해야 할 알고리즘에 관한 것입니다(SEED로 하거나, 3DES로 암호화 하여 개인키를 ‘저장’하면 됩니다. 그것이 다 입니다). 전자서명법은 ‘보안접속’에 관한 어떠한 규정도 없습니다.

전자서명법 뿐 아니라, 어떠한 법령에도 ‘보안접속’을 무슨 알고리즘으로 하라는 규정은 없습니다.

그리고, 5개 공인인증기관은 모두 가입자 설비를 제공해야 할 의무가 있습니다. 웹서버들은 그 중 어느 것이 되었건 간에 고객의 컴퓨터에 “이미” 설치된 공인인증용 가입자 설비(가입자 소프트웨어를 설치하지 않고 공인인증서를 발급받을 수는 없습니다)를 단순히 호출, 구동하기만 하면 됩니다. 따라서 고객은 이 은행, 저 카드사와 거래할 때 마다, 새로 가입자 설비를 내려받아 설치할 필요가 전혀 없으며, 보안경고창이 뜰 이유도 없습니다.

그러나, 현실은 전혀 다릅니다. 각각의 은행, 카드사 등이 전자서명거래에 필요한 사제(私製) 클라이언트 소프트웨어를 제각각 중복해서 보안업체로부터 구입하고 있습니다. 그 결과 고객들은 이 은행, 저 은행 거래를 개시할 때 마다, 새로운 私製가입자 소프트웨어를 자기 컴퓨터에 수북히 설치해야 하고, 그때 마다 보안경고창이 뜨고, 그때마다 “반드시 예”를 눌러야 합니다.

이런 사태는 금결원이 공인인증용 가입자 설비를 (심사까지 다 받았음에도) 은행, 결제대행사, 카드사 등에게 주지 않고 있기 때문에 생기는 것입니다. 보안업체와 금결원이 “협력관계“에 있다는 사실은 금결원 홈페이지에 공공연히 안내되어 있는 사실입니다.

이런 상황에서, 각 보안 업체는 서버측 소프트웨어도 만들고, 클라이언트 소프트웨어도 만들어 그 두가지를(total solution으로) 웹서버에게 팔아왔습니다. 이렇게 되면, 클라이언트 안에 어떤 루트인증서를 몰래 심어서 고객 PC에 설치하는지, 그 외에도 보안 업체가 클라이언트 소프트웨어를 이따금씩 어떻게 바꾸는지 아무도 알 수 없도록 되어 있습니다(서버와 클라이언트를 혼자서 다 해치우기 때문).

법대로, 제대로 하면, 서버측 소프트웨어 제공자와 클라이언트 제공자가 분리되어야 합니다(우연히 일치할 수는 있겠지만, 언제나 일치해서는 안됩니다.) 그렇게 해야, 투명성이 보장되고, 보안 업체가 이상한 일을 몰래 할 수 없게 됩니다. 현재와 같은 상황에서는 보안 업체 뿐 아니라 몰상식한 웹서버도 보안업체에게 이상한 짓을 하도록 부탁할 수 있습니다. 이니텍, 소프트포럼 등이 배포한 클라이언트에 들어가서는 안될 잡다한 자기서명 인증서가 몰래 포함되어 있는 이유는 “은행들이 그렇게 하도록 요구하였기 때문”이라는 주장도 있고, 세션암호화를 위하여 어쩔 수 없다는 주장도 있습니다. 최근 문제가 된 고객 PC 관련 정보 수집 문제도 은행이 그런 기능을 가진 플러그인을 요구했는지, 보안업체가 일방적으로 그런 기능을 포함시킨 플러그인을 업데이트 과정에서 만들어 내려줬는지 잘 알기 어렵습니다.

은행과 보안업체 말고는 아무도 통제할 수 없는 상황입니다.

추가 설명은 여기를 보시기 바랍니다.
[2009.2.24. 수정]

One Pingback/Trackback