분류 전체보기 (69)
Life Story (22)
Music Story (12)
My Play (10)
Security (20)
Scrap (3)
Virtualization (1)
기타연주  구글어스  기타  보안  마이클잭슨  Schecter  Jazz  블루스  hacking  가상화  schecter SD-II  Recording  Gartner  ActiveX  인터넷 뱅킹  전자정부  hijacking  웹 접근성  blues  jimi  연주  웹접근성  security  전자금융  웹표준  악플  srv  인터넷뱅킹  guitar  Virtualization 
 오픈웹 v. 금..
└>Open Web
 ActiveX 알고..
└>日常茶飯事
 Vista ActiveX..
└>SNAIPER의 조..
 마이클잭슨 내..
└>[Noenemy]'s m..
«   2017/06   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
+ VMblog.com -..
+ virtualizatio..
+ Virtualizatio..
+ VMTN Blog
+ Total : 71,559
+ Today : 0
+ Yesterday : 2
  

 

 

 

Open Web 사이트 방문 후 몇가지 궁금한 점.
+   [Security]   |  2007.01.26 09:00  
Open Web 사이트를 방문했었는데, 논리적이고 차분하게 향후 계획을 준비하는 것 같아서 기분이 아주 좋았습니다. 다만, 사이트 방문시 궁금했던 점 몇가지를 나열해 보도록 하겠습니다.

1. '전자서명법과 공인인증서' 내역에 대한 궁금증

궁금 1: 내용 중 아래에 해당하는 부분

이 기술규격(공인인증기관의 시설 및 장비 등에 관한 규정에 첨부된 기술규격을 의미)은 특정한 하나의 알고리즘 이나 보안모듈의 사용을 강제하지 않습니다. 예를 들어, 암호 알고리즘(기술규격 2.3)은 3-DES 또는 SEED를 사용하도록 되어 있고, 3-DES는 오픈소스로도 널리 구현되어 있는 알고리즘입니다. 기술규격이 어떤 배타적인 구현기술이나 특정 OS 또는 특정 브라우저에 종속된 기준을 정해둔 것은 더더욱 아닙니다.

오히려 “공인인증기관 간 상호연동을 위한 사용자 인터페이스 기술규격”(기술규격 6.1)은 MS 윈도즈 운영체제와 그 외의 운영체제를 모두 염두에 두고 작성되어 있습니다. 특히 그 개정연혁을 보면, “비 MS 윈도즈 사용자의 편의성을 고려하여 기술규격[이] 개정”(2003.12.) 되었음을 분명히 알 수 있습니다.

개인 해석: 문맥에서 설명하는 내역에서  첫번째 문장과 두번째 문장의 연결이 매끄럽지 못하며, 두개의 이야기는 서로 완전히 상반된 내용임에도 불구하고, 접속사로 "오히려"라는 문구를 삽입하고 있음.

법률 위반 문제에 대해 글에서 언급하고 있는 내용을 간단히 고쳐 보면... "공인인증기관으로 지정된 여섯 곳 모두 MS사 이외의 브라우저를 동시에 지원하지 않는 기술을 이용하며, 따라서 기술규격 미달이다. 이는 근거 법률을 어기는 것이다." 정도로 요약이 되며, 이에 대한 근거로 전자서명법 제7조 제1항, 제19조 제1항, 제22조의2 제2항을 인용하고 있음.

공인인증기관으로 지정된 여섯 곳 모두, MS사가 판매하는 운영체제와 MS사의 브라우저를 동시에 사용하지 않으면 공인인증서의 발급신청 조차 할 수 없도록 하는 기술을 사용하고 있습니다. 이것은 전자서명법 하위 규정에 부속된 기술규격 미달이라는 문제에 그치는 것이 아니라, 근거법률 자체를 어기는 것입니다. 이하에서 자세히 설명하겠습니다.

전자서명법(이하, “법”) 제7조 제1항은 다음과 같이 규정하고 있습니다:

공인인증기관은 정당한 사유없이 인증역무의 제공을 거부하여서는 아니된다.

법 제19조 제1항은 또한 다음과 같이 규정하고 있습니다:

공인인증기관은 자신이 발급한 공인인증서가 유효한지의 여부를 누구든지 항상 확인할 수 있도록 하는 설비 등 인증업무에 관한 시설 및 장비를 안전하게 운영하여야 한다.

법 제22조의2 제2항은 또한 다음과 같이 규정하고 있습니다:

공인인증기관은 이용자가 공인인증서에 의하여 다음 각호의 사항을 확인할 수 있도록 쉬운 수단을 제공하여야 한다.

1. 공인인증기관의 명칭 등 공인인증기관임을 확인할 수 있는 정보
2. 가입자가 당해 공인인증서가 발행된 당시에 전자서명생성정보를 지배·관리하고 있는 사실
3. 공인인증서의 발행 전에 전자서명생성정보가 유효한 사실



궁금 3:  전자서명법 제7조 제1항에 대한 개인 법률 해석

내용 : "공인인증기관은 정당한 사유없이 인증역무의 제공을 거부하여서는 아니된다."

개인 해석 : 이것은 "공인인증서를 이용한 전자서명의 확인을 요구하는 경우, 정당한 사유없이 특정 공인기관인증서만을 이용해서는 안된다"로 해석하는 것도 가능하지 않을까요? 이것은 공인인증기관(한국정보인증, 한국증권전산, 금융결제원, 한국전자인증, 한국무역정보통신, 한국전산원)간의 상호연동성과 비호환으로 인한 향후 악영향을 사전에 방지하자는 의미하는 것이지, OS나 Browser의 종류에 상관없이 인증을 모두 처리하라는 의미로 해석되기는 좀 힘들수도 있다고 봅니다. 경우에 따라서는 방어 대책이 필요할 수도 있을 것 같습니다.

