2010년 3월 12일 금요일

KISA 무선단말기에서의 공인인증서 저장 및 이용 기술규격

KISA 무선단말기에서의 공인인증서 저장 및 이용 기술규격 


관련해서

좀더 자세히 살펴보니 몇가지 문제점(?)이 보인다.

문서 위치는 다음 링크 참조 : http://bit.ly/cBvjC6

[공인인증서 관리 소프트웨어]

문서의 첫장에 나오는 개요에서 다음과 같이 기술하고 있다.
"본 규격은 무선단말기에서의 공인인증서비스 상호연동성 확보 및 이용 편의성을 고려하여 무선단말기내 공인인증서 관리 소프트웨어의 요구사항을 정의한다."

즉 "공인인증서 관리 소프트웨어"에 대한 기술규격이고
PureWeb에서는 유효하지 않은 규격이다.

[아이폰의 경우 동작구조]

다른 무선단말기는 자세히 살펴보지 않았고
아이폰에 대한 기술 부록4를 자세히 살펴보았다.

아이폰 공인인증서 App은 다음 두가지 기능을 가지고 있다.
"공인인증서 저장기능"
"공인인증서 획득기능"

공인인증서 저장기능은 다른 App에 존재하는 공인인증서를 아이폰의 공인인증서 App으로 보내서 저장하는 방식에 대한 것이고
공인인증서 획득기능은 다른 App에서 공인인증서가 필요할 경우 "공인인증서 App"을 호출하여 인증서를 획득하는 방식에 대한 것이다.

기업은행 App을 가정하여 동작방식을 순서대로 열거해보면

(공인인증서 저장기능 이용시)

1) 유저가 기업은행 App을 호출(ibkapp이라고 가정)
2) 유저가 공인인증서 저장을 위해서 "공인인증서 내보내기" 메뉴를 App에서 호출
3) 공인인증서 App을 호출하기 위해서는 
kisa-cert-exchange://?cmd=certpush&caller_url_scheme=ibkapp&callback=01&cert=base64(pfx) 
의 링크가 사용된다.
4) 이후 공인인증서 App이 실행되고 인증서를 불러들여 저장해두고 처리가 끝나면
ibkapp://?cmd=certpush&callback=01&result=00
으로 결과를 return한다.

(공인인증서 획득기능 이용시)

1) 유저가 기업은행 App을 호출(ibkapp이라고 가정)
2) 해당 App에는 공인인증서가 없어서 공인인증서를 가져와야한다.
3) 공인인증서 가져오기 메뉴를 호출하면
kisa-cert-exchange://?cmd=certget&caller_url_scheme=ibkapp&callback=01
의 링크로 공인인증서 App을 호출한다.
4) 공인인증서 App은 어딘가(?)로 공인인증서를 내보내고
ibkapp://?cmd=certget&callback=01&result=00&cert=base64(pfx)
으로 결과를 return한다.

[반쪽짜리 공인인증서 App]

공인인증서 사용을 위해서는
공인인증서 신규발급, 재발급, 갱신등의 행위가 꼭 필요한데
이런 행위는 여전히 Windows IE ActiveX에서만 가능하며
기술규격은 공인인증서의 사용에 대해서만 정의하고 있다.
즉 아이폰에서 사용하더라도 여전히 ActiveX는 필요하다는 의미.

향후 공인인증서 App에서 인증서 신규발급, 재발급, 갱신등이 지원된다는 의미는 달라질 수 있음.

그러나 지금 현재는 여전히 반쪽짜리임.

[피싱(Phishing)에 취약한 공인인증서 App]

공인인증서 App을 호출하기 위해서 Custom URL Scheme을 이용한다.
현재 "kisa-cert-excange"라고 명시해두었는데

이 구조를 국가 인프라에 도입해서 이용하는것은 상당히 아주 위험하다.

아래 몇가지 예를 들어보았는데 위험성에 대해서 판단해보시길

1. 일반 웹사이트를 통한 피싱(Phishing)

해커가 http://trust.me 라는 해킹사이트를 운영한다고 가정
해당 사이트에는 다음 링크를 포함하고 있음.
<a href=kisa-cert-exchange://?cmd=certget?caller_url_scheme=http://trust.me&callback=01>Login</a>

아이폰으로 접속한 유저가 "Login"버튼을 누르면 공인인증서 App이 실행되고 인증서 내보내기 절차를 진행.
내보낸 인증서는 어딘가(?)에 가 있을것이고
해커는 인증서를 그 어딘가(?)에서 가져온다.

2. 해킹 App을 통한 피싱

또다른 경우는 
해커가 공인인증서 App과 동일한 Custom URL Scheme을 가지는 피싱 App을 올려두고 기술규격 Spec에 맞게 반응하도록 구성하였다면
유저가 은행 뱅킹 App을 실행하고 인증서 내보내기를 실행하는 순간
KISA 공인인증서 App이 실행되는것이 아니고 해커가 준비한 App이 실행되어 공인인증서를 해커 서버로 탈취해갈 수 있다.
App등록이 통제되는 상황에서는 아주 희박한 경우이겠지만 Jailbroken iphone에서는 가능성이 없지 않다.
Custom URL Scheme이 중복되면 iPhone에서는 가장 나중에 설치된 App이 호출된다.

3. 의도하지 않은 선량한 앱에 의한 피싱

만일 선량한 다른 개발자가 의도하지는 않았지만
my.specialapp.kisa-cert-exchange 라고 URL Identifier를 기록했다면
이 App도 역시 kisa-cert-exchange://... 에 반응하여 호출된다.
유저는 공인인증서 App이 호출되기를 기대하였지만 엉뚱한 App이 호출될 가능성이 존재하는것이다.

[Gateway Server에 대한 규격 부재]

기술규격에는 명시되어 있지만
App to App으로 데이터를 전송하기 위해서는 Gateway Server가 필요하다.
이미 기업은행이나 하나은행 App에서 그러한 구조를 취하고 있다.

공인인증서 App에서 내보내기한 공인인증서(Private Key를 포함)가 어딘가로 전달되는데
이곳이 어디인지, 어떻게 관리되어야하는지등이 명확하게 표현되어 있지 않다.
결국 나의 공인인증 개인키가 아이폰 어플에서 공인인증서가 필요로 할때마다 외부로 나갔다 들어오는 과정을 반복하는데
의도적으로 숨기는것인지
아니면 아직 규격을 정한만한 사항이 아니라는건지 궁금하다.
아주 핵심적인 규격 하나가 빠져있어서
현재의 기술규격 자체도 반쪽짜리 규격이다.

