X.509 PKI를 사용하여 신뢰할 수 있는 MIDlet Suite

서명된 MIDlet Suite는 MIDlet Suite의 서명자를 인증하고 보호 도메인에 바인드함으로써 신뢰될 수 있습니다. 보호 도메인은 해당 보호 도메인에서 허용하는 권한을 MIDlet Suite에 부여함으로써 MIDlet Suite가 보호된 기능을 수행할 수 있도록 인증합니다. 여기에서 정의한 기법은 X.509 공용 키 인프라에 기반하여 MIDlet Suite의 서명과 인증하도록 함으로써 장치는 서명자를 확인하고 MIDlet Suite를 신뢰할 수 있습니다.

이 사양 구현이 PKI로 서명된 MIDlet Suite를 신뢰할 수 있는 MIDlet Suite로 인식하는 경우, 아래의 형식 및 프로세스에 따라 반드시 서명되고 확인되어야 합니다.

JAR을 서명하여 MIDlet Suite를 보호합니다. 서명 및 인증서는 응용 프로그램 설명자에 속성으로 추가됩니다. 장치는 이 속성을 사용하여 서명을 확인합니다. 장치는 장치의 보호 도메인에 바인드된 루트 인증서를 사용하여 인증을 완료합니다. 프로세스 및 형식에 대한 자세한 내용은 다음과 같습니다.

참조

MIDP 2.0 장치는 표준 인터넷 및 무선 프로토콜과 전송 및 보안에 대한 기술을 사용하여 작동합니다. 인터넷 컨텐트를 보안하기 위한 현재 방법은 아래와 같은 공용 키 암호화를 위한 기존 인터넷 표준에 기반합니다.

용어 정의

신뢰할 수 있는 MIDlet Suite, 권한 및 보호 도메인은 MIDP 응용 프로그램에 대한 보안에 정의되어 있습니다.

다음 용어가 추가로 정의됩니다.

용어 정의
보호 도메인 루트 인증서 다운로드한 MIDlet Suite를 확인하고 인증하기 위하여 장치가 암시적으로 신뢰하는 보호 도메인과 관련된 인증서

MIDlet Suite 서명

보안 모델은 MIDlet Suite, 서명자 및 공용 키 인증서와 관련되어 있습니다. 모든 공용 키 시스템과 마찬가지로 인증은 다른 인증서를 확인하는 데 사용하는 루트 인증서 집합에 기반합니다. 장치에는 0개 또는 그 이상의 루트 인증서가 있어야 합니다. 또한 루트 인증서가 SIM (WIM) 카드/USIM 모듈과 같은 이동식 미디어에 있을 수도 있습니다. 구현은 X.509 인증서와 해당 알고리즘을 반드시 지원해야 합니다. 장치는 추가 서명 방법 및 인증서 형식을 지원할 수도 있습니다.

MIDlet Suite의 서명자는 개발자이거나 배포, 지원 또는 사용 요금 청구를 책임지는 일부 엔티티가 될 수 있습니다. 서명자는 장치의 보호 도메인 루트 인증서 중 하나에서 검증할 수 있는 공용 키 인증서가 필요합니다. 공용 키는 MIDlet Suite 서명을 확인할 때 사용됩니다. 공용 키는 응용 프로그램 설명자에 포함된 RSA X.509 인증서로 제공됩니다.

JAR의 매니페스트 내에 정의된 속성은 서명으로 보호됩니다. 응용 프로그램 설명자 내에 정의된 속성은 안전하지 않습니다. 속성이 매니페스트에 나타나면 응용 프로그램 설명자의 다른 값이 속성을 덮어쓰지 않도록 해야 합니다. 신뢰할 수 있는 MIDlet Suite의 경우에는 응용 프로그램 설명자의 값과 매니페스트의 해당 속성 값이 일치해야 합니다. 일치하지 않는 경우에는 MIDlet Suite를 설치해서는 안됩니다. 속성 값이 정의되어 있으면 MIDlet.getAppProperty 메소드에서 매니페스트의 해당 속성 값을 반환해야 합니다. 속성 값이 정의되어 있지 않으면 응용 프로그램 설명자의 값(있는 경우)이 반환됩니다.

