---
title: "권장 보안 정책 — RP"
---

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

#### Mobile Information Device Profile 버전 2.0의 부록

---

##### *Copyright 2002, Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.*

---

## 머리말

*GSM/UMTS 호환 장치에 권장되는 보안 정책* 문서는 JavaTM 2 Platform, Micro Edition(J2METM)용 Mobile Information Device Profile(MIDP) 버전 2.0의 부록입니다.

여기서 사용되는 용어는 별도의 지침이 없는 한 해당 사양에 의해 정의됩니다.

## 본 문서의 사용자

본 문서의 주 사용자는 MIDP를 정의한 Java Community Process (JCP) 전문가 그룹, MIDP 구현자, MIDP를 사용하는 응용 프로그램 개발자, MIDP 응용 프로그램을 배포하는 서비스 공급자, MIDP 서비스를 지원하는 인프라를 배포하는 무선 운영자입니다. 특히 본 문서는 네트워크 운영자, 제조업체, GSM 및 UMTS 네트워크용 서비스 및 응용 프로그램 공급자를 대상으로 합니다.

## 본 문서의 범위

본 부록은 정보를 제공하기 위한 것입니다. 그러나 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에 의해 정의된 권한에 따른 응용 프로그램의 기능
- 로밍 네트워크에서의 응용 프로그램 동작
- SIM/USIM 변경 시의 응용 프로그램 동작
- 사용자 권한 유형의 사용
- 사용자 프롬프트 및 알림에 대한 지침

## 본 사양의 구성 방법

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

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

## 참조 자료

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

## 1 일반 사항

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

## 2 정책 파일에서의 도메인

도메인은 다운로드한 MIDlet을 출처에 따라 구분하고, MIDlet Suite에 특정 권한 집합을 부여하거나 허용하는 방법입니다. 도메인은 루트 인증서를 특정 권한 집합에 바인드하며, 권한은 도메인 정책에서 지정됩니다. 정책 파일이나 정책에는 장치에서 사용할 수 있는 도메인 개수만큼의 항목이 포함됩니다. `id-kp-codeSigning` 확장 키 사용 확장자가 포함된 루트 인증서가 있어야만 도메인으로 인정됩니다.

신뢰할 수 있는 루트 키를 인증하는 응용 프로그램은 신뢰할 수 있는 것으로 간주되어 해당 보호 도메인에 할당됩니다. 각 응용 프로그램을 한 개의 보호 도메인에만 할당해야 합니다. MIDlet 규트는 두 개 이상의 보호 도메인에 속할 수 없습니다.

장치에서 도메인을 나타내는 방법은 구현별로 달라집니다.

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

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

**제조업체 및 운영자 도메인** - 사용자가 본 문서의 표 2 - 표 6에 해당 보안 정책이 규정되어 있는 기능을 액세스할 경우 응용 프로그램은 MIDP 2.0 권한 프레임워크를 사용하여 사용자에게 메시지를 표시해야 합니다.

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

#### 3.1 제조업체 도메인

장치 제조업체의 신뢰할 수 있는 루트 인증서는 제조업체 응용 프로그램에 연결되며 정책 파일에 도메인이 식별되어 있어야 합니다. 지정된 장치에 제조업체 도메인은 없지만 제조업체에서 서명한 응용 프로그램을 인증할 수 있는 경우(즉, 제조업체 루트 인증서가 설치되어 있는 경우)에는 신뢰할 수 없는 장치로서만 권한이 부여되며 신뢰할 수 없는 도메인에 속하게 됩니다.

제조업체 도메인은 사용자나 타사에서 삭제 또는 수정할 수 없으며, 장치에 지정된 기능에 의해서만 삭제 또는 수정될 수 있습니다. 제조업체 루트 인증서를 업데이트한 경우 동일한 제조업체-도메인 정책 파일에 매핑해야 합니다. 제조업체 루트 인증서가 장치에 없으면 장치에 지정된 기능에 의해 제조업체 도메인이 제거될 수도 있습니다.