궁금 4: 전자서명법 제19조 제1항에 대한 개인 법률 해석

내용 : "공인인증기관은 자신이 발급한 공인인증서가 유효한지의 여부를 누구든지 항상 확인할 수 있도록 하는 설비 등 인증업무에 관한 시설 및 장비를 안전하게 운영하여야 한다."

개인 해석 : 제 19조 제 1항에서 가장 중요한 키포인트는 '누구든지 항상 확인 할 수 있도록'에 있다고 봅니다. 이 부분은 공인인증기관 스스로가 발급한 인증서의 유효성 검증 요청에 대해서는 항상 확인 할 수 있도록  설비를 갖추라는 의미이며, 이 부분에서 '누구든지'에 해당하는 의미를 Open Web에서는 Any OS, Any Browser로 정의하고 있는 듯 합니다. 그러나, 전자서명법 제19조는 '제19조(인증업무에 관한 설비의 운영)'이라고 명시되어 있어, 19조가 사실상 공인인증서의 처리 방법 및 유효성 검증을 위한 세부 조항이 아니라는 점에 있습니다. 설비의 운영과 관련된 조항이라는 것이죠. 또한, 누구든지라는 내용은 '전자서명된 전자문서를 제출하는 누구든지'로 해석될 수도 있는 부분이라고도 생각됩니다. 이 부분에 있어서는 상당한 법리적 공방이 예상되는 부분입니다.

또 한가지 부분은 사실 공인인증기관은 X.509 표준에 맞는 양식의 인증서를 제출하는 전자문서에 대한 유효성을 검증하는 것 뿐이지, 예를 들어 한국전산원이 배포하는 공인인증서는 반드시 한국전산원이 배포하는 Windows용 ActiveX 인증서 클라이언트를 사용하는 것은 아니라는 것이죠. 한국전산원이 배포하는 공인인증서를 A, B은행이 채택하여 이용한다고 가정할때, A, B은행은 서로 다른 인증서 클라이언트 개발사를 채택하여 사용할 수 있지 않던가요? 단지 공인인증기관은 간단히 인증서에 대한 공인된 자격의 서명을 할 뿐이 아니던가요? 따라서 이 부분은 '공인인증기관은 X.509 표준에 맞는 양식의 인증서를 제출하는 누구나'로 해석하는 것이 좀 더 맞을 수도 있겠다는 생각도 듭니다.

공인인증기관이 실제 인증이 필요한 사이트에서 이니텍 ActiveX쓰던 소프트포럼 ActiveX를 쓰던 또 다른 ActiveX 인증서 클라이언트를 쓰던 상관할 필요도 없고, 단지 인증서 발급 수수료를 받는 것이 중요한 것 아니던가요? 예를들어 공인인증기관중 한 곳인 금결원의 등록대행기관 즉, 금결원의 Yessign 서비스를 사용하는 곳은 22곳으로 여기에서 확인 할 수 있습니다. 이때, 이 22곳이 모두 금결원이 제공하는 동일한 Windows PC용 인증서 Client를 사용하는 것이 아니라는 것이죠. 22곳중 한곳인 기업은행은 소프트포럼의 제품을 이용하고 있으며, 신한은행의 경우에는 이니텍의 제품을 이용하는 것으로 알고 있습니다. 따라서 공인인증기관은 표준만 맞으면 유효성의 검증을 하는 것이며, 고객들이 사용하는 Windows PC용 인증서 Client의 선택은 각각의 은행들이 선택하는 것을 알 수가 있습니다. 공인인증기관이 실제 사용자의 Windows PC용 인증서 Client 사용을 권고하거나, Windows OS에서 서명된 인증서만을 받는다거나 하는 것이 금번 소송의 중요한 핵심적 쟁점이라면, 이것은 쟁점 선택에 좀 문제가 있을수도 있다는 생각이 듭니다.  

공인인증기관이 인증서에 대한 유효성 검증을 위해 Windows OS에서 서명된 인증서만을 받는다면 그때는 가능하겠으나, Mac이나 Linux에서 X.509 표준으로 만들어진 인증서 제출에 대해 공인인증기관이 처리할 수 있다는 테스트 결과 증거물을 보이는 순간 제19조 제1항에 대한 공격은 유효성을 즉시 상실할 것이 분명해 보입니다. (이 부분에 대해서는 많은 반박 자료 부탁드립니다.)

궁금 5: 전자서명법 제22조의2 제2항에 대한 개인 법률 해석

내용 : "공인인증기관은 이용자가 공인인증서에 의하여 다음 각호의 사항을 확인할 수 있도록 쉬운 수단을 제공하여야 한다."

개인 해석 : 글쎄요... 이 부분은 왜 인용이 되어 있는지 솔직히 모르겠습니다. 이 부분이 과연 "인증서 발급신청자가 MS 제품을 사용하지 않는 것이 인증역무의 제공을 거부할 정당한 사유"에 위반되는지 여러번 읽어봐도 제 짧은 지식으로는 파악하기 불가능합니다.

제가 볼때는 이후의 내용의 근거가 되는 선행논리가 상당부분 취약할 수도 있어 이후의 논리가 위협받는 지경에 이를 수도 있다고 봅니다. 이 부분은 위험 관리 차원에서 사전에 보강이 필요할 것으로 보입니다. 제가 만약 공격자의 입장이라면, 선행논리를 집중적으로 공격할 것 같기 때문입니다. 차라리 '공인인증기관 간 상호연동을 위한 사용자 인터페이스 기술규격'을 집중적으로 공략하는 것은 어떨지 싶기도 합니다.

