본문 바로가기
Windows/MFC

개발자를 위한 스마트폰 애플리케이션 보안 및 코드 서명 모델 방법에 대한 가이드

aucd29 2013. 10. 2. 18:38
http://msdn.microsoft.com/ko-kr/library/ms839377.aspx

개발자를 위한 스마트폰 애플리케이션 보안 및 코드 서명 모델 방법에 대한 가이드

제임스 프랫(James Pratt)
마이크로소프트

2003년 2월

적용 대상:
   Microsoft Windows Mobile-based Smartphone
   Microsoft ActiveSync
   Microsoft Visual Studio .NET 2003
   Microsoft eMbedded Visual C++ 3.0
   Microsoft eMbedded Visual C++ 4.0

요약: 스마트폰 애플리케이션 보안 모델과 관련해 애플리케이션 개발자가 이해해야 할 내용과 Windows Mobile 기반 스마트폰을 시장에 출시할 경우 무선 통신 사업자가 채택하고 있는 다양한 정책 선택에 대해 설명 드립니다. (20페이지 분량).

목차

개요 개요
개요 애플리케이션 보안에 대한 배경 설명
개요 디지털 코드 서명(Digital Code Signing)
개요 왜 디지털 코드 서명이 필요한가
개요 스마트폰 용 Windows Mobile 소프트웨어에서의 애플리케이션 보안
개요 언제 비특권(unprivileged) 실행 모드가 아니라 특권(privileged) 실행 모드가 필요한가
개요 특권(privileged) vs 비특권(unprivileged) 실행 모드
개요 보안 정책에는 무엇이 있는가
개요 실제 코드 서명
개요 Smartphone 2002/2003 공통 구성 단계
개요 Smartphone 2002에만 해당되는 구성 단계
개요 Smartphone 2003에만 해당되는 구성 단계 Steps
개요 특권(privileged) 접근을 고려한 개발
개요 배치를 위한 애플리케이션 서명ss
개요 결론
부록 A: Protected Registry Entry 부록 A: Protected Registry Entry
부록 B: 특권(privileged) API 리스트 부록 B: 특권(privileged) API 리스트

개요

Microsoft Windows Mobile 기반 스마트폰은 디지털 코드 서명에 기초한 애플리케이션 보안 모델을 구현합니다. Windows Mobile 기반 스마트폰을 목표로 하는 애플리케이션 개발자는 Smartphone Application Security 모델을 이해하고 Windows Mobile 기반 스마트폰을 시장에 출시할 때 무선 통신 사업자가 어떤 정책 선택권을 갖고 있는지 알아야 합니다.

Pocket PC나 스마트폰 애플리케이션 개발에 대한 지식을 갖고 있으며 Pocket PC와(또는) 스마트폰 설치 패키지(.cab)를 개발하고 있는 개발자에게 본 가이드는 스마트폰 애플리케이션 보안 모델에 대한 모든 것과 특권(privileged) 및 비특권(unprivileged) 애플리케이션의 차이점, 애플리케이션이 privileged trust를 필요로 하는 지 결정하는 방법, 스마트폰 개발을 위해 개발 환경을 구성하는 방법, 코드 서명 벤더를 통해 애플리케이션을 서명하는 방법 등에 관한 모든 정보를 제공해 드립니다.

애플리케이션 보안에 대한 배경 설명

Mobile2Market FAQ가 애플리케이션 보안과 코드 서명에 대한 심층적인 가이드를 제공합니다. 배경을 잘 이해하기 위해 본 가이드를 읽기 전 Mobile2Market FAQ을 읽어 보신다면 큰 도움이 될 것입니다.

디지털 코드 서명(Digital Code Signing)

디지털 코드 서명(Digital Code Signing)이란 디지털 컨텐츠의 출처를 증명하는 방식입니다. 디지털 코드 서명이 Windows Mobile 세계에서 때때로 로고 인증(logo certification)과 혼동될 때가 있습니다. 로고 인증이란 Windows Mobile 애플리케이션이 Windows Mobile 애플리케이션 구현을 위해 마련된 몇 가지 가이드라인을 만족시킨다는 점에 대한 증명서를 얻는 과정입니다. 현재 가이드라인은Mobile2Market FAQ에서 제공하고 있습니다. 인증을 받은 애플리케이션은 애플리케이션 안쪽과 패키지에 "Designed for Windows Mobile" 로고가 부착되어 있습니다. "Designed for Windows Mobile" 로고는 특정 소프트웨어 벤더가 애플리케이션을 제작했다는 점을 보증하거나 특정 소프트웨어 벤더가 애플리케이션을 마이크로소프트에 제출하는 과정에서 악의적으로 조작되지 않았다는 점을 보증하지 않습니다. 하지만, 코드 서명은 이러한 점을 보증해 줍니다.s

디지털 코드 서명이 디지털 인증서를 사용하는 반면, 별도의 로고 인증 프로그램이 있다는 점은 약간 혼란스러울 수도 있습니다. 하지만, 이 두 가지 제도는 전혀 다른 목표를 갖고 있습니다.

왜 디지털 코드 서명이 필요한가

디지털 코드 서명은 Windows Mobile 기반 스마트폰에만 사용되는 것이 아닙니다. Microsoft Internet Explorer가 Active X control 을 설치할 것인지 물어볼 때와 " X라는 회사에서 제공하는 컨텐츠를 신뢰" 하는 지 물어볼 때마다, 애플리케이션은 컨텐츠 제공자를 신뢰할 것인지 아닌지 결정을 내려달라고 요청하는 것입니다. Internet Explorer가 해당 패키지가 서명된 이래 변경되지 않았다는 점을 주장하는 것입니다. 출처를 신뢰할 수 있다면 검증된 출처에서 애플리케이션이 보내진 것이기 때문에 애플리케이션도 신뢰할 수가 있는 것입니다. 코드 서명은 디지털 컨텐츠의 출처를 검증하는 것이고 서명된 이후 변하지 않았다는 사실을 입증하는 과정입니다.