[투명한 논의과정 부재]

KISA 내부에서 어떤 논의 과정을 거쳐 이런 규격이 제정되었는지
회의록이라도 볼 수 있으면 좋겠다.

[References]

Custom URL Scheme관련해서는 아래 URL들을 참조하세요.

http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
http://www.handleopenurl.com

2010년 3월 9일 화요일

애플 유료앱 결제와 규제

애플 유료앱 결제와 규제 


아이폰이나 아이팟터치 사용자라면 한번쯤 유료앱을 결제후 다운로드 받아본 경험이 있을것이다.
유료앱은 돈을주고 구매하는 프로그램으로 
국내소비자를 대상으로 한국어 서비스가 되며 국내 신용카드로 결제하게 된다.

이 과정에서 국내 법규정이 어떻게 적용되고 있는지 살펴보자.


1. iTunes에서 "Create New Account"메뉴의 첫화면이다.


2. iTunes Store 사용 약관 동의과정

사용 약관중에서 
"귀하는 라이센스된 애플리케이션을 미합중국 법... 
라이센스된 애플리케이션을 (a)미국의 수출 봉쇄 국가로... 
(b) 미국 재무성의... 
또는 미국 상무성 거부 인물 목록.... 
미국법에서 금지하는 목적으로 사용하지 않기로 동의합니다."
라는 약관조항이 보인다.
즉 미국법을 준수한다는 동의과정이 포함된것이 이상함.

3. iTunes Store 계정(Apple ID) 만들기

유료앱 구매를 위한 iTunes Store 계정을 만드는 항목이다.
우측 상단의 "보안 연결" 이라는 메세지가 눈에 들어온다.


4. 지불방법 선택


여기서부터 본격 카드결제 관련 정보를 입력한다.

카드정보 입력화면을 국내 법규정에 대비하여 비교해보면 아래와 같다.

4.1 본인확인을 위한 전자인증 (여신전문금융업 감독규정 제24조의 6)

관련규정에서는 신용카드사가 전자인증을 제공해야한다고 되어 있는데
실제 국내 카드사가 본인확인을 위한 전자인증을 제공하고 있는것 같지는 않다.
"보안 코드"라는 것을 통해서 카드를 실제로 소지하고 있는지 여부만을 확인한다.

실제 카드정보를 입력하면 다음단계에서 본인확인 절차가 있을 수 있으니 
이 단계에서 예단하기는 시기상조.

4.2 30만원이상 결제시 공인인증서 적용 (전자금융거래법 시행세칙 31조)

iTunes Store를 통해 구매가능한 유료앱중에서 30만원이 넘는 것들도 상당수 존재한다.
그러나 이 결제화면에서 공인인증서 관련 일체의 요구사항을 볼 수 없다.

4.3 금융거래정보의 종단간(End to End) 암호화 (전자금융거래법 시행세칙 29조)

SSL을 적용하고 있는것으로 짐작됨
화면 하단에 
"Apple uses industry-standard encryption to protect the confidentiality of user personal information"이라는 문구로 짐작

4.4 입력정보 보호대책 (전자금융거래법 시행세칙 29조)

유저가 입력하는 카드정보 입력을 보호하는 키보드 보안 프로그램이나
하다못해 스크린키보드도 보이지 않는다.

4.5 악성코드 예방대책 (전자금융거래법 시행세칙 29조)

안티바이러스나 방화벽등에 대한 항목은 찾아볼 수가 없다.
웹어플리케이션 보안 관련해서는 단단한 보호를 하였을걸로 짐작해볼수는 있음.

5. 계정생성됨


끝났다. 허무하다.
본인확인을 위한 전자인증이나 이런것 없이 그냥 끝났다.

이렇게 등록한 카드정보로 이제 자유롭게 iTunes Store의 상품을 마음껏 구매할 수 있다.
아이팟이나 아이폰등에서 자유롭게 구매할 수 있는것은 말할필요도 없고
아이패드나 윈도우즈, Mac OS등에서 제한없이 구매가능하다.


국내 유저가 국내 카드로 한국 iTunes Store에서 구매가능한 유료앱이다.
공인인증서 사용안하고 결제 잘된다.(당연히)

"국내와 국외에 다른 규제"


한국 쇼핑몰에 애플처럼 쇼핑몰을 구성하는것은 규제때문에 꿈도 꾸지 못한다.
그런데 애플은 국내에서 전자금융거래법이나 기타 다른 제도적 제약없이 자유롭게 상품을 판매하고 있다.

SK T Store나 삼성 앱스토어에서 이런식으로 AppStore를 꾸미면 경쟁력 있을것인데
결제방식에서부터 근본적으로 국내 AppStore와 애플 AppStore가 경쟁이 안된다.

본인확인을 안해도 되는 유튜브가 국내 1위 동영상 사이트가 되었지만
국내 업체들은 여전히 제도적 규제때문에 실명제를 준수하고 있다.

전자상거래에서도 각 쇼핑몰 업체별로 나름 안전하고 간편한 방식을 선택하여 영업하려고 해도 
만만한 국내업체는 거래를 중단시키면서까지 제제를 가하지만
해외업체는 예외(?)가 적용되는 현실이 안타깝다.

이미 애플 iTunes Store를 보면 알듯이 전자상거래에는 국경의 제약이 없다.
국내 규제로 인해 전자상거래를 위축시키지 않았으면 하는 바램이다.





2010년 3월 4일 목요일

한국에서 ActiveX가 광범위하게 사용되는 이유

한국에서 ActiveX가 광범위하게 사용되는 이유

국내에서 ActiveX가 광범위하게 사용되는 원인에 대해서 제가 알고 있는 몇가지 요소들을 기술해봅니다.

1. 공인인증서

  • 공인인증기관이 MSIE ActiveX기반으로만 서비스를 제공합니다.

2. 신용카드 전자상거래 ISP결제

  • BC, 국민에서 설립한 자회사 K모사에서 개발하였고 ActiveX형태로만 동작합니다.
  • 국민, BC카드의 전자상거래 결제는 모두 ActiveX로만 가능한 이유입니다.