2. 주장에 대한 반박 부분
글의 제목이 "전자서명법과 공인인증서" 입니다만, 여기에 기술적인 내용과 법률적 내역 및 누가 말했는지도 모르는 내용에 대한 3가지 반박이 뒤섞여 있습니다. 문서 내용을 좀 분리 시키는 것이 좋지 않을지요? 또한 3가지 반박에 대한 부분은 누가 주장한 내용에 대한 반박인지에 대한 명시가 좀 필요로 하다고 봅니다. 최소한 어느 부처의 누구 또는 언제의 언론 배포 자료에 있는 내용이다 정도라도...


신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     , , , ,
     1   19
BlogIcon youknowit 2007.02.01 12:35 신고
매우 자세한 논의, 감사드립니다.

1. 전자서명법이 말하는 "설비"는 소프트웨어를 포함하는 개념입니다. 특히 "가입자 설비"는 "가입자 소프트웨어"입니다. 가입자 소프트웨어는 X.509 포멧에 맞는 인증서파일과 비밀키를 사용하여 가입자가 자신을 identify 하거나, 자기가 보내는 문서에 전자서명을 하는데 필요한 소프트웨어입니다. 선생님께서 말씀하시는 "인증서 Client"가 바로 가입자 설비 입니다.

2. 법령은 가입자 설비가 준수해야할 기술 규격(암호화 방법, 알고리즘 등)을 자세히 정하고 있습니다. 선생님께서는 "인증서 Client의 선택은 각각의 은행들이" 제각각 자기 돈을 들여 확보하는 "지금의 현실"을 전제로 생각하시는 듯합니다. 그러나, 선생님의 입장은 공인인증서와 사설인증서를 구분하지 않은데서 오는 오류인 것 같습니다.

3. '사설'인증서의 경우에는, 고객이 제시하는 사설인증서를 처리하는데 필요한 솔루션을 서버운영자가 나름대로 개발하여 제공하든지, 그것이 부담스러우면 아예 인증서를 요구하지 않던지 하면 됩니다. 사설인증서(verisign, thawte, cacert, rapidssl 등이 발급하는 인증서를 말합니다)를 처리하는 소프트웨어가 어떤 규격과 기술요건을 충족해야 하는지에 대하여는 아무런 법적 규제가 없습니다. 오로지 기술적, 경제적 고려만이 필요할 뿐입니다.

4. 그러나, '공인인증서'는 다릅니다. 아무나 "공인인증서 Client"(소프트웨어)를 마구잡이로 개발, 구입하여 (정보보호진흥원의 심사도 받지 않고) 국민에게 제공하는 것은 위법할 수도 있습니다. 그런 Client 소프트웨어를 사용하여 부착된 전자서명은 문서의 진정성립을 추정받는 근거로 되지 못할 가능성도 있습니다.

5. 공인인증기관은 "정당한 사유없이 인증역무의 제공을 거부"할 수는 없습니다. 금결원은 신한은행 이용자에게는 매킨토시 용 Client도 제공하고, 농협 이용자들에게는 리눅스 용 Client소프트웨어도 제공합니다(선생님은, 이것은 이들 은행이나 농협이 제공하는 것이고, 금결원과는 상관없다고 이해하시지만, 법률적으로는 금결원이 이들을 통하여 제공하는 것입니다). 그러나 나머지 이용자(예컨데, Yessign 인증서로 전자정부를 이용하려는 자)들에게는 이들 (리눅스, 맥 용) 소프트웨어 제공을 차별적으로 거절할 '정당한 이유'가 있다는 주장은 누구도 수긍하지 않을 것입니다.

6. 법은 가입자 설비(공인인증서 Client)를 제공할 의무를 공인인증기관에게 부과하고 있습니다. 은행, 행자부(전자정부), 카드사, 나아가 전국의 모든 웹사이트 운영자들 마다 "공인인증서 Client"를 마구잡이 해법, 편법을 써서 독자적으로 개발, 제공하려 노력한다는 것은 상식에 비추어 보아도 부당할 것입니다.

전자서명법은 상식에 크게 어긋나는 법이 아닙니다.
BlogIcon Jerry 2007.02.01 19:17 신고 
아, 댓글 남겨주셔서 감사드립니다. ^^

일단, 저는 '전자서명법과 공인인증서'라는 글을 토대로 작성을 했는데, 나중에 알고보니 'http://open.unfix.net/suit.zip'에 손해배상 청구관련 서류를 올려놓으셨더군요. '전자서명법과 공인인증서' 문서를 봤을때는 이해가 안가던 부분이 청구관련 서류를 보고는 대부분 이해가 되더군요.

특히 전자서명법의 하위 법률에서 정의하는 '설비'의 법주에는 S/W도 포함된다고 하는 부분에 대해서 명확히 확인할 수 있었습니다. 다만, 정부에서 지정한 공인인증기관과 대행기관간의 계약이 어떤식으로 되어있는지의 여부에 대해서는 저로써는 알 수 있는 방법이 없더군요. 사실 이 부분이 가장 궁금했었습니다. 왜냐하면 이 부분이 "정당한 사유없이 인증역무의 제공을 거부"하는 부분에서의 핵심적 부분일 수도 있다는 생각 때문입니다.

"웹 사이트 운영자들마다 공인인증서 Client를 마구잡이 해법, 편법을 써서 독자적으로 개발, 제공하려 노력한다는 것은 상식에 비추어 보아도 부당"부분에 대해서... 제 개인적 의견으로는 공인인증기관이 공인인증서 Client를 직접 배포하는 형태는 오히려 시장의 자율적 경쟁을 방해할 수도 있다는 점에서 의견을 달리합니다.

제 짧은 견해로는 현재의 공인인증기관과 대행기관이 존재하는 구조가 좀 더 합리적인 구조가 아닐까 생각을 해 보며, 다만, 국가로부터 지정을 받은 공인인증기관이 대행기관에 대한 관리 및 감독의 의무(이런 것이 계약 조항이 있는지도 의문이지만...)를 게을리 한 부분에 대해서는 책임이 있다고 봅니다.