스마트폰 용 Windows Mobile 소프트웨어에서의 애플리케이션 보안

Windows Mobile 기반 스마트폰에서 애플리케이션 보안을 통해 최종 사용자 스마트폰의 무결성(integrity)을 보호할 수 있습니다. 사용자가 알 수 없는 출처로부터 온 애플리케이션을 설치하도록 허용하지 않기 때문입니다. 애플리케이션 보안이란 코드 서명을 통해 집행되는 정책 결정입니다. 무선 통신 사업자는 시장에 기기를 출시하기 전 그 정책 결정을 내리게 됩니다. 또한, 무선 통신 사업자는 언제든 정책 결정을 바꿀 수 있습니다.

Windows Mobile 기반 스마트폰은 경계 보안(perimeter security)과 런타임 보안(runtime security)을 모두 구현합니다. 경계 보안 컨트롤은 기기에 설치될 수 있으며, 런타임 보안 컨트롤은 기기에서 실행될 수 있습니다. 예를 들어, 벨소리나 홈 화면을 설치할 때 애플리케이션을 설치하고 실행해야 합니다. 만일 실행가능한 컴포넌트가 전혀 포함되지 않은 기기에 설치되는 컨텐츠를 만들고 있다면, 경계 보안에 대해서만 생각하면 됩니다. 실행가능한 애플리케이션이나 컴포넌트를 개발하고 있다면 경계 및 런타임 보안을 모두 고려해야 합니다. 스마트폰은 unprivileged execution trust store, privileged execution trust store, installation trust store 라는 세 개의 인증서 저장소(certificate store)를 갖고 있습니다. 하나의 인증서 저장소에는 스마트폰에 설치되는 디지털 인증서의 공개 부분(public portion)이 포함되어 있습니다. 인증서의 공개 버전(public version)은 애플리케이션의 디지털 서명을 입증하는 데 사용될 수 있지만, 애플리케이션 서명에는 사용할 수 없습니다.

언제 비특권(unprivileged) 실행 모드가 아니라 특권(privileged) 실행 모드가 필요한가

게임이나 개인 생산성 애플리케이션 등 대부분의 애플리케이션은 비특권(unprivileged) 실행 모드만 필요로 합니다. 애플리케이션으로 다음과 같은 작업을 할 계획이라면 특권(privileged) 실행 모드가 필요하며, 따라서 특권(privileged) 인증서로 서명을 받아야 합니다.

  • system registry entry 수정하기 (참조 부록 A)

  • SMS subsystem에 접근하기 (SmsXXX functions)

  • 전화 걸기 및 가로채기(intercepting), 기타 exTAPI API에 접근하기

  • SIM management subsystem에 접근하기 (SimXXX functions)

  • Radio Interface Layer를 통해 무선(radio)에 직접 접근하기 (Smartphone SDK를 통해 노출되는 게 아닌)

  • low level system API 사용하기 예: Kernel IOControl

  • DLL처럼 시스템 프로세스나 특권(privileged) 프로세스에 플러그 인 되는 컴포넌트를 작성할 때. 기기 쪽 ActiveSync 애플리케이션이 특권(privileged) 애플리케이션으로 분류된다는 점에서 대표적인 예는 Microsoft ActiveSync Service Provider.

    주의   부록 B에는 특권(privileged) 접근을 필요로 하는 API 목록이 포함되어 있습니다.

특권(privileged) vs 비특권(unprivileged) 실행 모드

스마트폰 애플리케이션 보안 모델은 다양한 무선 통신 사업자의 네트워크 요구사항에 부응하도록 유연하게 설계되었습니다. 특권(privileged) 및 비특권(unprivileged) 애플리케이션 개념은 기기에 있는 기능과 특정 애플리케이션을 이용해 API에 접근하는 수준을 말합니다.

  • 특권 (privileged) trust 애플리케이션이 시스템과 API에 완벽하게 접근할 수 있습니다. 특권(privileged) 인증서 저장소에 있는 인증서로 서명된 애플리케이션이 이 execution privilege로 실행됩니다.

  • 비특권 (unprivileged) trust 애플리케이션이 제한적으로 시스템과 API에 접근할 수 있습니다. 비특권(unprivileged)인증서 저장소에 있는 인증서로 서명된 애플리케이션이 이 execution privilege로 실행됩니다.

  • Untrusted 애플리케이션은 스마트폰에 로딩될 수 없으며, 시스템이나 API에 접근할 수 없습니다.

    무선 통신 사업자는 스마트폰 보안 정책을 선택하게 됩니다. 이 정책을 통해 untrusted 애플리케이션이 비특권(unprivileged) 접근 권한으로 운영될 수도 있으며 애플리케이션 디지털 서명을 요구할 수도 있습니다. 다음 섹션에서는 보안 정책 기반에 대해 알아보도록 하겠습니다.

보안 정책에는 무엇이 있는가

애플리케이션 설치(경계 보안)를 위한 무선 통신 사업자의 정책 선택은 간단해야 합니다.

  • 서명되지 않은 설치 패키지의 설치를 허용

  • 서명되지 않은 설치 패키지의 설치를 허용하지 않음

Smartphone 2003에는 사용자에게 애플리케이션을 설치할 것인지를 묻는 추가적인 모드가 있습니다.

애플리케이션 실행(런타임 보안)을 위해 무선 사업자는 특권(privileged) 및 비특권(unprivileged) trust의 경우 애플리케이션이나 컴포넌트의 실행을 허용할지 선택해야 합니다. 다음의 표는 정책에 따라 애플리케이션 실행을 위해 서명을 받아야 할 인증서의 종류를 나타낸 것입니다. Smartphone 2002의 경우입니다.

정책

실행 모드

실행 모드

 

비특권(unprivileged)

특권(privileged)

무제한(Unrestricted)

없음

없음

표준(Standard)

없음

Operator privileged certificate 필요

제한적(Restricted)

Mobile2Market unprivileged certificate 필요

Operator privileged certificate 필요