3. 전자금융거래법 시행세칙 29조

  • 안티바이러스 ActiveX, 키보드보안 ActiveX, 개인방화벽 ActiveX가 모두 이 규정에서부터 파생되었습니다.

4. 금융거래시 전자서명

  • 금감원에서 금융거래시 전자서명을 요구하며
  • 공인인증 전자서명은 현재 ActiveX로만 가능합니다.

5. 보안서버 구축

  • http://secsv.kisa.or.kr/secsv/jsp/secsv.jsp 참조
  • 정보통신망 이용촉진 및 정보보호등에 관한 법률하위 시행령 하위 개인정보의 기술적 관리적 보호조치 기준 제5조에서 
    • SSL방식과 응용프로그램방식을 모두 인정하고 있습니다.
  • 응용 프로그램 방식은 공인인증서 사용모듈과 유기적으로 결합되어 하나의 ActiveX로 전자서명이나 End-to-End 암호화가 가능한점을 개발업체에서 장점으로 홍보하고 있어서 일반 업체에까지 광범위하게 ActiveX가 확산되게한 원인입니다.
  • 전자상거래 안심클릭 결제에 ActiveX가 사용되는 주요 이유중 하나입니다.

6. MSIE Auto Popup 차단

  • MS에서 특허나 보안등 여러가지 이유로 Auto Popup을 차단하고 있습니다.
  • 단 해당 서버 도메인이 Trusted Zone에 속하는 경우 Auto Popup이 가능합니다.
  • 신용카드 안심클릭 결제등은 팝업구조로 결제가 진행됩니다.
  • 많은 PG업체들이 결제팝업이 차단되는것을 방지하기 위해서 해당 업체 도메인을 MSIE Trusted Zone에 자동 추가하는 기능이 포함된 ActiveX를 결제시작하기전에 설치요구하고 있습니다.

7. iframe에 대한 오용

  • - ActiveX를 사용하더라도 이것이 꼭 필요한 단계에서만 사용하면 되는데 국내 현실은 일단 접속하는 모든 유저에게 ActiveX를 깔도록 요구합니다.
  • - 단순히 웹사이트를 둘러보기만 할 대다수 유저들에게 ActiveX를 깔도록 요구하는것은 불필요한 보안위험을 증대시킵니다.
  • - 실제로는 Javascript DOM 제어등을 통해 ActiveX를 꼭 사용해야한다면 그때 잠깐 활성화하여 사용할 수 있지만
  • - 상당수 업체들이 R&D가 부족하여 iframe등을 통해 무조건 ActiveX를 깔도록 요구합니다.

2010년 2월 1일 월요일

윈도우모바일6.1 해킹관련 PureWeb기반 보안대책

윈도우모바일6.1 해킹관련 PureWeb기반 보안대책

http://news.donga.com/It/New/3/08/20100201/25872427/1&top=1
기사를 보면 윈도우모바일 6.1 해킹관련 기사가 크게 났다.
퓨어웹환경에서의 보안대책을 고민해보았다.

1. 해킹절차

1) 유저는 해커가 준비한 웹사이트 방문
2) 유저는 해커가 유도한 프로그램 다운로드하여 자신의 기기에 설치
3) 유저가 웹사이트 방문하여 입력하는 정보를 Key-Logging
4) Logging한 정보를 해커가 설치한 프로그램을 통해 해커서버로 전송
5) 해커가 유저를 대신하여 쇼핑몰에서 상품 구매
6) Key-Logger로 빼낸 정보를 이용자를 가장하여 입력
7) 이통사에서 SMS문자인증 메세지 발송
8) 원 유저의 폰에서 문자 수신
9) 원 유저 폰에 설치된 프로그램이 문자내용을 해커에게 전송
10) 해커는 쇼핑몰에서 SMS 인증번호 입력하여 상품정상결제

2. PureWeb기반 보안대책

2.1 입력정보 보호대책

2.1.1  Javascript Screen Keyboard이용하여 keylogging 방지

- Javascript입력정보는 Javascript sandbox내에서만 존재함
- screen keyboard 배열을 세션 연계하여 random하게 변경

2.1.2 Javascript 보안

- Javascript 무결성 검증
- Javascript 동적 로딩 및 난독화
- Caja를 이용하여 보호

2.2 악성코드 예방대책

2.2.1 취약점이 존재하는 OS및 브라우저를 이용한 결제접근 차단

- Server에서 Browser UA정보 확인하여 취약점이 존재하고 벤더제공 패치가 나오지 않은 경우 결제접근 차단

2.2.2 이용자에게 보안권고 및 인지동의과정 추가

- 프로그램을 함부로 설치하지 않도록 보안권고
- OS 보안 업데이트 권고
- 본격 안티바이러스 설치 권고(가능하다면)

2.3 카드정보등 주요정보 Client 저장금지

- screen keyboard로 입력된 카드번호등은 서버전송후 browser memory에서 제거
- 주요정보는 browser sandbox내에서만 잠간 존재했다가 사라짐


2009년 12월 23일 수요일

순수웹환경에서의 전자금융 서비스 보안방안

순수웹환경에서의 전자금융 서비스 보안방안

ActiveX등의 Binary Plugin없이 순수웹(Pure Web)으로 전자금융서비스를 제공할 경우 어떤 보안대책이 필요할까
고민해보고 PCIDSS나 전자금융거래법 시행세칙등을 참조하여
최소한 아래와 같은 요구사항은 충족해줘야겠다는 생각이다.

이미 많은 기관들이 아래 보안요구사항들을 충족하고 있겠지만 확인하는 차원에서 한번더 정리해본다.

[순수웹환경에서의 전자금융서비스 보안]