제 개인적인 의견에 대해서 이렇게 상세한 설명을 달아주셔서 개인적으로는 대단히 감동 받았습니다. 거듭 감사드립니다. ^^
나그네 2007.02.01 13:50 신고
@youknowit//
5.공인인증기관은...>>신한, 농협 이외의 은행 등은 금결원에 (신한, 농협처럼)매킨토시, 리눅스용 클라이언트를 요구하지 않았다. 따라서 금결원은 제공을 "거부"한 것이 아니다
이런 해석은 안되나요? 법률을 모르니 그저 문맥만 보고 대충 이해한 글입니다. 죄송.
BlogIcon Jerry 2007.02.01 19:21 신고 
글쎄요. 공인인증기관이 대행기관을 지정할 때는 각각의 역할과 책임에 대한 명확한 규정이나 계약이 반드시 존재할 것 같습니다. 따라서 이러한 경우(제 개인적 의견이긴 합니다만...) 해당 공인인증기관은 관리, 감독의 책임을 다 했다고 보기는 어렵다고 봅니다. 공인인증기관의 역할에 대해서는 법률 분석을 좀 더 해봐야 할 필요성을 느끼는군요. 조만간에 이 부분에 대해서는 한번 검토해 볼 생각입니다.
BlogIcon youknowit 2007.02.01 20:41 신고
"이행보조자"라는 법률 개념이 있습니다. 채무(의무)를 부담하는 자는, 그 채무를 직접 이행할 수도 있고, 누구를 시켜서 할 수 있는 일이라면, 누구를 시켜서 그 채무를 이행하게 할 수도 있습니다.

전자서명법은 "공인인증기관"의 법률상 의무만을 규정할 뿐이므로, 그 의무를 이행하는 과정에서 공인인증기관이 등록대행기관과 어떤 계약관계를 맺었는지는 우리(이용자, 가입자)가 상관할 바는 아닙니다. 그들 간의 내막이야 어찌되었던, 최종적으로 의무가 이행되지 않았으면, 공인인증기관이 그 책임을 져야합니다.

짜장면을 주문하면, 중국집 주인이 직접 배달하지 않고, 다른 누구를 시켜서 배달하는 것이 보통입니다. 주인은 주문을 받고 배달해 주겠다고 했는데(즉, 의무를 부담하고 있는데), 배달을 담당하는 자가 임의로 성북동에 사는 사람에게는 배달을 거부하는 경우, 그 책임은 주인이 지는 것입니다. 손해배상도 주인을 상대로 구하는 것이고, 배달원을 상대로 구하는 것이 아닙니다. 자기들 간에 어떻게 되는지는 their problem, not mine.

따라서, 원고들로서는 등록대행기관과 공인인증기관 간의 계약 조항을 알 필요가 없습니다. 금결원은 자기 잘못이 아니라, 은행잘못이라고 주장하는데, 이것은 아마도 그쪽이 아직 제대로 된 법률 자문을 받지 못해서 그런 것일 가능성이 큽니다. 일부 대행기관은 리눅스, 맥 용 설비도 제공하고, 나머지는 안하고 있는 현재의 상황을 법률 용어로는, "이행보조자의 과실은 채무자의 과실로 본다"라고 설명합니다. 나그네 님이 궁금하게 여겼던 내용도 바로 이렇게 설명되는 것입니다. 은행(RA)이 이용자에게 인증서 발급 등을 거부하면, 그것은 곳 인증기관(CA)이 거부한 것입니다.

"시장의 자율적 경쟁"을 언급하셨는데(Jerry 님), 이점은 "사설인증서"와 "공인인증서"를 나누어 생각해야 합니다. 공인인증서는 특별한 법적 효력을 가집니다. 전자서명법 제3조. 그것을 감안하여 시장의 자유로운 경쟁에 맡기는 것이 아니라, 공인인증기관으로 "지정" 받은 업체만이 그 서비스를 제공할 수 있게 하고, 그들이 법령에 정한 요건을 준수하는지를 국가가 감독하는 규제체제(regulatory framework)가 적용됩니다. 자유 경쟁 체제가 아닙니다.

"공인인증서" 처리용 client 소프트웨어를 아무 사업자나 개발하여 공급하는 경우, 국가가 그 모든 소프트웨어를 감독하고 관리할 수는 없게 됩니다. Module은 대체로 공통적이므로, module 만 심사하면 되지 않을까? 그렇지 않습니다. 국정원의 보안성 심사와는 달리, 공인인증기관이 제공해야 할 가입자 설비는 "형상 관리"까지 받아야 합니다. 시설, 장비 규정 9.6 참조.

자유로운 경쟁 체제는 사설인증서 client에서 통용되는 개념입니다.

오픈웹이 파악하기로는, 현재 상황은 공인인증서 client를 금융기관, 카드사, 행자부가 "알아서" 마련합니다. 이들에게 솔루션을 파는 업체도, 자신들이 파는 "가입자 설비"가 전자서명 관련 법령의 규제 대상이라는 점, 공인인증기관이 이러한 가입자 설비를 정기적으로 심사받아야 할 법적 의무를 지고 있다는 점(그리고 그 의무를 완전히 무시하고 있다는 점)을 모르고, 그냥 장사합니다.