또한, Windows Mobile 2003 기반 스마트폰은 프롬프트 모드를 지원합니다. 단순히 사용자의 애플리케이션 설치나 실행 능력을 제한하기 보다는, 프롬프트 모드를 통해 사용자에게 결정을 미룰 수도 있습니다. 이 경우, 사용자는 프롬프트를 통해 애플리케이션을 실행하거나 설치하도록 허용할 것인지 질문을 받게 됩니다. 실행 정책은 다음과 같습니다.

정책

실행 모드

실행 모드

 

비특권(unprivileged)

특권(privileged)

무제한(Unrestricted)

없음

없음

표준(Standard)

Mobile2Market unprivileged certificate 필요 (또한 프롬프트 모드)

Mobile2Market 또는 Operator privileged certificate 필요

제한적(Restricted)

Mobile2Market unprivileged certificate 필요

Mobile2Market 또는 Operator privileged certificate 필요

Mobile2Market Build Applications 페이지에서 주요 무선 통신 사업자들의 보안 정책 결정에 대한 정보를 제공합니다. .

실제 코드 서명

코드 서명은 코드의 개발과 애플리케이션 배치 동안 개발자에게 영향을 미칩니다. 개발기간 동안 에뮬레이터나 인증서가 있는 기기를 어떻게 구성할 것인지 생각해 보아야 합니다. 애플리케이션을 배치할 때는 애플리케이션의 디지털 서명을 어떻게 받을 것인지, 어떤 컴포넌트에 대한 서명을 받을 것인지, 어떻게 그 컴포넌트를 서명할 것인지 생각해 보아야 합니다. 스마트폰 애플리케이션의 개발에 착수하기 전, 스마트폰 기기와 개발 환경을 준비해야 합니다.

Smartphone 2002의 경우, eMbedded Visual C++ 3.0 구성 방법과 서명을 위해 특권(privileged)과 비특권(unprivileged) 인증서 중 어떤 것을 사용할 것인지를 결정해야 합니다. Smartphone 2003의 경우, eMbedded Visual C++ 4.0 및 Microsoft Visual Studio .NET 2003 구성 방법에 대해 이해한 뒤, 개발 과정을 단순화하기 위해 같은 인증서 세트를 사용할 수 있습니다.

Smartphone 2002/2003 공통 구성 단계

Smartphone 2002/Smartphone 2003의 경우 일부 구성 단계 상 모두 SDK tools directory에서 명령 프롬프트를 사용해야 합니다. 툴을 디폴트 위치에 설치했다면, tools directory는 다음과 같습니다.

Platform

Tools directory

Smartphone 2002

C:\Windows CE Tools\wce300\Smartphone 2002\tools

Smartphone 2003

C:\Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Tools

명령 프롬프트를 열고 다음의 단계에 따라 디렉토리를 tools directory로 변경하십시오.

  1. Start menu를 클릭한 뒤 Run (또는 Windows logo key와 R을 누릅니다)을 클릭합니다. Run dialog가 열립니다.

  2. edit field에 cmd 를 입력한 뒤 ENTER key를 누릅니다. 명령 창이 열립니다.

smartphone_security01.gif

그림 1. 명령   창   열기  

  1. 디렉토리를 위의 플랫폼별 tools directory로 변경하십시오. cd 를 입력한 뒤 ENTER key를 누릅니다

smartphone_security02.gif

그림 2. 디렉토리를   플랫폼   별 tools directory 로   바꾸기

개발 인증서 만들기

Smartphone 2002/2003 SDK에는 spdps라는 툴이 들어 있습니다. 이 툴은 기기 측면의 개발 툴을 서명하기 위한 특권(privileged) 개발자 인증서를 만들고, 그 인증서를 스마트폰과 스마트폰 에뮬레이터에 제공하는 데 쓰입니다. Smartphone 2002 및 Smartphone 2003을 위한 spdps 명령을 각각 별도로 실행해야 에뮬레이터가 적절한 인증서로 구성되며 디버그 툴이 서명됩니다.

spdps tool은 SDK의 tools directory에 설치되어 있습니다. 이전의 단계에 따라 명령 프롬프트를 열고 디렉토리를 적절한 tools directory로 변경하십시오.

Platform

Tool name

Tools directory

Smartphone 2002

sp2002dps

C:\Windows CE Tools\wce300\Smartphone 2002\tools

Smartphone 2003

spdps

C:\Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Tools

이제 /create and /device parameter로 이전 표에 있던 툴을 실행합니다. 예를 들어, "sp2002dps /create /device"라고 입력한 뒤 를 치면 Smartphone 2002를 위한 툴이 실행될 것입니다. 이 명령을 내리기 전 스마트폰 기기가 PC에 연결되어야 하며, ActiveSync가 연결되어야 합니다.

그림 3 과 같은 모습이 나타나야 합니다.

smartphone_security03.gif

그림 3. ENTER를 누르면 플랫폼에 맞는 툴의 결과가 반환됩니다.

여기서 한 일은 모든 기기 측면의 개발 컴포넌트, 원격 툴, 디버거를 로컬에서 만든 인증서로 서명한 것입니다. 이 툴들은 기기에 대한 특권(privileged) 접근을 필요로 합니다. 따라서, 로컬에서 만든 인증서를 기기의 privileged execution trust store에 넣어야 합니다. 그 이후에야 기기가 컴포넌트의 특권(privileged) 프로세스 실행을 허용할 것입니다.

일부 무선 통신 사업자는 독자적인 개발을 지원하지 않도록 기기를 구성하기도 합니다. 이 경우, 다음과 같은 에러가 발생합니다.

smartphone_security04.gif

그림 4. 독자적인 개발을 지원하지 않는 기기 구성을 선택하면 에러가 반환됩니다.

스마트폰이 독자적인 개발을 지원하지 않는다면, 무선 통신 사업자에게 연락해서 스마트폰을 구성하기 위한 서비스를 제공하는 지와 스마트폰 애플리케이션을 개발할 수 있는지 확인해야 합니다. 무선 통신 사업자가 웹에서 회원가입을 하면 참여할 수 있는 스마트폰 활성화를 위한 개발자 프로그램을 운영하고 있을 수도 있습니다.

