권장 보안 정책 — GSM/UMTS

GSM/UMTS 호환 장치에 권장되는 보안 정책

Mobile Information Device Profile 버전 2.0의 부록

본 문서의 범위

본 부록은 정보를 제공하기 위한 것입니다. 그러나 GSM/UMTS 호환 장치에서의 모든 MIDP 2.0 구현은 본 부록의 내용을 준수합니다.

MIDP 2.0은 MIDlet Suite의 소스를 인증하고, 장치에 대한 보안 정책을 바탕으로 요청된 권한을 부여하여 MIDlet Suite가 보호된 기능을 수행할 수 있도록 인증하는 프레임워크를 정의합니다. 또한, 보안에 취약한 기능을 식별하고 보호된 기능에 대한 사용 권한을 정의합니다. MIDP 2.0은 MIDP와 함께 사용할 수 있지만 MIDP와 별도로 지정되는 API에 대한 일반 규칙도 지정합니다. MIDP 2.0 사양은 단일 신뢰 모델을 규정하는 대신, 모델이 장치 트러스트 정책을 준수할 수 있도록 합니다.

본 부록은 MIDP 2.0에 정의된 기본 MIDlet Suite 보안 프레임워크를 확장하여 다음 영역을 정의하는 것을 목적으로 합니다.

GSM/UMTS 호환 장치에 요구되는 신뢰 모델
장치 보안 정책에 명시된 도메인 번호와 구조
장치 외부의 소스로부터 루트 키를 읽는 기법
MIDP 2.0 및 다른 JSR에 의해 정의된 권한에 따른 MIDlet의 기능
로밍 네트워크에서의 MIDlet 동작
SIM/USIM 변경 시의 MIDlet 동작
사용자 권한 유형의 사용
사용자 프롬프트 및 알림에 대한 지침

본 사양의 구성 방법

본 사양은 다음과 같이 구성되어 있습니다.

2절에서 4절까지는 장치 보안 정책, 다른 보호 도메인 및 스마트 카드의 인증서 저장과 관련된 요구 사항 간의 관계에 대해 규정합니다. 5절에서는 기능 그룹을 지정하고, MIDP 2.0 보안 프레임워크를 사용하여 보호해야 하는 API 및 권한을 식별합니다. 6절과 7절에서는 권한이 부여될 때 준수해야 하는 규칙과 사용자 알림에 대한 요구 사항을 지정합니다. 마지막으로 8절에서는 로밍 중 및 스마트 카드 변경 후의 MIDlet 동작을 지정합니다.

참조 자료

Connected Limited Device Configuration (CLDC)
http://jcp.org/jsr/detail/30.jsp
Mobile Information Device Profile (MIDP) 2.0
http://jcp.org/jsr/detail/118.jsp
HTTP 1.1 Specification
http://www.ietf.org/rfc/rfc2616.txt
WAP Wireless Identity Module Specification (WIM) WAP-260-WIM-20010712-a
http://www.wapforum.org/what/technical.htm
WAP Smart Card Provisioning (SCPROV) WAP-186-ProvSC-20010710-a
http://www.wapforum.org/what/technical.htm
PKCS#15 v.1.1
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-15/
USIM, 3GPP TS 31.102: “Characteristics of the USIM applications”
http://www.3gpp.org
RFC3280
http://www.ietf.org/rfc

1 일반 사항

이 권장 보안 정책을 구현하는 GSM/UMTS 호환 장치는 MIDP 2.0에 규정된 보안 프레임워크를 준수해야 합니다. 또한, 신뢰할 수 있는 MIDlet을 지원하는 장치는 MIDP 2.0 사양에 정의된 PKI 기반의 인증 체계를 따라야 합니다.

2 장치 보안 정책에서의 보호 도메인

도메인은 MIDlet Suite를 서명한 엔티티에 따라 다운로드한 MIDlet Suite를 구분하고, MIDlet Suite에 특정 권한 집합을 부여하거나 허용하는 방법입니다. 도메인은 보호 도메인 루트 인증서를 특정 권한 집합에 바인드합니다. 권한은 보호 도메인 보안 정책에서 규정되며 장치에서 사용할 수 있는 보호 도메인 개수만큼의 항목이 정책에 포함됩니다. id-kp-codeSigning 확장 키 사용 확장자가 포함된 보호 도메인 루트 인증서가 있어야만 도메인으로 인정됩니다. 신뢰할 수 있는 보호 도메인 루트 인증서를 인증하는 MIDlet Suite는 신뢰할 수 있는 것으로 간주되어 해당 보호 도메인에 할당됩니다. MIDlet Suite는 두 개 이상의 보호 도메인에 속할 수 없습니다. 도메인과 해당 보안 정책을 나타내는 방법은 구현별로 달라집니다.

3 보호 도메인 및 권한 프레임워크

본 문서에서는 응용 프로그램이 실행하는 보호 도메인에 따라 MIDP 권한 프레임워크를 어떻게 사용해야 하는지에 관해 두 가지 요구 사항을 규정합니다.

제조업체 및 운영자 도메인 - MIDlet Suite는 보안에 취약한 API 및 기능에 액세스할 때 사용자로부터 권한을 받는 것이 좋습니다. MIDP 2.0 및 다른 API에 의해 정의된 권한은 어떤 기능이 보안에 취약하며 보호해야 하는지에 대한 지침을 제공합니다. 운영자가 신뢰할 수 있는 MIDlet은 보안상 보호된 이러한 기능에 액세스할 때 필요하면 사용자에게 지속적으로 프롬프트와 알림을 표시합니다.

타사 및 신뢰할 수 없는 도메인 - 장치 구현 시 본 문서의 표 1 - 표 6에 규정된 보안 정책에 따라 사용자에게 메시지를 표시해야 합니다.

3.1 제조업체 도메인

신뢰할 수 있는 제조업체 보호 도메인 루트 인증서는 제조업체 MIDlet Suite를 확인하는 데 사용됩니다. 제조업체 보호 도메인 루트 인증서는 장치상의 제조업체 도메인 보안 정책에 매핑해야 합니다. 장치는 제조업체 도메인의 보안 정책을 지원해야 합니다.