제조업체 도메인에서의 권한은 모두 *허용*으로 표시됩니다(정의는 MIDP 2.0 참조). 제조업체 도메인에서 *허용*으로 권한을 부여한 경우 다운로드하여 인증된 제조업체 응용 프로그램은 사용자 확인이 필요한 이벤트가 발생할 때마다 사용자에게 메시지 표시 및 보안과 관련하여 제조업체에서 미리 설치한 응용 프로그램과 일관되게 작동합니다. 제조업체 응용 프로그램은 보안에 취약한 API 및 기능에 액세스할 때 사용자로부터 권한을 받는 것이 좋습니다. MIDP 2.0 및 다른 API에 의해 정의된 권한은 어떤 기능이 보안에 취약하며 보호해야 하는지에 대한 지침을 제공합니다. 제조업체 응용 프로그램은 보안상 보호된 이러한 기능과 관련하여 사용자에게 지속적으로 프롬프트와 알림을 표시합니다. 구현 시에는 제조업체 도메인에 새로운 응용 프로그램이 설치될 때마다 제조업체 루트 공개 키가 포함된 루트 인증서의 *제목* 필드를 사용자에게 제공해야 합니다. 이 사용자 알림은 응용 프로그램 설치 시 표시되어야 합니다.

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

#### 3.2 운영자 도메인

신뢰할 수 있는 운영자 루트 인증서는 장치상의 운영자 도메인을 설명하는 정책 파일에 매핑해야 합니다. 장치는 운영자 도메인을 설명하는 정책 파일을 지원해야 합니다.

지정된 장치에 운영자 도메인은 없지만 운영자가 서명한 응용 프로그램을 인증할 수 있는 경우(즉, 스마트 카드에서 운영자 루트 인증서를 가져올 수 있는 경우)에는 신뢰할 수 없는 장치로서만 권한이 부여되며 신뢰할 수 없는 도메인에 속하게 됩니다.

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

> trustedUsage 필드가 있으며 키 사용 "운영자 도메인"의 OID(아직 정의되지 않았음)가 포함되어 있으면 인증서는 운영자 도메인으로 매핑됩니다.
>
> trustedUsage 필드가 없거나 키 사용 "운영자 도메인"의 OID가 포함되어 있지 않으면 인증서는 신뢰할 수 있는 타사 도메인으로 매핑됩니다.

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

운영자 루트 인증서는 장치 외부에 있으며, 스마트 카드 변경 시에는 다운로드한 운영자 응용 프로그램 인증에 사용할 수 있는 루트 인증서를 미리 알 수 없습니다. 운영자 루트 인증서의 운영자 도메인으로의 매핑은 구현별로 달라집니다. 그러나 모든 운영자 루트 인증서는 운영자 도메인의 동일한 *허용* 권한 집합으로 매핑되어야 합니다. 운영자 도메인은 사용자나 타사에서 삭제 또는 수정할 수 없으며, 장치에 지정된 기능에 의해서만 삭제 또는 수정될 수 있습니다.

응용 프로그램이 운영자 루트 공개 키로 인증된 경우 서명 및 인증된 응용 프로그램에는 운영자 도메인에 대한 권한이 부여되어야 합니다. 운영자 루트 공개 키는 현재 삽입되어 사용 가능한 스마트 카드의 신뢰할 수 있는 CDF에서 가져와야 하며, 스마트 카드 또는 장치의 다른 위치에서 가져올 수 없습니다. 구현 시에는 운영자 도메인에 새로운 응용 프로그램이 설치될 때마다 운영자 루트 공개 키가 포함된 루트 인증서의 제목 필드를 사용자에게 제공해야 합니다. 이 사용자 알림은 응용 프로그램 설치 시 표시되어야 합니다.