속성 값이 일치해야 한다는 요구 사항이 MIDP 1.0과는 다르다는 점과 속성 값이 이런 프로시저에서 서명되고 확인되는 응용 프로그램에 사용되어야 한다는 점에 유의하십시오. 신뢰할 수 없는 응용 프로그램 설명자의 경우에는 매니페스트 속성보다 응용 프로그램 설명자에게 우선 순위를 주는 MIDP 1.0 규칙을 따라야 합니다.

서명 인증서 생성

  1. 서명자는 장치에 대한 인증 정책을 인식하고 적합한 인증 기관에 연락해야 합니다. 예를 들어, 서명자는 고유 이름(DN)과 공용 키(보통 인증서 요청에 패키지화됨)를 인증 기관에 보내야 할 수도 있습니다.
  2. 인증 기관(CA)은 RSA X.509(버전 3) 인증을 만들어서 서명자에게 반환합니다.
  3. 여러 CA를 사용하는 경우에는 응용 프로그램 설명자의 모든 서명자 인증서에 반드시 동일한 공용 키를 포함해야 합니다.

응용 프로그램 설명자에 인증서 삽입

  1. 인증서 경로에는 서명자 인증서 및 필요한 모든 인증서가 포함되지만 루트 인증서는 생략합니다. 루트 인증서는 장치에서 찾을 수 있습니다.
  2. 경로에 있는 각 인증서는 인코딩(줄바꿈 없고 base64 사용)되고 다음 형식으로 응용 프로그램에 삽입됩니다. 
    MIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate>
    <n>:= 설명자의 첫 번째 인증 경로에 대해서는 1과 같은 수, 또는 추가 인증 경로에 대해서는 이전 수보다 1만큼 큰 수입니다. 이렇게 하여 해당 루트 인증서가 장치에 있는지 확인하기 위해 인증서를 검사하는 순서를 정의합니다. 아래의 MIDlet Suite 인증 절을 참조하십시오.
    <m>:= 인증 경로의 서명자 인증서에 대해서는 1과 같은 수, 또는 모든 후속 중간 인증서에 대해서는 이전 수보다 1만큼 큰 수입니다.

JAR의 RSA SHA-1 서명 생성

  1. JAR의 서명은 PKCS #1 버전 2.0 표준[RFC2437]의 EMSA-PKCS1-v1_5 인코딩 메소드에 따라 서명자 개인 키로 만듭니다.
  2. 서명은 base64로 인코딩되고 줄바꿈 없는 단일 MIDlet-Jar-RSA-SHA1 속성으로 서식이 지정되며 응용 프로그램 설명자에 삽입됩니다. 
    MIDlet-Jar-RSA-SHA1: <base64 encoding of Jar signature>

MIDlet Suite의 서명자는 해당 보호 도메인 루트 인증서 소유자에 대해 보호 도메인 이해 관계자의 자산 및 기능을 보호할 책임이 있으므로 서명하기 전에 MIDlet Suite를 확인해야 합니다. 신뢰할 수 있는 관계(가능하면 법적 계약으로 묶인)의 경우 보호 도메인 루트 인증서 소유자는 MIDlet Suite의 서명을 제3자, 경우에 따라서는 MIDlet 작성자에게 위임하기도 합니다.

MIDlet Suite 인증

MIDlet Suite를 다운로드할 때 장치에서는 인증이 필요한지 반드시 확인해야 합니다. MIDlet-Jar-RSA-SHA1 속성이 응용 프로그램 설명자에 있으면 아래와 같은 서명자 인증서와 JAR 서명을 확인하여 반드시 JAR을 인증해야 합니다.

MIDlet-Jar-RSA-SHA1 속성이 없는 응용 프로그램 설명자는 인증되지 않지만 신뢰할 수 없는 MIDlet Suite로서 설치되고 호출됩니다.

서명자 인증서 확인