여러 대의 스마트폰에서 개발하는 경우, spdps /device 명령을 사용해 개발 인증서를 각 스마트폰에 넣을 수 있습니다. 이 경우, /device parameter만 사용해야 합니다.

smartphone_security05.gif

그림 5. 하나의 파라미터 사용하기

/device without the /create switch를 사용할 때, 유틸리티가 사용자에게 인증서를 선택하라는 요청을 합니다.

smartphone_security06.gif

그림 6. 인증서 선택하기

eVC가 최초로 스마트폰 기기를 타겟으로 할 때, " Default Development Certificate"이 자동으로 생성됩니다. spdps /create에 의해 "Smartphone privileged Development Certificate for "이 생성됩니다. 이 경우, 기기에 넣기 위해 "Smartphone privileged Development Certificate for "을 선택합니다. 프로세스가 끝나면 이전과 같은 성공 화면이 나타날 것입니다.

스마트폰을 리셋하거나 배터리가 완전히 소모된다면, 이 과정을 반복해 다시 스마트폰을 구성해야 한다는 점을 잊지 마시기 바랍니다.

Smartphone 2002에만 해당되는 구성 단계

Smartphone 2002의 경우, eMbedded Visual C++ 3.0을 사용해서만 애플리케이션을 개발할 수 있습니다. 이전에 언급한 과정을 따라 함으로써, 기기의 특권(privileged) 및 비특권(unprivileged) 인증서 저장소에 인증서를 만들었습니다. 이를 통해 애플리케이션이 특권(privileged)과 비특권(unprivileged) 중 어떤 서명을 필요로 하는지 결정할 수 있습니다. 이 방법은 에뮬레이터가 아니라 실제 스마트폰 기기를 구성하는 데 초점을 맞추고 있습니다. 에뮬레이터에는 어떤 종류의 애플리케이션도 개발할 수 있도록 하는 공개 보안 정책이 들어 있습니다. 통신 사업자가 나름의 보안 정책을 선택할 수 있기 때문에, 개발자로서 기기를 사용할 때만 현재 서명에 어떤 인증서가 사용되고 있는지 알 필요가 있습니다.

Smartphone 2003에만 해당되는 구성 단계

Smartphone 2003 용 애플리케이션을 개발하는 데 두 개의 툴을 사용할 수 있습니다. 이전의 단계에서 이미 기기를 구성했기 때문에 eMbedded Visual C++ 4.0이 애플리케이션을 기기와 에뮬레이터에 배치 및 디버그할 수 있습니다. Smartphone 2003 SDK에는 특권(privileged) 및 비특권(unprivileged) 개발 인증서가 들어 있습니다. 이 인증서들은 이미 에뮬레이터의 특권(privileged) 및 비특권(unprivileged) 인증서 저장소에 로딩된 상태입니다. 비특권(unprivileged) 인증서는 Visual Studio .NET 2003이 디폴트 인증서로 사용하고 있습니다. 이번 섹션에서는 이러한 인증서를 사용하기 위해 기기를 구성하는 방법에 초점을 맞춰, 모든 툴과 에뮬레이터 전체에 걸쳐 일관성 있는 인증서 세트를 사용하는 방법에 대해 알아 보도록 하겠습니다.

개인 인증서 저장소에 테스트 인증서 추가하기

먼저, SDK tools directory에 있는 인증서를 개발 PC에 있는 개인 인증서 저장소에 추가합니다. 이 인증서 파일을 TestCert_Privileged.pfx 및 TestCert_UnPrivileged.pfx 라고 부릅니다. 개인 인증서 저장소에 인증서를 설치하기 위해서는 다음과 같은 과정이 필요합니다.

  1. Explorer에서 .pfx file을 더블클릭합니다.

  2. Next를 클릭합니다.

  3. 다시 Next를 클릭합니다.

  4. Next를 다시 클릭합니다 - 인증서에는 패스워드가 없습니다.

  5. "Automatically select cert store"를 선택하고 Next를 클릭합니다.

  6. Finish를 클릭합니다. s

기기에 인증서 배치하기

개인 인증서 저장소에 인증서를 추가했다면, 이제 이를 기기에 추가해야 합니다. 이 때 rapiconfig tool을 사용해야 합니다. Smartphone 2003 SDK에는 인증서를 기기의 적절한 인증서 저장소에 추가하는 구성 파일이 들어 있습니다. 이전의 지침에 따라 명령 프롬프트를 열고 SDK tools directory로 변경합니다. 다음을 입력합니다.

rapiconfig /p sdktestcerts.xml

다음과 같은 화면이 나타나야 합니다.

smartphone_security07.gif

그림 7. 디렉토리   변경을   위해 rapiconfig tool 사용하기

eMbedded Visual C++ 4.0 Project 구성하기

이제 기기에는 SDK 테스트 인증서가 포함되어 있습니다. 마지막 단계는 eMbedded Visual C++ 4.0 project를 업데이트해, 이 프로젝트가 애플리케이션 서명에 비특권(unprivileged) 테스트 인증서를 사용하도록 하는 것입니다. eMbedded Visual C++ 4.0에서 다음과 같은 과정을 실행합니다.

  1. Project로 이동해 Settings를 선택합니다.

  2. Security 즉, 가장 오른쪽의 탭으로 스크롤합니다 (7번째 단계의 주의 참조).

  3. 맨 위 체크박스에서 ONLY를 체크합니다. (Sign This Application).

  4. 위 쪽의 Browse button 을 누릅니다..

  5. "Smartphone 2003 Unprivileged Test Signing Authority" 라는 인증서를 선택하고 OK를 클릭합니다.

  6. "Configure device to trust signed applications" 체크박스의 체크를 해제합니다.

    주의    이미 인증서를 원하는 저장소에 배치했습니다. 따라서, 다시 배치할 필요가 없습니다. 이 박스의 체크를 해제하면 인증서가 엉뚱한 저장소로 가는 것을 막을 수 있습니다.

  7. OK를 클릭합니다.

    주의    Security tab은 Smartphone Projects에만 있습니다. main IDE에서 타겟 플랫폼이 Pocket PC가 아니라 Smartphone으로 설정되도록 하십시오. eMbedded Visual C++ 4.0 은 때때로 Smartphone project를 만들어도 디폴트로 Smartphone이 아니라 Pocket PC를 선택하기도 합니다.