운영자 도메인에서의 권한은 모두 *허용됨*으로 표시됩니다(정의는 MIDP 2.0 참조). 운영자 도메인에서 *허용*으로 권한을 부여한 경우 다운로드하여 인증된 운영자 응용 프로그램은 사용자 확인이 필요한 이벤트가 발생할 때마다 사용자에게 메시지 표시 및 보안과 관련하여 운영자가 설치한 다른 응용 프로그램과 일관되게 작동합니다. 운영자 응용 프로그램은 보안에 취약한 API 및 기능에 액세스할 때 사용자로부터 권한을 받는 것이 좋습니다. MIDP 2.0 및 다른 API에 의해 정의된 권한은 어떤 기능이 보안에 취약하며 보호해야 하는지에 대한 지침을 제공합니다. 운영자가 신뢰할 수 있는 응용 프로그램은 보안상 보호된 이러한 기능에 액세스할 때 사용자에게 지속적으로 프롬프트와 알림을 표시합니다.

운영자 도메인은 달리 명시되지 않는 한 MIDP 2.0 및 다른 API에 규정된 기능에 대해 어떤 제한도 두지 않습니다.

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

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

지정된 장치에서 사용할 수 있는 도메인 수에는 어떠한 명시적 제한도 없습니다. 신뢰할 수 있는 타사 루트 인증서를 인증하는 응용 프로그램은 타사 도메인에 속해야 합니다. 지정된 장치의 정책 파일에 타사 도메인이 없는 경우 신뢰할 수 없는 응용 프로그램으로만 타사 응용 프로그램에 권한을 부여하고 설치해야 하며, 신뢰할 수 없는 도메인에 속해야 합니다.

장치 제조 후에 다운로드한 타사 루트 인증서는 MIDlet 인증에 사용해서는 안 됩니다.

구현 시에는 새로운 MIDlet이 타사 도메인에 설치될 때마다 MIDlet 서명 인증서의 *제목* 필드를 사용자에게 제공해야 합니다. 이 사용자 알림은 MIDlet 설치 시 표시되어야 합니다. 응용 프로그램에 권한을 부여하라는 메시지를 사용자에게 표시할 경우 프롬프트는 서명 인증서의 *제목* 필드를 사용하여 신뢰할 수 있는 소스를 식별해야 합니다.

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

신뢰할 수 있는 타사 응용 프로그램에는 타사 도메인에서 *허용된* 권한이 하나도 부여되지 않습니다. 타사 도메인에서 부여된 모든 권한은 *사용자* 권한으로, 권한을 부여하려면 사용자 상호 작용이 필요합니다. 표 1에서는 타사 도메인의 응용 프로그램에 사용할 수 있는 사용자 권한 유형과 기능 그룹을 규정합니다. 표 2 - 표 6에서는 권한과 API의 다른 기능 그룹으로의 매핑에 대해 지정합니다.

#### 3.4 신뢰할 수 없는 도메인

**서명되지 않은 MIDlet은 신뢰할 수 없는 도메인에 속하게 됩니다.**

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

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

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

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

## 4 원격 정책 파일

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

## 5 다운로드한 MIDlet Suite의 권한

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

응용 프로그램 자체에서 필요한 사용자 프롬프트를 제공해야 하기 때문에 제조업체 및 운영자가 신뢰할 수 있는 응용 프로그램은 다음 표에 정의된 설정을 준수하지 않아도 됩니다. 제조업체 및 운영자가 신뢰할 수 있는 응용 프로그램은 표에 정의된 권한 지침을 준수하고, 보안상 보호된 기능을 식별할 수 있도록 사용자에게 적절한 프롬프트를 제공하는 것이 좋습니다.

표 1: 기능 그룹 및 사용자 설정