장치에서 제조업체 보호 도메인 루트 인증서를 사용할 수 없으면 제조업체 도메인을 사용할 수 없게 해야 합니다.

제조업체 보호 도메인 루트 인증서는 해당 제조업체만 삭제 또는 수정할 수 있습니다. 제조업체는 세부 정보가 본 사양의 범위에서 벗어나는 업데이트 기법을 사용할 수도 있습니다. 새로 작성되었거나 업데이트된 제조업체 보호 도메인 루트 인증서는 장치상의 제조업체 도메인 보안 정책에 연결해야 하며, 이전의 제조업체 보호 도메인 루트 인증서로 확인된 MIDlet Suite는 사용할 수 없게 해야 합니다.

제조업체 도메인에서의 권한은 모두 허용으로 표시됩니다(정의는 MIDP 2.0 참조). 제조업체 도메인에서 허용으로 권한을 부여한 경우 다운로드하여 인증된 제조업체 MIDlet Suite는 사용자 확인이 필요한 이벤트가 발생할 때마다 사용자에게 메시지 표시 및 보안과 관련하여 제조업체에서 미리 설치한 MIDlet Suite와 일관되게 작동합니다. 제조업체 MIDlet은 보안에 취약한 API 및 기능에 액세스할 때 사용자로부터 권한을 받는 것이 좋습니다. MIDP 2.0 및 다른 API에 의해 정의된 권한은 어떤 기능이 보안에 취약하며 보호해야 하는지에 대한 지침을 제공합니다.

MIDlet Suite 설치에서는 제조업체 보호 도메인 루트 인증서의 제목 필드에 조직 및 국가 필드가 있을 경우 구현 시 사용자에게 조직 및 국가 필드를 제공해야 합니다. 조직 및 국가 필드가 없으면 구현 시 사용자에게 제목 필드의 다른 해당 정보를 제공해야 합니다. 구현 시 제목 필드에 있는 조직 및 국가 필드 이외의 추가 정보를 항상 사용자에게 제공할 수도 있습니다. 이 사용자 알림은 응용 프로그램 설치 시 표시되어야 합니다.

제조업체 도메인은 MIDP 2.0 및 다른 JSR에 규정된 기능에 대해 어떤 제한도 두지 않습니다.

3.2 운영자 도메인

신뢰할 수 있는 운영자 보호 도메인 루트 인증서는 운영자 MIDlet Suite를 확인하는 데 사용됩니다. SIM, USIM 또는 WIM의 지정된 위치에서 사용 가능한 신뢰할 수 있는 운영자 보호 도메인 루트 인증서의 수에는 어떠한 명시적 제한도 없습니다. 신뢰할 수 있는 운영자 보호 도메인 루트 인증서는 장치상의 운영자 도메인 보안 정책에 매핑해야 합니다. 장치는 운영자 도메인의 보안 정책을 지원해야 합니다.

SIM, USIM 또는 WIM의 지정된 위치에서 운영자 보호 도메인 루트 인증서를 사용할 수 없으면 운영자 도메인을 사용할 수 없게 해야 합니다.