1. 안전한 네트웍을 구축하고 유지

    1.1 방화벽을 설치하고 유지

        1.1.1 방화벽 구성 기준 수립

            - 변화관리 시스템 유지 (모든 설정변경사항을 승인하고 테스트하는 공식 절차가 존재해야함.)
            - 최신의 네트워크 구성도 유지
            - 인터넷과 내부 네트워크 사이에 DMZ Network 운용
            - 네트웍 구성요소에 대한 조직, 역할 및 책임을 정의
            - 모든 서비스, 프로토콜, 포트 사용에 대한 문서화 및 사용근거 명시
            - 안전하지 않은 프로토콜 사용시 이에 대한 보안대책 수립하고 문서화해야함.
            - 최소 6개월마다 룰셋 검토해야함.

        1.1.2 방화벽 및 라우터 구성

            - Inbound / Outbound 트래픽 제어
            - default deny rule
            - 라우터 설정파일의 보호 및 동기화
            - 무선네트워크와 내부시스템사이에 방화벽 설치

        1.1.3 내부 시스템에 대한 외부자의 직접접근 제한

            - 외부자의 이용가능한 프로토콜 제한
            - DMZ Network을 거치도록 네트웍 구성
                * 외부에서 Inbound traffic은 DMZ 내의 IP로 제한
                * 내부 시스템에서의 outbound traffic도 DMZ내의 IP로 제한
                * 필요시 forward / reverse Proxy 구성 운영
                * reverse proxy는 웹방화벽으로 대체가능
            - 방화벽에서는 Stateful Inspection을 적용 (이미 체결된 접속만을 네트워크로 허용)
            - Database는 DMZ으로부터 분리된 구간에 위치시킴
            - NAT나 PAT처럼 내부주소가 그대로 공개되지 않도록 주소변환 기술 이용

        1.1.4 개인방화벽 소프트웨어 설치 또는 활성화

            1.1.4.1 내부 사용자 시스템
                - 방화벽 설정은 회사에서 정한 표준규칙을 따라야함.
                - 개인이 임의로 방화벽 설정을 해제할 수 없도록 해야함.
            1.1.4.2 외부 사용자 시스템
                - 서버에서 사용자 개인 PC 환경을 직접 제어할 수 없다는 기본적인 사실 인지
                - 다양한 운영체제에 맞는 개인 방화벽 프로그램이나 활성화하는 방법을 자세하게 안내

    1.2 안전한 시스템 구성

        1.2.1 벤더제공 디폴트값 변경

            - SNMP Community String이나 기본 패스워드 등 변경
            - 무선환경에 대해서도 디폴트값 변경

        1.2.2 시스템 설정 기준 수립

            - 시스템 설정 기준은 알려진 모든 보안취약점에 대응하도록 수립되어야함.(SANS, NIST, CIS등 업계가 인정하는 보안강화 기준을 참조)
            - 서버당 하나의 주요 기능만을 구현
            - 불필요한 서비스나 프로토콜은 비활성화
            - 오용방지를 위한 시스템 보안 파라미터 설정
            - 스크립트, 드라이버, 기능, 하위시스템, 파일시스템, 불필요한 웹서버등 모든 불필요 기능 삭제

        1.2.3 모든 전송데이터에 대한 암호화

            - 콘솔 접근을 제회
            - SSH, VPN또는 SSL/TLS등의 기술을 이용

2. 고객정보 보호

    2.1 저장된 고객정보 보호

        2.1.1 고객 개인정보는 최소범위에서 저장

            - 법적, 제도적 요구사항을 감안하여 데이터 보유 및 폐기정책 수립
            - 데이터 보유 및 폐기정책에 따른 자동삭제 소프트웨어 구성

        2.1.2 중요한 개인인증 데이터를 저장하지 않음.

            - 중요 개인인증 데이터는 암호화 여부와 관계없이 저장하지 않음.
            - 중요 개인인증 데이터를 수신이후 삭제하는 경우 복구 불가능하게 데이터를 삭제해야함.

        2.1.3 중요 개인정보 출력시 마스킹 처리

            - 전체의 일부만 표시

        2.1.4 고객정보는 암호화하여 저장

            - 모든 로그파일에 개인정보가 존재하지 않아야함.
            - 백업매체 저장되는 경우도 암호화하여 저장해야함.
            - 모든 운용자 PC에 개인정보가 존재하지 않아야함.
            - 로그파일이나 개인PC에 개인정보가 존재하지 않음을 자동화된 프로그램으로 검증해야함.

        2.1.5 암호화에 사용된 암호화키는 안전하게 보호되어야함.

            - 암호화키에 대한 접근을 최소한의 관리자로 제한
            - 암호화키를 최소한의 장소와 형태로 안전하게 저장
            - 키관리 프로세스를 문서화하고 정해진 절차를 따라야함.
            - 암호화키는 강력한 보안비도로 생성
            - 암호화키는 안전한 과정을 거쳐 배포
            - 암호화키는 안전하게 저장되어야함.
            - 정기적으로 암호화키를 보호해야함.
            - 암호화키는 2인 이상에 의해 이중통제되어야함.
            - 암호화키는 승인받지 않고 교체될 수 없어야함.
            - 암호화키 관리자의 이해와 책임을 수용하는 동의서를 작성하고 비치해야함.

    2.2 공중망을 통한 고객정보 데이터 전송 암호화

        2.2.1 공중망의 범위

            - 인터넷
            - 무선기술을 이용한 네트웍 (GSM, CDMA, GPRS, WIFI, 기타)

        2.2.2 SSL/TLS, IPSEC등과 같은 보안 프로토콜을 사용해야함.

            - 강력한 보안비도의 Symmetric Algorithm이 사용되어야함.
            - 신뢰할 수 있는 CA인증서여야함.
            - SSLv3/TLSv1등 안전한 SSL Protocol을 사용해야함.
            - 사용자가 SSL 서버인증서와 도메인 및 사이트운영 기관을 명확히 확인할 수 있도록 EV(Extended Validation) SSL 서버 인증서를 이용

        2.2.3 안전한 무선네트워크 암호화 적용

            - WEP 사용 금지
            - IEEE 802.11i등 강력한 암호화 적용

        2.2.4 일반 사용자 메시징 기술을 통해 주요 고객정보 전송금지

            - E-Mail, Messenger, Chat등을 통해 고객정보 전송금지