다만, 공인인증서 client에 대하여는 "자유경쟁"원리가 배제되지만, 인증서 처리와 관련된 프로토콜이 공개되어야 할 필요는 있습니다. 인증서 솔루션이 아니라, 각종 결제 대행 솔루션, 서버간 back-end communication 솔루션을 개발하려는 여러 업체( 이부분은 자유 경쟁이 이루어져야 하는 영역입니다)들은 인증서 처리와 관련된 프로토콜이 지금과 같이 아예 존재하지도 않는 상황에서는 자유롭게 경쟁할 수 없습니다. 개별카드사와의 결제 대행 계약을 따낸 업체만이 솔루션을 개발할 수 있는 과점적, 경쟁 제한적 현실이 판을 치고 있습니다. http://open.unfix.net/%EC%A0%84%EC%9E%90%EC%84%9C%EB%AA%85%EB%B2%95%EA%B3%BC-%EA%B3%B5%EC%9D%B8%EC%9D%B8%EC%A6%9D%EC%84%9Cin-progress/#c9 참조.

즉, 정작 경쟁이 이루어져야 할 영역에서는 위법한 경쟁 제한행위가 이루어지고(금결원은 결제대행 사업도 합니다(bankpay); 아마도 그래서 인증서 처리 프로토콜을 제정하지도, 공개하지 않고 있는지도...), 정부가 철저히 규제하고 감독해야 할 영역(가입자 설비)에서는 시장에 내팽겨 쳐놓은 사태가 지금의 현실입니다.
BlogIcon Jerry 2007.02.01 22:56 신고 
법 논리 측면에서는 저 역시도 공인인증기관의 책임은 피할 수 없다고 봅니다.(사실 지금까지 제가 잘못 알고 있었던 부분이 상당히 존재하더군요. OTL) 말씀하신 법리적 논리에 대해 거시적 관점에서 웹 개방성 증대 부분에서 충분히 납득을 합니다.

제 생각에는 '설비'를 S/W까지 포함하는 개념이 옳다고 보며, 또한, "이행보조자의 과실은 채무자의 과실로 본다"가 법률적으로 올바른 판단이라고 봅니다.(제 개인적으로도 이 부분은 법률적 논리에서는 문제 없다고 봅니다) 공인인증서 Client 소프트웨어를 만드는 제조사는 사설인증서용 Client 소프트웨어와 공개된 프로토콜을 사용하는 공인인증서용 Client 소프트웨어의 두가지 버전이 동시에 존재하여야 한다는 말씀과 같다고 봅니다. 이 부분이 Open Web에서 바라는 향후 방향성과 일치하는지요? 이것이 웹 개방성 증대를 이끌어 낼 수 있는 전략적 차원에서의 접근이 맞는지요?

사실 금감원의 전자금융감독규정세칙 6절 32조(보안성심의)에서 이야기 하는 "보안장비 및 암호프로그램 등 정보보호시스템(외부통신망 접속을 위하여 사용되는 경우에 한한다)을 도입하는 경우. 다만, 별도로 보안장비 인증을 담당하는 국가기관 또는 감독원장이 인정하는 기관에서 평가․인증․개발․발표하였거나 이에 준하는 것으로 감독원장이 인정한 장비 및 프로그램의 경우에는 그러하지 아니하다" 라는 부분은 사실상 금융기관이 전자금융감독규정에서 제시하는 평가, 인증, 개발 제품을 쓰도록 제한이 되어 있습니다. 문제는 국정원의 IT보안 인증사무국 홈페이지를 보면, PKI 제품 중 선택할 수 있는 제품이 현실적으로 제한이 되어 있다는 점을 확인할 수가 있지요. 사실상 최소한 금융기관 또는 국가기반시설로 지정된 곳에서는 국가기관이나 금융감독원장이 인정하는 장비 및 프로그램을 쓰라는 이야기와 같다고 봅니다. 이러한 경우, 방어자적 입장에서는 고의과실 또는 미필적고의 여부에 해당하느냐를 따지고 들어올 가능성도 있을 것 같기는 합니다. 선생님의 글을 보면 법률적 지식이 해박하신 분이라고 판단이 되는데, 이 부분은 좀 어떤지요? 개인적으로 궁금한 점이 너무도 많습니다. ^^

아 참... 선생님께서 말씀하신 "인증서 처리와 관련된 프로토콜이 지금과 같이 아예 존재하지도 않는 상황"부분에 대해서는 제가 좀 이해가 안가는데, 어떤 부분을 이야기 하시는지 모르겠습니다. 죄송합니다만, 이 글을 보시면 답글 좀 부탁드립니다. 감사합니다.
BlogIcon youknowit 2007.02.01 20:59 신고
Jerry 님, 페이지가 이상하게 되어버렸네요. 아마도, 중간에 나오는 링크 주소가 너무 길어서 이렇게 되었나 봅니다. 링크를 <a href=""></a>로 처리하시고, 이 댓글은 지워주세요.
BlogIcon Jerry 2007.02.01 22:00 신고 
죄송합니다만, 선생님의 글을 지우기 전에 제가 선생님의 글을 수정할 권한은 (정상적인 방법으로는) 없습니다. 지적해 주신 내용에 대해서 많은 생각을 필요로 하기 때문에 지우는 것은 좀 아니라고 봅니다. 그냥 있는 그대로 남겨 놓도록 하겠습니다. ^^
BlogIcon youknowit 2007.02.01 22:27 신고
아, 글 전체를 지우라는 뜻은 아니었고, "...과점적, 경쟁 제한적 현실이 판을 치고 있습니다." 라는 귀절 다음에 제가 걸어둔 링크 주소가 너무 길게 나오는데, 이것을 적절히 처리하시면 페이지가 정상적으로 보이지 않을까 하는 생각에서...
BlogIcon youknowit 2007.02.01 23:57 신고
아, 이러면 소송전략이 너무 노출되는데... haha

금융기관이 사용하는 암호화 관련프로그램은 금감원의 감독만 받으면 되느냐? 그렇다고들 생각하지만, 이것도 법적으로는 틀립니다. 공인인증서 처리에 사용되는 가입자 소프트웨어는 금융기관뿐 아니라, 전자정부, 쇼핑몰 등을 "통하여" 이용자에게 제공되지만, 이를 제공할 의무를 지는 자는 공인인증기관입니다.