Visual Studio .NET 2003 구성하기

Visual Studio .NET 2003은 디폴트로 Smartphone 2003 SDK에 딸려 오는 인증서를 사용합니다. Visual Studio .NET 2003이 자동으로 애플리케이션을 비특권(unprivileged) 인증서로 서명하도록 하기 위해서는 기기를 적절한 인증서로 구성하기만 하면 됩니다.

Visual Studio .NET 2003 애플리케이션이 특권(privileged) 서명을 필요로 하는 것 같다면, 애플리케이션 컴포넌트(.exe 및 .dll)를 "Smartphone 2003 Privileged Test Signing Authority"라는 특권(privileged) 테스트 인증서를 이용해 수동으로 서명해야 합니다. 이 작업은 signcode tool을 사용해서 할 수 있습니다. Signing Your Application for Deployment 섹션에 이 signcode tool 사용법이 설명되어 있습니다.

주의   기기에서 실행 파일(executable)을 시작함으로써 privileged trust를 요구하는 애플리케이션을 실행할 수 있습니다. 하지만, 개발 환경에서 애플리케이션을 실행하거나 디버그하는 경우, 비특권(unprivileged) 인증서로 애플리케이션을 다시 서명하게 됩니다.

특권(privileged) 접근을 고려한 개발

특권(privileged) Registry Entry 액세스

특권(privileged) registry key와 value를 통해 창을 열고 이동할 수 있습니다. 하지만, key나 value를 생성, 수정, 삭제할 수는 없습니다. 모든 registry access function이 LONG 값을 반환합니다. 특권(privileged) 접근을 요구하는 키를 생성, 수정, 삭제하려고 하면, 반환 값은 ERROR_ACCESS_DENIED (0x05)이 될 것입니다. 이 registry function return value를 확인하고 한번 실패해 보십시오.

특권(privileged) registry entry 리스트는부록 A. 를 참조하십시오.

특권(privileged) API 호출하기

애플리케이션에서 API가 실패한다면, 특권(privileged) API를 호출하고 privileged trust로 실행하지 않았기 때문일 수도 있습니다. 이러한 상황에서는 함수 호출이 실패합니다. 각 함수는 실패했다는 것을 각기 다른 방식으로 나타내며, 일부는 반환 값으로 나타냅니다. privileged trust로 실행해야 하기 때문에 이 자체로 호출이 실패한 것은 아닙니다.

privileged trust가 필요하기 때문에 함수 호출이 실패했다고 생각한다면, GetLastError 함수를 호출할 수 있습니다. 반환 값이 0x05 (ERROR_ACCESS_DENIED)라면, 이것은 그 함수를 사용하기 위해서는 privileged trust로 실행해야 할 지도 모른다는 점을 나타냅니다.

특권(privileged) 서명이 필요해서 문제가 발생했는지 테스트할 수 있는 방법을 설명한 섹션을 참고하십시오.

특권(privileged) API 리스트는 부록 B를 참고하십시오.

DLL 및 기타 컴포넌트 작성하기

하나의 실행가능한 컴포넌트가 다른 실행가능한 컴포넌트로부터 기능을 로딩받는 경우가 많습니다. DLL이 대표적인 예입니다. 보통 런타임(runtime)이나 링크 타임(link time)에 기능을 로드하는 형태입니다. 표준 스마트폰 애플리케이션 중 일부는 ActiveSync, Inbox, Home Screen 등의 특정 기능을 구현하는 DLL을 작성함으로써 스스로 확장하기도 합니다.

실행 가능한 스마트폰 컴포넌트가 다른 컴포넌트를 로딩하려고 할 때, 시스템은 그 실행 가능한 컴포넌트의 특권 수준(privilege level)을 확인합니다. 만일 낮은 수준의 trust를 갖고 있다면 컴포넌트 로딩을 허용하지 않습니다.

특히, 거의 모든 시스템 실행파일(executable)이 privileged trust로 실행된다는 점을 기억하셔야 합니다.

Smartphone 2002에서 비특권(unprivileged) 컴포넌트를 특권(privileged) 프로세스로 로딩하려고 하면 보기 좋게 실패합니다. 예를 들어, ActiveSync service provider를 만든다고 가정해 봅시다. 데스크탑과 기기에 컴포넌트를 정확하게 설치하고 데스크탑에서 service provider가 ActiveSync option에 나타난다 해도, 싱크하려고 하면 어떤 데이터도 전송되지 않습니다. 왜냐하면, 컴포넌트가 기기에 로딩되지 않았기 때문입니다. 일반적으로 시스템 애플리케이션에 플러그 인 되는 컴포넌트는 특권(privileged) 인증서로 서명해야 합니다.

Smartphone 2003에서 특권(privileged) 프로세스에 비특권(unprivileged) 컴포넌트를 로딩하려고 할 때, 그 결과는 보안 정책에 달려 있습니다. 무선 통신 사업자가 프롬프트 모드를 허용했다면, 사용자는 다음과 같이 컴포넌트를 로딩할 것인지를 묻는 프롬프트를 받게 됩니다. 

이 프로그램은 신뢰할 수 없는 알려지지 않은 출처에서 제공되는 컴포넌트를 필요로 합니다. 
이 컴포넌트를 실행하시겠습니까

만일 통신 사업자가 프롬프트 모드를 지원하지 않는다면, 그 행동은 Smartphone 2002와 같습니다.

애플리케이션이나 컴포넌트가 특권(privileged) 서명이 없어서 실패한다는 것을 어떻게 경험적으로 테스트합니까

