보안과 관련해서 궁금한 점
youknowit
보안과 관련해서, 저같은 비전문가가 품고 있는 의문점을 한가지 적어 보았습니다. 여러분들은 어떻게 생각하시는지요?
+++++
국내 보안업체 종사자분들, 그리고 국정원 보안인증심의국 직원분들께서는 흔히, "보안프로그램은 소스가 공개되면 위험하다"고 하십니
다.
그러나, 프로그램 소스 / 프로그램 설계구조 / 그 프로그램이 작동하여 최종적으로 생성해 내는 데이터는 구분해서 생각해야 합니
다.
첫째, 프로그램 소스는 개발업체의 선택에 따라 공개할 수도 있고, 안할 수도 있습니다. 공개한다고 해서 보안에 위험이 온다면,
그 프로그램은 애초에 잘못 만든 프로그램입니다. 제대로 된 보안프로그램은 소스가 공개되어도 안전합니다. 실제로 무수히 많은 보안
프로그램의 소스는 완벽히 공개되어 있습니다. Openssl, OpenPGP, GnuPG, ccrypt 등을 이용한 무수한
applications 이 그러합니다.
둘째, 보안 프로그램의 설계구조는 반드시 공개되어야 할 뿐 아니라, 상세한 documentation 이 제공되어야 합니다. 어
떤 정보를 어떤 프로세스로 처리하여, 어떻게 하길래 안전하다고 주장하는지를 공개적으로 검증할 수 있도록 설계 구조의 골격은 공개
되어야 합니다. 이것은 특허권의 문제도 아니고, 저작권의 문제도 아닙니다. 보안 프로그램 설계구조는 "idea 자체"에 대한 것
이고, idea 는 누구도 독점적 보호를 주장할 수 없습니다(저작권/특허권은 "idea 자체"를 보호하는 제도가 아니라, 그
idea 의 구체적 표현, 그 idea 를 실제로 구현한 방법을 보호하는 제도입니다).
자기가 개발, 판매하는 보안 프로그램의 설계구조를 제대로 설명하는 문헌도 만들 능력이 없는 업체는 기본이 안된 업체입니다.
셋째. 이렇게 설계된 프로그램이 실제로 작동하여 생성해 낸 암호화된 데이터는 누구에게 제공하더라도 key 가 없는 자는 그
content를 복호화 할 수 없어야 합니다. 따라서 이 단계에서는 공개/비공개가 무의미 합니다. 보안/암호화의 존재 이유가,
데이터가 공개적으로 오고가도 그 내용은 key 없이는 접근할 수 없도록 하기 위한 것입니다.
따라서, 예를 들어, 어느 '보안접속 프로그램'이 서버와 클라이언트 간에 공유키를 어떻게 안전하게 네트웤 상에서 전달하고, 접
속 체널을 개시하는지에 대한 설계 구조 자체는 공개적으로 제공되어야 합니다. 그래야 그 프로그램이 과연 안전한지, 그 각 단계에
서 공략 가능성에 노출된 부분은 없는지 등을 객관적으로 검토할 수 있게 됩니다.
물론, 그 보안접속 프로그램의 '소스코드'를 공개할지 여부는 그 업자의 선택입니다. 하지만, 설계 구조 조차 변변히 제시하지 못
하면서, "무조건 우리 프로그램을 믿으라"는 것은 납득하기 어렵습니다. 국정원 보안인증 심의국의 모듈 심사를 받았으니, 무조건
믿으라? hmm... 이른바 '전문가'께서 OK 했으니, 무조건 믿으라는 말씀처럼 들리네요. 그렇게 안전하게 설계 되었다면,
그 '설계 구조'는 왜 공개하지 못하지요? 소스코드를 공개하라는 것도 아닌데.
미국과 유럽의 세계 정상급 보안 전문가들이 엄선한 "보안과 관련해서 저지르기 쉬운 25가지 실수 들"이라는 문건이 있습니다.
http://cwe.mitre.org/top25 그 중, 암호화 알고리즘과 관련된 항목(http: //cwe.mitre.org/
top25/#CWE-327)을 보면, 이런 내용이 있습니다:
As with all cryptographic mechanisms, the source code should be
available for analysis. 번역해 보면, "모든 암호화 매커니즘의 경우에서처럼, (알고리듬을 실제로 구현하는 모
듈의) 소스코드는 분석(을 통하여 그 위험성/안전성을 객관적으로 검증)할 수 있도록 제공되어야 한다."
적어도 보안 프로그램의 경우에는 "감출수록 위험은 커진다"고 생각합니다.
swlee
한가지 문의드릴점이 있는데요..
보안 기술에 대한 지적재산권 입니다.
구체적으로 한가지만 예를 들어보겠습니다.
안티 키로거의 기본적인 기능은 윈도우 OS에 저장된 현재 KEY 값을 재빨리 CLEAR 하는 것입니다.
실제는 F10, F11 등의 거의 사용하지 않는 키값을
사용자가 키를 눌렀을때 뒤를 이어 OS에 추가로 송신합니다.
사용자가 A 키를 눌러서 윈도우 메모리에 A가 저장되 있는데
안티 키로거가 재빨리 F10값을 윈도우로 보내서 메모리 값을 F10으로 변경해 버리는 것이죠..
기술의 핵심은 키로거가 윈도우 메모리에 저장되어 있는 값을 얻어가기 이전에
메모리에 있는 값을 의미없는 더미값으로 바꿔버리는 것입니다.
그리고 특허의 핵심은 안티키로거가 동작하는 시점입니다.
(키로거 보다 먼저 동작을 해야 하니까요..)
전기신호가 윈도우 메모리에 저장되는 일련의 과정에서
특정 시점에서 동작을 했더니 키로거 무력화에 성공했다는 것입니다.
그래서 안티 해킹에 성공할 수 있다는 것입니다.
제가 구체적인 예를 들어 보았는데요,,
다른 예들도 별반 다르지는 않습니다.
이러한 경우도 근본적으로는
지적 재산권으로서, IDEA 로서 보호받을수는 없습니까?
> 미국과 유럽의 세계 정상급 보안 전문가들이 엄선한 "보안과 관련해서 저지르기 쉬운 25가지 실수 들"이라는 문건이 있습니다.http://cwe.mitre.org/top25그 중, 암호화 알고리즘과 관련된 항목(http: //cwe.mitre.org/
youknowit
일단, 소프트웨어에 대하여 "특허권"을 부여하여 보호하는 것이 적절한지에 대하여는 유럽 국가들과 북미권 국가들 간에 입장 차이
가 상당합니다. 우리 나라는 미국 영향이 커서 인지, 소프트웨어에 대한 특허권 보호가 유럽 국가들 보다는 비교적 수월하게 제공되
는 듯합니다.
그러나, 특허제도의 본질은 어떤 결과를 달성하는데 사용되는 프로세스를 발명한 자가 그것을 "공개"하고, 그렇게 하는데 대한 일종
의 보상으로서, 그 프로세스에 대한 독점적 권리를 일정 기간 누리도록 하는 것입니다. 물론 실제로는 완벽한 "공개"를 하지는 않
지요(따라서 특허권자에게 개별적으로 접촉하여 knowhow 를 추가적으로 구입해야 실제로 구현할 수 있도록 해두는 경우가 많습니
다).
하지만, 특허권의 보호대상이 되려면 제가 위에서 말한 "설계 구조의 얼개" 보다는 훨씬 더 자세한 프로세스를 모두 공개해야 합니
다. 따라서 그 프로그램이 안전한지를 객관적으로 검증하는데에는 지장이 없을 수준의 공개는 확보되는 셈입니다.
특허제도는 비밀을 보호하기 위한 제도가 아닙니다. 특허권을 누리려면, 프로세스를 공개해야 하고, 공개하기 싫으면 특허권을 주장
할 수는 없습니다. 단순히 영업비밀(trade secret)로서 보호될 뿐입니다.
"설계 구조의 얼개"가 모두 영업비밀에 해당하는 것은 아닙니다. 물론, 영업비밀이므로 공개하지 않겠다는 입장은 누구든지 내세울
수는 있지만, 보안업체가 그 프로그램의 "안전성 여부를 객관적으로 검증하는데 필요한 정보' 마저도 공개하지 않을 경우, 그런 프
로그램을 구입할지 여부는 구매자가 판단하는 것입니다.
업체의 말만 "무조건 믿고" 그런 솔루션을 사는 "바보같은 구매자"도 물론 있겠지만, 제대로 된 구매자라면, 그런 결정을 할 가
능성은 없지요. 국제 수준의 회사 중에는 안전성 여부에 대한 검증에 필요한 수준의 documentation 을 제공하면서도,
영업비밀은 비밀로 유지하는 선진적인 곳도 많을 터이니...
> > 미국과 유럽의 세계 정상급 보안 전문가들이 엄선한 "보안과 관련해서 저지르기 쉬운 25가지 실수 들"이라는 문건이 있습니다.http://cwe.mitre.org/top25그중, 암호화 알고리즘과 관련된 항목(http: //cwe.mitre.org/
swlee
저도 개인적으로 연구한 보안 기술을 특허내 보려고 하고 있었거든요,,,
도움이 될 것 같습니다.
안전성을 검증해 보는 것은 좋은 것 같습니다.
그런데 설계 / 구조 하면 좀 막연합니다.
무엇을 원하는지 정확히 모를수도 있다고 생각합니다.
안전성을 검증해 보기 위해서는 구체적으로 이러이러한 항목이 있는데..
이러한 항목은 어떻게 되어 있는가라는 식으 구체적인 요청이면
업체도 고민을 해 볼 수는 있다고 생각합니다.
예를들어 암호화에 사용하는 알고리즘은 국제적으로 공인된 암호화 방식을 사용하는가?
고객에서 설치되는 ActiveX 는 모든 윈도우 버전에서 테스트를 해 보았는가?
등등입니다.
> > > 적어도 보안 프로그램의 경우에는 "감출수록 위험은 커진다"고 생각합니다.- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -
youknowit
업이익이 침해되지 않을지를 가장 정확하게 판단할 수 있는 자는 바로 그 프로그램을 개발한 주체입니다.
그 주체가 안전성 검증에 필요한 충분한 정보를 제공하지 않는다면, 1) 안전성 검증을 위해서는 어떤 부분을 주목해야 하는지를 자
신도 모르거나, 2) 자기 프로그램이 허술하여 그 내막을 차마 공개 못하거나, 3) 그저 아무 생각이 없거나 중 하나일 가능성
이 크지 않을까요?
swlee
말씀을 듣고 보니 가능성 만으로
업체가 잘못되었다고 말씀하시는 것 같습니다.
공개해야할 법적 의무도 없는데요..
지난 수년동안 수십만명이 써온 모듈이며 문제가 있다고 보고된건은 없습니다.
이것이야 말로 안정성에 대해서 더 무엇을 논하겠습니까?
문제가 있으면 문제제기를 하는것을 옳지만
추측이나 의심만으로는 문제제기로 끝날 뿐
근본적으로 해결을 얻을 수는 없다고 생각합니다.
보안 업체가 문제가 있다고 말씀을 하기 이전에
확실한 근거가 있어야 된다고 생각하며
그것이 아니라면 비난까지 할 이유는 없다고 생각합니다.
> ...
>
> 추가 정보 »- 따온 텍스트 숨기기 -
Hyun
법에서 어떻게 되어있더라도 그 구조가 명확하지 않게 감춰져있으면 저는 상당히 기분나쁩니다. 이부분은 다른 여러사람들도 같을거라고 생각합니다.
swlee 쓴 글:
youknowit
제하는 곳은 없습니다. 법률 이슈가 아니라 보안 이슈입니다.
국내에서 지난 10여년간 사용되어 온 보안 소프트웨어는 안전한지 위험한지를 공개적으로 검증할 수 없도록 되어 있을 뿐입니다. 안
전한지, 위험한지는 모른다는 것이지요.
상세한 documentation 이 제공되면, 정상급 기술인력이 모두 공개적으로 검토, 논의 할 수 있습니다. 그러나, 아무
spec도 documentation 도 없는 어떤 소프트웨어에 대하여, 그 안전성을 공개적으로 논의하려면, 리버스 엔지니어링을
해봐야 됩니다.
정상급 인력이 무슨 할 일이 없어서, 남이 만든 소프트웨어를 리버스 엔지니어링하고, 그 결과를 공개적으로 논의하겠습니까? 그랬
다가 괜히 공격만 당할 것 아니겠습니까? 반면에 악의적 공격자는 "조용히" 리버스 엔지니어링하고, 그 결과를 표안나게 최대한 오
래, 오래 exploit 하려고 시도할 것입니다.
국내에서 사용되어 온 보안소프트웨어가 "위험하다"는 것이 아니라, "안전한지, 위험한지 알 수 없다"는 말씀을 드리는 것 뿐입니
다.
> ...
>
> read more >>
Won-Kyu Park
> 어떤 동작을 하는지 구체적으로 알지도 못하면서 내 컴퓨터에서 실행시켜야 한다는 건 사용자입장에서는 상당히 기분나쁩니다. 보안프로그램이라고 하면서 그냥 “안전하다. 그동안 잘 동작하던거다.” 라고 설득하며 그냥 써라고 하는 건 더더욱 어처구니가 없죠.
> 법에서 어떻게 되어있더라도 그 구조가 명확하지 않게 감춰져있으면 저는 상당히 기분나쁩니다. 이부분은 다른 여러사람들도 같을거라고 생각합니다.
>
기분나쁜건 사실이겠지만 보안업체쪽은 어떻게 생각할까요?
자칫 그 말은 무턱대고 좋아하지 않는다는 말로 오해될 수 있을것 같네요.
보안 소프트웨어 회사가 가보시면 자신들의 기술에 대해서 꽤 장황하게 서술해놓은 것을 볼 수 있습니다.
기술적인 자세한 것 까지는 아니더라도 사용자의 신뢰를 하기 위한 노력을 하지 않을 리 없죠.
게다가 특히 기술자들은 보통 정치하는사람보다 정직합니다. .자신의 기술에 대해 자부심도 많이 가지고 있구요.
최근에 블로그에서 들끓었던 오픈웹 사건은 이런 개발자들의 심기를 건드렸던 점이 분명이 있습니다.
분명한 잘못을 지적하기 보다는 관계자들을 모두 비난하는 식으로 느꼈던 것이죠.
기분나쁘다거나 감정적인 발언 대신에, 해야 할 것에 대해 좀 더 분명하게 밝혀주고,
잘못된 점을 정확하게 지적하는 것이 이 토론에서 이어졌으면 좋겠습니다.
그래야만 불분명한 오해를 줄이고 우리의 요구사항을 정확하게 이해할 것입니다.
그저 그런.. 불분명한 불만은 양쪽에 모두 이롭지 못합니다.
--
온갖 참된 삶은 만남이다 -- 마르틴 부버
swlee
상용화된 보안 솔루션이 상세 spec을 공개하고 공개적으로 리버스엔지니어링을 했다는 예기는
한번도 들어본 적이 없습니다.
혹시 그러한 예가 있습니까?
안전성을 검증하기 위해 어떠한 spec 을 공개했으며
어떤 방식의 검증이 이루었는지 구체적인 사례가 있으면
오픈웹이 정확히 무엇에 대해 불안해 하고
무엇을 요구하는지 참고가 될 것 같습니다.
On 4월9일, 오후11시05분, Won-Kyu Park <wkp...@gmail.com> wrote:
> 2009년 4월 9일 (목) 오후 7:46, Hyun <hyunwoo.p...@gmail.com>님의 말:
youknowit
로 대접 받는 수준입니다(PKCS; Public Key Cryptographic Standard).
> ...
>
> 추가 정보 >>
youknowit
Information Processing Standard (FIPS) 프로그램이 있습니다.
우리 나라 국정원이 수행하는 보안성심의는 아마도 이것을 모방한 것으로 짐작하는데, 그 문서화의 정도는 아마 비교하기 어려울 정도
일 것입니다.
물론, FIPS 는 소스비공개 상용 프로그램과 오픈소스 프로그램 모두에 대하여 각 프로그램의 보안적합성 등급을 심사, 공표합니다
(FIPS Level1 에서 level 4까지)
자세한 내용은 http://en.wikipedia.org/wiki/FIPS_140-2 참조바랍니다.
우리나라 국정원은 "보안프로그램은 소스가 공개되면 위험하다"는 황당무개한 듣보잡 견해를 몇년째 견지하면서, 공개소스 보안 프로그
램은 아예 심의대상도 못되게 하고 있지요 아마...(확인해 주시기 바랍니다)
물론 FIPS 심의를 받은 프로그램은 우리 국정원 심의를 새로 받을 필요가 없도록 최근에야 비로소 시정된 것으로 알고 있습니
다.
youknowit
게 되었습니다.
제가 오픈웹에 3.1 게시한 포스팅("Frame: 웹페이지 주소감추기")에서, 마우스 오른쪽 버튼을 못쓰게 막아둔 처사를 공개적
으로 비난하는 글을 게시한 이래로, 이제는 그 조치를 중단한 듯 합니다. 신속히 조치를 취해 주셔서 감사드립니다.
물론, 어느 기관이건 간에 웹페이지에 대해서는 그 기관의 전문인력분들께서는 사실 별로 관심을 두지 않으십니다. 웹페이지는 보통
납품업체(웹 에이전시)가 대충 만들어 둔 것을 그냥 걸어두는 경우가 많지요. 따라서 보안인증사무국 웹페이지가 보여주는 좀 이상
한 행태를 근거로 그곳에 근무하시는 분들을 "도매금"으로 매도하는 것은 옳지 않음은 물론입니다.
그러나, 한국씨티은행은 여전히 "뻘짓"으로 일관하고 있지요: i) 홈페이지에 게시된 공지사항 "링크"만 클릭해도 당장에 키보드
보안프로그램 설치를 강요합니다. 그래서 그 프로그램을 설치하지 않으면, 공지사항을 읽지도 못하게 해둡니다; ii) 마우스 오른
쪽 버튼을 못쓰게 막아 두었습니다; ii) 고객 문의 글을 쓰는 게시판 페이지가 있습니다. 그 게시판은 5분 가량이 지나면 자동
으로 로그아웃되도록 되어 있습니다. 그래서, 문의 내용이 많으면, 별도로 note pad 같은 곳에 미리 적은 다음 "붙여넣
기"하라는 식으로 안내 하고 있습니다. (5분 안에 신속히 타자를 다 칠 수 없기 때문에) 그런데. 붙여넣기가 불가능하게 마우
스 오른쪽 버튼을 못쓰게 해 두고 있지요...ㅎㅎㅎ iii) OTP 를 사용하는 고객들도 의무적으로 키보드 보안프로그램 설치를
강요하고 있습니다. 한마디로 뭐하자는 분들인지 알지 못하겠습니다.
물론, 이런 내용을 조목조목 지적하고 까놓고 이야기 하면, 보안업계 종사자분들의 심기가 편하지는 않겠지만, 그렇다고 무작정 "잘
한다, 잘한다"고 하기는 어렵다고 생각합니다.
> ...
>
> 추가 정보 >>
Won-Kyu Park
2009년 4월 10일 (금) 오전 1:44, youknowit <keecha...@googlemail.com>님의 말:
> 댓글을 적는 과정에서 국정원 보안인증 사무국 홈페이지(http://www.kecs.go.kr/main.jsp) 를 다시 방문하
> 게 되었습니다.
>
> 제가 오픈웹에 3.1 게시한 포스팅("Frame: 웹페이지 주소감추기")에서, 마우스 오른쪽 버튼을 못쓰게 막아둔 처사를 공개적
> 으로 비난하는 글을 게시한 이래로, 이제는 그 조치를 중단한 듯 합니다. 신속히 조치를 취해 주셔서 감사드립니다.
>
> 물론, 어느 기관이건 간에 웹페이지에 대해서는 그 기관의 전문인력분들께서는 사실 별로 관심을 두지 않으십니다. 웹페이지는 보통
> 납품업체(웹 에이전시)가 대충 만들어 둔 것을 그냥 걸어두는 경우가 많지요. 따라서 보안인증사무국 웹페이지가 보여주는 좀 이상
> 한 행태를 근거로 그곳에 근무하시는 분들을 "도매금"으로 매도하는 것은 옳지 않음은 물론입니다.
>
마우스 막는 류의 "뻘짓"을 행하는 곳은 포탈도 그렇고 상당히 많지요ㅋㅋ
이런 웹의 *접근성*을 떨어뜨리는 행위는 왜 하는지 알다가도 모를 일입니다.
아예 자세한 이유를 상세하게 문서화 해야 할까요? 아예 마우스 막은 것을 해제하는 방법을 상세하게 문서화 해야할까봅니다.
할일 #1 마우스 막기의 문제점과 웹의 접근성, 마우스 막는 문제 해제시키는 법 문서화.
> 그러나, 한국씨티은행은 여전히 "뻘짓"으로 일관하고 있지요: i) 홈페이지에 게시된 공지사항 "링크"만 클릭해도 당장에 키보드
> 보안프로그램 설치를 강요합니다. 그래서 그 프로그램을 설치하지 않으면, 공지사항을 읽지도 못하게 해둡니다; ii) 마우스 오른
> 쪽 버튼을 못쓰게 막아 두었습니다; ii) 고객 문의 글을 쓰는 게시판 페이지가 있습니다. 그 게시판은 5분 가량이 지나면 자동
> 으로 로그아웃되도록 되어 있습니다. 그래서, 문의 내용이 많으면, 별도로 note pad 같은 곳에 미리 적은 다음 "붙여넣
> 기"하라는 식으로 안내 하고 있습니다. (5분 안에 신속히 타자를 다 칠 수 없기 때문에) 그런데. 붙여넣기가 불가능하게 마우
> 스 오른쪽 버튼을 못쓰게 해 두고 있지요...ㅎㅎㅎ iii)
다른 여러 은행사이트에서도.. 1) 그냥 둘러보기만 하려고 해도 ActiveX를 깔아야 한다거나, Netscape 6.0은
안됩니다라는 경고문구를
보여주면서 전혀 문제 없이 둘러보기는 할 수 있는 경우. 2) ActiveX 설치하는 페이지로 아예 옮긴 후에 아무런 동작도 할 수 없는 경우.
이런 경우가 너무도 많습니다. 은행이 아니더라도 ActiveX 요구하는 곳은 여전히 많구요.
보안과 전혀 상관 없는 사이트까지 ActiveX를 요구하며 웹의 접근성을 떨어뜨리는 행위 역시 비난받아야 마땅하고,
이러한 접근성을 헤치고 있는 사이트 목록을 아예 만드는 작업을 병행해야 하지 않을까 싶습니다.
할일 #2 - 보안과 관련이 없는 사이트에서 ActiveX로 접근성을 방해하는 모든 사이트 정리.
> OTP 를 사용하는 고객들도 의무적으로 키보드 보안프로그램 설치를
> 강요하고 있습니다. 한마디로 뭐하자는 분들인지 알지 못하겠습니다.
>
> 물론, 이런 내용을 조목조목 지적하고 까놓고 이야기 하면, 보안업계 종사자분들의 심기가 편하지는 않겠지만, 그렇다고 무작정 "잘
> 한다, 잘한다"고 하기는 어렵다고 생각합니다.
>
조목조목 따지고 그 말이 맞는다면 전혀 문제될 것이 없을 것입니다 :)
--
Hyeonseok Shin
http://www.kecs.go.kr/ 로 들어가면 아직 프레임이 있고 우클릭도 안되네요. 일시적인 현상이었거나 접속 URL때문에 프레임이 안나온 것 같습니다. :(
제가 마우스 우클릭을 막은 사이트에서 이를 해제할수 있게 하는 자바스크립트 북마클릿을 만들어서(한줄로 해결 되겠군요;;;) 한번 뿌려보겠습니다.
--
Hyeonseok.com
Hyun
Hyeonseok Shin 쓴 글:
> http://www.kecs.go.kr/ 로 들어가면 아직 프레임이 있고 우클릭도 안되네요.
> 일시적인 현상이었거나 접속 URL때문에 프레임이 안나온 것 같습니다. :(
>
> 제가 마우스 우클릭을 막은 사이트에서 이를 해제할수 있게 하는 자바스크립
> 트 북마클릿을 만들어서(한줄로 해결 되겠군요;;;) 한번 뿌려보겠습니다.
흠... 이거 기다려지네요.
>
> 2009/4/10 Won-Kyu Park <wkp...@gmail.com <mailto:wkp...@gmail.com>>
>
> 슬슬 일거리들이 보이기 시작합니다 :)
>
> 2009년 4월 10일 (금) 오전 1:44, youknowit
> <keecha...@googlemail.com <mailto:keecha...@googlemail.com>>님
> <mailto:keechang....@googlemail.com>> wrote:
> >> 그리고, 무수히 많은 보안 애플리케이션들에 대하여는 미국의 NIST와
> 카나다의 CSE 가 공동으로 수행하는 Federal
> >> Information Processing Standard (FIPS) 프로그램이 있습니다.
> >>
> >> 우리 나라 국정원이 수행하는 보안성심의는 아마도 이것을 모방한 것
> 으로 짐작하는데, 그 문서화의 정도는 아마 비교하기 어려울 정도
> >> 일 것입니다.
> >>
> >> 물론, FIPS 는 소스비공개 상용 프로그램과 오픈소스 프로그램 모두
> 에 대하여 각 프로그램의 보안적합성 등급을 심사, 공표합니다
> >> (FIPS Level1 에서 level 4까지)
> >>
> >> 자세한 내용은http://en.wikipedia.org/wiki/FIPS_140-2참조바랍니다.
> >>
> >> 우리나라 국정원은 "보안프로그램은 소스가 공개되면 위험하다"는 황
> 당무개한 듣보잡 견해를 몇년째 견지하면서, 공개소스 보안 프로그
> >> 램은 아예 심의대상도 못되게 하고 있지요 아마...(확인해 주시기 바
> 랍니다)
> >>
> >> 물론 FIPS 심의를 받은 프로그램은 우리 국정원 심의를 새로 받을 필
> 요가 없도록 최근에야 비로소 시정된 것으로 알고 있습니
> >> 다.
> >>
> >> On 4월10일, 오전12시56분, youknowit <keechang....@googlemail.com
> <mailto:keechang....@googlemail.com>> wrote:
> >>
> >> > RSA Security 가 아마 대표적인 경우 아닐까요? 이 회사 제품의
> 상세한 기술 스펙은 아예 암호화 제품의 국제적 표준으
> >> > 로 대접 받는 수준입니다(PKCS; Public Key Cryptographic Standard).
> >>
> >> > On 4월9일, 오후11시56분, swlee <Bang...@gmail.com
> <mailto:Bang...@gmail.com>> wrote:
> >>
> >> > > 암호화 알고리즘이 공개가 되고 이에대한 취약점 연구를 하는것
> 은 예기를 들었는데..
> >> > > 상용화된 보안 솔루션이 상세 spec을 공개하고 공개적으로 리버
> 스엔지니어링을 했다는 예기는
> >> > > 한번도 들어본 적이 없습니다.
> >>
> >> > > 혹시 그러한 예가 있습니까?
> >> > > 안전성을 검증하기 위해 어떠한 spec 을 공개했으며
> >> > > 어떤 방식의 검증이 이루었는지 구체적인 사례가 있으면
> >> > > 오픈웹이 정확히 무엇에 대해 불안해 하고
> >> > > 무엇을 요구하는지 참고가 될 것 같습니다.
> >>
> >> > > On 4월9일, 오후11시05분, Won-Kyu Park <wkp...@gmail.com
> <mailto:wkp...@gmail.com>> wrote:
> >>
> >> > > > 2009년 4월 9일 (목) 오후 7:46, Hyun
> <hyunwoo.p...@gmail.com <mailto:hyunwoo.p...@gmail.com>>님의 말:
> <keechang....@googlemail.com <mailto:keechang....@googlemail.com>>
> wrote:
> >> > > > >>> 어디까지를 공개하면, 제3자가 자기 프로그램의 안전성 여
> 부를 객관적으로 검증할 수 있고, 어디부터는 비밀로 유지해야, 자신의 영
> >> > > > >>> 업이익이 침해되지 않을지를 가장 정확하게 판단할 수 있
> 는 자는 바로 그 프로그램을 개발한 주체입니다.
> >>
> >> > > > >>> 그 주체가 안전성 검증에 필요한 충분한 정보를 제공하지
> 않는다면, 1) 안전성 검증을 위해서는 어떤 부분을 주목해야 하는지를 자
> >> > > > >>> 신도 모르거나, 2) 자기 프로그램이 허술하여 그 내막을
> 차마 공개 못하거나, 3) 그저 아무 생각이 없거나 중 하나일 가능성
> >> > > > >>> 이 크지 않을까요?
> >>
> >> > > > >>> On 4월8일, 오후5시42분, swlee <Bang...@gmail.com
> <mailto:Bang...@gmail.com>> wrote:
> >>
> >> > > > >>>> 감사합니다.
> >> > > > >>>> 저도 개인적으로 연구한 보안 기술을 특허내 보려고 하고
> 있었거든요,,,
> >> > > > >>>> 도움이 될 것 같습니다.
> >> > > > >>>> 안전성을 검증해 보는 것은 좋은 것 같습니다.
> >> > > > >>>> 그런데 설계 / 구조 하면 좀 막연합니다.
> >> > > > >>>> 무엇을 원하는지 정확히 모를수도 있다고 생각합니다.
> >> > > > >>>> 안전성을 검증해 보기 위해서는 구체적으로 이러이러한
> 항목이 있는데..
> >> > > > >>>> 이러한 항목은 어떻게 되어 있는가라는 식으 구체적인 요
> 청이면
> >> > > > >>>> 업체도 고민을 해 볼 수는 있다고 생각합니다.
> >> > > > >>>> 예를들어 암호화에 사용하는 알고리즘은 국제적으로 공인
> 된 암호화 방식을 사용하는가?
> >> > > > >>>> 고객에서 설치되는 ActiveX 는 모든 윈도우 버전에서 테
> 스트를 해 보았는가?
> >> > > > >>>> 등등입니다.
> >> > > > >>>> On 4월8일, 오후5시34분, youknowit
> <keechang....@googlemail.com <mailto:keechang....@googlemail.com>>
써머즈
Won-Kyu Park
> 이런 류는 이미 많지 않나요?
> http://delpini.egloos.com/1890983
>
> 크롬에서 해보니 http://www.kecs.go.kr/ 가서 해보니 바로 풀리네요.
>
우클릭 같은 것은 저런식으로 매우 쉽게 무력화된다는 것을 더 널리 알려야 하겠지요.
아예 저것보다도 더 자세한 문서를 만들어서 자극적인 멘트로
*30초안에 무력화 시키는 우클릭* 이런 식으로 오픈웹에 공식적으로 올리고,
모모 사이트 운영진이나 그 게시판에 적극 설득하는데 써먹어야 하겠구요.
>
> 2009년 4월 10일 (금) 오전 10:39, Hyun <hyunwo...@gmail.com>님의 말:
>>
>>
>> Hyeonseok Shin 쓴 글:
>> > http://www.kecs.go.kr/ 로 들어가면 아직 프레임이 있고 우클릭도 안되네요.
>> > 일시적인 현상이었거나 접속 URL때문에 프레임이 안나온 것 같습니다. :(
>> >
>> > 제가 마우스 우클릭을 막은 사이트에서 이를 해제할수 있게 하는 자바스크립
>> > 트 북마클릿을 만들어서(한줄로 해결 되겠군요;;;) 한번 뿌려보겠습니다.
>> 흠... 이거 기다려지네요.
>>
스크립트를 브라우져 별로 작동 확인한 후에 문서화를 해야겠네요.
KLDP 위키도 좋겠고, 오픈웹도 위키가 있다면.. 아니 구글 그룹스도 위키기능이 있는데
이 기능을 활용하는 방법도 있겠네요.
써머즈
lecore
웹접근성, 웹표준 전문가와 용역업체가 모여 모처(?)에서 작은 회의를 진행했습니다.
회의는 1.이런방식을 사용하게 된 원인, 2.장단점, 3.대응방안.. 순서로 진행됐고, 아주 흥미진진한 회의
였습니다.
우선, 원인은 공식적으로 아무도 모른다..가 정답이였는데요. 2005년경 공공기관의 보안을 관리하는 모
기관(?)에서 비공식적으로 프레임셋을 권고하여 이를 근거로 프레임셋을 적용했고, 그 이후 추가 권고가
없었기 때문에 기관에서 자율적으로 유지 혹은 삭제를 결정했다..로 정리됐습니다. 모, 장단점이야 많은
분들이 아시는데로, 실익이 없다, 혹은 아무짝에도 쓸모없다..로 정리됐구요.. 따라서 제가 진행하는 프
로젝트에서도 기술검토(SSO, 기타솔루션)를 거쳐 걷어내는 것으로 진행하게 됐습니다.
회의 자체는 흥미진진 했으나, 개인적으로는 많이 부끄러웠습니다. 현재 공공기관 웹사이트의 많은 문제
점에 대해 사업담당자나 공무원은 직간접적으로 욕을 먹고 있습니다만, 동일한 수준의 비판대상이여야
할 저와 같은 용역업체들은 왠지 비판을 하는 쪽에 주력하고 있단 느낌 때문입니다.
원래 사업담당자들은 기술적으로 부족합니다. 그걸 보완해주는 역할이 용역업체의 업무중 하나라고 봤
을때, 고객이 시키니까 했다..라는 변명은 통하지 않습니다. 반대로, 용역업체가 고객의 무지를 이용하
는 일은 비일비재하니까요..
따라서, 몇몇분께서 말씀하시는 마우스 오른쪽 버튼금지 기능의 해제와 같은 지엽적인 문제에 대한 확
산은 대단히 중요하다고 생각합니다. 웹표준, 웹접근성을 준수하자...도 중요하지만, 이런이런 케이스는
이렇게 처리해야 웹표준, 웹접근성을 준수하는거다..라는 자세한 가이드말이죠..
그런면에서 봤을 때, 토론하고, 싸우고, 가끔은 비도 오는 오픈웹이라는 사이트도 그런 가이드를 제공하
는 사이트중에 하나라는 측면에서 김교수님이 상상하는 것 이상으로 많은 분들에게 혜택을 주고 있습니
다.
On 4월10일, 오전11시36분, 써머즈 <summ...@gmail.com> wrote:
> 파이어폭스 같은 경우는 오래 전부터 아예 블라우저 차원에서 지원하기도 합니다.http://firefoxinside.tistory.com/entry/우클릭-사용을-막아-놓았다면-우클릭-금지-해제하기<http://firefoxinside.tistory.com/entry/%EC%9A%B0%ED%81%B4%EB%A6%AD-%E...>
>
> 2009년 4월 10일 (금) 오전 11:31, Won-Kyu Park <wkp...@gmail.com>님의 말:
>
> > 2009년 4월 10일 (금) 오전 11:15, 써머즈 <summ...@gmail.com>님의 말:
> > > 이런 류는 이미 많지 않나요?
> > >http://delpini.egloos.com/1890983
>
> > > 크롬에서 해보니http://www.kecs.go.kr/가서 해보니 바로 풀리네요.
>
> > 우클릭 같은 것은 저런식으로 매우 쉽게 무력화된다는 것을 더 널리 알려야 하겠지요.
> > 아예 저것보다도 더 자세한 문서를 만들어서 자극적인 멘트로
> > *30초안에 무력화 시키는 우클릭* 이런 식으로 오픈웹에 공식적으로 올리고,
> > 모모 사이트 운영진이나 그 게시판에 적극 설득하는데 써먹어야 하겠구요.
>
> > > 2009년 4월 10일 (금) 오전 10:39, Hyun <hyunwoo.p...@gmail.com>님의 말:
>
> > >> Hyeonseok Shin 쓴 글:
> > >> >http://www.kecs.go.kr/로 들어가면 아직 프레임이 있고 우클릭도 안되네요.
> > >> > 일시적인 현상이었거나 접속 URL때문에 프레임이 안나온 것 같습니다. :(
>
> > >> > 제가 마우스 우클릭을 막은 사이트에서 이를 해제할수 있게 하는 자바스크립
> > >> > 트 북마클릿을 만들어서(한줄로 해결 되겠군요;;;) 한번 뿌려보겠습니다.
> > >> 흠... 이거 기다려지네요.
>
> > 스크립트를 브라우져 별로 작동 확인한 후에 문서화를 해야겠네요.
> > KLDP 위키도 좋겠고, 오픈웹도 위키가 있다면.. 아니 구글 그룹스도 위키기능이 있는데
> > 이 기능을 활용하는 방법도 있겠네요.
>
> > >> > 2009/4/10 Won-Kyu Park <wkp...@gmail.com <mailto:wkp...@gmail.com>>
>
> > >> > 슬슬 일거리들이 보이기 시작합니다 :)
>
> > >> > 2009년 4월 10일 (금) 오전 1:44, youknowit
> > >> > <keechang....@googlemail.com <mailto:keechang....@googlemail.com
> ...
>
> 추가 정보 >>