따라서 공인인증기관이 정통부(실제로 심사를 하는 곳은 정보보호진흥원)의 심사를 받아서 제공한 것이 아니라, 은행이 "알아서" 제돈 들여서, 정보보호진흥원의 심사도 받지 않고, 금감원의 심사만을 받고 제공하는 가입자 소프트웨어는, 엄격히 말하면 전자서명법의 요건을 충족하지 못하는 것입니다. 극단적으로 고객이 송금거래를 부인할 경우, 은행으로서는 전자서명을 증거로 제시할 것인데, 만일 고객이 그 전자서명이 어떤 가입자 소프트웨어로 암호화된 것인지, 그 가입자 소프트웨어가 전자서명법 규정에 따라 공인인증기관이 제공한 것인지, 아니면 은행이 스스로 만든 것인지를 문제삼으면, 은행이 패소할 여지도 있습니다. 은행은 공인인증기관이 아닙니다.(test case 도 준비 중입니다)

마찬가지로 지금 행자부가, 전자정부 사이트에서 제공되는 공인인증서 client 를 비스타에서 돌아가도록 하기 위하여 날밤을 새고 있는데, 참 웃기는 일입니다. 행자부가 공인인증기관 입니까? 만일 비스타에서 돌아가도록 "행자부가" 수정한 가입자 소프트웨어를 정보보호진흥원의 심사를 받지 않고 배포하는 경우, 전자서명법상 가입자 소프트웨어의 '무단 변경'으로 평가 받을 여지도 없지는 않습니다.(제19조 제3항) 민원신청의 진정성립이 대량 부인될 가능성도 있습니다.

그렇다고, 행자부가 정보보호진흥원에 가입자 소프트웨어 심사를 요청하는 것은 더 웃깁니다. (공인인증기관도, 등록대행기관도 아닌 주제에...) 은행의 경우에는 그래도, 공인인증기관의 agent로서 심사를 요청한다고 이해해 줄수는 있겠지만,,,

말씀하신 세칙 제6절 32조는, 은행 A가 공인인증기관 B로부터 제공받은(즉, 이미 정보보호진흥원의 심사를 받은) 가입자 설비를 고객에게 제공하는 경우에, 금감원의 심사를 또 받을 필요는 없다는 뜻으로 보입니다. 은행이 독자적으로 마련한 공인인증서 client는 금감원의 심사를 받아야 하겠지만, 그 심사를 받았다고 해서, 적법한 전자서명 소프트웨어가 되는 것은 아닙니다. 금감원이 정보보호진흥원의 심사권한을 대리 행사할 수는 없기 때문입니다.

인증서 처리 표준 프로토콜은 이렇게 설명드릴 수 있겠습니다. 고객(A), 쇼핑몰(B), 카드사(C)를 가정합시다. 쇼핑몰에서 구입한 물품대금을 카드로 결제할 때, 인증서가 사용된다면, 결제대행사(PG)는 카드사와의 back-end communication 과정에서 다음과 같은 문제들에 대한 해답이 있어야 할 것입니다: 카드번호를 서명대상인 평문의 제일 앞에 놓을것인가? 유효기간은 카드번호의 앞에 놓을것인가? 카드번호나 유효기간에 변수명을 추가할것인가? 변수명이 필요하다면 어떤 변수명이 필수이고 그 변수가 전달되었을때 카드사 서버는 어떻게 반응할 것인가?

카드사와 결제대행 계약을 "이미 체결한" PG사는 카드사 서버의 DB 구조, 카드사 receiving end 의 스크립트 등을 모두 참조할 수 있으므로 그것을 기초로 전자서명이 부착된 결제정보를 communicate 하는 솔루션을 만들 수 있습니다. 그럼, 그 카드사와 결제대행계약을 체결하고 싶어하는 경쟁 PG회사는? "그것 좀 보여 주세요" 라고 하면 되나요? 가르쳐 주겠습니까?

저는 여러 전문가 분들의 자발적 도움을 얻어 오픈웹의 시다바리 일을 보고 있는 김기창이라고 합니다.
BlogIcon Jerry 2007.02.02 11:59 신고 
아~ 교수님 안녕하세요. 어쩐지 필체 하나하나에서 포스가 느껴져서 사실 감탄해하고 있었는데, 김 교수님께서 직접 글을 남겨주시고 계셨네요. 상당히 바쁘실 것으로 생각됩니다만, 이러한 열정이 있기에 오픈웹의 미래에 좋은 성과가 있을 것이라고 믿어의심치 않습니다. (제가 법 전공자가 아닌지라 법률 해석 부분에서 상당한 오류가 있었는데, 얼굴이 다 화끈 거립니다. ^^)

일단, 말씀해 주신 부분에 대해서는 사실 논란의 여지가 좀 있지 않나 하는 생각을 조금 가져 봅니다. 이 부분에 대해서는 외부 미팅 다녀와서 제 의견을 올려보도록 하겠습니다. 감사합니다.
BlogIcon youknowit 2007.02.02 14:07 신고
Jerry 님, 고견 기다리겠습니다.
다만, 한가지 보충할 부분은, 전자서명법은 공인인증기관에게 가입자 소프트웨어를 제공할 의무만을 규정할 뿐, 그것이 무료로 제공되어야 한다는 규정은 없습니다.

물론, 가입자 소프트웨어(공인인증서 client)는 지금도 무상으로 깔리는 것으로 알고 있습니다. 그러나 서버측 플러그인(공인인증서 관련 작업을 수행하는)과 스크립팅 작업 등은 공인인증기관이 적정한 가격을 받고 각 웹서버에 제공할 수도 있고, 웹서버가 직접 확보할 수도 있을 것입니다. 서버 사이드 인증관련 솔루션은 공인인증기관이 제공하여야 할 법적 의무가 없습니다. 그것을 독점 제공할 "권리"는 당연히 없습니다.