지금까지의 구성 지침을 따랐다면, 개발 환경은 자동으로 애플리케이션을 알려진 비특권(unprivileged) 인증서로 서명하도록 구성되어 있을 것입니다. 지금까지의 구성 지침을 따랐는데 애플리케이션이나 컴포넌트가 특권(privileged) 서명을 필요로 한다고 생각한다면, 기기의 특권(privileged) 저장소에 있는 특권(privileged) 인증서로 서명함으로써 이를 경험적으로 테스트할 수 있습니다. 이전의 지침을 사용해 환경을 구성했다는 가정하에, 보안 관련 오류를 식별할 수 있도록 도와 주는 다음의 과정을 사용할 수 있습니다.

eMbedded Visual C++ 3.0/ 4.0

eMbedded Visual C++ family의 경우, project settings에서 애플리케이션이나 컴포넌트 서명에 사용되는 인증서를 변경해야 합니다. eMbedded Visual C++ 3.0 과 4.0 중 어느 것을 사용하고 있는가에 따라 약간 다른 선택을 해야 합니다.

주의   Smartphone 2002 에뮬레이터에는 공개 보안 정책이 있기 때문에, Smartphone 2002의 경우 에뮬레이터를 사용해 이 테스트를 실시할 수 없습니다.

eVC 버전

인증서 이름

3.0

Smartphone Privileged Development Certificate for

4.0

Smartphone 2003 Privileged Test Signing Authority

  1. Project로 이동해 Settings를 선택합니다.

  2. Security 즉, 가장 오른쪽의 탭으로 스크롤합니다 (7번째 단계의 주의 참조).

  3. 위쪽의 체크박스만 체크합니다(Sign This Application).

  4. 위쪽의 Browse button을 누릅니다.

  5. 위의 탭에서 인증서를 선택합니다.

  6. . "Configure device to trust signed applications" 체크박스의 체크를 해제합니다.

    주의    이미 인증서를 원하는 저장소에 배치했습니다. 따라서, 툴을 사용해 다시 배치하고 싶지 않을 수 있습니다. 이 박스의 체크를 해제하면, 인증서가 엉뚱한 저장소로 가는 걸 막을 수 있습니다.

  7. OK를 클릭합니다.

    주의   Security tab은 Smartphone Projects에만 있습니다. 주 IDE에서 타겟 플랫폼이 Pocket PC가 아니라 Smartphone으로 설정되도록 하십시오. eMbedded Visual C++ 4.0 은 때때로 Smartphone project를 만들어도 디폴트로 Smartphone이 아니라 Pocket PC를 선택하기도 합니다.

모든 애플리케이션이나 컴포넌트를 재구축(Rebuild)하면, 특권(privileged) 인증서로 서명이 될 것입니다. 예상대로 애플리케이션이나 컴포넌트가 작동하기 시작하면, 애플리케이션은 특권(privileged) 서명을 필요로 하게 될 것입니다.

Visual Studio .NET 2003

Visual Studio .NET 2003으로 테스트하는 것은 약간 다릅니다. 이 경우, signcode tool을 사용해 컴포넌트를 수동으로 서명한 뒤 이를 배치해야 합니다. 본 문서의 Signing Your Application for Deployment 섹션에서 signcode 사용법에 대한 가이드를 제공하고 있습니다. 애플리케이션이나 컴포넌트를 서명하기 위해서는 Smartphone 2003 Privileged Test Signing Authority 인증서를 선택해야 합니다. Visual Studio .NET 2003이 오직 Smartphone 2003만 지원한다는 점을 기억하시기 바랍니다.

스마트폰의 인증서 저장소에 어떤 인증서가 있는지 묻기

Smartphone 2003/ Smartphone 2002 SDK에는 모두 rapiconfig라는 툴이 포함되어 있습니다. Rapiconfig을 통해 스마트폰에서 인증서 저장소를 물어볼 수 있습니다. 2002/2003 SDK에는 모두 querystore.xml라는 예제 파일이 들어 있습니다. 이 문서를 사용해서 스마트폰의 특권(privileged), 비특권(unprivileged), 설치 저장소에 정확히 어떤 인증서가 들어 있는지 물어 볼 수 있습니다. 방법은 다음과 같습니다.

  1. 특권(privileged), 비특권(unprivileged), 설치 저장소를 위해 적절한 .xml 파일을 만듭니다.

  2. . rapiconfig를 사용해 스마트폰에서 정보를 얻습니다.

  3. 스마트폰이 개발을 차단하는지 알아 봅니다.

쿼리 파일 만들기

템플릿 querystore.xml 는 다음과 같습니다.

querystore_priv.xml, querystore_unpriv.xml, querystore_spc.xml 라는 세 개의 문서를 만들어야 합니다. 이름이 중요하지 않습니다만, 이 이름을 예제 동안 계속 사용하게 될 것입니다. SDK Tools directory 에서 querystore.xml를 만들어야 command line tool rapiconfig과 사용하기 쉽습니다.

Notepad나 선호하는 텍스트, XML 편집기 등을 사용해 이 파일들을 편집할 수 있습니다.

...을 위해

...을

...로 대체

Querystore_unpriv.xml

{Enter certificate store name over here}

Unprivileged Execution Trust Authorities

Querystore_priv.xml

{Enter certificate store name over here}

Privileged Execution Trust Authorities

Querystore_spc.xml

{Enter certificate store name over here}

SPC

RAPIConfig 사용하기

SDK의 tools directory 에서 명령 프롬프트를 여는 방법은 Configuring Your Development Environment 섹션을 참조하시기 바랍니다. rapiconfig tool이 2002 과 2003의 경우 약간 다르게 작동됩니다. 2002 버전은 화면으로 출력되며, 2003 버전은 파일로 출력됩니다. 아래의 지침을 따르면 3개의 .xml 파일을 만들 수 있을 것입니다. 각각의 .xml 파일은 저장소의 인증서 목록을 포함하고 있습니다.

Smartphone 2002 