|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **기능 그룹** | **신뢰할 수 있는 타사 도메인** | | **신뢰할 수 없는 도메인** | |
| 전화 걸기 | 기본 설정 | 원샷 | 기본 설정 | 원샷 |
| 기타 설정 | 권한 없음 | 기타 설정 | 권한 없음 |
| 네트 액세스 | 기본 설정 | 세션 | 기본 설정 | 세션 |
| 기타 설정 | 블랭킷, 권한 없음 | 기타 설정 | 권한 없음 |
| 메시징 | 기본 설정 | 원샷 | 기본 설정 | 원샷 |
| 기타 설정 | 권한 없음 | 기타 설정 | 권한 없음 |
| 응용 프로그램 자동 호출 | 기본 설정 | 원샷 | 기본 설정 | 원샷 |
| 기타 설정 | 블랭킷, 권한 없음 | 기타 설정 | 권한 없음 |
| 로컬 연결 | 기본 설정 | 세션 | 기본 설정 | 세션 |
| 기타 설정 | 블랭킷, 권한 없음 | 기타 설정 | 블랭킷, 권한 없음 |
| 멀티미디어 레코딩 | 기본 설정 | 세션 | 기본 설정 | 원샷 |
| 기타 설정 | 블랭킷, 권한 없음 | 기타 설정 | 세션, 권한 없음 |
| 사용자 데이터 읽기 액세스 | 기본 설정 | 원샷 | 기본 설정 | 권한 없음 |
| 기타 설정 | 세션, 블랭킷, 권한 없음 | 기타 설정 | 권한 없음 |
| 사용자 데이터 쓰기 액세스 | 기본 설정 | 원샷 | 기본 설정 | 원샷 |
| 기타 설정 | 세션, 블랭킷, 권한 없음 | 기타 설정 | 권한 없음 |

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

신뢰할 수 있거나 신뢰할 수 없는 각 응용 프로그램에 대해 구현 시 MIDlet-Permissions 및 MIDlet-PermissionsOpt 속성에서 요청된 권한을 읽고, 응용 프로그램에 필요한 기능을 사용자에게 알려주며, 사용자에게 응용 프로그램 설치를 승인 또는 거부하라는 메시지를 표시할 수 있습니다.

주: 타사 도메인 또는 신뢰할 수 없는 도메인의 응용 프로그램의 경우 네트 액세스, 메시징 및 로컬 연결에 블랭킷 권한이 있으면 멀티미디어 레코딩이나 사용자 데이터 읽기 액세스는 블랭킷 권한을 가질 수 없으며 그 반대의 경우도 마찬가지입니다. 이 제한은 MIDlet이 사용자 동의 없이 네트워크 연결과 사용자 프라이버시와 관련된 기능을 동시에 활성화할 수 없도록 하기 위한 것입니다.  
  
이와 마찬가지로, 응용 프로그램 자동 호출의 블랭킷 설정과 네트 액세스의 블랭킷 설정도 동시에 사용할 수 없습니다. 이 제약 조건은 응용 프로그램이 자신을 자동 호출한 다음, 보호하에 있어야 할 네트워크를 사용자도 모르게 액세스할 수 없도록 차단합니다.

이러한 권한 조합 중 하나로 네트 액세스에 블랭킷 권한이 부여될 경우 세션 권한으로 하향 조정해야 합니다.

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

표 2: 기능 그룹에 MIDP 2.0에 규정된 권한 할당

|  |  |  |
| --- | --- | --- |
| **MIDP 2.0** -**JSR 118** | | |
| **권한** | **프로토콜** | **기능 그룹** |
| javax.microedition.io.Connector.http | http | 네트 액세스 |
| javax.microedition.io.Connector.https | https | 네트 액세스 |
| javax.microedition.io.Connector.datagram | 데이터그램 | 네트 액세스 |
| javax.microedition.io.Connector.datagramreceiver | 데이터그램 서버(호스트 없음) | 네트 액세스 |
| javax.microedition.io.Connector.socket | 소켓 | 네트 액세스 |
| javax.microedition.io.Connector.serversocket | 서버 소켓(호스트 없음) | 네트 액세스 |
| javax.microedition.io.Connector.ssl | ssl | 네트 액세스 |
| javax.microedition.io.Connector.comm | comm | 로컬 연결 |

표 3: 기능 그룹에 PDA 프로필의 개인 정보 관리 패키지에 규정된 API 호출 및 제안된 권한 할당

편집자 주: 현재의 PIM API 패키지는 쓰기 전용 API를 규정하지 않습니다. PIM 패키지에서는 PIM API를 보호하는 데 필요한 권한도 규정하지 않습니다. 이러한 변경 사항이 PIM 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) | 사용자 데이터 쓰기 액세스 |