그러나 웹서버가 서버사이드 인증 솔루션을 스스로 확보하기 위하여는, client가 공인인증서 처리에 사용하는 프로토콜이 당연히 공개되어 있어야 하겠지요.

즉, "가입자 설비"제공 의무만을 공인인증기관에게 부과한 법 규정의 취지에 비추어보면, 공인인증기관은 공인인증서 처리 프로토콜을 확정, 공개하여야 함이 당연합니다. 만일 그렇지 않다면, 공인인증기관은 client를 제공하여야 할 자신의 "의무"를 핑게로하여, 서버사이드 솔루션 장사를 독점하게 되기 때문입니다.
BlogIcon youknowit 2007.02.03 13:42 신고
마침 법원에 추가로 제출할 서류를 준비 중 이라서, 그 내용을 알려 드립니다. 어차피 금결원도 알게 될 거니까...

1. 가입자 설비(인증서 클라이언트)를 만일 은행, 카드사 등이 독자적으로 확보하여 제공하는 경우, 다음과 같은 문제점이 있습니다. 가입자 소프트웨어가 수행하는 작업은 여러가지가 있겠지만, 전자서명 부착을 예로 들겠습니다. 자신이 보낼 문서에 전자서명을 부착하려면, 그 문서의 고유식별값(hash value)을 계산하고, 그 값을 자신의 비밀키로 암호화해야 합니다. 이 점에 대한 기술적 설명은 이미 제출된 조정신청서 별지4, "공인인증 제도 개요", paras. 1-6 참조. 이 서류는 http://open.unfix.net/suit.zip 에서 내려받아 보실 수 있습니다.

2. 문서의 고유식별값은 sha1sum 으로 계산할 수도 있고, md5sum 으로 계산할 수도 있습니다. 그렇게 계산한 값을 암호화하는데는 SEED 알고리즘을 사용할 수도 있고, AES 알고리즘을 사용할 수도 있고, 그 외에도 암호화 알고리즘은 무수히 많습니다(BlowFish, IDEA 등 약 60여종이 알려져 있습니다). 웹브라우저로 https://www.fortify.net/sslcheck.html 에 접속하면, 자신의 브라우저가 그 사이트에 암호화 접속을 하는데 사용하는 알고리즘과 암호화 강도를 확인할 수 있습니다. 녹색으로 표시되는 것이 바로 자기 브라우저가 해낼 수 있는 최고 수준의 암호화 능력입니다. 파이어폭스, 오페라 등의 브라우저는 256bit 암호화까지 해낼 수 있고(AES 알고리즘 사용), 인터넷 익스플로러는 128bit 수준의 암호화에 머물고 있습니다(RC4 알고리즘 사용).