3. 보안취약점 관리

    3.1 안티바이러스

        3.1.1 내부사용자

            - 운영자 PC에는 안티바이러스 소프트웨어를 적용
            - 바이러스 감염가능한 서버시스템에도 안티바이러스 소프트웨어 적용
            - 모든 시스템의 안티바이러스 적용여부를 확인할 수 있어야함.
            - 안티바이러스 감사 로그를 생성할 수 있어야한다.

        3.1.2 외부사용자

            - 서버에서 사용자 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실에 인지
            - 다양한 운영체제에 맞는 안티바이러스 프로그램이나 활성화하는 방법을 자세하게 안내해야함.

    3.2 안전한 시스템과 어플리케이션을 개발하고 유지

        3.2.1 내부시스템

            - 모든 시스템과 소프트웨어에는 벤더제공 최신 보안 패치를 설치해야함.
            - 새로운 보안취약점을 식별하는 프로세스를 수립해야함.
            - 확인된 새로운 보안취약점에 대한 대응방안을 "시스템 설정기준" 문서에 반영해야함.

        3.2.2 외부 사용자 시스템

            - 서버에서 사용자 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실 인지
            - 사용자 이용환경에 대한 보안패치 안내 
            - 사용자에게 보안업데이트이 중요성과 설치방법을 각 운영체제별로 충분히 안내
            - 윈도우 운영체제일 경우 OS Update나 KISA에서 제공하는 PC자동보안 업데이트 프로그램을 설치안내

    3.3 소프트웨어 개발 라이프사이클 전반에 걸쳐 정보보호 관련 사항을 통합해야함.

        3.3.1 반드시 운영시스템 적용전 테스트를 수행

            - 모든 입력값 검증테스트 수행
            - 적절한 에러처리 검증 테스트 수행
            - 안전한 암호화 저장 검증 테스트 수행
            - 안전한 커뮤니케이션 검증 테스트 수행
            - 적절한 역할기반 접근제어(RBAC) 검증 테스트 수행

        3.3.2 개발, 테스트 및 운영환경을 분리해야함.

        3.3.3 개발, 테스트 및 운영환경에 대한 직무를 분리해야함.

        3.3.4 운영데이터를 테스트나 개발을 위해 사용하지 않아야함.

        3.3.5 운영시스템 가동전 테스트트 데이터나 계정을 제거해야함.

        3.3.6 어플리케이션 가동전, 고객배포전 개발계정, 사용자ID, 임시 패스워드 제거해야함.

        3.3.7 제3자에 의한 개발코드 리뷰를 거쳐야함.

            - 코드 작성자 외의 제3자에 의한 코드리뷰가 필요
            - 코드 리뷰 결과는 경영층에 의해 검토되고 승인되어야함.
            - 코드 리뷰시 OWASP와 같은 코딩 지침에 따라 개발되었는지 검토해야함.

    3.4 변경관리절차에 따라 시스템 구성요소 변경

        - 변경의 영향에 대한 문서화
        - 적합한 관리자의 승인
        - 운영기능 테스트
        - 복귀(Back-out) 절차

    3.5 OWASP 취약점 대응

        - 크로스사이트 스크립팅(XSS) 대응
        - SQL Injection등 Injection 오류에 대응
        - 사용자가 어플리케이션에 실행가능한 악성파일을 올릴 수 없고 실행되지 않도록 악성파일 실행을 방지해야함.
        - 시스템 내부 Object를 사용자에게 노출하지 않도록 불안전한 직접 객체 참조 방지
        - 크로스 사이트 요청변조(CSRF) 방지
        - 오류 메세지등에서 주요정보가 유출되지 않도록 정보유출과 부적절한 에러처리 방지지
        - 취약한 인증 및 세션관리 방지
        - 불안전한 암호화 저장 방지
        - 모든 인증과 민감한 통신에 적절한 암호화를 적용하여 불안전한 통신을 예방
        - URL접근통제 실패 대응
        - 기타 OWASP version별 보안취약점에 대하여 대응해야함.

    3.6 웹어플리케이션 보호

        - 정기적으로 자동화된 웹어플리케이션 취약점 보안측정 도구 혹은 방법으로 취약점 검토
        - 웹방화벽 설치

    3.7 Anti keylogger

        - 사용자 개인 PC가 침해되었더라도 전자금융거래에 필요한 최소한의 보안성을 확보하기 위해 키보드 해킹방지 솔루션 적용할 수 있음.
        - 자바스크립트 기반의 "Onscreen Keyboard"를 이용하여 사용자가 키 입력을 하지 않도록 유도
        - 키 배열은 세션별로 Random하게 배치

    3.8 자바스크립트 보안

        - 자바스크립트의 무결성(Integrity)를 확인할 수 있는 체계를 수립하여 적용
        - 자바스크립트 난독기(Obfuscation)을 적용할 수 있음.
        - 자바스크립트의 일부를 서버에서 필요시 동적으로 로딩하여 사용
        - 자바스크립트의 주요 소스를 세션정보와 연계하여 Static하게 재사용 불가하도록 구성

    3.9 피싱방지를 위한 조치

        - 사용자 아이디 입력 페이지와 로그인 페이지를 순차로 배치하고
        - 로그인 페이지에서 해당 사용자가 미리 선택한 seal이나 site key아이콘이 뚜력이 드러나도록 설계한다.
        - 서버가 EV SSL 인증서를 채택하는 경우 사용자들이 EV SSL 인증서 채택 서버에 접속해 있음을 확인하고 
        - 로그인 정보를 입력하도록 해당 정보 입력란 근처에 설명, 안내한다.
        - 사용자의 명시적 요청이 없는한 서버가 사용자에게 명세서, 기타 안내 메일을 보내지 않는다.

    3.10 부인방지

        3.10.1 사전 약정에 의한 부인방지 효력 부여

            - 부인방지 효력은 오프라인 서명이나 인감날인 및 온라인 공인 전자서명으로 발생됨
            - 사전 약정과정에서 온라인에서 특정 인증정보 사용시 부인방지효력을 명시하고 동의받음.
            - 특정 인증정보는 아래와 같은 사항을 고려한다.
                * OTP 인증코드사용
                * 이체 비밀번호 사용
                * 로그인 비밀번호 재입력
                * 기타 플랫폼 독립적인 별도 방식 이용

        3.10.2 기술적 부인방지

            - 계좌이체와 같은 금융거래시 악성 코드의 Form데이터 조작에 의해 사용자의 보안빙자 자체에 위해가 가해질 수 있음.
            - 공격에 의한 데이터 조작으로 부인방지 효력상실을 방지하기 위한 기술적 절차적 수단을 강구한다.
                * 실시간 수행하지 않고 시차를 두어 Queue에 쌓아둔 후 사용자에 의한 추심 인증이 있을때 거래를 승인한다.

        3.10.3 추심인증

            - 일정조건의 거래에 대해서 사용자가 접속한것과 다른 채널 (SMS, OTP, 전화 등)을 통해서 2차 인증하는 정책을 유지해야함.