rapiconfig /p querystore_unpriv.xml > unpriv_certs.xml 
rapiconfig /p querystore_priv.xml  > priv_certs.xml 
rapiconfig /p querystore_spc.xml  > spc_certs.xml

Smartphone 2003

rapiconfig /p querystore_unpriv.xml 
copy rapiconfigout.xml priv_certs.xml
rapiconfig /p querystore_priv.xml 
copy rapiconfigout.xml priv_certs.xml
rapiconfig /p querystore_spc.xml 
copy rapiconfigout.xml spc_certs.xml

각각의 인증서 저장소에 인증서 목록을 갖고 있는 세 개의 파일이 만들어졌습니다.

파일

...에 대한 인증서 목록

priv_certs.xml

특권 저장소(privileged store)

priv_certs.xml

비특권 저장소(unprivileged store)

spc_certs.xml

설치 저장소(Installation store)

rapiconfig로부터 에러 메시지를 받으면 다음 섹션을 확인해야 합니다.

스마트폰이 개발을 할 수 없게 잠겨 있다면 어떤 일이 일어나는가

무선 통신 사업자가 스마트폰의 보안을 통제하는 방법 중 하나는 개발자의 개발 머신과 스마트폰의 연결을 허용하지 않는 것입니다. 무선 통신 사업자가 제한적인 정책을 선택했을 경우, 다음과 같은 에러 메시지가 뜨게 됩니다. 

Config failed (0x80070005): Access is denied

이 경우, 무선 통신 사업자에게 연락해서 특정 스마트폰 하드웨어에 대해 개발할 수 있도록 허용하는 개발자를 위한 프로그램이 있는지 문의합니다.

주의   .xml 파일에서 에러가 발생해도 역시 접근 불가 에러 메시지가 나타납니다. 하지만 이 경우 에러 숫자는 0x80042004입니다.

배치를 위한 애플리케이션 서명

애플리케이션에 서명하기 위해서는 목표로 하는 스마트폰이 신뢰하는 디지털 인증서를 얻어야 합니다. 디지털 인증서는 실행하고자 하는 실행 특권 수준(execution privileges level)으로 신뢰를 얻어야 합니다. 즉, privileged trust execution이 필요하다면, 특권(privileged) 인증서로 서명을 받아야 한다는 뜻입니다. Unprivileged trust execution만 필요하다면, 비특권(unprivileged) 인증서로 서명을 받으면 됩니다. 대부분의 애플리케이션의 경우 unprivileged trust execution이면 충분합니다.

인증서 얻기

Mobile2Market은 Windows Mobile 기반 스마트폰의 비특권(unprivileged) 저장소에 있는 모든 인증서를 제공합니다. 애플리케이션 서명을 통해 다양한 종류의 스마트폰에서 작업하고자 한다면, Mobile2Market 참여 방법 섹션의 참여 인증서 벤더에서 인증서를 구입하시면 됩니다.

이 벤더에게서 얻은 인증서는 보통 스마트폰이 신뢰하지 않습니다. 애플리케이션 서명을 위해 인증서를 서명한 뒤, 서명된 애플리케이션을 인증서 벤더에 제출하십시오 (보통 Web interface를 통해). 인증서 벤더는 자동화된 프로세스를 통해 애플리케이션을 스마트폰이 신뢰하는 인증서로 서명하고, 이 애플리케이션을 다운로드 받을 수 있는 링크를 제공합니다. 이 과정을 통해서 벤더는 귀사의 신원을 확인하고 따라서, 스마트폰이 신뢰하는 인증서의 무결성(integrity)이 유지될 수 있습니다.

인증서는 때때로 필수 PIN code와 함께 물리적인 USB로 제공되기도 합니다. 설치하는 방법에 대해서는 벤더측에서 지침을 제공할 것입니다.

애플리케이션과 설치기(Installer) 서명하기

개발을 끝내고 인증서를 받고 난 뒤 애플리케이션 서명을 만들기 위해서는 간단한 다섯 단계만 거치면 됩니다.

  1. 애플리케이션의 실행가능한 컴포넌트를 (.exe 및 .dll) Mobile2Market 인증서 벤더로부터 구입한 인증서로 서명합니다. 이 부분에 대한 지침은 아래에 있습니다.

  2. 애플리케이션의 서명된 컴포넌트를 Web interface를 통해 인증서 벤더에게 제출합니다. 자세한 사항에 대해서는 인증서 벤더에게 문의하십시오. 스마트폰이 신뢰하는 인증서로 서명된 파일을 돌려 받습니다.

  3. 이 컴포넌트를 설치 패키지 파일로(.cab) 만듭니다.

  4. Mobile2Market 벤더에서 구입한 인증서를 사용해 .cab 파일을 서명합니다.

  5. Web interface를 통해 인증서 벤더에 서명된.cab 파일을 제출합니다. 자세한 사항은 인증서 벤더에 문의하시기 바랍니다. .cab 파일을 돌려 받습니다.

이 .cab 파일은 모든 Windows Mobile 기반 스마트폰에 설치될 수 있습니다. 프롬프팅 없이 애플리케이션 자체가 실행될 수 있습니다.

.exe, .dll, .cab 파일을 서명하기 위해서는, Smartphone 2002/Smartphone 2003의 Tools directory에 설치된 signcode.exe tool을 사용해야 합니다. 툴은 모두 동일합니다. 툴을 실행하면 마법사가 나타납니다.

smartphone_security08.gif

그림 8. 디지털   서명   마법사 (Digital Signature Wizard) 열기

Next를 클릭하면, 어떤 파일을 서명할 것인지를 묻는 질문이 나타납니다. 서명 받을 컴포넌트 즉, .exe, .dll, .cab 파일에 대해 각각 툴을 실행합니다. my project의 ARMRel directory에서 my Signing Demo.exe가 선택된 것을 아실 수 있습니다.

smartphone_security09.gif

그림 9. 디지털   서명   마법사 (Digital Signature Wizard) 에서   파일   선택하기