구현 시에는 이러한 기능에 대한 응용 프로그램 액세스를 허용하기 전에 응용 프로그램이 액세스할 수 있는 사용자 데이터의 속성(예: 이벤트 또는 할 일 목록)을 사용자에게 알려줘야 합니다. 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://:<PORT>”)   Connector.open(“tcpobex://”) | 네트 액세스 |
| javax.microedition.io.PushRegistry.bluetooth.server | PushRegistry.registerConnection(“btspp://<server BD\_ADDR>:<channel ID>”)  PushRegistry.registerConnection(“btl2cap://<server BD\_ADDR>:<PSM>”) | 응용 프로그램 자동 호출 |
| javax.microedition.io.PushRegistry.obex.server | PushRegistry.registerConnection(“btgoep://<server BD\_ADDR>:<channel ID>”)  PushRegistry.registerConnection(“irdaobex://???…”) | 응용 프로그램 자동 호출 |
| javax.microedition.io.PushRegistry.obex.server.tcp | PushRegistry.registerConnection(“tcpobex://:<PORT>”) | 응용 프로그램 자동 호출 |

주: 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) | 메시징 |

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

표 6: 기능 그룹에 모바일 미디어 API에 규정된 API 호출 및 제안된 권한 할당

|  |  |  |
| --- | --- | --- |
| **모바일 미디어 API**-**JSR 135** | | |
| **정책 파일 식별자(제안된 권한)** | **허용되는 API 호출** | **기능 그룹** |
| javax.microedition.media.RecordControl.startRecord | RecordControl.startRecord ( ) | 멀티미디어 레코딩 |
| javax.microedition.media.VideoControl.getSnapshot | VideoControl.getSnapshot (…) | 멀티미디어 레코딩 |

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

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

사용자가 기능 그룹에 권한을 부여하면 MIDlet에 권한이 부여된 이 기능 그룹 하의 모든 개별 권한에 대한 액세스가 부여됩니다. 그룹의 모든 개별 권한을 포함해서는 안 됩니다. 예를 들어, MIDlet이 HTTP 연결을 구성할 수 있는 권한은 있지만 네트 액세스 그룹의 다른 보호된 기능을 액세스할 수 있는 권한이 없을 경우 네트 액세스에 블랭킷 권한을 부여하면 HTTP 연결만 사용할 수 있습니다. 기능 그룹은 사용자 표시용으로만 사용되기 때문에 MIDP 권한 부여 프레임워크에서 MIDlet에 부여하지 않은 개별 권한은 사용자가 네트 액세스를 허용해도 부여되지 않습니다.

구현 시 참고 사항:

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

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

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

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

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

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

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

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

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

## 7 사용자 프롬프트 및 알림

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

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

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

이전에 권한이 부여되어 설치된 모든 MIDlet은 장치가 로밍 중이거나 장치 스마트 카드를 변경할 때 장치 정책에 따라 작동해야 합니다. 새로 다운로드한 MIDlet은 인증서 저장소에서 현재 사용 가능한 루트 인증서에 대해 인증되며 장치 정책에 따라 권한이 부여됩니다.

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

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

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

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

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

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

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

스마트 카드 변경 시 인증 루트가 여전히 스마트 카드에 있는지 여부를 확인하는 것만 요구되긴 하지만 구현 시 다른 경우에도 확인하여 그 결과에 따라 지정된 대로 운영자 도메인의 응용 프로그램을 사용할 수 없게 할 수도 있습니다.

인증 운영자 루트 공개 키가 없어 MIDlet을 실행할 수 없는 경우 장치에서 응용 프로그램을 삭제해서는 안 됩니다. 장치는 적절한 기법을 통해 응용 프로그램의 실행 가능 여부를 미리 사용자에게 알려줄 수도 있습니다. 예를 들어, 디스플레이에 "사용 불가" 상태를 표시할 수 있습니다. 그러나 사용자는 이러한 사용 불가 응용 프로그램을 삭제할 수 없어야 합니다.