4. 강력한 접근통제

    4.1 업무상 알 필요가 있는지에 따라 개인정보 접근제한

        4.1.1 해당 데이터가 필요한 직원에게만 접근 허용

            - 사용자 ID는 직무수행에 필요한 최소권한으로 제한
            - 권한할당은 직원의 직무분류와 기능을 근거로
            - 공식적인 관리자의 승인절차를 거침
            - 자동화된 접근통제 시스템의 구현

        4.1.2 Default Deny 접근통제 정책 설정

            - 모든 시스템 구성요소를 포함
            - 직무분류와 기능을 기준으로 개인별 권한 할당

    4.2 사용자별 고유 ID 부여

        4.2.1 시스템에 접근하는 모든 사용자에게는 사용자를 구분할 수 있는 고유 ID를 발급해야함.

        4.2.2 고유ID는 패스워드등 추가 인증방식으로 사용자를 인증해야함.

        4.2.3 원격 접속시 2-Factors 인증 적용해야함.

        4.2.4 모든 패스워드에 대해서 강력한 암호화를 적용해야함.

        4.2.5 공식적인 사용자 인증 및 패스워드 통제절차를 마련해야함.

            - 사용자의 추가, 삭제, 수정에 대한 통제절차를 마련해야함.
            - 패스워드 재설정전 사용자 신원확인
            - 초기설정 패스워드는 즉시 변경 유도
            - 퇴사/ 탈퇴시 접근권한 즉시 말소
            - 최소 90일마다 미사용 사용자 계정 재거 또는 정지
            - 원격유지보수를 위한 계정은 일정시간만 사용가능하게 설정
            - 모든 사용자에게 패스워드 절차와 정책 배포
            - 공용 패스워드사용 금지
            - 패스워드는 90일마다 변경
            - 최소 7자리의 패스워드 자릿수 
            - 영문과 숫자를 포함한 복잡한 패스워드 사용
            - 과거 4회까지의 패스워드 재사용금지
            - 6번이상 접근실패시 사용자 계정 자동잠금
            - 계정잠금시 최소 30분간은 유지
            - 세션이 15분이상 Idle상태인 경우 자동 Timeout
            - 데이터베이스에 대한 접근통제 포함

        4.2.6 외부 사용자에 대한 두가지 이상 요소로 사용자 인증

            - 명확하고 안전하게 사용자 인증을 하기 위ㅐ서 최소한 2가지 이상의 방식을 복합하여 사용자 인증을 수행
            - 복합 사용가능한 인증요소로 다음사항을 고려
                * 패스워드 (조회 또는 이체에 복수 사용 가능)
                * 일회용 암호 생성기(OTP) 혹은 모바일 OTP 소프트웨어
                * 모바일 SMS 인증
                * SSL Client Authentification하의 공인인증서 로그인
            - 위 인증방식들을 제시하고 이중 사용자가 2개 이상을 복합적으로 선택하여 인증을 수행할 수 있도록 제공

    4.3 물리적 접근통제

        4.3.1 적절한 출입통제 사용

            - DVR등을 통한 감시
            - 네트웍 잭에 대한 접근통제
            - 무선 AP에 대한 접근통제
            - 휴대용 장비에 대한 접근통제

        4.3.2 직원과 방문자 식별절차 마련

        4.3.3 모든 방문자에 대한 적절한 통제

        4.3.4 방문자 활동기록 보관

        4.3.5 안전한 백업매체 보관

        4.3.6 개인정보를 포함한 종이 및 물리적 전자매체에 대한 보호

            - 해당 매체가 기밀로 식별되도록 분류
            - 이동시 추적가능한 안전한 방법으로 전달
            - 이동에 대한 관리자 승인

        4.3.7 개인정보를 담고 있는 저장소나 매체에 대한 엄격한 접근통제

            - 매체목록을 유지하고 연 1회 재고조사

        4.3.8 불필요 정보에 대한 적절한 파기

            - 복구불가능한 방법으로 파기한다.
            - 종이 분쇄기 이용
            - 전자매체에 대한 DeGausser이용 파기

5. 모니터링 및 테스트

    5.1 모든 접근을 추적하고 감시

        5.1.1 모든 접근시도에 대한 개별 사용자 연관 프로세스 수립

        5.1.2 자동화된 감사추적기능 구현

            - 사용자 식별
            - 이벤트 종류
            - 날짜와 시간
            - 성공 혹은 실패 표시
            - 이벤트의 시작지점
            - 영향받는 데이터, 시스템 구성요소 또는 자원으 신원 또는 이름

        5.1.3 시간동기화 설정

        5.1.4 감사기록에 대한 무결정(Integrity) 보호

        5.1.5 모든 로그에 대한 일일 점검

        5.1.6 로그기록은 최소 1년간 보관


    5.2 보안시스템 및 프로세스에 대한 정기적 시험

        5.2.1 분기별 1회 무선보안 취약점 시험

        5.2.2 정기적 네트웍 취약점 스캐닝

            - 최소 분기별 1회
            - 내부 및 외부 취약점 스캐닝

        5.2.3 정기적 침투시험

            - 내부 및 외부 네트워크 계층 침투 시험
            - 내부 및 외부 어플리케이션 계층 침투 시험
            - 침투시험시 알려진 모든 해킹기법을 이용한 침투 시험실시

        5.2.4 IDS/IPS를 이용하여 시스템 보호

        5.2.5 시스템 파일 무결성(Integrity) 감시 소프트웨어 운용용