인증 경로는 응용 프로그램 설명자의 서명자 및 루트 인증서를 제외한 다른 필요한 인증서로 구성되어 있습니다.

  1. 서명자 인증서의 인증 경로를 응용 프로그램 설명자 속성 MIDlet-Certificate-1-<m>에서 가져옵니다. 여기에서 <m>은 1부터 시작하여 제공된 이름에 속성이 없을 때까지 1배수로 증가합니다. 각 속성 값은 base64로 인코딩된 인증서이므로 디코딩하고 구문 분석해야 합니다.
  2. 보호된 도메인을 보호 도메인 루트 인증서의 믿을만한 소스로 사용하는 RFC2459의 기본 경로 검증 과정을 사용하여 인증 경로를 검증합니다. 서명자에서 루트까지의 첫 번째 체인을 검증하는 보호 도메인 루트 인증서를 포함하는 보호 도메인에 MIDlet Suite를 바인드하고 설치를 진행합니다.
  3. 만약 1 보다 큰 <n>을 가진 MIDlet-Certificate-<n>-<m>속성이 있고 MIDlet-Certificate-<1>-<m> 인증서를 확인한 후 전체 인증 경로를 설정하지 못한 경우에는 이전 값보다 1 더 큰 <n> 값에 대해 1단계와 2단계를 반복해서 수행합니다. 인증서 확인에 대한 결과는 표1에 나와 있습니다.

표 1. 서명자 인증서 확인 완료 후 작업

결과 작업
<n>개 경로를 검증하려고 했습니다. 인증서 발급자의 공용 키를 찾을 수 없거나 검증할 수 있는 인증 경로가 없습니다. 인증이 실패하여 JAR 설치가 허용되지 않습니다.
두 개 이상의 전체 인증서 경로가 설정되고 검증되었습니다 구현에서는 첫 번째로 성공적으로 검증된 인증서 경로를 사용하는 서명 확인을 사용하여 인증하고 승인합니다.
전체 인증서 경로가 한 개만 설정되고 검증되었습니다 구현은 서명 확인을 진행합니다

MIDlet Suite JAR 확인

  1. 확인된 서명자 인증서(위)에서 공용 키를 가져옵니다.
  2. 응용 프로그램 설명자에서 MIDlet-Jar-RSA-SHA1 속성을 가져옵니다.
  3. PKCS #1 서명 [RFC2437]를 따르는 base64의 속성 값을 디코드합니다.
  4. 서명자의 공용 키, 서명 및 JAR의 SHA-1 다이제스트를 사용하여 서명을 확인합니다. 서명 확인이 실패하면 응용 프로그램 설명자 및 MIDlet Suite를 거부합니다. 구현은 실패 시 JAR을 설치해서는 안되고 또는 MIDlet Suite에서 MIDlet을 호출할 수 없게 해야 합니다.

인증서 확인, 서명 확인 및 JAR 확인 단계가 전부 성공하면 MIDlet Suite의 컨텐트가 손상되지 않은 것으로 간주되며 서명자의 ID가 알려집니다. 이 프로세스는 설치하는 동안 수행되어야 합니다.

MIDlet Suite 소스 확인 결과 요약

위에서 설명한 대로 디지털 서명을 확인하는 단계를 통해 MIDlet Suite 서명자의 ID를 증명하도록 하는 것은 매우 중요합니다. 확인 결과는 인증에 직접적인 영향을 줍니다. 다음 표 2는 서명 확인 단계 상태와 설치 시 승인에 사용된 상태를 요약한 것입니다.

표 2. MIDlet Suite 소스 확인 요약

초기 상태 확인 결과
JAD가 없음, JAR이 다운로드됨 인증을 수행할 수 없음, JAR을 설치해야 함. MIDlet Suite가 신뢰할 수 없는 것으로 처리됨.
JAD는 있지만 JAR이 서명되지 않음 인증을 수행할 수 없음, JAR을 설치해야 함. MIDlet Suite가 신뢰할 수 없는 것으로 처리됨.
JAR이 서명되었지만 인증서 체인을 검증하기 위한 루트 인증서가 키스토어에 없음 인증을 수행할 수 없음, JAR을 설치할 수 없음.
JAR이 서명됨, 경로의 인증서가 만료됨 인증을 완료할 수 없음, JAR을 설치할 수 없음.
JAR이 서명됨, 만료 외 다른 이유로 인증서가 거부됨 JAD가 거부됨, JAR을 설치할 수 없음.
JAR이 서명됨, 인증서가 검증되었지만 서명 확인은 실패함 JAD가 거부됨, JAR을 설치할 수 없음.
JAR이 서명됨, 인증서 경로가 검증됨, 서명이 확인됨 JAR을 설치할 수 있음.