3. 관련 법령은, 문서의 해쉬값은 sha1sum, HAS-160 으로 계산하여야 하고, 그 값의 암호화는 SEED 또는 3-DES 알고리즘을 사용하도록 규정하고 있습니다. 시설 및 장비 규정, 5.1.2.나(1), 5.1.3.가. 참조. (시설 및 장비 규정은 http://www.rootca.or.kr/kisa/kcac/jsp/kcac_9041.jsp 에서 확인하실 수 있습니다.) 그리고 가입자 소프트웨어가 과연 이러한 규격을 준수하는지를 정보보호진흥원이 심사하도록 하고 있습니다. 이것이 중요한 이유는, 마구잡이로 암호화를 하거나, 약한 수준의 암호화를 사용하여 생성된 전자서명이 나도는 경우에는 공인인증서 제도 자체가 붕괴되기 때문입니다.

4. 따라서 공인인증기관도 아닌 은행, 카드사 등이 "독자적으로" 공인인증서 지원에 필요한 인증서 클라이언트를 만드는 경우, 그런 소프트웨어를 사용하여 부착된 전자서명은 문서의 진정성립을 인정받는 근거(법 제3조 참조)로 되지 못할 수도 있습니다. 나아가, 은행, 카드사 등이 설사, 기술 규격에 맞추어 가입자 소프트웨어를 스스로 개발하였다 하더라도, 그것에 대하여 전자서명법에 규정된 심사를 정보보호진흥원에 요청할 권리조차 없습니다. 공인인증기관도 아닌 아무 사설 업체가 정통부에 그 심사를 요청할 법적 근거는 없습니다.

5. 결국, 카드사 등은 가입자 소프트웨어를 스스로 제공해서도 안되고, 제공한다 하더라도, 그런 소프트웨어(인증서 클라이언트)로 생성된 전자서명은 법이 정하는 효력을 인정받을 수 없습니다.

6. 공인인증기관에게 가입자 소프트웨어를 제공할 의무를 부과하는 반면, 서버사이드 솔루션을 제공할 의무를 부과하지는 않고 있는 이유는, 서버측에서는 전자서명 부착을 위한 암호화(encryption) 작업이 필요없기 때문입니다. 클라이언트가 암호화해서 보내온 전자서명을 복호화(decrypt)하여 나머지 필요한 작업을 수행하기만 하면됩니다. 따라서 이 부분은 업체간의 "자유 경
쟁"이 확보되어야 하는 영역입니다. 그러나, 가입자 설비(클라이언트)는 암호화 작업을 수행하므로 공인인증기관이 일괄 제공하고 형상관리까지 해야 할 의무가 있는 영역입니다.
BlogIcon Jerry 2007.02.05 18:28 신고 
말씀해 주신 부분에 대해서 몇일째 계속 고민중 입니다. 조만간에 제 의견을 포스팅하도록 하겠습니다.
BlogIcon Jerry 2007.03.07 13:34 신고 
최근에 방송이긴 하지만 우연히 교수님 방송에서 뵈었네요. ^^

글쎄요... 제 생각에는 가입자쪽에서 암호화를 수행하는데 있어서 공인, 사설 CA가 무분별하게 서비스를 제공해 온 것은 부인할 수 없는 사실이라고 봅니다. 이 부분에 대해서는 명확한 역할과 책임을 다 하고 있다고 볼 수 없으며, 관리적, 기술적 대응방안이 필요로 하다고 봅니다.

그러나, 제 기우일지는 모르겠습니다만, 공인인증기관에서 가입자 설비를 제공하는 부분은 향후 시장에 신규 업체의 진입을 현실적으로 불가능하게 만들고, 자율적인 경쟁을 방해할 수 있다는 측면에서 저는 좀 반대 입장입니다.

결국 공인인증기관이 선정하거나 만든 가입자 Client만을 이용할 수 밖에 없다는 것은 공인인증기관이 독과점 지위를 통한 현재의 MS와 같은 행태를 그대로 답습할 수도 있다는 판단이 들기 때문입니다.

공인인증기관의 법적 요건이 스스로의 법적 요건에 위배 된다면, 프로세스를 개선하고 서비스에 대한 관리감독 권한을 토대로 스스로의 역할과 책임을 다하는 것이 옳다고 보지만, 법적 요건에 위배된다고 해서 법적요건에 맞는 100%를 다하라고 요구하는 것은 법적 요건이 100% 신뢰적이라는 필요충분조건이 성립해야 한다고 봅니다. 그러나, 현재의 기형적 공인인증기관과 서비스 사업자의 법적 위배 사항은 부족하기는 하겠습니다만, 최소한의 설득력은 갖을 수도 있다고 봅니다. 공인인증기관이 가입자 소프트웨어에 대해 제공 및 관리, 감독의 책임이 있는 것이 법적 구속력을 갖는다면, 사실 이러한 것에도 폐단이 예상된다고 봅니다.

따라서 제 개인적으로는 현재의 잘못된 체계를 바꾸는 노력도 중요하겠습니다만, 현실적인 법률 개선을 같이 병행하는 노력도 의미있을 것 같습니다.
BlogIcon youknowit 2007.02.04 20:39 신고
오늘 오후, '오랫만에' 윈도/IE 를 쓸 일이 있어 Jerry 님 사이트를 IE 로 보았더니, 제대로 나오는 군요. firefox 에서는 조금 이상하게 나오는데...
BlogIcon bluesman 2007.03.07 12:05 신고 
오랜만에 포스팅 하는군요. 최근에 너무 바빠서 정신 없었네요. 현재 이 공간은 Daum과 Tattertools가 제공하는 블로그 서비스를 이용하고 있습니다. FF에서 제대로 보였었는데, 좀 이상하게 보이는 모양입니다. ^^
BlogIcon youknowit 2007.03.13 22:07 신고
인증 '클라이언트'와 서버측 인증 솔루션은 분명히 구별되어야 합니다.전자서명법 규정은 공인인증기관에게 인증 클라이언트(가입자 소프트웨어) 제공의무만을 부과할 뿐, 서버측 인증 솔루션을 제공할 의무를 부과하는 것이 결코 아닙니다.

수백, 수천개의 서버들, 온갖 다양한 서비스를 제공하는 서버들의 수요에 맞는 서버측 인증 솔루션을 공인인증기관이 제공할 이유는 전혀 없습니다. 그럴 수도 없습니다. 서버측 솔루션은 서버가 알아서 만들어야 하며, 이 과정에서 보안업체들의 사업기회가 보장됩니다.

클라이언트만을 제공할 의무를 부과하는 법규정은 인증 프로토콜과 API의 공개를 당연히 전제하는 것입니다. 그렇게 하지 않으면, 어떤 웹서버도 그 클라이언트를 사용할 수 없게 되기 때문입니다. 프로토콜과 API가 공개되면, 온갖 파생 서비스 제공자(결제 서비스 관련)가 마음껏 혁신적인 솔루션을 독자 개발하여 자유롭게 경쟁할 수 있게 되며, 이것이 바로 보안 산업에 활력을 불어넣게 됩니다.

보다 자세한 설명은 현재 준비 중인 조정합의문(초안) http://openweb.or.kr/settlement.pdf 제3조에 관한 설명(p.5), 제6조에 관한 설명(p.8)을 참조하시기 바랍니다.

한번 개발한 인증클라이언트를 끝없이 반복하여 팔아먹을 수 있는 기회를 보장해주는 것이 과연 우리 SI 산업에 도움이 될까요? 저는 그렇지 않다고 생각합니다. "공인"인증제도를 도입한 이상, 공인인증 "클라이언트"로 장사할 생각은 접어야 합니다. 공인인증 "서버솔루션", 공인인증을 부가한 "각종 파생 서비스 솔루션"에 대한 사업으로 승부하여야 하지 않을까요?
BlogIcon Jerry 2007.03.26 19:57 신고
한참동안을 생각하게 되는 내용이었습니다만, 사실 현재 시장에서 공인인증 서버솔루션을 토대로 사업을 하는 것이 과연 가능한지의 여부에 대해서는 사실 좀 회의적 입장입니다. 하지만 현재의 왜곡된 시장이 정상적인 길을 가는 하나의 과정이 아닐까 생각도 듭니다. 최근에 향후 Architecture 관점에서의 방향성에 대해서 많이 생각하게 되는데, 정말이지 쉽지는 않은 것 같습니다.

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | ··· | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | ··· | 69 | 다음>>

bluesman's Blog is powered by Daum & Tattertools

 

티스토리 툴바