6. 보안정책관리

    6.1 정보보호 정책의 수립, 공표, 유지관리 및 배포

        - 여기서 언급되는 모든 보안요구사항이 다루어져야함.
        - 위협과 취약점을 파악하고 공식적인 위험평가를 수행하는 연간 프로세스가 포함되어야함.
        - 최소한 매년 검토되어야함.

    6.2 일일 보안점검 절차 수립

    6.3 직원들이 사용하는 중요한 기술들에 대한 사용정책 제정

        - 사용에 대한 명시적 관리자 승인
        - 기술사용에 대한 인증
        - 장비목록과 사용자 목록 유지
        - 소유자, 연락처, 사용목적이 명시된 라벨링
        - 해당기술의 합당한 사용
        - 해당기술에 대한 네트워크상의 합당한 위치
        - 회사가 승인한 제품 목록
        - 특정 시간동안 활동이 없을 경우 자동 세션 종료
        - 벤더에 의한 운격접근기술은 필요시만 이용하고 사용후 즉시 구동중지
        - 원격접근시 데이터 복사, 이동, 저장 금지

    6.4 모든 직원과 계약업체의 정보보호 관련 책임을 명확히 규정

    6.5 직원 또는 팀에게 정보보호 관리 책임 할당

        - 정보보호 정책과 절차의 수립, 문서화 및 배포 책임
        - 보안경고 및 정보 감시/분석하고 적절한 인력에게 배포하는 책임
        - 보안사고 대응 및 보고절차를 수립/문서화/배포 책임
        - 사용자 계정 관리 책임
        - 데이터 접근 감시 및 통제 책임

    6.6 정보보호 중요성을 인식할 수 있는 공식적인 보안인식 프로그램 이행

    6.7 직원고용이전 적격 심사 수행

    6.8 외부 서비스 업체와의 상호연동을 위한 정책과 절차를 유지하고 이행

    6.9 침해사고 대응계획 수립

2009년 12월 22일 화요일

한국형 전자상거래 서비스 제공자간 상호연동 표준안(KECIS)

한국형 전자상거래 서비스 제공자간 상호연동 표준안

Korea Electronic Commerce Interoperability Standard

(분산환경에서 서비스 제공자들간의 상호 연계를 위한 데이터 송수신 표준 구조)




1. KECIS가 왜 필요한가?

- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "방법" 부재
- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "구조" 부재
- 위 "부재"로 인해 서비스 연동을 위한 중복된 Resource 소모, 복합적인 서비스 연계 불가

- 유저가 쇼핑몰(Shopping Service Provider)에 접근하는 경우
- 공급자는 유저에 대하여는 자신의 방식으로 서비스를 제공한다.
- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.


==> 각 공급자간의 표준 데이터 송수신 방법 부재

- 분산환경하의 결제서비스 공급자(Payment Service Provider)를 포함한 다수의 공급자들(Providers)이 자유롭게 결제및 인증 구조에 참여할 수 있는 표준화된 데이터 송수신 구조 확립이 필요

1.1 ECML을 이용한 구조 표준화

- XML Encryption으로 데이터 암복호화
- XML Signature으로 데이터 전자서명/서명검증
- 공인인증 인프라 이용

1.2 SAML이용하여 송수신 방법 표준화





2. KECIS는 누구에게 필요한가?

2.1 분산환경에서의 다양한 공급자들


다양한 형태의 서비스 공급자들이 인터넷 상이 존재한다.

- 쇼핑몰 서비스 공급자

- 신용카드 결제서비스 공급자

- 휴대폰 결제서비스 공급자

- 계좌이체 결제서비스 공급자

- 공인인증 인증서비스 공급자

- i-PIN 인증서비스 공급자

- OpenID 인증 서비스 공급자

- 배송서비스 공급자

- 문자발송서비스 공급자


이 공급자들은 나름의 방법으로 서비스를 유저에게 제공


3. KECIS에서는 공급자들간 무엇을 주고받는가?

3.1 K-ECML 포맷의 XML Message

3.1.1 ECML (Electronic Commerce Modeling Language)

- ECML v1 by RFC2706 at 1999
- ECML v1.1 by RFC3106 at 2001
- ECML v2.0 by RFC4112 at Jun/2005
- IETF에서 기술적인 개발 및 변경관리 수행

3.1.2 K-ECML as ECML addon

- 국내 카드사 코드 추가
- 국내 카드거래 종류 추가 (금액인증, ISP, 안심클릭 등)
- 국내 결제수단 추가 (계좌이체, 휴대폰 결제, 가상계좌 입금통지 등)

3.2 K-ECML Field List

4. KECIS에서는 공급자들간 어떻게 데이터를 주고받는가?

4.1 SAML 이용

- SAML의 데이터 송수신 구조 응용
- 유저 브라우저가 데이터 송수신의 라우터 역할을 함.

4.1.1 SAML Use Case Diagram


- Google Login with SAML

4.2 KECIS의 SAML 응용 데이터 흐름도


4.3 이용자와 다수의 공급자


각 공급자는 기존의 존재하는 자신만의 방식으로 그대로 서비스를 제공하면서
다른 서비스 제공자와 서비스 결과를 표준화된 방식으로 주고받을 수 있다면

하나의 공급자가 모든 서비스를 묶어서 힘들게 제공할 필요없이

자신이 가장 잘하는 서비스를 집중하여 유저에게 제공하며
자신이 보유하고 있지 않은 서비스를 해당 서비스 공급자에게 표준적인 방법으로 요청(*)하고
그 결과를 역시 표준적인 방법으로 응답받아 확인(*) 하고
다음 프로세스를 진행할 수 있다.




각 공급자간의 데이터 송수신은 XML Message를 기반으로 하며

공급자의 공인인증서로 상호 XML 전자서명 - 서명검증 하거나
XML 암호화 - 복호화 하여 데이터를 주고받으며
주고받는 데이터의 구조는 XML Schema 표준에 의하여 정의한다.

4.4 다수 공급자간의 Use Case Diagram









5. KECIS는 구현되어 있는가?

5.1 오픈소스로 공개되어 있음.


5.2 KECI Public Server

- java daemon
- 공인인증 Public Key만을 Handling
- XML Request Message에 대한 공인인증 공개키 암호화
- XML Response Message에 대한 공인 전자서명 검증
- Public Key에 대한 CRL checking

5.3 KECI Private Server

- java daemon
- 공인인증 Public & Private Key pair handling
- 공인인증 Private Key의 HSM 보관을 위한 Interface
- KECI Public Server의 모든 기능 포함
- XML Encryption / Decryption
- XML Signature / Verification

5.4 client Libraries

- JSP로 구현
- KECI Public Server와 TCP/IP Socket 통신
- K-ECML XML Message 생성 / 파싱
- DOM Communication을 위한 javascript library 포함

6. KECIS구조하의 상호연동 시나리오

6.1 2곳의 서비스 제공자간 상호연동 시나리오

6.1.1 상점과 결제대행사