신뢰할 수 있는 보호 도메인 루트 인증서는 신뢰할 수 있는 인증서 [WIM]의 Certificate Directory File (CDF)에서 읽어옵니다. WIM상의 trustedCertificates 파일에 있는 보호 도메인 루트 인증서는 인증서 [PKCS#15]와 연결된 CommonCertificateAttributes의 trustedUsage 필드에 따라 운영자 도메인이나 신뢰할 수 있는 타사 도메인으로 매핑됩니다.

trustedUsage 필드가 있으며 키 사용 OID “iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operator(1)“가 포함되어 있으면 이 인증서는 운영자 도메인으로 매핑됩니다.

trustedUsage 필드가 없거나 키 사용 “운영자 도메인”의 OID가 포함되어 있지 않으면 인증서는 신뢰할 수 있는 타사 도메인으로 매핑됩니다.

운영자가 신뢰할 수 있는 보호 도메인 루트 인증서는 WIM, SIM 또는 USIM의 trustedCertificates Certificate Directory File (CDF)에 놓일 수 있습니다. 운영자 보호 도메인 루트 인증서가 WIM 응용 프로그램 아래가 아닌 SIM 또는 USIM에 직접 저장되는 경우에는 [SCPROV]에 정의된 것처럼 DF(PKCS#15) 아래에 있는 EF trustedCertificates CDF에 저장될 것입니다. 운영자 보호 도메인 루트 인증서는 신뢰할 수 있는 CDF(카드 소유자는 이 디렉토리를 업데이트할 수 없음)에서만 가져올 수 있으며, 스마트 카드의 다른 디렉토리에서는 운영자 루트 인증서를 가져올 수 없습니다.

신뢰할 수 있는 모든 운영자 보호 도메인 루트 인증서는 장치상의 동일한 운영자 도메인 보안 정책에 매핑해야 합니다. 운영자 도메인은 사용자나 타사에서 삭제 또는 수정할 수 없으며, 장치에 지정된 기능에 의해서만 삭제 또는 수정될 수 있습니다.

MIDlet Suite가 운영자 보호 도메인 루트 인증서로 인증된 경우 서명 및 인증된 MIDlet Suite에는 운영자 도메인에 대한 권한이 부여되어야 합니다. 운영자 루트 공개 키는 현재 삽입되어 사용 가능한 스마트 카드의 신뢰할 수 있는 CDF의 인증서에서 가져와야 하며, 스마트 카드 또는 장치의 다른 위치에서 가져올 수 없습니다. MIDlet Suite 설치에서는 운영자 보호 도메인 루트 인증서의 제목 필드에 조직 및 국가 필드가 있을 경우 구현 시 사용자에게 조직 및 국가 필드를 제공해야 합니다. 조직 및 국가 필드가 없으면 구현 시 사용자에게 제목 필드의 다른 해당 정보를 제공해야 합니다. 구현 시 제목 필드에 있는 조직 및 국가 필드 이외의 추가 정보를 항상 사용자에게 제공할 수도 있습니다. 이 사용자 알림은 응용 프로그램 설치 시 표시되어야 합니다.

운영자 도메인의 보안 정책에는 장치상에 “허용”으로 구현된 모든 권한이 포함되어 있어야 합니다. 운영자 도메인에서 허용으로 권한을 부여한 경우 다운로드하여 인증된 운영자 MIDlet Suite는 사용자 확인이 필요한 이벤트가 발생할 때마다 사용자에게 메시지 표시 및 보안과 관련하여 운영자가 설치한 다른 MIDlet Suite와 일관되게 작동합니다. 운영자 MIDlet은 보안에 취약한 API 및 기능에 액세스할 때 사용자로부터 권한을 받는 것이 좋습니다. MIDP 2.0 및 다른 API에 의해 정의된 권한은 어떤 API 및 기능이 보안에 취약하며 보호해야 하는지에 대한 지침을 제공합니다. 운영자 도메인은 MIDP 2.0 및 다른 JSR에 규정된 기능에 대해 어떤 제한도 두지 않습니다.

운영자 도메인에 설치된 MIDlet Suite는 응용 프로그램 서명에 사용되는 서명 인증서를 발급하는 보호 도메인 루트 인증서 해시를 응용 프로그램과 함께 저장해야 합니다. 사용되는 해시 알고리즘은 보호 도메인 루트 인증서부터 시작하여 해당 인증서의 BIT STRING subjectPublicKey 값의 20바이트 SHA-1 해시(태그, 길이 및 사용하지 않은 비트 수 제외)를 계산해야 합니다. 이 방법은 일반적으로 키 식별자를 계산하는 데 사용되며, 특히 신뢰 체인 구축 [RFC3280, §4.2.1.2]를 가속화합니다. 구현 시에는 최적화를 위해 X.509 키 식별자나 PKCS#15 레이블을 올바른 값으로 가정해서는 안 되며 해시 자체를 계산해야 합니다. 장치는 이 해시를 사용하여 8절에 규정된 대로 언제 지정된 MIDlet Suite를 사용할 수 없게 해야 하는지 결정해야 합니다.

3.3 신뢰할 수 있는 타사 도메인

신뢰할 수 있는 타사 보호 도메인 루트 인증서는 타사 MIDlet Suite를 확인하는 데 사용됩니다. 장치상이나 SIM, USIM 또는 WIM의 지정된 위치에서 사용 가능한 신뢰할 수 있는 타사 보호 도메인 루트 인증서의 수에는 어떠한 명시적 제한도 없습니다(3.2절 참조). 신뢰할 수 있는 타사 보호 도메인 루트 인증서는 장치상의 신뢰할 수 있는 타사 도메인 보안 정책에 매핑해야 합니다. 장치는 신뢰할 수 있는 타사 도메인의 보안 정책을 지원해야 합니다. 장치상이나 SIM, USIM 또는 WIM의 지정된 위치에서 신뢰할 수 있는 타사 보호 도메인 루트 인증서를 사용할 수 없으면 신뢰할 수 있는 타사 도메인을 사용할 수 없게 해야 합니다.

장치 제조 후에 다운로드한 타사 보호 도메인 루트 인증서는 MIDlet Suite 인증에 사용해서는 안 됩니다. 그렇다고 해서 SIM, USIM 또는 WIM의 지정된 위치에서 신뢰할 수 있는 타사 보호 도메인 루트 인증서를 가져오는 것이 차단되지는 않습니다.

MIDlet Suite 설치에서는 MIDlet Suite 서명 인증서의 제목 필드에 조직 및 국가 필드가 있을 경우 구현 시 사용자에게 조직 및 국가 필드를 제공해야 합니다. 조직 및 국가 필드가 없으면 구현 시 사용자에게 제목 필드의 다른 해당 정보를 제공해야 합니다. 구현 시 제목 필드에 있는 조직 및 국가 필드 이외의 추가 정보를 항상 사용자에게 제공할 수도 있습니다. 이 사용자 알림은 MIDlet Suite 설치 시 표시되어야 합니다. 응용 프로그램에 권한을 부여하라는 메시지를 사용자에게 표시할 경우 프롬프트는 위에서 설명한 것처럼 서명 인증서의 제목 필드에 있는 해당 필드를 사용하여 신뢰할 수 있는 소스를 식별해야 합니다.

사용자는 신뢰할 수 있는 타사 보호 도메인 루트 인증서를 삭제하거나 사용 불가능하게 할 수 있어야 합니다. 구현 시 타사 보호 도메인 루트 인증서를 삭제할 경우의 결과에 대해 사용자에게 경고하는 것이 좋습니다. 사용자는 사용할 수 없는 타사 보호 도메인 루트 인증서를 사용 가능하게 할 수 있어야 합니다. 사용할 수 없는 타사 보호 도메인 루트 인증서를 사용하여 다운로드한 MIDlet Suite를 확인해서는 안 됩니다. 또한, 타사 보호 도메인 루트 인증서가 삭제 또는 사용 불가능하게 된 경우(예: 사용자가 철회, 삭제 또는 사용 불가능하게 한 경우) 타사 도메인이 더 이상 이 보호 도메인 루트 인증서에 연결되어서는 안 됩니다. 사용자가 보호 도메인 루트 인증서를 삭제하거나 사용할 수 없도록 선택하면 구현 시 이 루트 인증서를 인증한 MIDlet Suite를 삭제할 수 있는 옵션을 제공해야 합니다.

신뢰할 수 있는 타사 도메인의 보안 정책에는 장치상에 “허용”으로 구현된 권한을 부여해서는 안 됩니다. 타사 도메인에서 부여된 모든 권한은 사용자 권한이어야 하므로 권한을 부여하려면 사용자 상호 작용이 필요합니다. 표 1에서는 타사 도메인의 MIDlet Suite에 사용할 수 있는 사용자 권한 유형과 기능 그룹을 규정합니다. 표 2 - 표 6에서는 권한과 API의 다른 기능 그룹으로의 매핑에 대해 지정합니다.

3.4 신뢰할 수 없는 도메인

서명되지 않은 MIDlet Suite는 신뢰할 수 없는 도메인에 속하게 됩니다. 구현 시에는 신뢰할 수 없는 도메인에 새로운 MIDlet Suite가 설치될 때마다 사용자에게 이를 알려야 합니다. 알림은 응용 프로그램이 신뢰할 수 있는 도메인에서 온 것이 아님을 명확히 해야 합니다. 사용자는 응용 프로그램에 권한을 부여하기 전에 사용 가능한 정보에 따라 올바른 결정을 내릴 수 있어야 합니다.

응용 프로그램에 권한을 부여하라는 메시지를 사용자에게 표시할 경우 프롬프트는 응용 프로그램이 신뢰할 수 있는 도메인에서 온 것이 아님을 명확히 해야 합니다.

신뢰할 수 없는 MIDlet Suite는 JSR 075에 정의된 API(5절의 표 1과 표 3 참조)를 통해 PIM 데이터에 대한 읽기 액세스 권한을 직접 부여 받아서는 안 됩니다. 그러나 javax.microedition.lcdui package를 구현하여 신뢰할 수 없는 응용 프로그램과 PIM 데이터 간의 상호 작용을 사용 가능하게 할 수 있습니다. 응용 프로그램 프로그래머가 제약 조건 TextField.PHONENUMBER를 설정하면 TextField 클래스의 구현 시 사용자가 자신의 전화번호부에서 번호를 조회하여 TextField 항목에 복사하도록 제안할 수도 있습니다. 예를 들어, TextField 항목에 입력 포커스가 있으면 사용자는 메뉴를 사용하여 전화번호부에 들어갈 수 있습니다. 사용자가 전화번호부에서 항목을 선택하면 선택한 항목의 내용이 TextField 항목에 “복사”됩니다.

표 1에서는 신뢰할 수 없는 도메인의 MIDlet Suite에 사용할 수 있는 사용자 권한과 기능 그룹을 규정합니다. 표 2 - 표 6에서는 권한과 API의 다른 기능 그룹으로의 매핑에 대해 지정합니다.

4 원격 보안 정책

MIDP 2.0 사양은 이동식 미디어에서 읽을 수 있는 정책 파일의 일반 형식을 정의합니다. 첫 단계에서는 GSM/UMTS 호환 장치가 이 정책 파일을 사용하는 것이 아니라 장치에 있는 보안 정책을 사용합니다. 원격 보안 정책 파일의 가능성은 추후에 다시 고려해야 할 사항입니다.

5 다운로드한 MIDlet Suite의 권한

5.1 MIDP 2.0 권한의 보호된 도메인 기능 그룹으로의 매핑

작은 디스플레이를 가진 장치는 단일 구성 설정 메뉴를 통해 사용자에게 친숙한 방식으로 모든 권한을 사용자에게 표시하지 못할 수도 있습니다. 따라서 장치는 모든 권한을 표시하여 사용자 확인을 받을 필요가 없습니다. 하지만 보호된 기능에 의해 시작된 고급 수준의 특정 작업은 사용자 승인을 받아야 합니다. 사용자에게 표시되는 고급 기능은 궁극적으로 각 기본 권한의 작업과 결과를 반영합니다. 다음과 같은 기능 그룹이 있습니다.

네트워크/비용 관련 그룹:

전화 걸기 - 전화 통화를 발생시키는 모든 기능에 대한 권한을 나타냅니다.

네트 액세스 - 활성 네트워크 데이터 연결을 발생시키는 모든 기능(예: GSM, GPRS, UMTS 등)에 대한 권한을 나타냅니다. 이러한 기능은 이 그룹에 매핑해야 합니다.

메시징 - 메시지 전송 또는 수신을 허용하는 모든 기능(예: SMS, MMS 등)에 대한 권한을 나타냅니다.

응용 프로그램 자동 호출 - MIDlet Suite를 자동으로 호출할 수 있도록 하는 모든 기능(예: 푸시, 시간 제한 MIDlet 등)에 대한 권한을 나타냅니다.

로컬 연결 - 추가 연결을 위해 로컬 포트를 활성화하는 모든 기능(예: COMM 포트, IrDa, Bluetooth 등)에 대한 권한을 나타냅니다.

사용자 프라이버시 관련 그룹:

멀티미디어 레코딩 - MIDlet Suite에서 스틸 이미지를 캡처하거나 비디오 또는 오디오 클립을 레코딩할 수 있도록 지원하는 모든 기능에 대한 권한을 나타냅니다.

사용자 데이터 읽기 액세스 - MIDlet Suite에서 사용자의 전화번호부나 파일 또는 디렉토리의 다른 모든 데이터를 읽을 수 있도록 지원하는 모든 기능에 대한 권한을 나타냅니다.

사용자 데이터 쓰기 액세스 - MIDlet Suite에서 사용자의 전화번호부나 파일 또는 디렉토리의 다른 모든 데이터를 추가하거나 수정할 수 있도록 지원하는 모든 기능에 대한 권한을 나타냅니다.

새로운 기능이 MIDP에 추가되면 해당 기능 그룹에 이 기능을 할당해야 합니다. 또한, 다른 JSR에서 지정되었지만 MIDP 보안 프레임워크를 사용하는 API도 해당 기능 그룹에 할당해야 합니다. 그러나 이 절에 정의된 기능 그룹 중에서 새 기능을 사용자에게 적절하게 표시할 수 있는 그룹이 없으면 본 문서에서 새 기능 그룹을 정의해야 합니다.

새로운 기능 그룹을 추가할 경우 다음을 고려해야 합니다. 이 그룹을 추가함으로써 기존 그룹이 중복되지 않아야 하며, 새 그룹이 다양한 유사 기능을 보호할 수 있어야 합니다. 두 번째 요구 사항은 좁은 범위의 그룹이 생기지 않도록 방지합니다.

사용자에게 메시지를 표시할 때는 개별 권한이 아닌 기능 그룹을 제공해야 합니다. 또한, 지정된 MIDlet Suite의 설정에서 사용자에게 제공해야 하는 것도 기능 그룹입니다.

표 1에는 MIDP 2.0에 정의된 보안 프레임워크를 사용하여 시행해야 하는 정책이 나와 있습니다. 이 표에서는 정의된 각 기능 그룹에 사용할 수 있는 권한 설정을 규정합니다. 처음 MIDlet Suite를 호출할 때 적용되며 사용자가 MIDlet Suite 구성 메뉴에서 변경할 때까지 계속 유효한 설정을 “기본 설정”이라고 합니다. 사용자가 구성 메뉴에서 선택하여 기본 설정을 바꿀 수 있는 설정을 “기타 설정”이라고 합니다. 기본 설정과 기타 설정이 MIDlet Suite에 사용할 수 있는 구성 설정 풀을 형성합니다. 각 기능 그룹과 보호 도메인에 기본 설정과 기타 설정이 제공됩니다. 기능 그룹의 이름은 구현별로 다르지만 본 문서에 정의된 기능 그룹 이름에 대한 지침과 이러한 그룹 정의를 따라야 합니다.

표 2 - 표 5에서는 MIDP 2.0과 다른 JSR에 정의된 각 권한을 보여주며 이 절에 지정된 기능 그룹에 매핑합니다. 각 권한은 한 개의 기능 그룹에만 사용되어야 합니다.

제조업체 및 운영자가 신뢰할 수 있는 MIDlet Suite는 표에 정의된 권한 지침을 준수하고, 보안상 보호된 기능을 식별할 수 있도록 사용자에게 적절한 프롬프트를 제공하는 것이 좋습니다.

장치는 단일 구성 설정 집합(기본 설정 또는 기타 설정)을 단일 MIDlet Suite는 물론 지정된 서명자의 모든 MIDlet Suite에 적용함으로써 사용자 환경을 향상시키고 단순화할 수 있습니다. 이 옵션으로 인해 표 1에 정의된 기능 그룹과 사용 가능한 설정이 손상되어서는 안 됩니다. 이러한 옵션이 있을 경우 사용자는 설정을 저장하여 나중에 동일한 소스의 MIDlet Suite에 다시 사용하라는 메시지를 받게 됩니다. 이러한 기능은 사용자에게 지정된 소스가 이미 승인되었으며 저장된 구성 설정에 대한 별칭이 있다는 것을 알려줄 수도 있습니다. 신뢰할 수 있거나 신뢰할 수 없는 각 응용 프로그램에 대해 구현 시 MIDlet-Permissions 및 MIDlet-PermissionsOpt 속성에서 요청된 권한을 읽고, 응용 프로그램에 필요한 기능을 사용자에게 알려주며, 사용자에게 응용 프로그램 설치를 승인 또는 거부하라는 메시지를 표시할 수 있습니다.

일부 기능 그룹 조합에 블랭킷 권한을 부여할 경우 사용자에게 더 큰 위험을 초래할 수 있습니다. 타사 도메인에 있는 MIDlet Suite의 경우 사용자에게 위험이 크다는 것을 알려야 하며, 사용자가 이러한 조합을 설정하기 위해 위험을 감수하겠다고 승인해야 합니다. 이러한 경우에 해당하는 기능 그룹의 블랭킷 권한 조합은 다음과 같습니다.

네트 액세스, 메시징 또는 로컬 연결 중 하나가 블랭킷으로 설정되어 있으며, 멀티미디어 레코딩 또는 사용자 데이터 읽기 액세스가 블랭킷으로 설정되어 있는 조합

신뢰할 수 없는 도메인에는 이러한 조합이 표 1에 따라 금지되기 때문에 이 제한이 적용되지 않습니다.

또한, 응용 프로그램 자동 호출의 블랭킷 설정과 네트 액세스의 블랭킷 설정은 상호 배타적입니다. 이 제약 조건은 MIDlet Suite가 자신을 자동 호출한 다음, 보호 하에 있어야 할 네트워크를 사용자도 모르게 액세스할 수 없도록 차단합니다. 사용자가 응용 프로그램 자동 호출이나 네트워크 기능 그룹 중 하나가 이미 “블랭킷” 모드로 설정되어 있을 때 다른 하나를 “블랭킷”으로 설정하려고 시도하면 어떤 기능 그룹에 “블랭킷”을 부여하고 어떤 기능 그룹에 “세션”을 부여할지에 관해 사용자에게 메시지를 표시해야 합니다.

전화 걸기 및 메시징 작업의 경우 구현 시 사용자가 작업을 승인하기 전에 사용자에게 대상 전화 번호를 표시해야 합니다. 메시징 그룹의 경우, 구현 시 단일 API 호출을 두 개 이상의 메시지에 매핑하면(즉, 구현 시 역어셈블리/재어셈블리를 지원하면) 실제로 전송되는 메시지 수를 사용자에게 표시해야 합니다. 이 요구 사항은 어떤 API 호출이 관련되어 있든 간에 사용자가 항상 프로그램 실행을 위한 네트워크 비용을 이해할 수 있도록 하기 위한 것입니다.

표 3: 기능 그룹에 PDA 프로필의 개인 정보 관리 패키지에 규정된 API 호출 및 제안된 권한 할당| PDAP PIM 패키지 API (JSR75) | | | | 보안 정책 식별자(제안된 권한) | 허용되는 Java API 호출 | 기능 그룹 | | javax.microedition.pim.PIM. contact.readonly | PIM.listContactLists() PIM.openContactList(READ_ONLY) PIM.openContactList(READ_ONLY, listName) | 사용자 데이터 읽기 액세스 | | javax.microedition.pim.PIM. contact.readwrite | PIM.listContactLists() PIM.openContactList(READ_ONLY) PIM.openContactList(READ_WRITE) PIM.openContactList(READ_ONLY, listName) PIM.openContactList(READ_WRITE, listName) | 사용자 데이터 쓰기 액세스 | | javax.microedition.pim.PIM. event.readonly | PIM.listEventLists() PIM.openEventList(READ_ONLY) PIM.openEventList(READ_ONLY, listName) | 사용자 데이터 읽기 액세스 | | javax.microedition.pim.PIM. event.readwrite | PIM.listEventLists() PIM.openEventList(READ_ONLY) PIM.openEventList(READ_WRITE) PIM.openEventList(READ_ONLY, listName) PIM.openEventList(READ_WRITE, listName) | 사용자 데이터 쓰기 액세스 | | javax.microedition.pim.PIM. todo.readonly | PIM.listToDoLists() PIM.openToDoList(READ_ONLY) PIM.openToDoList(READ_ONLY, listName) | 사용자 데이터 읽기 액세스 | | javax.microedition.pim.PIM. todo.readwrite | PIM.listToDoLists() PIM.openToDoList(READ_ONLY) PIM.openToDoList(READ_WRITE) PIM.openToDoList(READ_ONLY, listName) PIM.openToDoList(READ_WRITE, listName) | 사용자 데이터 쓰기 액세스 |

표 3 편집자 주: PIM 패키지에서는 PIM API를 보호하는 데 필요한 권한을 규정하지 않습니다. 이러한 변경 사항이 PIM API 패키지에 통합되면 이 표의 내용도 업데이트될 것입니다.

구현 시에는 이러한 기능에 대한 응용 프로그램 액세스를 허용하기 전에 응용 프로그램이 액세스할 수 있는 사용자 데이터의 속성(예: 이벤트 또는 할 일 목록)을 사용자에게 알려줘야 합니다. MIDlet이 원샷 권한 유형의 PIM 항목을 추가, 삭제 또는 업데이트할 때마다 이를 표시하여 사용자 확인을 받아야 합니다.

표 4: 기능 그룹에 Bluetooth API에 규정된 API 호출 및 제안된 권한 할당| Bluetooth API-JSR 82 | | | | 보안 정책 식별자(제안된 권한) | 허용되는 API 호출 | 기능 그룹 | | javax.microedition.io.Connector.bluetooth.client | Connector.open(“btspp://<server BD_ADDR>…”) Connector.open(“btl2cap://<server BD_ADDR>…”) | 로컬 연결 | | javax.microedition.io.Connector.obex.client | Connector.open(“btgoep://<server BD_ADDR>…”) Connector.open(“irdaobex://discover…”) Connector.open(“irdaobex://addr…”) Connector.open(“irdaobex://conn…”) Connector.open(“irdaobex://name…”) | 로컬 연결 | | javax.microedition.io.Connector.obex.client.tcp | Connector.open(“tcpobex://<server IP_ADDR>…”) | 네트 액세스 | | javax.microedition.io.Connector.bluetooth.server | Connector.open(“btspp://localhost:…”) Connector.open(“btl2cap://localhost:…”) | 로컬 연결 | | javax.microedition.io.Connector.obex.server | Connector.open(“btgoep://localhost:…”) Connector.open(“irdaobex://localhost:…”) | 로컬 연결 | | javax.microedition.io.Connector.obex.server.tcp | Connector.open(“tcpobex://:”) Connector.open(“tcpobex://”) | 네트 액세스 |

표 4 편집자 주: Bluetooth API에 제안된 권한은 아직 JSR82에 정의되어 있지 않습니다.

표 5: 기능 그룹에 무선 메시징 API에 규정된 API 호출 및 제안된 권한 할당| 무선 메시징 API -JSR 120 | | | | 보안 정책 식별자(제안된 권한) | 허용되는 API 호출 | 기능 그룹 | | javax.microedition.io.Connector.sms.send | Connector.open(“sms://…”, WRITE) Connector.open(“sms://…”, WRITE, Bool) | 메시징 | | javax.microedition.io.Connector.sms.receive | Connector.open(“sms://…”, READ) Connector.open(“sms://…”, READ, Bool) | 메시징 | | javax.microedition.io.Connector.sms | Connector.open(“sms://…”) Connector.open(“sms://…”, READ) Connector.open(“sms://…”, READ, Bool) Connector.open(“sms://…”, WRITE) Connector.open(“sms://…”, WRITE, Bool) Connector.open(“sms://…”, READ_WRITE) Connector.open(“sms://…”, READ_WRITE, Bool) | 메시징 | | javax.microedition.io.Connector.cbs.receive | Connector.open(“cbs://…”) Connector.open(“cbs://…”, READ) Connector.open(“cbs://…”, READ, Bool) | 메시징 |

표 5 편집자 주: 무선 메시징 API에 제안된 권한은 아직 JSR120에 정의되어 있지 않습니다.

표 6 편집자 주: 모바일 미디어 API에 제안된 권한은 아직 JSR135에 정의되어 있지 않습니다.

구현 시 모바일 미디어 API에서의 I/O 액세스가 javax.microedition.io의 패키지 설명서에 명시된 것처럼 일반 연결 프레임워크와 동일한 보안 요구 사항을 따라야 합니다. 예를 들어, javax.microedition.media.Player.start, javax.microedition.media.Player.prefetch 등의 메소드가 있습니다. 이러한 메소드를 사용하여 HTTP 연결을 통해 플레이어의 컨텐트를 가져올 경우에는 구현 시 HTTP에 대해 규정된 보안 요구 사항을 시행해야 합니다.

5.2 구현 시 참고 사항:

사용자가 기능 그룹에 권한을 부여하면 이 기능 그룹 하의 모든 개별 권한에 대한 액세스가 부여됩니다.

구현 시에는 호출자에게 적절한 보안 권한이 없을 경우 보안 예외를 발생시키도록 해야 합니다.

메시징 그룹에 원샷 권한을 부여하면 javax.microedition.io.Connector.sms 및 javax.microedition.io.Connector.cbs의 블랭킷 권한과 메시지 수신을 사용 가능하게 하는 권한으로 변환됩니다. 하지만 메시지 전송 권한은 여전히 원샷입니다. 즉, 사용자는 열려 있는 연결 내에서 MIDlet Suite가 전송하는 각 메시지에 권한을 부여합니다. 세션 권한의 경우도 마찬가지입니다. 메시지 전송과 관련된 기능에는 세션 권한이 부여되지만 다른 기능은 블랭킷 권한을 부여 받습니다. 메시징 그룹에 블랭킷 권한과 권한 없음을 부여할 경우 이 그룹 하의 모든 개별 권한에 적용됩니다.

MIDlet이 MIDP 및 다른 API에 정의된 기능을 사용할 경우 다음 규칙을 적용해야 합니다.

MIDP 2.0 보안 프레임워크에서 보호해야 하는 모든 외부 API 함수는 후속 JSR에 권한이 정의되어 있어야 하며 MIDP 2.0 사양인 “Security for MIDP Applications”에 규정된 이름 지정 규칙을 따라야 합니다.
사양에서 보안상 보호해야 하는 기능으로 분류되지 않은 기능은 일반 MIDP 보안 규칙에 따라 신뢰할 수 있는 MIDlet Suite와 신뢰할 수 없는 MIDlet Suite가 모두 명시적으로 액세스할 수 있습니다.
API 사양이 MIDP 2.0보다 이전에 출시되어 외부 API에 보안상 보호된 기능에 대한 권한이 정의되어 있지 않은 경우에도 네트워크 액세스와 관련된 모든 기능에 장치에서 구현된 사용자 프롬프트가 있어야 합니다.
장치는 적절한 사용자 알림 없이 네트워크에 액세스할 수 없습니다.
모든 개방형 클래스는 본 문서에 정의된 권한 프레임워크를 준수해야 합니다.

6 권한 부여 기법에 의해 MIDlet Suite에 부여된 권한

MIDP 2.0 사양의 “Security for MIDP Applications” 절에 정의된 것처럼 MIDlet Suite 권한은 실제로 JSR 상세 목록에 있는 도메인 권한 Midlet-Permission과 Midlet-Permission-Opt의 교집합입니다. 부여된 MIDlet Suite의 권한을 사용자에게 제공하는 방법은 구현별로 다르지만 다음 규칙을 적용해야 합니다.

5절의 표에 규정된 사용자 권한 유형의 기본 집합과 사용 가능한 집합을 바탕으로, 사용자는 기본 권한 설정(5.2절의 구현 시 참고 사항을 따르는 경우)을 지정된 MIDlet Suite 권한에 사용 가능한 어떤 설정으로든 변경할 수 있어야 합니다. 이러한 유연성을 통해 사용자는 필요에 따라 기본 권한을 상향 조정하거나 하향 조정할 수 있습니다.
MIDlet 권한이 해당 기능에 따라 그룹화되어 있으면 MIDlet Suite에 부여된 권한은 기능 그룹으로 구성되어 사용자에게 표시됩니다. 기능 그룹을 사용할 경우 그룹 하의 모든 권한 그룹에 기본 권한이 적용됩니다. 사용 가능한 사용자 권한 유형 집합도 마찬가지입니다. 기본 권한을 변경하면 그룹 하의 개별 권한이 아닌 전체 그룹에 변경 사항이 동시에 적용됩니다.
기능 그룹은 다른 기본 설정과 기타 설정을 조합하여 사용할 수 없습니다. 따라서 5절의 표는 단일 기능 그룹의 모든 권한에 동일한 기본 설정과 사용 가능한 설정을 사용하는 규칙을 따르고 있습니다. 새 권한과 정책을 설계할 경우 이 규칙을 고려해야 합니다.

장치는 MIDlet Suite 이름, 버전 번호 등의 일반 MIDlet Suite 정보 외에도 설치된 각 MIDlet Suite의 보안 관련 데이터를 유지 관리해야 합니다. 이 데이터에는 최소한 다음과 같은 정보가 포함되어야 합니다.

MIDlet Suite의 서명자, 즉 MIDlet Suite가 서명된 경우 서명 인증서의 제목 필드. 최소한 MIDlet-Vendor는 설치된 MIDlet Suite와 함께 저장해야 합니다.
서명된 MIDlet을 인증한 보호 도메인 루트 인증서와 관련된 데이터(최소한 보호 도메인 루트 인증서의 제목 필드 포함)
MIDlet Suite를 서명한 서명자 인증서와 관련된 데이터(최소한 인증서의 제목, 발급자 및 일련 번호 필드 포함). 또는 장치에서 MIDlet 설명자 파일과 함께 제공된 전체 인증서 체인을 저장할 수도 있습니다.
MIDlet Suite에 부여된 권한 목록

장치는 응용 프로그램 서명자와 관련된 정보를 사용자에게 친숙한 방법으로 제공할 수 있어야 합니다.

7 사용자 프롬프트 및 알림

사용자가 충분한 정보를 받은 후에 MIDlet 작업에 동의할 수 있도록 하려면 다음 규칙을 따라야 합니다.

보호되어야 할 이벤트가 타사 도메인 및 신뢰할 수 없는 도메인의 MIDlet에서 생성되는 경우 미리 사용자 권한 설정에 따른 사용자 알림을 표시해야 합니다. 예를 들어, MIDlet이 전화를 거는 전화 번호, 연결하는 URL 또는 SMS의 수신자 등을 표시해야 합니다.
보호되어야 할 이벤트를 진행 중인 경우(예: 사용자에게 책임이 있는 피어-투-피어 연결) 사용자에게 모두 표시해야 합니다.
MIDlet은 정책의 사용자 권한 설정에 따라 사용자 승인을 받은 후 네트워크에 연결해야 합니다.
모든 MIDlet 권한을 직관적이고 사용자에게 친숙한 방식으로 사용자에게 표시해야 합니다.
MIDlet은 시스템 또는 가상 머신에서 생성된 보안 프롬프트와 사용자 알림을 무시할 수 없어야 합니다.
MIDlet은 사용자의 오해를 불러일으키는 보안 경고를 시뮬레이트할 수 없어야 합니다.
MIDlet은 사용자의 오해를 불러일으키는 키 누름 이벤트를 시뮬레이트할 수 없어야 합니다.

8 로밍 중 및 스마트 카드 변경 후의 MIDlet 다운로드 및 실행

이전에 권한이 부여되어 설치된 모든 MIDlet Suite는 장치가 로밍 중이거나 장치 스마트 카드를 변경할 때 장치 정책에 따라 작동해야 합니다. 새로 다운로드한 MIDlet Suite는 현재 장치(타사 응용 프로그램에만 해당)나 SIM, USIM 또는 WIM의 지정된 위치(운영자 및 타사 응용 프로그램에 해당)에서 사용할 수 있는 보호 도메인 루트 인증서와 장치 정책에 따라 인증됩니다.

장치 로밍 또는 스마트 카드 변경으로 인해 MIDlet이 이전에 액세스할 수 있었던 네트워크 자원에 대한 액세스에 실패한 경우에는 구현 시 SecurityException을 발생시키지 않아야 합니다. 이 실패는 MIDlet Suite 권한 부여로 인한 것이 아니므로 구현 시 IOException을 발생시켜야 합니다.

제조업체, 신뢰할 수 있는 타사 및 신뢰할 수 없는 도메인에 설치된 MIDlet Suite에 할당된 권한은 (U)ICC [(U)ICC]를 변경해도 영향을 받지 않지만, 운영자 도메인에 설치된 MIDlet Suite는 스마트 카드 변경 후 SIM에 MIDlet Suite를 운영자 도메인에 인증할 때 사용된 운영자 루트 공개 키가 포함된 인증서가 없을 경우 실행되지 않아야 합니다(3.2절 “운영자 도메인” 참조).

운영자 도메인의 MIDlet Suite 실행 가능 여부는 보호 도메인 루트 인증서의 BIT STRING subjectPublicKey 값의 20바이트 SHA-1 해시(태그, 길이 및 사용하지 않은 비트 수 제외)로 계산된 “루트 키 해시” 값 비교에 따라 결정됩니다. 결정 프로세스에서는 다음 기법을 따라야 합니다.

운영자 도메인에 설치된 MIDlet은 인증서 체인이 스마트 카드의 운영자 도메인 키 사용 필드에 저장된 인증 보호 도메인 루트 인증서로 끝나는 인증서로 서명됩니다. 보호 도메인 루트 인증서의 BIT STRING subjectPublicKey 값의 20바이트 SHA-1 해시(태그, 길이 및 사용하지 않은 비트 수 제외)는 MIDlet의 “인증 루트 키 해시”라고 하며 3.2절에 규정된 것처럼 MIDlet과 함께 장치에 저장됩니다.
스마트 카드를 변경할 때마다 운영자 도메인의 MIDlet을 실행하기 전에 새로운 스마트 카드의 운영자 도메인 키 사용 필드에 저장된 각 인증서의 BIT STRING subjectPublicKey 값의 20바이트 SHA-1 해시(운영자 도메인 루트 키 해시)가 계산 및 저장됩니다.
운영자 도메인의 MIDlet은 해당 인증 루트 키 해시가 스마트 카드 변경 후에 생성된 새로운 운영자 도메인 루트 키 해시 중 하나에 일치하지 않을 경우 사용할 수 없게 됩니다.

주: 이 기법에서 장치는 스마트 카드 변경 후 다음 두 단계를 수행합니다.

새로운 운영자 도메인 루트 키 해시 계산
운영자 도메인의 각 MIDlet Suite에 대해 인증 루트 키 해시가 새로운 운영자 도메인 루트 키 해시 중 하나와 일치하는지 여부 확인

인증 루트 키 해시가 새로운 운영자 도메인 루트 키 해시 중 하나에 일치하지 않으면 스마트 카드 변경 후 어떠한 운영자 MIDlet Suite도 실행되지 않을 경우, 구현 시 언제든지 이러한 두 단계를 수행할 수 있습니다. 1단계 후에 바로 2단계를 수행할 수도 있습니다. 또는 1단계와 2단계에 시간 차를 둘 수 있으며, 이 경우에는 구현 시 1단계 결과를 안전하게 저장하여 나중에 2단계에서 사용할 수 있도록 하는 것이 좋습니다.

지정된 위치에 운영자 보호 도메인 루트 인증서가 없을 경우 인증 보호 도메인 루트 인증서가 없으면 응용 프로그램을 실행할 수 없다는 것을 사용자에게 알려야 합니다. 또한 장치는 응용 프로그램을 운영자 도메인에 인증할 때 사용된 보호 도메인 루트 인증서의 정보를 가져올 수 있는 옵션을 사용자에게 제공하는 것이 좋습니다. 이 정보에는 루트 인증서의 제목 필드를 포함시키는 것이 좋습니다.

스마트 카드 변경 시 인증 루트가 여전히 스마트 카드에 있는지 여부를 확인하는 것만 요구되긴 하지만 구현 시 다른 경우에도 확인하여 그 결과에 따라 위에서 지정된 대로 운영자 도메인의 MIDlet Suite를 사용할 수 없게 할 수도 있습니다. 인증 운영자 보호 도메인 루트 인증서가 없어 MIDlet Suite를 실행할 수 없는 경우 장치에서 MIDlet Suite를 삭제해서는 안 됩니다. 장치는 적절한 기법을 통해 MIDlet Suite의 실행 가능 여부를 미리 사용자에게 알려줄 수도 있습니다. 예를 들어, 디스플레이에 “사용 불가” 상태를 표시할 수 있습니다. 그러나 사용자는 이러한 사용 불가 MIDlet Suite를 삭제할 수 없어야 합니다.