인증 및 승인 결과의 캐싱

인증 및 승인 프로세스 구현은 후속 사용을 위해 결과를 저장하고 전송할 수 있으며 캐시된 정보는 실질적으로 손상되지 않도록 해야 합니다. JAR, 응용 프로그램 설명자에서 계산된 시점과 인증 정보 및 승인 정보가 사용되는 시점 사이에 정보가 손상될 수 있습니다.

MIDlet Suite를 인증하고 승인하는 데 사용하는 MIDlet Suite 및 보안 정보가 손상되지 않는 것이 중요합니다. 예를 들어, 이동식 미디어를 사용하거나 손상되었을 수 있는 MIDlet Suite 저장소에 액세스하는 경우에 손상될 수 있습니다.

Split-VM 구현의 보안

스플릿 VM (CLDC 5.4.6)을 사용하는 환경에서는 JAR을 사용하는 보안 기법을 구현하는 것이 가능하지만 이는 MIDlet의 의미를 온전하게 보존하면서도 JAR이 네트워크에 진입할 때 JAR을 장치 형식으로 변환하는 것에 달려 있습니다. 변환이 일어난 후 응용 프로그램의 장치 형식은 변형되지 않도록 안전하게 보안되어야 하고 그 승인된 권한을 그대로 보존해야 합니다. 이 네트워크 보안은 MIDlet 보안과 유사한 디지털 서명 기술을 기반으로 하며 이 네트워크 보안 인프라가 이미 존재하고 활성화되어 있을 수도 있습니다. 이런 종류의 네트워크 보안 인프라만이 이미 존재하고 있고 이 보안 인프라가 이 사양( 및 이 사양에 기반한 향후 JSR)에서 요구하는 모든 형식의 보호를 지원할 수 있는 경우, MIDlet Suite 보안의 허용 가능한 구현은 MIDlet의 장치 형식을 인증하고 승인하는 것에 기반할 수 있습니다. 왜냐하면 이러한 구현 형식이 장치에서 사용될 실제로 실행 가능한 컨텐트이기 때문입니다. MIDlet Suite의 장치 형식 버전을 인증 및 승인하는 데 대한 자세한 내용은 구현에 따라 다르므로 이 사양에서 다루지 않습니다.

신뢰할 수 있는 MIDlet Suite에 대한 MIDP X.509 인증서 프로필

보안되고 신뢰할 수 있는 MIDlet Suite는 HTTPS에서처럼 동일한 기본 인증서 프로필을 활용합니다. 프로필은 RFC2459 인터넷 X.509 공용 키 인프라 인증서 및 CRL 프로필[RFC2459]에 기반한 WAP 인증서 프로필인 WAP-211-WAPCert-20010522-a [WAPCert]에 기반합니다. 자세한 내용은 javax.microedition.pki에 대한 설명서를 참조하십시오.

OTA 인증서 처리

장치는 주요 확장자를 인식해야 하고 확장자가 있을 경우 확장자가 digitalSignature 비트 집합을 가지고 있는지 확인해야 합니다. 장치는 중요한 확장 키 사용 확장자를 반드시 인식해야 하고 확장자가 있을 경우 확장자에 id-kp-codeSigning 객체 식별자(RFC249의 4.2.1.12 조항 참조)가 있는지 확인해야 합니다.

응용 프로그램 설명자는 설명자 인증서 체인에서 자체 발급한 루트 인증서를 포함해서는 안됩니다. 그러나, MIDP 장치는 인증서를 체인의 다른 인증서로 처리해야 하며 해당 체인에서 X.509v3가 자체 발급한 CA 인증서를 가진 체인을 명시적으로 거부해서는 안됩니다.