Next를 클릭하면, Typical 또는 Advanced 설정을 할 것인지 묻는 질문이 나타납니다. Typical을 선택하십시오. 다음 화면에서는 서명에 사용할 인증서를 선택하라는 요청이 나타납니다. Select From Store를 선택하면, 인증서 저장소에 있는 인증서 목록이 나타납니다. 지금까지 사용해 온 로컬에서 만든 인증서가 아니라 벤더에서 구입한 인증서를 사용하십시오.

주의   Codesign으로 서명해도 제공업체에서 받은 Signing Event가 사용되지 않습니다. 로컬에서 서명한 애플리케이션을 웹 사이트를 통해 벤더에 제출할 때만 Signing Event가 사용됩니다.

smartphone_security10.gif

그림 10. 서명할 인증서 선택하기

Issued By field 가 인증서를 구입한 회사 이름과 같기 때문에 Mobile2Market 인증서를 쉽게 알아볼 수 있습니다. 예를 들어, Geotrust certificate 인증서를 선택합니다. OK를 클릭하고, Next를 누릅니다.

다음 화면에서는 선택적인 설명 데이터에 대한 질문이 나타납니다. Next를 누르십시오. timestamp을 추가할 필요가 없기 때문에 timestamp 화면에서 Next를 클릭하면 됩니다.

이제 성공적으로 마법사를 마치셨습니다. Finish를 클릭하면, .exe, .dll, .cab이 서명됩니다. 컴포넌트를 서명 벤더에게 제출할 준비가 되었습니다. 벤더 별로 제시하는 지침에 따라 주십시오. 하지만, 일반적으로 웹 사이트에 로그인 하는 방법이 사용되며, ID 확인을 위해 벤더가 보내는 USB 인증서를 사용해야 하는 경우도 있습니다. 로그인한 뒤, 컴포넌트를 업로드하면 스마트폰이 신뢰하는 인증서로 서명 받게 됩니다.

특권(privileged) 접근을 요구하는 애플리케이션 서명

일부 보안 정책으로 특권(privileged) 인증서 저장소에 있는 인증서를 무선 통신 사업자가 소유하는 경우가 있습니다. privileged execution trust가 필요한 경우, 무선 통신 사업자에게 연락해 (때로는 개발자 프로그램을 통해) 어떻게 이 인증서로 애플리케이션을 서명 받는지 알아보시기 바랍니다.

주의   이 서비스를 제공하는 것은 무선 통신사업자의 재량에 달려 있습니다.

결론

스마트폰 애플리케이션 보안 정책과 코드 서명은 처음에는 어렵고 복잡하게 여겨질 수도 있습니다. 하지만, 실제로는 생각보다 간단하며, 본 문서를 통해 스마트폰에 있는 서로 다른 인증서 저장소를 이해하고, 저장소에 인증서를 저장하는 방법, 인증서 배치 시 정확한 인증서로 애프리케이션을 서명하는 방법에 대해 아실 수 있을 것입니다. 이렇게 간단한 기법을 통해 정확한 신뢰 수준(trust level)으로 애플리케이션을 서명할 수 있을 것입니다.

본문의 내용에 대한 의견은 wmsecfbk@microsoft.com로 보내 주시기 바랍니다. .

부록 A: Protected Registry Entry

Registry Keys

HKEY_LOCAL_MACHINE\Comm

HKEY_LOCAL_MACHINE\Drivers

HKEY_LOCAL_MACHINE\HARDWARE

HKEY_LOCAL_MACHINE\SYSTEM

HKEY_LOCAL_MACHINE\Init

HKEY_LOCAL_MACHINE\Security

HKEY_LOCAL_MACHINE\WDMDrivers

HKEY_LOCAL_MACHINE\Services

HKEY CLASSES_ROOT (device specific)

부록 B: 특권(privileged) API 리스트

컴포넌트

APIs

Public

SetInterruptEvent

SetSystemMemoryDivision

CESetThreadPriority

CeSetThreadQuantum

ForcePageout

VirtualCopy

LockPages

UnlockPages

SetProcPermissions

SetKMode

ReadProcessMemory

WriteProcessMemory

SetCleanRebootFlag

PowerOffSystem

DebugActiveProcess

CreateProcess (only the debug flags DEBUG_ONLY_THIS_PROCESS and DEBUG_PROCESS)

KernelIOControl

Extended Telephony Application Program Interface (ExTAPI)

lineRegister

lineSetCallBarringPassword

lineSetCallBarringState

lineUnregister

lineSetPreferredOperator

lineSetEquipmentState

lineGetGeneralInfo

lineManageCalls

lineSetGprsClass

lineGetNumberCalls

lineSetHSCSDState

lineGetUSSD

lineSendUSSD

lineSetSendCallerIDState

lineSetCallWaitingState

SIM Manager

simUnlockPhone

simSetLockingStatus

simGetSmsStorageStatus

simChangeLockingPassword

simReadMessage

simWriteMessage

simDeleteMessage

simReadRecord

simWriteRecord

simGetRecordInfo

Short Message Service

SmsSetMessageNotification

SmsClearMessageNotification

SmsReceiveAllMessagesFromSIM

SmsSetSMSC

Connection Manager

ConnMgrProviderMessage

Critical Process Monitor (CPM)

CPMRegister (Reboot)

CPMShutdown

CPMStatus

CPMRegisterTest

Radio Interface Layer

모든 RIL API

주의    : RIL API에 요구되는 신뢰 수준은 다음의 레지스트리 키의 값이 2에서 1로 변하면 수정될 수 있습니다.

[HKEY_LOCAL_MACHINE\Security\Policy\APIs\RILGSM] @="2"

'Windows > MFC' 카테고리의 다른 글

Intercept SMS Messages In Native Code  (0) 2013.10.02
Sending mail using the Microsoft Windows CE Mail API  (0) 2013.10.02
Windows Mobile POOM Sample Code  (0) 2013.10.02
Windows Mobile Version 5.0 SDK  (0) 2013.10.02
Visual Studio Smart Device Development - Native C++ Project  (0) 2013.10.02

'Windows/MFC' Related Articles

티스토리툴바