머천트
    • 머천트는 고객이 상품선택을 완료하면
    • K-ECML formatXML Message 생성
    • KECI Public Server를 통해 결제대행사의 공인인증서로 요청정보 암호화
    • 유저 브라우저를 통해 해당 요청정보를 결제대행사로 전송

결제대행사
    • 결제대행사에서는 요청정보를 공인인증서의 개인키로 복호화
    • 고유한 프로세스로 결제처리
    • 결제결과를 KECI Private Server를 이용하여 전자서명
    • 서명된 메세지를 유저 브라우저를 이용하여 전송

머천트
    • 결제대행사에서 유저브라우저를 거처 전송해온 정보 수신
    • KECI Public Server를 이용하여 서명 검증
    • 결제가 완료된것을 확인한 머천트는 유저에게 상품 제공

6.1.2 상점과 은행

상점
    • 고객이 상점의 상품 선택
    • KECI client library를 이용하여 K-ECML XML Message 생성
    • 생성된 K-ECML Message를 KECI Public Server로 암호화
    • 암호화된 "요청" 메세지를 은행으로 전송

은행
    • 유저 브라우저를 거쳐 암호화된 메세지 수신
    • KECI Private Server를 통해 해당 메세지 복호화
    • 은행 웹사이트내에서 계좌이체 진행
    • 계좌이체 결과를 KECI Private Server로 전자서명
    • 서명된 메세지를 유저 브라우저를 통해 상점으로 전송

상점
    • 은행에서 유저 브라우저를 거쳐 전송되어온 서명된 메세지 수신
    • KECI Public Server통해 공인 전자서명 검증
    • 계좌이체가 완료된것을 확인후 유저에게 상품 제공

6.2 n개의 서비스 제공자간

6.2.1 상점, 은행, 공인인증기관

상점
    • 고객이 상품 선택
    • KECI Public Server로 요청정보 암호화
    • 유저브라우저 통해 은행으로 계좌이체 요청 전송

은행
    • 암호화 메세지 수신
    • KECI Private Server통해 정보 복호화
    • 계좌이체 시작
    • 본인확인을 위해 본인확인 요청 정보 KECI Public Server통해 암호화
    • 공인인증기관으로 전송

공인인증기관
    • 본인확인 요청 접수
    • 공인인증기관 웹사이트에서 유저와 본인확인 진행
    • 본인확인결과를 KECI Private Server로 전자서명
    • 은행으로 본인확인 결과 전달

은행
    • 전자서명된 본인확인 정보 수신
    • 계좌이체 처리
    • 계좌이체 처리완료 정보를 KECI Private Server로 전자서명
    • 유저브라우저를 통해 상점으로 이체결과 전송

상점
    • 계좌이체 결과 수신
    • KECI Public Server로 서명검증
    • 유저에게 상품제공

6.2.2 n개의 서비스 제공자들

  • 암호화된 요청정보 수신
  • KECI Private Server로 데이터 복호화
  • 서비스 제공자의 고유한 서비스 제공
  • 서비스 제공 결과를 KECI Private Server통해 전자서명
  • 전자서명된 결과를 원 요청자에게 응답

7. References

7.1 ECML


7.2 SAML

http://blog.sdnkorea.com/blog/501 : SAML을 이용한 SSO 구현

7.3 XML Encryption


7.4 XMLDSIG


8. 작성자

이동산 (Mountie Lee)
mountie@paygate.net

2009년 11월 2일 월요일

전자정부 세션보안 ActiveX

전자정부 사이트(www.g4c.go.kr)에 처음 접속하면
접속하자 마자 무슨 ActiveX를 설치하라고 나온다.
세션보안을 위한 XecureWeb을 설치하다는것인데
..

유저가 단순히 사이트 조회만을 위해 방문하든
민원을 신청하기 위해 방문하든 상관하지 않고 무조건 설치를 요구한다.

세션보안을 위한 것이라면 "정보통신망 이용촉진 및 정보보호 등에 관한 법률"및 그 하위 규정을 보면 분명하게
SSL과 응용프로그램방식 2가지를 모두 인정하고 있다.

당연하게 SSL 보안웹서버를 구성해야하는것이 아닌가?
웹 접근성을 적극 추진하고 있는 전자정부 사이트인데
아직도 응용프로그램 방식 보안웹서버를 구성하고 있다는것이

이해가 안된다.

XecureWeb이 다목적 프로그램인것은 알고 있다.
단순히 세션보안만을 위한것이 아니고 나중에 민원신청시에 다양한 기능이 동작한다.

그러나 그건 그 업무를 할 유저에게만 제시하는것이 적당하지

사이트 처음 접속하는 불특정 다수의 유저에게 무조건 설치를 강요하는것은 바람직하지 않다.

그 업무를 할 유저에게만 어떻게 제시할 수 있을까?

기술적으로는 아래와 같은과정으로 처리할 수 있다.

1. 페이지내에 < id="'xecureuse'"> < / div > tag를 하나 준비한다.
이 div tag내에는 아직 아무런 내용이 없다.

2. 만일 유저가 민원 신청을 위하여 xecureweb이 필요하다면
javascript으로 DOM element을 하나 생성한다.
그 과정은

var xecureobject = '';
document.getElementById('xecureuse').innerHTML = xecureobject;

이렇게 하면 다이나믹하게 object tag가 page내에 생성된다.
물론 단순하게 object tag만 넣기보다 실제 서비스를 위해서는 좀더 복잡한 콘트롤이 필요하다.

그렇지만 서비스 제공자가 좀더 복잡하게 콘트를하여 유저가 좀더 편리함을 느낀다면
그게 더 낳은 방식이다.

위의 개념은 activex control이 꼭 필요하더라도
무작정 불특정 다수의 유저에게 강요하기 보다
위와같은 dynamic object creation등을 통하면 기술적으로 해법이 존재하며
서비스 제공자가 무관심해서 안하는것이다.

정리하면

* 일단 세션보안은 무조건 SSL : 이것만 해도 웹 접근성이 엄청나게 증가된다.(사이트 방문하는 수많은 readonly user 지원)
* ActiveX control이 필요하다면 필요할때만 DOM element를 생성해서 사용

이정도만 해서 엄청난 웹 접근성 향상이 기대된다.

전자정부 사이트뿐만 아니라 다른 사이트도 마찬가지.