인증서 만료 및 해지

응용 프로그램 설명자에서 제공한 인증서의 만료 및 해지는 승인 과정, 명확히 말하자면 인증서 경로를 검증하는 동안 확인됩니다. 인증서 만료는 인증서 자체에서 관련 정보를 조회할 수 있을 경우 장치에서 로컬로 검사합니다. 인증서 만료 확인은 인증서 경로 검증의 고유하면서 필수적인 단계입니다.

인증서 해지 확인은 서버에 요청을 보내야 하고 수신된 응답을 근거로 결정을 내려야 하므로 보다 더 복잡한 검사 작업입니다. 적절한 기법이 장치에 구현될 경우에는 인증서 해지를 수행할 수 있습니다. 이러한 기법은 MIDP 구현의 일부분이 아니므로 MIDP 2.0 보안 프레임워크의 일부를 구성하지 않습니다.

장치에서 인증서 해지가 구현되면 장치는 온라인 인증서 상태 프로토콜(OCSP) [RFC2560]을 지원해야 합니다. 다른 인증서 해지 프로토콜이 지원될 경우에는 이러한 다른 프로토콜에 대한 지원으로 인증서가 해지되었음을 나타낼 수도 있습니다. 이런 경우, OCSP 프로토콜에서 반환한 결과와는 상관없이 인증서가 해지되었다고 간주할 수 있습니다.

MIDlet Suite 서명 예

보호 도메인 루트 인증서와 관련된 서명 정책을 구성하는 방법은 많습니다. 이러한 예들은 이 사양의 일부 개념을 설명하기 위하여 제공하는 것이지 MIDlet PKI 서명을 사용하는 방법을 제한하려는 것은 아닙니다. 이 예들에서 MIDlet은 해지될 수 있지만(장치가 인증서 해지를 지원하는 경우) 그 세부적인 내용은 서로 다릅니다.

예 1 - 개발자가 서명 인증서를 소유한 경우

이는 MIDlet Suite의 출처를 JAD(서명자의 ID를 통해)로 인코딩합니다. 인증서가 해지되면 모든 사용자에 대해 모든 장치에서 개발자가 서명한 MIDlet의 실행 권한은 모두 해지됩니다.

  1. 개발자가 MIDlet 네트워크 응용 프로그램을 작성한 경우
  2. 개발자는 권한을 JAR 매니페스트로 인도킹하여 최종 MIDlet JAR을 만듭니다.
  3. 개발자는 서명 인증서와 짝을 이루는 개인-공용 키 상을 생성하고 인증서에 한 개 이상의 보호 도메인 루트 인증서가 서명하게 합니다.
  4. 개발자의 인증서는 MIDlet JAR을 서명하고 관련 JAD 항목을 만드는 데 사용됩니다.
  5. MIDlet JAR은 적절하게 채워진 JAD와 같이 배포할 수 있으며 적절한 보호 도메인 루트 인증서와 같이 MIDP 2.0을 준수하는 장치에서 실행할 수 있습니다.

예 - 보호 도메인 이해 관계자가 서명 인증서를 소유함

서명자의 ID (MIDlet Suite 개발자가 아님)를 JAD로 인코딩합니다. 인증서가 해지되면 이 특정 인증서로 서명된 모든 MIDlet의 실행 권한이 해지됩니다.

  1. 개발자가 MIDlet 네트워크를 작성합니다.
  2. 개발자는 권한을 JAR 매니페스트로 암호화하고 최종 MIDlet JAR을 만듭니다.
  3. 보호 도메인 이해 관계자의 서명 인증서(반드시 루트 인증서일 필요는 없음)는 MIDlet JAR을 서명하고 관련된 JAD 항목을 만드는 데 사용됩니다.
  4. MIDlet JAR은 적절하게 채워진 JAD와 같이 배포할 수 있고 적절한 보호 도메인 루트 인증서와 같이 MIDP 2.0을 준수하는 호환 장치에서 실행할 수 있습니다.