KR20090034332A - 아이덴터티 오브젝트를 사용하는 제어 시스템과 방법 - Google Patents

Abstract

아이텐터티 오브젝트로 알려진 오브젝트는 공개 키와 비밀 키 쌍과, 그 쌍 중 공개 키가 진짜임을 인증하는 인증 권한에 의해 발행된 적어도 하나의 인증서를 포함한다. 이 오브젝트는 이에 제공되는 데이터 또는 상기 데이터로부터 유도되는 신호에 서명하는데 비밀 키를 사용함으로써 식별의 증명으로 사용될 수 있다. 아이덴터티 오브젝트는 아이덴터티의 증명으로서 비휘발성 메모리에 저장될 수 있다. 메모리는 제어기에 의해 제어된다. 바람직하게, 하우징은 메모리와 제어기를 둘러싼다. 메모리 시스템은 호스트에 착탈 가능하게 접속된다. 호스트 디바이스가 성공적으로 인증된 후, 오브젝트의 공개 키는 호스트 디바이스로부터의 데이터 또는 상기 데이터로부터 유도되는 신호를 암호화하는데 사용되고, 적어도 하나의 인증서와 암호화된 데이터 또는 신호들은 호스트로 전송된다. 엔티티가 메모리 시스템의 제어 데이터 구조에 의하여 인증된 후, 아이덴터티 오브젝트의 공개 키와 이 공개 키를 인증하는 적어도 하나의 인증서가 엔티티에 제공된다. 아이덴터티 오브젝트의 공개 키에 의해 암호화된 암호화 데이터가 엔티티로부터 수신되면, 메모리 시스템은 아이덴터티 오브젝트의 공개 키를 사용하여 이 암호화된 데이터를 암호 해제할 수 있다.

Description

아이덴터티 오브젝트를 사용하는 제어 시스템과 방법{CONTROL SYSTEM AND METHOD USING IDENTITY OBJECTS}

관련 출원에 대한 상호 참조

이 출원은 2006년 7월 7일에 출원된 미국 가출원 60/819,507의 이익을 청구한다.

이 출원은 2005년 12월 20일 출원된 미국 출원 11/313,870에 관련되며, 이 출원은 2004년 12월 21일에 출원된 미국 가출원 60/638,804의 이익을 청구한다. 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/314,411에 더 관련되며, 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/314,410에 더 관련되며, 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/313,536에 더 관련되며, 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/313,538에 더 관련되며, 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/314,055에 더 관련되며, 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/314,052에 더 관련되며, 이 출원은 2005년 12월 20일에 출원된 미국 출원 11/314,053에 더 관련된다.

본 출원은 2006년 11월 6일 출원된 "Content Control Method Using Certificate Chains" 명칭의 Holtzman 등의 미국 출원 11/557,028; 2006년 11월 6일 출원된 "Content Control System Using Certificate Chains" 명칭의 Holtzman 등의 미국 출원 11/557,010; 2006년 11월 6일 출원된 "Content Control Method Using Certificate diamondcation Lists" 명칭의 Holtzman 등의 미국 출원 11/557,006; 2006년 11월 6일 출원된 "Content Control System Using Certificate diamondcation Lists" 명칭의 Holtzman 등의 미국 출원 11/557,026; 2006년 11월 6일 출원된 "Content Control Method Using Versatile Control Structure" 명칭의 Holtzman 등의 미국 출원 11/557,049; 2006년 11월 6일 출원된 "Content Control System Using Versatile Control Structure" 명칭의 Holtzman 등의 미국 출원 11/557,056; 2006년 11월 6일 출원된 "Method for Controlling Information Supplied From Memory Device" 명칭의 Holtzman 등의 미국 출원 11/557,052; 2006년 11월 6일 출원된 "System for Controlling Information Supplied From Memory Device" 명칭의 Holtzman 등의 미국 출원 11/557,051; 2006년 11월 6일 출원된 "Control Method Using Identity Objects" 명칭의 Holtzman 등의 미국 출원 11/557,041; 2006년 11월 6일 출원된 "Control System Using Identity Objects" 명칭의 Holtzman 등의 미국 출원 11/557,039에 관련된다.

위에 열거된 출원은, 본 명세서에 완전히 개시된 것처럼 그 전체 기재 내용이 본 명세서에 참조로 포함되어 있다.

이 발명은, 일반적으로 메모리 시스템들에 관한 것이고, 특히 다기능 제어 특징을 구비한 메모리 시스템에 관한 것이다.

플래시 메모리 카드들과 같은 저장 디바이스들은 사진들과 같은 디지털 콘텐 트를 저장하기 위해 선택되는 저장매체가 되었다. 플래시 메모리 카드들은 다른 유형들의 미디어 콘텐트를 배포하기 위해서도 사용될 수 있다. 또한, 이를테면 컴퓨터들, 디지털 카메라들, 셀룰러 전화들, PDA들(personal digital assistant) 및 MP 3 플레이어들과 같은 미디어 플레이들 등의 증가하는 다양한 호스트 디바이스들은 이제 플래시 메모리 카드들에 저장된 미디어 콘텐트를 렌더링하는 능력을 갖추고 있다. 이에 따라 다른 유형들의 이동 저장 디바이스들뿐만 아니라 플래시 메모리 카드들은 디지털 콘텐트를 배포하기 위해 널리 사용되는 매개물이 될 큰 잠재력이 있다.

임의 애플리케이션들에 있어서는, 메모리 카드들 등의 메모리 디바이스와 관련된 엔티티에 그것의 아이덴터티(identity)를 입증할 것을 요구한다. 아이덴티의 입증이 불가능한 경우에는 불편할 수도 있다. 다른 애플리케이션들에 있어서는, 메모리 카드 등의 메모리 디바이스에 저장된 데이터는 보안 방법들에 의해 보호되어야 한다.

아이덴터티 오브젝트로 알려진 오브젝트는 공개 키 및 비밀 키 쌍과, 그 쌍 중 공개 키가 진짜임을 증명하는 인증 기관에 의해 제시되는 적어도 하나의 증명서를 포함한다. 일 실시예에서, 이러한 오브젝트는 그것에 제공되는 사인(sign) 데이터 또는 그 데이터로부터 파생되는 신호에 비밀 키를 사용하여 식별 입증으로 사용될 수 있다. 아이덴터티 오브젝트는 아이덴터티의 입증으로 비휘발성 메모리에 저장될 수 있으며, 이 메모리는 제어기에 의해 제어된다. 바람직하게는, 하우징은 메모리 및 제어기를 둘러싼다.

또 다른 실시예에서, 아이덴터티 오브젝트는 아이덴터티 입증으로 메모리 시스템의 비휘발성 메모리에 저장될 수 있다. 메모리 시스템은 호스트 디바이스에 착탈 가능하게 접속된다. 호스트 디바이스가 성공적으로 인증된 후, 그 오브젝트의 비밀 키는 호스트 디바이스로부터의 데이터 또는 상기 데이터로부터 파생되는 신호들을 암호화하는데 사용되며, 적어도 하나의 인증서 및 암호화된 데이터 또는 신호들은 호스트 디바이스에 전송된다.

또 다른 실시예에서, 엔티티가 메모리 시스템의 제어 데이터 구조에 의해 인증된 후, 아이덴터티 오브젝트의 공개 키와 그 공개 키를 증명하는 적어도 하나의 인증서는 엔티티에 제공된다. 이 실시예의 한 가지 특정 애플리케이션에서, 아이덴터티 오브젝트의 공개 키에 의해 암호화된 암호화 데이터가 그 엔티티로부터 수신된 경우, 메모리 시스템은 아이덴터티 오브젝트의 공개 키를 사용하여 그 암호화 데이터를 암호 해제할 수 있게 된다. 아이덴터티 오브젝트와 적어도 하나의 인증서는 메모리가 제어기에 의해 제어되는 비휘발성 메모리에 저장된다. 바람직하게는, 하우징은 메모리와 제어기를 둘러싼다.

일 실시예에서, 아이덴터티 오브젝트는 메모리 시스템의 비휘발성 메모리에 저장될 수 있다. 메모리 시스템은 호스트 디바이스에 착탈 가능하게 접속된다. 호스트 디바이스가 성공적으로 인증된 후, 아이덴터티 오브젝트의 공개 키 및 그 공개 키를 증명할 적어도 하나의 인증서는 호스트 디바이스에 제공된다. 아이덴터티 오브젝트의 공개 키에 의해 암호화된 암호화 데이터가 호스트 디바이스로부터 수신된 경우, 메모리 시스템은 아이덴터티 오브젝트의 공개 키를 사용하여 암호화 데이터를 암호 해제한다.

본 명세서에 인용된 모든 특허, 특허 출원, 기사, 책자, 명세서, 규격, 그외 공보, 문헌, 및 자료는, 모든 목적들을 위해 그 전체 내용이 본 명세서에 참조로 포함되어 있다. 포함된 공보, 문헌 또는 자료 중 임의의 것과 본 문헌의 텍스트 간 용어의 정의 또는 사용에 임의의 모순 또는 충돌의 정도까지, 본 문헌에서 용어의 정의 또는 사용이 우세할 것이다.

도 1은, 이 발명을 예시하는데 유용한 호스트 디바이스와 통신하는 메모리 시스템의 블록도.

도 2는, 메모리의 서로 다른 파티션들 및 서로 다른 파티션들에 저장된 비암호화된 및 암호화된 파일들의 개략도로서, 여기서 어떤 파티션들 및 암호화된 파일에 대한 액세스는 발명의 서로 다른 실시예들을 예시하는데 유용한 액세스 정책들 및 인증 절차들에 의해 제어되는, 도면.

도 3은, 메모리 내 서로 다른 파티션들을 예시하는 메모리의 개략도.

도 4는, 발명의 서로 다른 실시예들을 예시하는데 유용한 것으로, 파티션들 내 일부 파일들이 암호화되는 도 3에 도시된 메모리의 서로 다른 파티션들에 대한 파일 위치 테이블들의 개략도.

도 5는, 발명의 서로 다른 실시예들을 예시하는데 유용한 액세스 제어된 레코드 그룹 내 액세스 제어 레코드들 및 연관된 키 참조의 개략도.

도 6은, 발명의 서로 다른 실시예들을 예시하는데 유용한 액세스 제어된 레코드 그룹들 및 액세스 제어된 레코드들에 의해 형성된 나무 구조들의 개략도.

도 7은, 나무들의 형성 프로세스를 예시하기 위해서 액세스 제어된 레코드 그룹들의 3개의 계층 나무들을 나타낸 나무의 개략도.

도 8a 및 도 8b는, 시스템 액세스 제어 레코드를 생성하고 사용하기 위해 호스트 디바이스 및 메모리 카드와 같은 메모리 디바이스에 의해 수행되는 프로세스들을 예시하는 흐름도.

도 9는, 발명의 서로 다른 실시예들을 예시하는데 유용한 액세스 제어된 레코드 그룹을 생성하기 위해 시스템 액세스 제어 레코드를 사용하는 프로세스를 예시한 흐름도.

도 10은, 액세스 제어 레코드를 생성하기 위한 프로세스를 예시한 흐름도.

도 11은, 계층 나무의 특정한 적용을 예시하는데 유용한 2개의 액세스 제어 레코드 그룹들의 개략도.

도 12는, 특정한 권한들의 위임을 위한 프로세스를 예시한 흐름도.

도 13은, 도 12의 위임 프로세스를 예시하기 위해 액세스 제어된 레코드 그룹 및 액세스 제어 레코드의 개략도.

도 14는, 암호화 및/또는 해독의 목적을 위해 키를 생성하기 위한 프로세스를 예시하는 흐름도.

도 15는, 액세스된 제어된 레코드에 따라 데이터 액세스를 위해 액세스 권한들 및/또는 허가를 제거하기 위한 프로세스를 예시한 흐름도.

도 16은, 액세스 권한들 및/또는 액세스 허가가 삭제 또는 만기되었을 때 액세스를 요청하기 위한 프로세스를 예시한 흐름도.

도 17a 및 도 17b는, 발명의 서로 다른 실시예들을 예시하는데 유용한 크립토그래픽(cryptographic) 키에 대한 액세스를 승인하기 위한 인증 및 정책들을 위한 규칙 구조의 조직화를 예시한 개략도.

도 18은, 정책들에 따라 보호된 정보에 대한 액세스를 제어하기 위한 대안적 방법을 예시하는 데이터베이스 구조의 블록도.

도 19는, 패스워드들을 사용한 인증 프로세스들을 예시한 흐름도.

도 20은, 다수의 호스트 증명서 체인들을 예시한 도면.

도 21은, 다수의 디바이스 증명서 체인들을 예시한 도면.

도 22 및 도 23은, 단방향 및 상호 인증 방법들을 위한 프로세스들을 예시한 프로토콜도.

도 24는, 발명의 서로 다른 실시예들을 예시하는데 유용한 증명서 체인도.

도 25는, 발명의 또 다른 실시예를 예시하기 위해 증명서가 증명서 체인에서 마지막 증명서라는 표시를 나타내는 것으로, 마지막 증명서를 메모리 디바이스에 보내기 위해 호스트에 의해 보내지는 증명서 버퍼에 선행하는 제어 섹터 내 정보를 예시한 테이블.

도 26 및 도 27은, 메모리 카드가 호스트 디바이스를 인증하고 있는 인증 방법들에 대해 각각 카드 및 호스트 프로세스들을 예시한 흐름도.

도 28 및 도 29는, 호스트 디바이스가 메모리 카드를 인증하는 인증 방법들 에 대해 각각 카드 및 호스트 프로세스들을 예시한 흐름도.

도 30 및 도 31은, 발명의 하나 이상의 실시예를 예시하기 위해 메모리 디바이스에 저장된 증명서 철회 리스트가 호스트 디바이스에 의해 검색되는 경우 호스트 디바이스 및 메모리 디바이스에 의해 각각 수행되는 프로세스들을 예시한 흐름도.

도 32는, 발명의 또 다른 실시예를 예시하기 위해 리스트 내 필드들을 보인 증명서 철회 리스트도.

도 33 및 도 34는, 증명서 철회 리스트들을 사용하여 증명서들을 검증하기 위한 카드 및 호스트 프로세스들을 각각 예시하는 흐름도.

도 35는, 호스트에 보내진 데이터에 서명하고 호스트로부터의 데이터를 해독하기 위한 카드에 대한 카드 프로세스들을 예시한 흐름도.

도 36은, 호스트에 보내진 데이터를 카드가 서명하는 경우 호스트 프로세스들을 예시한 흐름도.

도 37은, 호스트가 암호화된 데이터를 메모리 카드에 보내는 경우 호스트 프로세스들을 예시한 흐름도.

도 38 및 도 39는, 일반 정보 및 디스크리트 정보 조회들에 대한 프로세스들을 각각 예시한 흐름도.

도 40a는, 발명의 실시예를 예시하기 위해 호스트 디바이스에 접속된 메모리 디바이스(이를테면 플래시 메모리 카드)에 시스템 구조의 기능 블록도.

도 40b는, 도 40a의 SSM 코어의 내부 소프트웨어 모듈들의 기능 블록도.

도 41은, 일회용 패스워드를 생성하기 위한 시스템의 블록도.

도 42는, 일회용 패스워드(OTP) 시드 공급 및 OTP 생성을 예시한 기능 블록도.

도 43은, 시드 공급 국면을 예시한 프로토콜도.

도 44는, 일회용 패스워드 생성 국면을 예시한 프로토콜도.

도 45는, DRM 시스템을 예시한 기능 블록도.

도 46은, 키가 라이센스 오브젝트에 제공되는 경우 라이센스 제공 및 콘텐트 다운로드를 위한 프로세스를 예시한 프로토콜도.

도 47은, 플레이백 동작을 위한 프로세스를 예시한 프로토콜도.

도 48은, 키가 라이센스 오브젝트에 제공되지 않는 경우 라이센스 제공 및 콘텐트 다운로드를 위한 프로세스를 예시한 프로토콜도.

도면은 발명의 면들의 여러 실시예들에서 특징들을 도시한다. 설명을 간단하게 하기 위해서, 이 출원에서 동일 구성성분들을 동일 참조부호들로 표시하였다.

본 발명의 여러 면들이 구현될 수 있는 메모리 시스템이 도 1의 블록도에 의해 도시되었다. 도 1에 도시된 바와 같이, 메모리 시스템(10)은 중앙처리유닛(CPU)(12), 버퍼 관리유닛(BUM)(14), 호스트 인터페이스 모듈(HIM)(16) 및 플래시 인터페이스 모듈(FIM)(18), 플래시 메모리(20) 및 주변 액세스 모듈(22)을 포함한다. 메모리 시스템(10)은 호스트 인터페이스 버스(26) 및 포트(26a)를 통해 호스트 디바이스(24)와 통신한다. NAND 유형일 수 있는 플래시 메모리(20)는, 디지털 카메라, 개인용 컴퓨터, PDA(personal digital assistant), MP-3 플레이어와 같은 디지털 미디어 플레이어, 셀룰러 전화, 셋탑박스 또는 이외 디지털 디바이스 또는 기기일 수 있는 호스트 디바이스(24)를 위해 데이터 저장을 제공한다. CPU(12)를 위한 소프트웨어 코드도 플래시 메모리(20)에 저장될 수 있다. FIM(18)은 플래시 인터페이스 버스(28) 및 포트(28a)를 통해 플래시 메모리(20)에 접속한다. HIM(16)은 호스트 디바이스에 접속하기에 적합하다. 주변 액세스 모듈(22)은 CPU(12)와 통신을 위해 FIM, HIM 및 BMU와 같은 적합한 제어기 모듈을 선택한다. 일 실시예에서, 점선 박스 내 시스템(10)의 모든 성분들은 이를테면 메모리 카드 또는 스틱(10') 내와 같이 단일 유닛 내에 내장될 수 있고 인캡슐레이트되는 것이 바람직하다. 메모리 시스템(10)은 호스트 디바이스(24)에 탈착 가능하게 접속되므로, 시스템(10) 내 콘텐트는 많은 서로 다른 호스트 디바이스들에 의해 액세스될 수 있다.

이하 설명에서, 메모리 시스템(10)은 메모리 디바이스(10)라고도 하고, 또는 간단히 메모리 디바이스 또는 디바이스라고도 한다. 발명이 플래시 메모리들을 참조하여 예시되지만, 발명은 모든 다른 유형들의 재기입가능 비휘발성 메모리 시스템들뿐만 아니라, 이를테면 자기 디스크들, 광학 CD들과 같은 다른 유형들의 메모리들에도 적용할 수 있다.

버퍼 관리유닛(14)은 호스트 다이렉트 메모리 액세스(HDMA)(32), 플래시 다이렉트 메모리 액세스(FDMA)(34), 중재기(arbiter)(36), 버퍼 랜덤 액세스 메모리(BRAM)(38) 및 크립토-엔진(40)을 포함한다. 중재기(36)는 언제든 단지 한 마스 터 또는 선창자(HDMA(32), FDMA(34) 또는 CPU(12)일 수 있는)가 언제든 활성화될 수 있고 슬레이브 또는 타깃은 BRAM(38)이 되도록 하는 공유 버스 중재기이다. 중재기는 적합한 선창자 요청을 BRAM(38)에 채널링하게 한 것이다. HDMA(32) 및 FDMA(34)는 HIM(16)과, FIM(18)과 BRAM(38) 또는 CPU 랜덤 액세스 메모리(CPU RAM)(12a)간에 수송되는 데이터를 맡는다. HDMA(32) 및 FDMA(34)의 동작은 통상적인 것으로 여기에서는 상세히 기술될 필요는 없다. BRAM(38)은 호스트 디바이스(24)와 플래시 메모리(20) 간에 전달되는 데이터를 저장하는데 사용된다. HDMA(32) 및 FDMA(34)는 HIM(16)/FIM(18)과 BRAM(38) 또는 CPU RAM(12a) 간에 데이터를 전송하는 것과 섹터 완료를 나타내게 한 것이다.

일 실시예에서, 메모리 시스템(10)은 암호화 및/또는 해독에 사용되는 키값(들)을 생성하는데, 이 값(들)은 호스트 디바이스(24)와 같은 외부 디바이스들이 실질적으로 액세스될 수 없는 것이 바람직하다. 대안적으로, 키값은 시스템(10) 외부, 이를테면 라이센스 서버에 의해 생성되어 시스템(10)에 보내질 수도 있다. 키값이 어떻게 생성되는지에 관계없이, 일단 키값이 시스템(10)에 저장되면, 인증된 실체들만이 키값에 액세스할 수 있을 것이다. 그러나, 호스트 디바이스는 메모리 시스템(10)에 데이터를 파일들 형태로 읽고 기입하기 때문에, 암호화 및 해독은 전형적으로 파일단위로 행해진다. 많은 그외 다른 유형들의 저장 디바이스들처럼, 메모리 디바이스(10)는 파일들을 관리하지 않는다. 메모리(20)는 파일들의 논리 주소들이 확인되는 파일 할당 테이블(FAT)을 저장하고 있어, FAT는 전형적으로 제어기(12)가 아니라 호스트 디바이스(24)에 의해 액세스되고 관리된다. 그러므로, 특 정 파일 내 데이터를 암호화하기 위해서, 제어기(12)는 메모리(20) 내 파일 내 데이터의 논리 주소들을 보내기 위해 호스트 디바이스에 의존해야 하고, 따라서 특정 파일의 데이터는 시스템(10)만이 사용할 수 있는 키값(들)을 사용하여 시스템에 의해 발견되고 암호화되고 및/또는 해독될 수 있다.

호스트 디바이스(24) 및 메모리 시스템(10) 둘 다가 파일들 내 데이터를 크립토그래픽적으로 처리하기 위해 동일 키(들)를 참조하는 방법을 제공하기 위해서, 호스트 디바이스는 시스템(10)에 생성되거나 이에 의해 보내진 키값들 각각에 대한 참조를 제공하는데, 여기서 이러한 참조는 단순히 키 ID일 수도 있다. 이에 따라, 호스트(24)는 시스템(10)에 의해 크립토그래픽으로 처리되는 각 파일을 키 ID에 연관시키고, 시스템(10)은 데이터를 크립토그래픽으로 처리하는데 사용되는 각 키값을 호스트에 의해 제공된 키 ID에 연관시킨다. 이에 따라, 데이터가 크립토그래픽으로 처리될 것을 호스트가 요청할 때, 메모리(20)로부터 페치(fetch)되거나 이에 저장된 데이터의 논리 주소들과 함께 키 ID와 더불어 요청을 시스템(10)에 보낼 것이다. 시스템(10)은 키값을 생성 또는 수신하고 호스트(24)에 의해 제공된 키 ID를 이러한 값에 연관시키고, 크립토그래픽 처리를 수행한다. 이에 따라, 메모리 시스템(10)이 키값(들)에 대한 배타적 액세스를 포함하여, 키(들)를 사용하여 크립토그래픽 처리를 완전히 제어할 수 있게 하면서도 메모리 시스템(10)이 동작하는 방식에 어떠한 변경도 행할 필요가 없다. 즉, 일단 키값이 시스템(10)에 저장되거나 생성되면, 시스템은 크립토그래픽 처리에 사용되는 키값(들)의 관리를 위한 배타적 제어를 유지하면서도, 호스트(24)가 FAT의 배타적 제어를 취함으로써 계속하여 파 일들을 관리하게 한다. 호스트 디바이스(24)는 키값(들)이 메모리 시스템(10)에 저장된 후, 데이터의 크립토그래픽 처리를 위해 사용되는 키값(들)의 관리에 관계가 없다.

호스트(24)에 의해 제공되는 키 ID 및 메모리 시스템에 보내지거나 이에 의해 생성된 키값은 이하 실시예들 중 한 실시예에서 "콘텐트 암호화 키" 또는 CEK라고 하는 두 속성들의 량을 형성한다. 호스트(24)가 각 키 ID를 하나 이상의 파일들에 연관시킬 수도 있는 한편, 호스트(24)는 각 키 ID를 조직화되지 않은 데이터에, 또는 임의의 방식으로 조직화된 데이터에 연관시킬 수도 있으나, 완전한 파일들로 조직화된 데이터로 제한되는 것은 아니다.

사용자 또는 애플리케이션이 시스템(10) 내 보호된 콘텐트 또는 영역에 액세스할 수 있기 위해서, 시스템(10)에 사전에 등록된 자격증명서(crediential)를 사용하여 인증될 필요가 있을 것이다. 자격증명서는 이러한 자격증명서를 가진 특정 사용자 또는 애플리케이션에 승인된 액세스 권한들에 결부된다. 사전 등록 프로세스에서, 시스템(10)은 사용자 또는 애플리케이션의 아이덴터티(identity) 및 자격증명서, 및 사용자 또는 애플리케이션에 의해 결정되고 호스트(24)를 통해 제공된 이러한 아이덴터티 및 자격증명서에 연관된 액세스 권한들의 레코드를 저장한다. 사전 등록이 완료된 후, 사용자 또는 애플리케이션이 데이터를 메모리(20)에 기입할 것을 요청할 때, 이의 아이덴터티 및 자격증명서, 데이터를 암호화하기 위한 키 ID, 및 암호화된 데이터가 저장될 논리 주소들을 호스트 디바이스를 통해 제공하는 것이 필요할 것이다. 시스템(10)은 키값을 생성 또는 수신하고 이 값을 호스트 디 바이스에 의해 제공된 키 ID에 연관시키고, 기입될 데이터를 암호화하는데 사용되는 키값에 대한 키 ID를 이 사용자 또는 애플리케이션을 위한 레코드 또는 테이블에 저장한다. 이어서 시스템은 데이터를 암호화하고 이 시스템이 생성 또는 수신한 키값 뿐만 아니라 암호화된 데이터를 호스트에 의해 지정된 주소들에 저장한다.

사용자 또는 애플리케이션이 암호화된 데이터를 메모리(20)로부터 읽기를 요청할 때, 이의 아이덴터티 및 자격증명서, 요청된 데이터를 암호화하기 위해 이전에 사용된 키에 대한 키 ID, 및 암호화된 데이터가 저장된 논리 주소들을 제공하는 것이 필요할 것이다. 이어서 시스템(10)은 호스트에 의해 제공된 사용자 또는 애플리케이션 아이덴터티 및 자격증명서를 자신의 레코드에 저장된 것들과 맞추어 볼 것이다. 이들이 일치한다면, 시스템(10)은 이의 메모리부터 사용자 또는 애플리케이션에 의해 제공된 키 ID에 연관된 키값을 페치하고, 호스트 디바이스에 의해 지정된 주소들에 저장된 데이터를 키값을 사용하여 해독하고 해독된 데이터를 사용자 또는 애플리케이션에 보낸다.

인증 자격증명서들을 크립토그래픽 처리에 사용되는 키들의 관리로부터 분리함으로써, 자격증명서를 공유하지 않고 데이터에 액세스할 권한들을 공유하는 것이 가능하다. 이에 따라, 서로 다른 자격증명서들을 가진 일 그룹의 사용자들 또는 애플리케이션들은 동일 데이터에 액세스하기 위해 동일 키들에 액세스할 수 있고, 반면에 이 그룹 밖의 사용자들은 액세스할 수 없다. 그룹 내 모든 사용자들 또는 애플리케이션들이 동일 데이터에 액세스할 수도 있으나, 이들은 여전히 서로 다른 권한들을 가질 수 있다. 이에 따라, 일부는 독출국한 액세스만을 할 수도 있고, 다른 일부는 기입 액세스만을 할 수 있고, 다른 일부는 둘 다를 할 수도 있다. 시스템(10)은 사용자들 또는 애플리케이션 아이덴터티 및 자격증명서들, 이들이 액세스할 수 있는 키 ID들, 및 키 ID들 각각에 연관된 액세스 권한들의 레코드를 유지하기 때문에, 시스템(10)이 키 ID들을 추가 또는 삭제하거나 특정 사용자들 또는 애플리케이션을 위한 이러한 키 ID들에 연관된 액세스 권한들을 변경하거나 한 사용자 또는 애플리케이션을 다른 사용자 또는 애플리케이션에 액세스 권한들을 위임하거나, 사용자들 또는 애플리케이션들을 위한 레코드들 또는 테이블들을 삭제 또는 추가하는 것도 가능하며, 이들 모두는 적합하게 인증된 호스트 디바이스에 의해 제어된다. 저장된 레코드는 어떤 키들을 액세스하기 위해 보안 채널이 필요함을 명시할 수도 있다. 인증은 패스워드들뿐만 아니라 대칭 또는 비대칭 알고리즘들을 사용하여 행해질 수도 있다.

메모리 시스템(10)에 보안 콘텐트의 휴대성은 특히 중요하다. 키값에 대한 액세스가 메모리 시스템에 의해 제어되는 실시예들에서, 시스템을 탑재한 메모리 시스템 또는 저장 디바이스가 한 외부 시스템에서 다른 시스템으로 옮겨질 때, 이에 저장된 콘텐트의 보안이 유지된다. 키가 메모리 시스템에 의해 생성되든 아니면 메모리 시스템 밖에서 발원하든, 외부 시스템들은 이들이 메모리 시스템에 의해 완전히 제어되는 방식으로 인증되지 않았다면, 시스템(10) 내 이러한 콘텐트에 액세스할 수 없다. 이와 같이 인증된 후에도, 액세스는 메모리 시스템에 의해 전적으로 제어되며, 외부 시스템들은 메모리 시스템에 기설정된 레코드들에 따라 제어된 방식으로만 액세스할 수 있다. 요청이 이러한 레코드들에 순응하지 않는다면, 요청은 거절될 것이다.

콘텐트를 보호함에 있어 더 큰 융통성을 제공하기 위해서, 이하 파티션들이라 언급되는 메모리의 어떤 영역들이 적합하게 인증된 사용자들 또는 애플리케이션들에 의해서만 액세스될 수 있음이 고찰된다. 키를 기반으로 하는 데이터 암호화의 전술한 특징들과 결합되었을 때, 시스템(10)은 더 큰 데이터 보호 능력을 제공한다. 도 2에 도시된 바와 같이, 플래시 메모리(20)는 다수의 파티션들로서 사용자 영역 또는 파티션 및 커스텀 파티션들로 분할된 저장용량을 가질 수 있다. 사용자 영역 또는 파티션(PO)은 인증 없이 모든 사용자들 및 애플리케이션들이 액세스할 수 있다. 사용자 영역에 저장된 데이터의 모든 비트 값들이 임의의 애플리케이션 또는 사용자에 의해 독출 또는 기입될 수 있는데, 독출된 데이터가 암호화된다면, 해독할 권한이 없는 사용자 또는 애플리케이션은 사용자 영역에 저장된 비트 값들에 의해 나타내어진 정보에 액세스할 수 없을 것이다. 이것이, 예를 들면, 사용자 영역(P0)에 저장된 파일들(102, 104)에 의해 도시되었다. 또한, 사용자 영역에는 모든 애플리케이션들 및 사용자들에 의해 독출되어 이해될 수 있는 106과 같은 암호화되지 않은 파일들이 저장된다. 이에 따라, 암호화된 파일들은 파일들(102, 104)에 대한 것과 같이 이들에 연관된 록들(lock)로 기호로 도시되어 있다.

사용자 영역(P0) 내 암호화된 파일이 권한없는 애플리케이션들 또는 사용자들에 의해 이해될 수 없으나, 이러한 애플리케이션들 또는 사용자들은 여전히 파일을 삭제 또는 변질시킬 수 있어, 이는 일부 애플리케이션들에게 바람직하지 않을 수 있다. 이 목적을 위해서, 메모리(20)는 사전 인증 없이 액세스될 수 없는 파티 션(P1,P2)과 같은 보호된 커스텀 파티션을 포함한다. 이 출원에서 실시예들에서 허용되는 인증 프로세스가 이하 설명된다.

도 2에도 도시된 바와 같이, 다양한 사용자들 또는 애플리케이션들이 메모리(20) 내 파일들에 액세스할 수 있다. 이에 따라 사용자 1 및 사용자 2, 애플리케이션들 1 ~ 4(디바이스들 상에서 동작하는)가 도 2에 도시되었다. 메모리(20) 내 보호된 콘텐트에 액세스할 것이 이들 실체들에 허용되기 전에, 이들은 먼저 후술하는 방식으로 인증 프로세스에 의해 인증된다. 이 프로세스에서, 액세스를 요청하고 있는 실체는 역할 기반 액세스 제어를 위해 호스트 측에서 확인될 필요가 있다. 이에 따라, 액세스를 요청하는 실체를 이를테면 "나는 애플리케이션 2이며 파일 1을 읽기를 원한다"와 같은 정보를 공급함으로써 자신을 확인시킨다. 이어서 제어기(12)는 메모리(20) 또는 제어기(12)에 저장된 레코드에 대해서 아이덴터티, 인증정보 및 요청과 맞추어 본다. 모든 요구사항들이 충족된다면, 이러한 실체에 액세스가 승인된다. 도 2에 도시된 바와 같이, 파티션(P1) 내 파일(101)로부터 읽고 이에 기입하는 것이 사용자 1에 허용되나, 사용자 1가 P0 내 파일들(106)로부터 읽고 이에 기입하는 제약없는 권한들을 갖는 것 외에 파일들(102, 104)만을 읽을 수 있다. 반면, 사용자 2는 파일(101, 104)에 액세스가 허용되지 않으나 파일(102)에 독출 및 기입 액세스를 할 수 있다. 도 2에 나타낸 바와 같이, 사용자 1 및 사용자 2는 동일 로그인 알고리즘(AES)을 가지나 애플리케이션들 1 및 3은 사용자 1 및 사용자 2과도 다른 서로 다른 로그인 알고리즘들(예를 들면, RSA 및 001001)을 갖는다.

보안 저장 애플리케이션(SSA)은 메모리 시스템(10)의 보안 애플리케이션이고 위에 언급된 다수의 특징들을 구현하는데 사용될 수 있는 발명의 실시예를 예시한다. SSA는 메모리(20) 또는 CPU(12) 내 비휘발성 메모리(도시되지 않음)에 저장된 데이터베이스와 함께 소프트웨어 또는 컴퓨터 코드로서 실현될 수 있고, RAM(12a) 내 읽혀져 CPU(12)에 의해 실행된다. SSA에 관련하여 사용되는 두문자어들을 이하 표에 나타내었다.

정의, 두문자어 및 약어

ACR	액세스 제어 레코드들
AGP	ACR 그룹
CBC	체인 블록 사이퍼(cipher)
CEK	콘텐트 암호화 키
ECB	전자 코드북
ACAM	ACR 속성 관리
PCR	허가 제어 레코드
SSA	보안 저장 애플리케이션
실체	SSA에 로그인하며, 이에 따라 그의 기능들을 이용하는 실제의 개별적 존재(호스트측)를 갖는 임의의 것.

SSA 시스템 설명

데이터 보안, 무결성 및 액세스 제어가 SSA의 주 역할들이다. 데이터는 다른 경우라면 명백히 어떤 종류의 대량 저장 디바이스에 저장되었을 파일들이다. SSA 시스템은 저장 시스템의 최상부에 놓이고 저장된 호스트 파일들을 위한 보호층을 부가하여 후술되는 보안 데이터 구조들을 통해 보안 기능들을 제공한다.

SSA의 주임무는 메모리 내 저장된(및 보안된) 콘텐트에 연관된 서로 다른 권한들을 관리하는 것이다. 메모리 애플리케이션은 복수의 사용자들 및 복수의 저장된 콘텐트에 대한 콘텐트 권한들을 관리하는 것을 필요로 한다. 호스트 애플리케이 션들은 이들 측에서, 이러한 애플리케이션들이 알 수 있는 드라이브들 및 파티션들, 및 저장 디바이스 상에 저장된 파일들의 위치들을 관리하고 기술하는 파일 할당 테이블들(FAT)를 파악한다.

이 경우 저장 디바이스는 파티션들로 분할된 NAND 플래시 칩을 사용하나, 그러나 이외 다른 이동 저장 디바이스들도 사용될 수 있고 이 발명의 범위 내에 있다. 이들 파티션들은 시작 및 끝 주소가 이들의 경계들을 정의하는, 논리 주소들의 연속된 스레드(thread)이다. 그러므로 요망된다면, 은닉된 파티션에 대한 액세스에 제약들이, 이러한 경계들 내에 주소들에 이러한 제약을 연관시키는 소프트웨어(이를테면 메모리(20)에 저장된 소프트웨어)에 의해, 부과될 수 있다. 파티션들은 SSA에 의해 관리되는 이들 파티션들이 논리 주소 경계들에 의해 SSA에 완전히 인식될 수 있다. SSA 시스템은 권한없는 호스트 애플리케이션들로부터 데이터를 물리적으로 보안이 되게 하기 위해 파티션들을 사용한다. 호스트에게 있어, 파티션들은 데이터 파일들을 저장할 전유 공간들을 정의하는 메커니즘이다. 이들 파티션들은 저장 디바이스에 액세스할 수 이는 어느 누구든 디바이스 상에 파티션의 존재를 보고 알 수 있는 공개인 것일 수도 있고, 또는 선택된 호스트 애플리케이션들만이 저장 디바이스 내 이들의 존재에 액세스하여 이들을 알 수 있는 사설 또는 은닉된 것일 수도 있다.

도 3은 메모리의 파티션들로서 P0, P1, P2 및 P3(자명하게 4개보다 덜 또는 더 많은 파티션들이 채용될 수 있다)을 도시한 메모리의 개략도로서, P0는 인증 없이 임의의 실체에 의해 액세스될 수 있는 공개 파티션이다.

사설 파티션(이를테면 Pl, P2 또는 P3)은 이 내에 파일에 대한 액세스를 숨긴다. 호스트가 파티션에 액세스하지 못하게 함으로써, 플래시 디바이스(예를 들면, 플래시 카드)는 데이터 파일들의 보호를 파티션에 전달한다. 그러나, 이러한 종류의 보호는 파티션 내 논리 주소들에 저장된 데이터에 대한 액세스에 제약들을 부과함으로써 은닉된 파티션에 상주하는 모든 파일들을 포함해버린다. 즉, 제약들은 한 범위의 논리 주소들에 연관된다. 이 파티션에 액세스할 수 있는 모든 사용자들/호스트들은 내부에 모든 파일들에 무제한으로 액세스할 수 있을 것이다. 서로 다른 파일들을 서로간에 -또는 다수 그룹들의 파일들과- 분리하기 위해서, SSA 시스템은 파일 -또는 다수 그룹들의 파일들- 마다 다른 레벨의 보안 및 무결성을, 키들 및 키 참조들 또는 키 ID들을 사용하여 제공한다. 서로 다른 메모리 주소들에 데이터를 암호화하는데 사용되는 특정 키값의 키 참조 또는 키 ID는 암호화된 데이터를 내포하는 컨테이너 또는 도메인과 유사할 수 있다. 이러한 이유로, 도 4에서, 키 참조 또는 키 ID들(예를 들면, "키 1" 및 "키 2)")이, 키 ID들에 연관된 키값들을 사용하여 암호화된 파일들을 둘러싸는 영역들로서 그래픽적으로 도시되었다.

도 4를 참조하면, 예를 들면, 파일 A는 어떠한 키 ID에 의해서도 둘러싸이지 않은 것으로서 도시되었기 때문에, 어떠한 인증도 없이 모든 실체들이 액세스할 수 있다. 공개 파티션 내 파일 B가 모든 실체들에 의해 독출 또는 덮어 쓰일 수 있을지라도, 이것은 ID "키 1"을 가진 키로 암호화된 데이터를 내포하므로, 파일 B에 내포된 정보는 실체가 이러한 키에 액세스할 수 없다면 이러한 실체가 액세스할 수 없다. 따라서 키값들 및 키 참조 또는 키 ID들을 사용하는 것은 위에 기술된 파티 션에 의해 제공된 보호의 유형과는 반대로, 논리적 보호만을 제공한다. 그러므로, 파티션(공개 또는 사설)에 액세스할 수 있는 어떠한 호스트이든 암호화된 데이터를 포함하여, 전체 파티션에 데이터를 독출 또는 기입할 수 있다. 그러나 데이터가 암호화되기 때문에, 권한없는 사용자들은 이를 변질시킬 수 있을 뿐이다. 이들은 데이터를 변경한 경우 검출할 수 있는 것이 바람직하다. 암호화 및/또는 해독 키에 대한 액세스를 제약하여, 이 특징은 권한있는 실체들만이 데이터를 사용하게 할 수 있다. 파일 B 및 파일 C는 P0에서 키 ID "키 2"를 가진 키를 사용하여 암호화된다.

데이터 기밀성 및 무결성은 콘텐트 암호화 키들(CEK)마다 하나로, CEK를 사용하는 대칭 암호화 방법들을 통해 제공될 수 있다. SSA 실시예에서, CEK들에서 키값들은 플래시 디바이스(예를 들면, 플래시 카드)에 의해 생성 또는 수신되고, 내부적으로만 사용되고, 외부 세계로부터 비밀들로서 유지된다. 암호화 또는 사이퍼되는 데이터는 해시될 수도 있고 또는 사이퍼는 데이터 무결성을 보장하기 위해 체인 블록된다.

파티션 내 모든 데이터가 서로 다른 키들에 의해 암호화되고 서로 다른 키 ID들에 연관되는 것은 아니다. 공개 또는 사용자 파일들 또는 운영 시스템 영역(즉 FAT)에 어떤 논리 주소들은 임의의 키 또는 키 참조에 연관되지 않을 수 있고 따라서 파티션 자체에 액세스할 수 있는 어떠한 실체든 사용할 수 있다.

파티션들로부터 데이터를 기입하고 독출하거나 키들을 사용하는 것뿐만 아니라 키들 및 파티션들을 생성하는 능력을 요구하는 실체는 액세스 제어 레코드(ACR)를 통해 SSA 시스템에 로그인할 필요가 있다. SSA 시스템에서 ACR의 특전 들(privilege)은 작업들(Action)이라고 한다. 모든 ACR은 다음 3개의 범주들, 즉 파티션들 및 키들/키 ID들을 생성, 파티션들 및 키들에 액세스 및 다른 ACR들을 생성/업그레이드하는 작업들을 수행할 허가를 가질 수도 있다.

ACR들은 ACR 그룹들 또는 AGP들이라고 하는 그룹들로 조직된다. 일단 ACR이 성공적으로 인증되면, SSA 시스템은 ACR의 작업들 어느 것이 실행될 수 있게 하는 세션을 연다. ACR들 및 AGP들은 정책들에 따라 파티션들 및 키들에 액세스를 제어하는데 사용되는 보안 데이터 구조들이다.

사용자 파티션(들)

SSA 시스템은 사용자 파티션(들)이라고도 하는 하나 이상의 공개 파티션들을 관리한다. 이 파티션은 저장 디바이스 상에 존재하며 저장 디바이스의 표준 독출 기입 명령들을 통해 액세스될 수 있는 파티션 또는 파티션들이다. 디바이스 상에 파티션의 존재뿐만 아니라 파티션(들)의 크기에 관해 정보를 얻는 것은 호스트 시스템으로부터 감추어질 수 없다.

SSA 시스템은 이 파티션(들)을 표준 기입 독출 명령들 또는 SSA 명령들을 통해 액세스할 수 있게 한다. 그러므로, 파티션에 액세스하는 것은 바람직하게는 특정 ACR들로 제약될 수 없다. 그러나, SSA 시스템은 사용자 파티션에 대한 액세스를 호스트 디바이스들이 제약할 수 있게 할 수 있다. 독출 및 기입 액세스들은 개별적으로 활성화/비활성화될 수 있다. 모든 4개의 조합들(예를 들면, 기입국한, 독출국한(기입 보호), 독출 및 기입 및 액세스 불가)가 허용된다.

SSA 시스템은 ACR들이 사용자 파티션 내 파일들에 키 ID들을 연관시키고 이 러한 키 ID들에 연관된 키들을 사용하여 개개의 파일들을 암호화시킬 수 있게 한다. 파티션들에 액세스 권한들을 설정할 뿐만 아니라 사용자 파티션들 내 암호화된 파일들에 액세스하는 것은 SSA 명령 세트를 사용하여 행해질 것이다. 위에 특징들은 파일들로 조직되지 않은 데이터에도 적용한다.

SSA 파티션들

이들은 SSA 명령들을 통해서만 액세스될 수 있는 은닉된(비인증된 당사자들로부터) 파티션들이다. SSA 시스템은 바람직하게는, ACR에 로그온함으로써 수립되는 세션(후술함)을 통한 것 외에, 호스트 디바이스가 SSA 파티션에 액세스하지 못하게 할 것이다. 마찬가지로, 바람직하게 SSA는 SSA 파티션의 존재, 크기 및 액세스 허가에 관해 정보를, 이 요청이 수립된 세션을 통해 오지 않는다면, 제공하지 않을 것이다.

파티션에 대한 액세스 권한들은 ACR 허가들로부터 도출된다. 일단 ACR이 SSA 시스템에 로그인 되면, 파티션을 다른 ACR들(후술함)과 공유할 수 있다. 파티션이 생성될 때, 호스트는 파티션에 대한 참조 이름 또는 ID(예를 들면, 도 3 및 도 4에서 P0 ~ P3)을 제공한다. 이 참조는 파티션의 이후 독출 및 기입 명령들에서 사용된다.

저장 디바이스 파티션

디바이스의 모든 가용한 저장용량은 바람직하게는 사용자 파티션 및 현재 구성된 SSA 파티션들에 할당된다. 그러므로, 어떠한 재-파티션(repartition) 동작이든 현존 파티션들의 재구성을 수반할 수 있다. 디바이스 용량(모든 파티션들의 크 기들의 합)에 순 변화는 제로가 될 것이다. 디바이스 메모리 공간에서 파티션들의 ID들은 호스트 시스템에 의해 정의된다.

호스트 시스템은 현존 파티션들을 2개의 보다 작은 파티션들로 재 파티션하거나, 2개의 현존 파티션들(이웃하여 있을 수도 있고 그렇지 않을 수도 있다)을 하나로 합체할 수 있다. 분할 또는 합체된 파티션들 내 데이터는 호스트의 재량으로 소거되거나 그대로 놔둘 수 있다.

저장 디바이스의 재 파티션은 데이터의 유실을 야기할 수 있기 때문에(소거되었거나 아니면 저장 디바이스의 논리 주소 공간에서 이동되었기 때문에) 재 파티션에 엄격한 제약들은 SSA 시스템에 의해 관리된다. 루트 AGP(후술함)에 상주하는 ACR만이 재 파티션 명령을 발행하는 것이 허용되고 이에 의해 소유된 파티션들을 참조할 수 있을 뿐이다. SSA 시스템은 데이터가 파티션들에서 어떻게 조직되었는지를(FAT 또는 그외 다른 파일 시스템 구조) 모르기 때문에, 디바이스가 재 파티션되는 언제든 이들 구조들을 재구성하는 것이 호스트의 의무이다.

사용자 파티션의 재 파티션은 호스트 OS에 의해 본 이 파티션의 크기 및 그외 속성들을 변경시킬 것이다.

재 파티션 후, SSA 시스템 내 어떠한 ACR이든 존재하지 않는 파티션들을 참조하지 않게 하는 것이 호스트 시스템의 의무이다. 이들 ACR들이 삭제되지 않거나 적합하게 업그레이드된다면, 이들 ACR들을 대신하여, 존재하지 않는 파티션들에 액세스하려는 차후의 시도들이 시스템에 의해 검출되어 거절될 것이다. 삭제된 키들 및 키 ID들에 관하여, 유사한 주의가 취해진다.

키들, 키 ID들 및 논리 보호

파일이 어떤 은닉된 파티션에 기입될 때, 이것은 일반적인 공개로부터 은닉된다. 그러나, 실체(적대적인 또는 아닌)가 이 파티션을 알고 이에 액세스할 수 있게 되면, 파일은 입수가 가능해지고 보기가 용이해진다. 파일을 더 보안이 되게 하기 위해서, SSA는 이를 은닉된 파티션에서 암호화할 수 있고, 이 경우 파일을 해독하기 위한 키에 액세스하기 위한 자격증명서들은 파티션에 액세스하기 위한 것들과는 다른 것이 바람직하다. 파일들이 호스트에 의해 완전히 제어되고 관리된다는 사실에 기인하여, CEK를 파일에 연관시키는 것은 문제가 된다. SSA가 수신응답하는 어떤 것, 즉 키 ID에 파일을 링크하는 것은 이것을 제거한다. 따라서, 키가 SSA에 의해 생성될 때, 호스트는 이를 위한 키 ID를 SSA에 의해 생성된 키를 사용하여 암호화된 데이터에 연관시킨다. 키가 키 ID와 함께 SSA에 보내진다면, 키 및 키 ID는 서로 쉽게 연관될 수 있다.

키값 및 키 ID는 논리적 보안을 제공한다. 주어진 키 ID의 위치에 관계없이, 이에 연관된 모든 데이터는 호스트 애플리케이션에 의한 생성에서 유일하게 제공되는 참조 이름 또는 키 ID를 갖는 콘텐트 암호화 키(CEK) 내 동일 키값으로 사이퍼된다. 실체가 은닉된 파티션에 대한 액세스를 얻고(ACR을 통해 인증함으로써) 이 파티션 내 암호화된 파일을 독출하거나 기입하기를 원한다면, 파일에 연관된 키 ID에 액세스할 수 있을 필요가 있다. 이 키 ID에 대한 키에 대한 액세스를 승인할 때, SSA는 이 키 ID에 연관된 CEK에 키값을 로딩하고, 데이터를 호스트에 보내기 전에 이를 해독하거나 데이터를 플래시 메모리(20)에 기입하기 전에 이 데이터를 암호화한다. 일 실시예에서, 키 ID에 연관된 CEK에서 키값은 SSA 시스템에 의해 한번 랜덤하게 생성되고 이 SSA 시스템에 의해 유지된다. SSA 시스템 밖의 어떠한 것도 CEK 내 이 키값을 모르고 이에 액세스할 수 없다. 외부 세계는 CEK 내 키값이 아닌, 참조 또는 키 ID만을 제공하고 사용한다. 키값은 SSA에 의해 전적으로 관리되고 바람직하게 이에 의해서만 액세스될 수 있다. 대안적으로, 키는 SSA 시스템에 제공될 수 있다.

SSA 시스템은 다음 사이퍼 모드들 중 어떤 것(사용자가 정한)을 사용하여 키 ID에 연관된 데이터를 보호한다(CEK들 내 키값들 뿐만 아니라, 사용된 실제 크립토그래픽 알고리즘들은 시스템 제어되고 외부 세계에 드러나지 않는다).

블록 모드 - 데이터는 블록들로 분할되고, 이들 각각은 개별적으로 암호화된다. 이 모드는 덜 보안적이고 일반적으로 사전 공격들(dictionary attack)을 받기 쉽다. 그러나, 이것은 사용자들이 데이터 블록들 중 어느 것을 랜덤하게 액세스할 수 있게 할 것이다.

체인모드(Chained mode) - 데이터는 블록들로 분할되고, 이들 블록들은 암호화 프로세스 동안 체인된다. 모든 블록은 다음 블록의 암호화 프로세스에 입력들 중 하나로서 사용된다. 이 모드에서, 데이터는 보다 보안적인 것으로서 간주될지라도, 데이터는 시작부터 끝까지 순차적으로 기입되고 독출되어, 사용자들이 수락할 수 없을 수 있는 오버헤드를 야기한다.

해시(Hashed) - 데이터 무결성을 유효화하는데 사용될 수 있는 데이터 다이제스트의 추가의 생성을 가진 체인 모드

ACR들 및 액세스 제어

SSA는 복수의 애플리케이션들의 각각이 시스템 데이터베이스에서 노드들의 나무로서 표현되는 이들 복수의 애플리케이션들을 취급하게 설계된다. 애플리케이션들간에 상호배타는 나무 가지들간에 어떠한 크로스토크도 없게 함으로써 달성된다.

SSA 시스템에 액세스를 할 수 있기 위해서, 실체는 시스템의 ACR들 중 하나를 통해 접속을 수립하는 것이 필요하다. 로그인 절차들은 사용자가 접속하기로 선택한 ACR 내에 있는 정의들에 따라 SSA 시스템에 의해 관리된다.

ACR은 SSA 시스템에 대한 개별적 로그인 포인트이다. ACR은 로그인 자격증명서들 및 인증 방법을 유지한다. 또한, 레코드에 상주하는 것은 SSA 시스템 내 로그인 허락들이며, 이들 중에는 독출특전 및 기입특전이 있다. 이것이 도 5에 도시되었으며, 도 5는 동일 AGP에 n개의 ACR들을 도시하고 있다. 이것은 n개의 ACR들 중 적어도 일부는 동일 키에 대한 액세스를 공유할 수 있음을 의미한다. 이에 따라, ACR #1 및 ACR #n은 키 ID "키 3"을 가진 키에 대한 액세스를 공유하며, 여기서 ACR#1 및 ACR#n은 ACR ID들이며, "키 3"은 "키 3"에 연관된 데이터를 암호화하는데 사용되는 키에 대한 키 ID이다. 동일 키가 복수의 파일들, 또는 복수 세트들의 데이터를 암호화 및/또는 해독하는데 사용될 수도 있다.

SSA 시스템은 일단 사용자가 성공적으로 로그인하였으면 시스템에서 사용자의 특전들일 수 있으므로, 인증 알고리즘들 및 사용자 자격증명서들이 다를 수 있는 시스템에 대한 몇 가지 유형들의 로그인을 지원한다. 다시, 도 5는 서로 다른 로그인 알고리즘들 및 자격증명서들을 도시한다. ACR#1은 패스워드 로그인 알고리즘 및 패스워드를 자격증명서로서 명시하며 반면 ACR#2는 PKI(공개키 기반구조) 로그인 알고리즘 및 공개키를 자격증명서로서 명시한다. 이에 따라, 로그인하기 위해서, 실체는 정확한 로그인 알고리즘 및 자격증명서뿐만 아니라, 유효한 ACR ID를 제시할 필요가 있을 것이다.

일단 실체가 SSA 시스템의 ACR에 로그인 되면, 이의 허가들 -SSA 명령들을 사용할 권한들- 은 ACR에 연관된 허가 제어 레코드(PCR)에 정의된다. 도 5에서, ACR#1은 "키 3"에 연관된 데이터에 대한 독출국한 허가를 승인하고, ACR #2는 보인 PCR에 따라 "키 5"에 연관된 데이터를 독출 및 기입하는 허가를 승인한다.

서로 다른 ACR들은 독출 및 기입할 키들에서와 같이 시스템에서 공통의 권리(interests) 및 특전들을 공유할 수 있다. 이것을 달성하기 위해서, 공통으로 어떤 것을 가진 ACR들은 AGP들 - ACR 그룹들로 그룹화된다. 이에 따라, ACR #1 및 ACR #n은 키 ID "키 3"을 가진 키에 대한 액세스를 공유한다.

AGP들 및, 이 내에 ACR들은 계층 나무들로 조직되고 따라서 민감(sensitive) 데이터를 보안이 되게 유지하는 보안 키들을 생성하는 것을 제외하고, ACR은 바람직하게는 자신의 키 ID/파티션들에 대응하는 다른 ACR 엔트리들을 생성할 수 있다. 이들 ACR 자식들은 이들의 부(father) -생성자와 동일한 또는 미만이 허가들을 가질 것이며, 자식들에 부 ACR 자신이 생성한 키들에 대한 허가들이 주어질 수 있다. 추가할 필요 없이, 자식 ACR들은 이들이 생성하는 임의의 키에 액세스 허가들을 얻는다. 이것이 도 6에 도시되었다. 이에 따라, AGP(120)에 모든 ACR들은 ACR(122)에 의해 생성되었으며 이러한 ACR들 중 2개는 "키 3"에 연관된 데이터에 액세스할 허가(들)를 ACR(122)로부터 물려받는다.

AGP

SSA 시스템에 로그인 하는 것은 AGP 및 AGP 내 ACR를 명시함으로써 행해진다.

모든 AGP는 고유의 ID(참조 이름)을 가지며, 이것은 SSA 데이터베이스에서 자신의 엔트리에 대한 색인으로서 사용된다. AGP가 생성될 때, SSA 시스템에 AGP 이름이 제공된다. 제공된 AGP 이름이 이미 시스템에 존재한다면, SSA는 생성 동작을 거절할 것이다.

AGP들은 다음 절들에서 기술되는 바와 같이 액세스 및 관리 허가들의 위임에 관한 제약들을 관리하는데 사용된다. 도 6에서 2개의 나무들에 의해 제공되는 기능들 중 하나는 이를테면 2개의 서로 다른 애플리케이션들, 또는 서로 다른 두 컴퓨터 사용자들과 같은, 전적으로 개별적 실체들에 의한 액세스를 관리하는 것이다. 이러한 목적들을 위해서, 2개의 액세스 프로세스들이, 이들 둘이 동시에 일어날지라도, 실질적으로 서로 무관하게 하는 것이(즉, 실질적으로 크로스-토크가 전혀 없게) 중요할 수 있다. 이것은 각 나무에서 추가의 ACR들 및 AGP들의 생성뿐만 아니라 허가들은 다른 나무의 것들에 연결되지 않고 이들에 의존하지 않음을 의미한다. 그러므로, SSA 시스템이 메모리(10)에서 사용될 때, 이것은 메모리 시스템(10)이 복수의 애플리케이션들에 동시에 서비스할 수 있게 한다. 또한, 이것은 2개의 애플리케이션들이 개별적인 2 세트들의 데이터를 서로에 무관하게 액세스할 수 있게 한 다(예를 들면, 한 세트의 사진들 및 한 세트의 곡들). 이것이 도 6에 도시되었다. 이에 따라, 도 6의 윗부분에 나무에 노드들(ACR들)을 통해 액세스하는 애플리케이션 또는 사용자를 위한 "키 X" 및 "키 Z"은 사진들을 포함할 수 있다. 도 6에 아랫부분에 나무의 노드들(ACR들)을 통해 액세스하는 애플리케이션 또는 사용자를 위한 "키 5" 및 "키 Y"에 연관된 데이터는 곡들을 포함할 수 있다. AGP를 생성한 ACR은 AGP가 ACR 엔트리들이 없을 때만 이를 삭제할 허가를 갖는다.

실체의 SSA 엔트리 점: 액세스 제어 레코드(ACR)

SSA 시스템에 ACR은 시스템에 로그인하는 것이 실체에 허락되는 방법을 기술한다. 실체가 SSA 시스템에 로그인할 때 실체는 수행하려고 하는 인증 프로세스에 대응하는 ACR를 명시할 필요가 있다. ACR은 도 5에 도시된 ACR에 정의된 바와 같이 일단 인증되면 사용자가 실행할 수 있는 승인된 작업들을 예시하는 허가 제어 레코드(PCR)를 포함한다. 호스트측 실체는 모든 ACR 데이터 필드들을 제공한다.

실체가 성공적으로 ACR에 로그인 되었을 때, 실체는 ACR의 모든 파티션 및 키 액세스 허가들 및 ACAM 허가들(후술함)에 대해 조회할 수 있을 것이다.

ACR ID

SSA 시스템 실체가 로그인 프로세스를 시작할 때 이 시스템은 로그인 방법에 대응하는 ACR ID(ACR이 생성되었을 때 호스트에 의해 제공되는)을 명시할 필요가 있고 따라서 SSA는 정확한 알고리즘을 셋업하고 모든 로그인 요구사항들이 충족되었을 때 정확한 PCR을 선택할 것이다. ACR이 생성되었을 때 ACR ID가 SSA 시스템에 제공된다.

로그인/인증 알고리즘

인증 알고리즘은 어떤 종류의 로그인 절차가 실체에 의해 사용될 것인지와, 사용자의 아이덴터티의 증명을 제공하기 위해 어떤 종류의 자격증명서들이 필요로 되는지를 명시한다. SSA 시스템은 무 절차(및 무 자격증명서) 및 패스워드 기반 절차들 내지는 대칭 또는 비대칭 크립토그래피에 기초한 양방향 인증 프로토콜들 범위의 몇 가지 표준 로그인 알고리즘들을 지원한다.

자격증명서들

실체의 자격증명서들은 로그인 알고리즘에 대응하며, 사용자를 검증하고 인증하기 위해 SSA에 의해 사용된다. 자격증명서에 대한 예는 패스워드 인증을 위한 패스워드/PIN-번호, AES 인증을 위한 AES-키 등일 수 있다. 자격증명서들의 유형/포맷(즉, PIN, 대칭키 등...)은 기정의되고 인증 모드로부터 도출되는데, 이들은 ACR이 생성될 때 SSA 시스템에 제공된다. 디바이스(예를 들면, 플래시 카드)가 RSA를 생성하는데 사용될 수 있거나 증명서 생성을 위해 다른 유형의 키 쌍 및 공개 키가 이출(exported)될 수 있는 PKI 기반의 인증은 제외하고, SSA 시스템은 전술한 자격증명서들을 정의, 분배 및 관리와는 무관하다.

허가 제어 레코드(PCR)

PCR은 SSA 시스템에 로그인하고 ACR의 인증 프로세스를 성공적으로 통과한 후에 실체에 무엇이 승인되지는지를 보여준다. 3가지 유형들의 허가 범주들로서, 파티션 및 키들에 대한 생성 허가들, 파티션들 및 키들에 대한 액세스 허가들, 및 실체-ACR 속성들에 대한 관리 허가들이 있다.

파티션들에 액세스

PCR의 이 절은 ACR 국면을 성공적으로 완료하였을 때 실체가 액세스할 수 있는 파티션들의 리스트(SSA 시스템에 제공된 이들의 ID들을 사용한)를 내포한다. 각각의 파티션에 대해서 액세스 유형은 기입국한 또는 독출국한으로 제약될 수 있고 또는 완전한 기입/액세스 권한들을 명시할 수도 있다. 이에 따라, 도 5에서 ACR#1은 파티션 #1이 아니라 파티션 #2에 액세스할 수 있다. PCR에 명시된 제약들은 SSA 파티션들 및 공개 파티션에 적용한다.

공개 파티션은 SSA 시스템을 호스트하는 디바이스(예를 들면, 플래시 카드)에 정규(regular) 독출 및 기입 명령들에 의해서, 또는 SSA 명령들에 의해서 액세스될 수 있다. 공개 파티션을 제약하는 허가를 갖고 루트 ACR(후술함)이 생성될 때, 이를 자신의 자식들에게 넘길 수 있다. 바람직하게 ACR은 공개 파티션에 액세스하는 것으로부터 정규 독출 및 기입 명령들을 제약할 수 있을 뿐이다. SSA 시스템에서 ACR들은 바람직하게 이들의 생성시에만 제약될 수 있다. 일단 ACR이 공개 파티션으로부터/에 독출/기입하는 허가를 갖게 되면, 바람직하게 ACR은 제거될 수 없다.

키 ID에 대한 액세스

PCR의 이 절은 ACR 정책들이 실체의 로그인 프로세스에 의해 충족되었을 때 실체가 액세스할 수 있는 키 ID들의 리스트(호스트에 의해 SSA 시스템에 제공된)에 연관된 데이터를 내포한다. 명시된 키 ID는 PCR에서 나타나는 파티션에 상주하는 파일/파일들에 연관된다. 키 ID들은 디바이스(예를 들면, 플래시 카드)에서 논리 주소들에 연관되지 않기 때문에, 하나보다 더 많은 파티션이 특정 ACR에 연관될 때, 파일들은 파티션들 중 하나에 있을 수 있다. PCR에 명시된 키 ID들은 각각, 상이한 한 세트의 액세스 권한들을 가질 수 있다. 키 ID들에 의해 가리켜진 데이터에 액세스하는 것은 기입국한 또는 독출국한으로 제약될 수 있고 또는 완전한 기입/독출 액세스 권한들을 명시할 수도 있다.

ACR 속성 관리(ACAM)

이 절은 어떤 경우들에서 ACR의 시스템 속성들이 변경될 수 있는지를 기술한다.

SSA 시스템에서 허용될 수 있는 ACAM 작업들은 다음과 같다.

1. AGP들 및 ACR을 생성/삭제/업데이트

2. 파티션들 및 키들을 생성/삭제

3. 키들 및 파티션들에 액세스 권한들을 위임

부(father) ACR는 바람직하게는 ACAM 허가들을 편집할 수 없다. 이것은 바람직하게는 ACR의 삭제 및 재생성을 필요로 할 것이다. 또한, ACR에 의해 생성된 키 ID에 액세스 허가는 바람직하게, 제거될 수 없다.

ACR은 다른 ACR들 및 AGP들을 생성하는 역량을 가질 수 있다. CR들을 생성하는 것은 이들에 이들의 생성자에 의해 소유된 ACAM 허가들 일부 또는 모두를 위임하는 것을 의미할 수도 있다. ACR들을 생성하는 허가를 갖는다는 것은 다음 작업들에 대한 허가를 갖는다는 것을 의미한다.

1. 자식의 자격증명서들을 정의하고 편집한다 - 인증방법은 바람직하게는 생 성하는 ACR에 의해 일단 설정되면 편집될 수 없다. 자격증명서들은 이미 자식에 대해 정의된 인증 알고리즘의 경계 내에서 변경될 수 있다.

2. ACR을 삭제한다.

3. 생성하는 허가를 자식 ACR에 위임한다(이에 따라 손자를 갖는다).

다른 ACR들을 생성하는 허가들을 가진 ACR은 이것이 생성하는 ACR들을 언블록(unblock) 허가를 위임하는 허가를 갖는다(비록 아마도 ACR들을 언블록하는 허가를 갖고 있지 않을지라도). 부(father) ACR은 자식 ACR에 그의 언블록커(unbloker)에 대한 참조를 배치할 것이다.

부(father) ACR는 자신의 자식 ACR을 삭제하는 허가를 갖는 유일한 ACR이다. ACR이 자신이 생성한 저 레벨의 ACR을 삭제할 때, 이 저 레벨 ACR이 만들어낸 모든 ACR들도 자동적으로 삭제된다. ACR이 삭제될 때 이것이 생성한 모든 키 ID들 및 파티션들은 삭제된다.

ACR이 이 자신의 레코드를 업데이트할 수 있게 되는 2가지 예외들이 있다.

1. 생성자 ACR에 의해 설정될지라도, 패스워드들/PIN들은 이들을 포함하는 ACR에 의해서만 업데이트될 수 없다.

2. 루트 ACR은 자신 및 이것이 상주되는 ACP를 삭제할 수도 있다.

액세스 권한들을 키들 및 파티션들에 위임

ACR들 및 이들의 AGP들은 루트 AGP 및 이 내에 ACR들이 나무의 맨 위(예를 들면, 도 6에서 루트 AGP들(130, 132))에 있는 계층 나무들에 조립된다. SSA 시스템에 몇 개의 AGP 나무들이 서로간에 완전히 분리될지라도 이들이 있을 수 있다. AGP 내 ACR은 이의 키들에 대한 액세스 허가들을 이 ACR이 내에 있는 동일 AGP 내 모든 ACR들에, 그리고 이들에 의해 생성된 모든 ACR들에 위임할 수 있다. 키들을 생성하는 허가는 바람직하게는 키들을 사용하기 위해 액세스 허가들을 위임하는 허가를 포함한다.

키들에 대한 허가들은 3가지 범주들로 분할된다.

1. 액세스 - 이것은 키에 대한 액세스 허가들, 즉 독출, 기입을 정의한다.

2. 소유권 - 키를 생성한 ACR은 정의에 의해 그의 소유자이다. 이 소유권은 한 ACR에서 다른 ACR로 위임될 수 있다(이들이 동일 AGP 또는 자식 AGP에 있다면). 키의 소유권은 키에 위임 허가들뿐만 아니라 이를 삭제하는 허가를 제공한다.

3. 액세스 권한 위임 - 이 허가는 ACR이 소유하는 권한들을 ACR이 위임할 수 있게 한다.

ACR은 자신이 행할 액세스 허가들을 갖는 다른 파티션들 뿐만 아니라 자신이 생성한 파티션들에 액세스 허가들을 위임할 수 있다.

허가 위임은 파티션들의 이름들 및 키 ID들을 지정된 ACR의 PCR에 추가함으로써 행해진다. 키 액세스 허가들을 위임하는 것은 키 ID에 의해서 또는 액세스 허가가 위임하는 ACR의 모든 생성된 키들에 대한 것임을 표명함으로써 될 수 있다.

ACR들의 블록킹 및 언블록킹

ACR은 시스템에 실체의 ACR 인증 프로세스가 비성공적일 때 증분하는 블록킹 카운터를 구비할 수 있다. 비성공 인증들의 어떤 최대 수(MAX)에 도달되었을 때, ACR은 SSA 시스템에 의해 블록킹될 것이다.

블록킹된 ACR은 블록킹된 ACR에 의해 참조된, 또 다른 ACR에 의해 언블록킹될 수 있다. 블록킹 ACR에 대한 참조는 이의 생성자에 의해 설정된다. 언블록킹 ACR은 블록킹된 ACR의 생성자와 동일한 AGP에 있는 것이 바람직하고 "언블록킹" 허가를 갖는다.

시스템 내 어떤 다른 ACR도 블록킹된 ACR을 언블록킹할 수 없다. ACR은 블록킹 카운터로, 그러나 언블록커 ACR 없이 구성될 수도 있다. 이 경우, 이 ACR이 블록킹되면 이것은 언블록킹될 수 없다.

루트 AGP : 애플리케이션 데이터베이스 생성

SSA 시스템은 복수의 애플리케이션들을 취급하고 이들 각각의 데이터를 분리하게 설계된다. AGP 시스템의 나무 구조는 애플리케이션 특유의 데이터를 확인하고 분리하는데 사용되는 주 도구이다. 루트 AGP는 애플리케이션 SSA 데이터베이스 나무의 정점에 있고 다소 다른 거동 규칙들을 고수한다. 몇 개의 루트 AGP들이 SSA 시스템에 구성될 수 있다. 2개의 루트 AGP들(130, 132)이 도 6에 도시되었다. 자명하게 더 적은 또는 더 많은 AGP들이 사용될 수 있고 이들은 이 발명의 범위 내에 있다.

새로운 애플리케이션에 대해 디바이스(예를 들면, 플래시 카드)에 등록하는 것 및/또는 디바이스에 대해 새로운 애플리케이션들의 자격증명서 발행은 새로운 AGP/ACR 나무를 디바이스에 추가하는 프로세스를 통해 행해진다.

SSA 시스템은 3가지 서로 다른 모드들의 루트 AGP 생성(루트 AGP의 모든 ACR들 및 이들의 허가들뿐만 아니라)을 지원한다.

1. 개방(Open): 어떠한 종류의 인증도 요구하지 않고 임의의 사용자 또는 실체, 또는 시스템 ACR(후술함)를 통해 인증된 사용자들/실체들은 새로운 루트 AGP를 생성할 수 있다. 개방 모드는 어떠한 보안 조치 없이도 루트 AGP들을 생성할 수 있도록 하는 반면, 모든 데이터 전송은 개방 채널로 행해지거나(즉, 발행국의 보안 환경에서), 시스템 ACR 인증(즉, OTA(Over The Air) 및 사후 발행 절차들)을 통해 수립된 보안 채널을 통해 행해진다.

시스템 ACR이 구성되지 않고(이것은 선택적 특징이다) 루트 AGP 생성 모드가 개방으로 설정된다면, 개방 채널 선택만이 사용될 수 있다.

2. 제어(Controlled): 시스템 ACR을 통해 인증된 실체들만이 새로운 루트 AGP를 생성할 수 있다. SSA 시스템은 시스템 ACR이 구성되지 않는다면 이 모드로 설정될 수 없다.

3. 록(Locked): 루트 AGP들의 생성은 비활성화되고 어떠한 추가의 루트 AGP들도 시스템에 추가될 수 없다.

2개의 SSA 명령들이 이 특징을 제어한다(이들 명령들은 인증 없이 임의의 사용자/실체가 사용할 수 있다):

1. 방법 구성 명령 - 3개의 루트 AGP 생성 모드들 중 임의의 하나를 사용하기 위해서 SSA 시스템을 구성하는데 사용된다. 다음 모드 변경들만이 허용된다: 개방 -> 제어(Controlled), 제어(Controlled) -> 록(Locked) (즉, SSA 시스템이 현재 제어(Controlled)로서 구성된다면, 이것은 록(Locked)으로 변경될 수 있을 뿐이다).

2. 방법 구성 록(lock) 명령 - 방법 구성 명령을 비활성화하고 현재 선택된 방법을 영구히 록 하는데 사용된다.

루트 AGP가 생성될 때, 이것은 이의 ACR들을 생성하고 구성할 수 있게 하는(루트 AGP의 생성에 적용된 것과 동일한 액세스 제약들을 사용하여) 특별한 초기화 모드이다. 루트 AGP 구성 프로세스의 끝에서, 실체가 이를 동작모드로 명백히 전환할 때, 현존의 ACR들은 더 이상 업데이트될 수 없고 추가의 ACR들이 더 이상 생성될 수 없다.

일단 루트 AGP가 표준 모드에 놓여지면 루트 AGP를 삭제하는 허가가 할당된 이의 ACR들 중 하나를 통해 시스템에 로그인함으로써만 삭제될 수 있다. 이것은 특별한 초기화 모드 외에도, 루트 AGP의 또 다른 예외이며, 다음 나무 레벨에 AGP들과는 반대로, 자신의 AGP를 삭제하는 허가를 가진 ACR를 내포할 수 있는 유일한 AGP인 것이 바람직하다.

루트 ACR과 표준 ACR간에 세 번째 및 마지막 차이는 파티션들을 생성하고 삭제하는 허가를 가질 수 있는 시스템 내 유일한 ACR이라는 것이다.

SSA 시스템 ACR

시스템 ACR은 다음 두 SSA 동작들을 위해 사용될 수 있다.

1. 적대적 환경들 내에서 보안 채널의 보호 하에 ACR/AGP 나무를 생성한다.

2. SSA 시스템을 호스트하는 디바이스를 확인하고 인증한다.

SSA에 단지 하나의 시스템 ACR만이 있는 것이 바람직할 수 있고 일단 정의되면 이것은 바람직하게는 변경될 수 없다. 시스템 ACR를 생성할 때 시스템 인증에 대한 필요성은 없으며, SSA 명령만이 필요하다. 시스템 ACR 생성 특징은 비활성화될 수 있다(루트 AGP 생성 특징과 유사하게). 시스템 ACR이 생성된 후, 시스템 ACR 생성 명령은 바람직하게 단지 한 시스템 ACR만이 허용되기 때문에 효과가 없다.

생성 프로세스에 있는 동안, 시스템 ACR은 동작하지 않는다. 종료되었을 때, 시스템 ACR이 생성되고 시작할 준비가 되었음을 나타내는 특별 명령이 발행될 필요가 있다. 이때 이후에 시스템 ACR은 바람직하게는 업데이트 또는 대체될 수 없다.

시스템 ACR은 SSA에서 루트 ACR/AGP를 생성한다. 호스트가 이에 만족되어 이를 블록킹하도록 하는 시간까지 루트 레벨을 추가/변경하는 허가를 갖는다. 루트 AGP 블록킹은 근본적으로 시스템 ACR에 대한 연결을 끊고 부정방지(temper proof)되게 한다. 이때 어떤 것도 루트 AGP 및 이 내에 ACR들을 변경/편집할 수 없다. 이것은 SSA 명령을 통해 행해진다. 루트 AGP들의 생성을 비활성화하는 것은 영속적 효과를 가지며 반대로 할 수 없다. 시스템 ACR을 수반하는 위의 특징들이 도 7에 도시되었다. 시스템 ACR은 3개의 서로 다른 루트 AGP들을 생성하는데 사용된다. 이들이 생성된 후 어떤 시간에, 도 7에 루트 AGP들에 시스템 ACR을 연결하는 점선들로 나타낸 바와 같이, 루트 AGP들을 시스템 ACR로부터 블록킹하고 그럼으로써 루트 AGP 생성 특징을 비활성화하기 위해서 SSA 명령이 호스트로부터 보내진다. 이것은 3개의 루트 AGP들을 부정방지되게 한다. 3개의 루트 AGP들은 루트 AGP들이 차단되기 전 또는 후에 3개의 개별적 나무들을 형성하기 위해 자식 AGP들을 생성하는데 사용될 수 있다.

위에 기술된 특징들은 콘텐트를 구비한 보안 제품들을 구성함에 있어 콘텐트 소유자에게 큰 융통성을 제공한다. 보안 제품들은 "발행(Issued)"될 필요가 있다. 발행은 디바이스가 호스트를 확인하고 그 반대로도 할 수 있게 하는 확인 키들을 설치하는 프로세스이다. 디바이스(예를 들면, 플래시 카드)를 확인하는 것은 호스트가 자신의 비밀들을 그에 신뢰할 수 있는지를 판단할 수 있게 한다. 반면, 호스트를 확인하는 것은 호스트가 허용되는 경우에만 디바이스가 보안 정책들(특정 호스트 명령을 승인하고 실행하는)을 시행할 수 있게 한다.

복수의 애플리케이션들에 서비스하게 설계된 제품들은 몇 개의 확인 키들을 가질 것이다. 제품은 "사전에 발행" -출하전에 제조 동안 저장된 키들- 될 수 있고, 또는 "사후에 발행" -출하 후에 새로운 키들이 추가된다- 될 수 있다. 사후 발행의 경우, 메모리 디바이스(예를 들면, 메모리 카드)는 애플리케이션들을 디바이스에 추가하는 것이 허용된 실체들을 확인하는데 사용되고 있는 어떤 종류의 마스크 또는 디바이스 레벨 키들을 내장할 필요가 있다.

위에 기술된 특징들은 제품이 사후 발행을 활성화/비활성화하게 구성될 수 있게 한다. 또한, 사후 발행 구성은 출하 후에 보안적으로 행해질 수 있다. 디바이스는 위에 기술된 마스터 또는 디바이스 레벨 키들 외에도 그에 어떠한 키들도 없이 소매 제품으로서 구입되고, 이어서 추가의 사후 발행 애플리케이션들을 활성화하거나 이들을 비활성화하게 새로운 소유자에 의해 구성될 수도 있다.

이에 따라, 시스템 ACR 특징은 위에 목적들을 달성하는 능력을 제공한다:

- 시스템 ACR이 없는 메모리 디바이스들은 애플리케이션들의 무제한의 제어되지 않은 추가를 허용할 것이다.

- 시스템 ACR이 없는 메모리 디바이스들은 시스템 ACR 생성을 비활성화하게 구성될 수 있고, 이는 새로운 애플리케이션들의 추가를 제어할 방법이 없음을 의미한다(새로운 루트 AGP를 생성하는 특징도 비활성화되지 않는다면)

- 시스템 ACR을 가진 메모리 디바이스들은 시스템 ACR 자격증명서를 사용하여 인증 절차를 통해 수립하기 위한 보안 채널을 통해 애플리케이션들의 단지 제어된 추가만을 허용할 것이다.

- 시스템 ACR을 가진 메모리 디바이스들은 애플리케이션이 추가되기 전 또는 추가된 후, 애플리케이션 추가 특징을 비활성화하게 구성될 수 있다.

키 ID 리스트

특정 ACR 요청마다 키 ID들이 생성되는데, 그러나, 메모리 시스템(10)에서, 이들은 SSA 시스템에 의해서 단독으로 사용된다. 키 ID가 생성될 때 생성하는 ACR에 의해 또는 이에 다음 데이터가 제공된다.

1. 키 ID. ID는 호스트를 통해 실체에 의해 제공되며 키와, 모든 후 독출 또는 기입 액세스들에서 키를 사용하여 암호화 또는 해독되는 데이터를 참조하는데 사용된다.

2. 키 사이퍼 및 데이터 무결성 모드(위에서 그리고 이하 설명되는 바와 같이 차단, 체인, 및 해시 모드들).

호스트에 의해 제공된 속성들 외에도, 다음 데이터가 SSA 시스템에 의해 유지된다.

1. 키 ID 소유자. 소유자인 ACR의 ID. 키 ID가 생성되고 생성자 ACR이 그의 소유자일 때, 그러나, 키 ID 소유권은 또 다른 ACR에 넘겨질 수 있다. 바람직하게, 키 ID 소유자만이 키 ID의 소유권을 넘기고 키 ID를 위임하는 것이 허용된다. 연관된 키에 대한 액세스 허가를 위임하는 것, 및 이들 권한들을 취소하는 것은 키 ID 소유자 또는 위임 허가들이 할당된 그외 어떤 다른 ACR에 의해 관리될 수 있다. 이들 동작들 중 어느 것을 행사하려는 시도가 있을 때는 언제나, SSA 시스템은 요청하는 ACR이 권한이 있을 경우에만 그 시도를 승인할 것이다.

2. CEK. 이것은 키 ID에 연관된 또는 이에 의해 가리켜진 콘텐트를 사이퍼하는데 사용되는 키를 갖는 CEK이다. 키값은 SSA 시스템에 의해 발생된 128 비트 AES 랜덤 키일 수 있다.

3. MAC 및 IV 값들. 체인 블록 사이퍼(CBC) 암호화 알고리즘들에서 사용되는 동적 정보(메시지 인증 코드들 및 초기화 벡터들).

SSA의 여러 특징들이 도 8a 내지 도 16에 흐름도들을 참조하여 도시되었으며, 단계의 좌측에 'H'는 동작이 호스트에 의해 수행됨을 의미하고, 'C'는 동작이 카드에 의해 수행됨을 의미한다. 이들 SSA 특징들이 메모리 카드들을 참조하여 예시되지만, 이들 특징들은 다른 물리적 형태들의 메모리 디바이스들에도 적용함이 이해될 것이다. 시스템 ACR을 생성하기 위해서, 호스트는 메모리 디바이스(10) 내 SSA에 시스템 ACR 생성 명령을 발행한다(블록 202). 디바이스(10)는 시스템 ACR이 이미 존재하는지 체크함으로써 응답한다(블록 204, 마름모 206). 이것이 이미 존재한다면, 디바이스(10)는 실패를 리턴하고 종료한다(사각형 208). 존재하지 않는다면, 메모리(10)는 시스템 ACR 생성이 허용되는 알기 위해 체크하고(마름모 210), 허용되지 않는다면 실패 상태를 리턴한다(블록 212). 이에 따라, 디바이스가 이를테면 어떠한 시스템 ACR도 필요하지 않도록 필요한 보안 특징들이 기결정되어 있는 경우에서와 같이, 디바이스 발행자가 시스템 ACR의 생성을 허용하지 않는 경우들이 있을 수 있다. 이것이 허용된다면, 디바이스(10)는 OK 상태를 리턴하고 호스트로부터 시스템 ACR 자격증명서들을 대기한다(블록 214). 호스트는 SSA 상태와, 디바이스(10)가 시스템 ACR의 생성이 허용됨을 표시되었는지를 체크한다(블록 216 및 마름모 218). 생성이 허용되지 않거나 시스템 ACR이 이미 존재한다면, 호스트는 중지한다(사각형 220). 디바이스(10)가 시스템 ACR의 생성이 허용됨을 표시하였다면, 호스트는 이의 로그인 자격증명서를 정의하는 SSA 명령을 발행하고 이를 디바이스(10)에 보낸다(블록 222). 디바이스(10)는 수신된 자격증명서로 시스템 ACR 레코드를 업데이트하고 OK 상태를 리턴한다(블록 224). 이 상태 신호에 응하여, 호스트는 시스템 ACR이 준비된 것을 나타내는 SSA 명령을 발행한다(블록 226). 디바이스(10)는 시스템 ACR이 업데이트되거나 대체될 수 없도록 이 시스템 ACR을 록 함으로써 응답한다(블록 228). 이것은 시스템 ACR 및 호스트에 디바이스(10)를 확인하기 위한 그의 아이덴터티의 특징들을 록 한다.

새로운 나무들(새로운 루트 AGP들 및 ACR)을 생성하기 위한 절차는 이들 기능들이 디바이스에 구성된 방법에 의해 결정된다. 도 9는 절차들을 설명한다. 호스트(24) 및 메모리 시스템(10) 둘 다 이를 따른다. 새로운 루트 AGP를 추가하는 것이 함께 비활성화된다면, 새로운 루트 AGP들은 추가될 수 없다(마름모 246). 이것이 활성화되었지만 시스템 ACR이 필요하다면, 호스트는 시스템 ACR를 통해 인증하 고 루트 AGP 생성 명령을 발행하기에 앞서(블록 254) 보안 채널(마름모 250, 블록 252)을 확립한다. 시스템 ACR이 필요하지 않다면(마름모 248), 호스트(24)는 인증 없이 루트 AGP 생성 명령을 발행하고 블록 254로 진행할 수 있다. 시스템 ACR이 존재한다면, 호스트는 이것이 필요하지 않을지라도 이를 사용할 수 있다(흐름도에 도시되지 않음). 디바이스(예를 들면, 플래시 카드)는 기능이 비활성화된다면 새로운 루트 AGP를 생성하는 어떤 시도든 거절할 것이며 시스템 ACR이 필요하다면(마름모들 256 및 250) 인증 없이 새로운 루트 AGP를 생성하는 시도를 거절할 것이다. 블록 254에서 새로이 생성된 AGP 및 ACR은 이제 동작모드로 전환되어 이러한 AGP들 내 ACR들은 업데이트 아니면 변경될 수 없고, 어떠한 ACR들도 이들에 추가될 수 없다(블록 256). 이어서 시스템은 추가의 루트 AGP들이 생성될 수 없도록(블록 258), 선택적으로 록 된다. 점선 박스(258)는 이 단계가 선택적 단계임을 나타내는 관례이다. 이 출원의 도면들의 흐름도들에서 점선들로 된 모든 박스들은 선택적 단계들이다. 이것은 적법의 콘텐트를 가진 진본 메모리 디바이스를 모사할 수 있는 그외 불법 목적들을 위한 디바이스(10)의 사용을 콘텐트 소유자가 블록킹할 수 있게 한다.

ACR들(위에 기술된 바와 같이 루트 AGP에 ACR들 이외의)을 생성하기 위해서, 도 10에 도시된 바와 같이 ACR를 생성하는 권한을 갖는 임의의 ACR부터 시작할 수 있다(블록 270). 실체는 진입점 ACR 아이덴터티와, 생성하기를 원하는 모든 필요한 속성들과 함께 ACR을 제공함으로써 호스트(24)를 통해 진입하려고 시도할 수 있다(블록 272). SSA는 ACR 아이덴터티와 일치에 대해서 그리고 이러한 아이덴터티를 가진 ACR이 ACR을 생성하는 허가를 갖고 있는지(마름모 274)에 대해 체크한다. 요청이 권한이 부여된 것으로 검증된다면, 디바이스(10) 내 SSA는 ACR를 생성한다(블록 276).

도 11은 도 10의 방법을 사용하여 보안 애플리케이션들에서 유용한 나무를 도시한 2개의 AGP들을 도시한다. 이에 따라, 마케팅 AGP에서 아이덴터티 m1을 갖는 ACR은 ACR을 생성하는 허가를 갖는다. ACR m1은 키 ID "마케팅 정보"에 연관된 데이터 및 키 ID "가격 리스트"에 연관된 데이터를 독출 및 기입하기 위한 키를 사용할 허가도 갖는다. 도 10의 방법을 사용하여, 키 ID "가격 리스트"에 연관된 가격 데이터에 액세스하기 위한 키에 독출국한 허가는 있지만 키 ID "마케팅 정보"에 연관된 데이터에 액세스하는데 필요한 키에 대한 독출 허가는 없는 s1 및 s2인 2개의 ACR들을 가진 판매 AGP를 생성한다. 이렇게 하여, ACR들 s1 및 s2를 가진 실체들은 독출만 할 수 있고 가격 데이터를 변경할 수 없으며, 마케팅 데이터에 액세스할 수 없을 것이다. 반면, ACR m2는 ACR들을 생성할 허가는 없으며 키 ID "가격 리스트"에 연관되고 그리고 키 ID "마케팅 정보"에 연관된 데이터에 액세스하기 위한 키들에 대한 독출국한 허가를 갖는다.

이에 따라, 액세스 권한들은 m1이 가격 데이터를 독출하는 권한들을 s1 및 s2에 위임하는 위에 설명된 방식으로 위임될 수 있다. 이것은 대형 마케팅 및 판매 그룹들이 연루되는 경우 특히 유용하다. 그러나 하나 또는 소수의 판매원들이 있는 경우, 도 10의 방법을 사용할 필요는 없을 수 있다. 대신에, 도 12에 도시된 바와 같이, 액세스 권한들이 ACR에 의해 동일 AGP 내 낮은 또는 동일 레벨의 것에 위임 될 수 있다. 먼저, 실체는 위에 기술된 방식으로 호스트를 통해 나무에 ACR를 명시함으로써(블록 280) 이러한 AGP에 대한 나무에 진입한다. 다음에 호스트는 ACR 및 이에 위임할 권한들을 명시할 것이다. SSA는 이러한 ACR을 위한 나무(들)와, 명시된 또 다른 ACR에 권한들을 위임할 허가를 ACR이 갖고 있는지를(마름모 282) 체크한다. 그러하다면, 권한들이 위임되고(블록 284), 그렇지 않다면 중지한다. 결과가 도 13에 도시되었다. 이 경우 ACR m1은 ACR s1에 독출 허가를 위임하는 허가를 가지므로, s1은 위임 후에 가격 데이터에 액세스하기 위해 키를 사용할 수 있을 것이다. 이것은 m1이 가격 데이터에 액세스할 동일 또는 더 큰 권한들과 그와 같이 위임할 허가를 갖고 있다면 수행될 수 있다. 일 실시예에서, m1은 위임 후에 그의 액세스 권한들을 보유한다. 바람직하게, 액세스 권한들은 이를테면 제한된 시간, 제한된 수의 액세스들 등과 같은 제약된 조건들 하에서 위임될 수 있다.

키 및 키 ID를 생성하는 프로세스가 도 14에 도시되었다. 실체는 ACR를 통해 인증한다(블록 302). 실체는 호스트에 의해 명시된 ID를 가진 키의 생성을 요청한다(블록 304). SSA는 명시된 ACR이 그와 같이 행할 허가를 갖고 있는지를 체크하고 안다(마름모 306). 예를 들면, 키가 특정 파티션 내 데이터에 액세스하는데 사용될 것이라면, SSA는 ACR이 이러한 파티션에 액세스할 수 있는지를 체크하여 알 것이다. ACR이 권한이 있다면, 메모리 디바이스(10)는 호스트에 의해 제공된 키 ID에 연관된 키값을 생성하고(블록 308), 키 ID를 ACR에, 그리고 키값을 이의 메모리(제어기에 연관된 메모리에 또는 메모리(20)에)에 저장하고, 실체에 의해 공급된 정보에 따라 권한들 및 허가들을 할당하고(블록 310) 이러한 할당된 권한들 및 허가들 로 이러한 ACR의 PCR을 수정한다(블록 312). 이에 따라, 키의 생성자는 이를테면 독출 및 기입 허가들, 위임하고 동일 AGP 내 다른 ACR들 또는 낮은 레벨에 ACR과 공유하는 권한, 키의 소유권을 이전할 권한과 같은 모든 가용한 권한들을 갖는다.

ACR은 도 15에 도시된 바와 같이 SSA 시스템에서 또 다른 ACR의 허가들(또는 존재(existence)도 함께)를 변경할 수 있다. 실체는 전처럼 ACR을 통해 나무에 진입할 수 있는데, 이 경우 실체는 인증되고 이어서 ACR을 명시한다(블록들 330, 332). 이것은 타깃 ACR의 위임 또는 타깃 ACR에서 허가를 요청한다(블록 334). 명시된 ACR 또는 이러한 시간에 활성인 ACR이 그와 같이 행할 권한을 갖는다면(마름모 336), 타깃 ACR은 삭제되거나, 타깃 ACR의 PCR은 이러한 허가를 삭제하게 변경된다(블록 338). 이러한 권한이 없다면 시스템은 중지한다.

위에 기술된 프로세스 후, 타깃은 프로세스에 앞서 할 수 있었던 데이터에 더 이상 액세스할 수 없을 것이다. 도 16에 도시된 바와 같이, 실체는 타깃 ACR에 진입하려고 시도할 수 있고(블록 350) 이전에 존재한 ACR ID가 SSA에 더 이상 없어 액세스 권한들이 거절되기 때문에(마름모 352), 인증 프로세스가 실패한 것을 발견한다. ACR ID가 삭제되지 않았다고 가정하면, 실체는 ACR(블록 354) 및 키 ID 및/또는 특정 파티션에 데이터(블록 356)를 명시하고, 이어서 SSA는 키 ID 또는 파티션 액세스 요청이 이러한 ACR의 PCR에 따라 허용되는지를 알기 위해 체크한다(마름모 358). 허가가 삭제되거나 만기되었다면, 요청은 다시 거절된다. 그렇지 않다면, 요청은 승인된다(블록 360).

위에 프로세스는 ACR 및 이의 PCR이 또 다른 ACR에 의해 변경되었는지 아니 면 시작하기 위해 그와 같이 구성되었는지에 관계없이, 보호된 데이터에 대한 액세스가 디바이스(예를 들면 플래시 카드)에 의해 어떻게 관리되는가를 기술한다.

세션들

SSA 시스템은 동시에 로그인 된 복수의 사용자들을 취급하게 설계된다. 이 특징이 사용될 때, SSA에 의해 수신된 모든 명령은 특정 실체에 연관되고 이 실체를 인증하는데 사용되는 ACR이 요청된 작업에 대한 허가를 갖는 경우에만 실행된다.

복수의 실체들은 세션 개념을 통해 지원된다. 세션은 인증 프로세스를 동안 수립되고 SSA 시스템에 의해 세션-id가 할당된다. 세션-id는 시스템에 로그인하는데 사용되는 ACR에 내부적으로 연관되고 모든 후 SSA 명령들에서 사용되기 위해 실체에 이출된다.

SSA 시스템은 두 유형들의 세션들로서 개방, 및 보안 세션들을 지원한다. 특정 인증 프로세스에 연관된 세션 유형은 ACR에 정의된다. SSA 시스템은 자체 인증을 시행하는 방법과 유사한 방식으로 세션 수립을 시행할 것이다. ACR이 실체 허가들을 정의하기 때문에, 이 메커니즘은 시스템 설계자들이 보안 터널링을 특정 키 ID들에 액세스하는 것에 또는 특정 ACR 관리 동작들(즉, 새로운 ACR들을 생성하고 자격증명서들을 설정하는 것)을 기동하는 것에 연관시킬 수 있게 한다.

개방 세션

개방 세션은 세션-id로 그러나 버스 암호화 없이 확인되는 세션이며, 모든 명령들 및 데이터는 암호화 없이(in the clear) 전달된다. 이 모드의 동작은 바람 직하게는 실체들이 위협 모델(threat model)의 부분도 아니고 버스에서 도청하고 있는 것도 아닌 복수-사용자 또는 복수-실체 환경에서 사용된다.

데이터의 전송을 보호하지도 않고 호스트 측에 애플리케이션들간에 효율적 방화-벽도 할 수 있게 하지 않을지라도, 개방 세션 모드는 SSA 시스템이 현재 인증된 ACR들에 대해 허용된 정보에만 액세스를 허용할 수 있게 한다.

개방 세션은 파티션 또는 키가 보호될 필요가 있는 경우들에 대해 사용될 수도 있다. 그러나, 유효 인증 프로세스 후, 호스트 상에 모든 실체들에게 액세스가 승인된다. 인증된 ACR의 허가들을 얻기 위해서, 여러 호스트 애플리케이션들이 공유할 필요가 있는 유일한 것은 세션-id이다. 이것이 도 17a에 도시되었다. 선 400 위에 단계들은 호스트(24)에 의해 취해지는 것들이다. 실체가 ACR 1에 대해 인증된 후에(블록 402), 메모리 디바이스(10)에서 키 ID X에 연관된 파일에 대한 액세스를 요청한다(블록들 404, 406, 408). ACR 1의 PCR이 이러한 액세스를 허용한다면, 디바이스(10)는 요청을 승인한다(마름모 410). 그렇지 않다면, 시스템은 블록(402)으로 되돌아간다. 인증이 완료된 후, 메모리 시스템(10)은 할당된 세션 id(ACR 자격증명서들이 아닌)에 의해서만 명령을 발행하는 실체를 확인한다. 개방 세션에서, 일단 ACR 1이 이의 PCR에 키 ID들에 연관된 데이터에 액세스할 수 있게 되면, 호스트(24) 상에 서로 다른 애플리케이션들간에 공유되는 정확한 세션 ID를 명시함으로써 어떤 다른 애플리케이션 또는 사용자든 동일 데이터에 액세스할 수 있다. 이 특징은 단지 한번 로그인할 수 있고, 서로 다른 애플리케이션들에 대해 로그인이 수행되는 계정에 결부된 모든 데이터에 액세스하는 것이 사용자에게 더 편한 애플리 케이션들에선 이점이 있다. 이에 따라, 셀룰러 전화 사용자는 저장된 이메일들에 액세스하여, 복수회 로그인해야 할 필요 없이 메모리(20) 내 저장된 음악을 들을 수 있다. 반면, ACR 1에 의해 포함되지 않은 데이터는 액세스될 수 없을 것이다. 이에 따라, 동일 셀룰러 전화 사용자는 별도의 계정 ACR 2을 통해 액세스될 수 있는 이를테면 게임들 및 사진들과 같은 가치있는 콘텐트를 가질 수도 있다. 이것은 사용자가 다른 사용자들이 그의 제 1 계정 ACR을 통해 가능한 데이터에 액세스하는 것에 개의치 않을 수 있을지라도, 사용자가 자신의 전화를 빌린 다른 사용자들이 액세스하는 것을 원하지 않는 데이터이다. 개방 세션에서 ACR 1에 대한 액세스를 허용하면서도 데이터에 대한 액세스를 2개의 개별적 계정들로 분리하는 것은 가치있는(valuable) 데이터의 보호를 할 수 있게 할 뿐만 아니라 사용의 용이함을 제공한다.

ACR이 개방 세션을 요청하고 있을 때, 호스트 애플리케이션들간에 세션-id를 공유하는 프로세스를 훨씬 더 용이하게 하기 위해서, 세션에 "0(제로") id가 할당될 것을 명시적으로 요청할 수 있다. 이렇게 하여, 애플리케이션들은 기정의된 세션-id를 사용하게 설계될 수 있다. 유일한 제약은, 명백한 이유들로, 세션 0을 요청하는 단지 한 ACR만이 특정 시간에 인증될 수 있다는 것이다. 세션 0을 요청하는 또 다른 ACR을 인증하려는 시도는 거절될 것이다.

보안 세션

한 층의 보안을 추가하기 위해서, 도 17b에 도시된 바와 같이 세션 id가 사용될 수도 있다. 이때 메모리(10)는 활성 세션들의 세션 id들도 저장한다. 예를 들 면, 도 17b에서, 키 ID X에 연관된 파일에 액세스할 수 있기 위해서, 실체는 파일에 액세스하는 것이 허용되기 전에 이를테면 세션 id "A"와 같은 세션 id을 제공할 필요가 있을 것이다(블록들 404, 406, 412, 414). 이에 따라, 요청하는 실체가 정확한 세션 id를 모른다면, 메모리(10)에 액세스할 수 없다. 세션 id는 세션이 종료된 후 삭제되고 각 세션마다 다를 것이기 때문에, 실체는 세션 번호를 제공할 수 있었을 때만 다시 액세스할 수 있다.

SSA 시스템은 세션 번호를 사용함으로써 정확한 인증된 실체로부터 명령이 실제로 오고 있는지를 추적한다. 공격자들이 악의적 명령들을 보내기 위해 개방 채널을 사용하려고 시도할 위협이 있는 애플리케이션들 및 사용 경우들에 있어서, 호스트 애플리케이션은 보안 세션(보안 채널)을 사용한다.

보안 채널을 사용할 때, 전체 명령뿐만 아니라, 세션-id는 보안 채널 암호화 (세션) 키로 암호화되고 보안 레벨은 호스트측 구현만큼 높다.

세션 종료

다음 시나리오들 중 어느 하나에서, 세션은 종료되고, ACR은 로그 오프된다.

1. 실체가 명확한 세션 종료 명령을 발행한다.

2. 통신 타임아웃. 특정 실체가 ACR 파라미터들 중 하나로서 한 기간동안 아무 명령도 발행하지 않았다.

3. 디바이스(예를 들면, 플래시 카드)가 리셋 및/또는 파워 사이클 후에 모든 열린 세션들은 종료된다.

데이터 무결성 서비스들

SSA 시스템은 SSA 데이터베이스(모든 ACR들, PCR들 등을 내포하는)의 무결성을 검증한다. 또한, 키 ID 메커니즘을 통해 실체 데이터에 대해 데이터 무결성 서비스들이 제공된다.

키 ID가 이의 암호화 알고리즘으로서 해시(Hashed)로 구성된다면, 해시값들은 CEK 레코드에 CEK 및 IV와 함께 저장된다. 해시값들은 기입동작 동안 계산되어 저장된다. 해시값들은 독출동작동안 다시 계산되어 이전 기입동작들동안 저장된 값들과 비교된다. 실체가 키 ID에 액세스할 때마다 추가의 데이터가 이전 데이터 및 업데이트된 적합한 해시값(독출을 위한 또는 기입을 위한)에 연결(concatenated) (크립토그래픽으로)된다.

호스트만이 키 ID에 연관된 또는 이에 의해 가리켜진 데이터 파일들을 알고 있기 때문에, 호스트는 다음 방식으로 데이터 무결성 기능의 몇 가지 면들을 명확히 관리한다:

1. 키 ID에 연관된 또는 이에 의해 가리켜진 데이터 파일들은 처음부터 끝까지 기입 또는 독출된다. SSA 시스템이 CBC 암호화 방법을 사용하고 있고 전체 데이터의 해시된 메시지 다이제스트를 발생하기 때문에 파일의 부분들에 액세스하려는 어떠한 시도이든 엉망이 될 것이다.

2. 중간 해시값들이 SSA 시스템에 의해 유지되기 때문에 인접한 스트림(데이터 스트림은 다른 키 Id들의 데이터 스트림과 인터리브될 수 있으며 복수의 세션들에 대해 분할될 수도 있다)에 데이터를 처리할 필요가 없다. 그러나, 실체는 데이터 스트림이 재시작된다면 해시값들을 리셋할 것을 SSA 시스템에 명확히 지시할 필 요가 있을 것이다.

3. 독출동작이 완료되었을 때, 호스트는 기입동작동안 계산된 해시값과 비교함으로써 독출된 해시를 유효화할 것을 SSA 시스템에 명확하게 요청한다.

4. SSA 시스템은 "더미 독출" 동작도 제공한다. 이 특징은 암호화 엔진들을 통해 데이터를 스트리밍할 것이지만 이를 호스트에 내보내지는 않을 것이다. 이 특징은 디바이스(예를 들면, 플래시 카드)로부터 실제로 독출되기 전에 데이터 무결성을 검증하는데 사용될 수 있다.

난수 발생

SSA 시스템은 외부 실체들이 내부 난수 발생기를 이용하고 난수들을 SSA 시스템 외부에서 사용될 것을 요청할 수 있게 할 것이다. 이 서비스는 어떤 호스트이든 사용할 수 있고 인증을 필요로 하지 않는다.

RSA 키 쌍 생성

SSA 시스템은 외부 사용자들이 내부 RSA 키 쌍 생성 특징을 이용하고 키 쌍을 SSA 시스템 외부에서 사용될 것을 요청할 수 있게 할 것이다. 이 서비스는 어떤 호스트이든 사용할 수 있고 인증을 필요로 하지 않는다.

대안적 실시예

계층적 방법을 사용하는 대신에, 도 18에 도시된 바와 같이, 데이터 베이스 방법을 사용하여 유사한 결과들이 달성될 수 있다.

도 18에 도시된 바와 같이, 실체들을 위한 자격증명서들, 인증 방법들, 실패된 시도들의 최대 수, 및 언블록킹하는데 필요한 자격증명서들의 최소 수의 리스트 가, 제어기(12) 또는 메모리(20)에 저장된 데이터베이스에 입력될 수 있고, 이것은 이러한 자격증명서 요구사항들을 메모리(10)의 제어기(12)에 의해 수행되는 데이터베이스 내 정책들(키들 및 파티션들의 독출, 기입 액세스, 보안 채널 요구사항)에 관계시킨다. 데이터베이스에는 키들 및 파티션들에 대한 액세스에 대한 제약들 및 제한들도 저장된다. 이에 따라, 일부 실체들(예를 들면, 시스템 관리자)은 화이트 리스트(white list) 상에 있을 수 있는데, 이것은 이들 실체들이 모든 키들 및 파라미터들에 액세스할 수 있음을 의미한다. 이외 다른 실체들은 블랙 리스트 상에 있을 수 있고, 임의의 정보에 액세스하려는 이들의 시도들은 차단될 것이다. 제한은 전역적일 수도 있고, 또는 키 및/또는 파티션에 특정할 수도 있다. 이것은 어떤 실체들만이 어떤 특정 키들 및 파티션들에 액세스할 수 있고 어떤 실체들은 그렇게 할 수 없음을 의미한다. 콘텐트가 들어있는 파티션, 또는 이 콘텐트를 암호화 또는 해독하는데 사용되는 키에 관계없이, 이 콘텐트 자체에 제약들이 가해 질 수도 있다. 이에 따라, 어떤 데이터(예를 들면, 곡들)는 이들에 액세스하는 제 1의 5개의 호스트 디바이스들에 의해서만 액세스될 수 있거나 다른 데이터(예를 들면, 영화)가 어떤 실체들이 액세스하였는지 관계없이 제한 회수 동안만 읽혀질 수 있는 속성을 가질 수도 있다.

인증

. 패스워드 보호

. 패스워드-보호는 보호된 영역에 액세스하기 위해 패스워드가 제시될 필요가 있음을 의미한다. 이것이 하나보다 더 많은 패스워드일 수 없다면, 패스워드 들은 독출 액세스 또는 독출/기입 액세스와 같은 서로 다른 권한들에 연관될 수도 있을 것이다.

. 패스워드 보호는 디바이스(예를 들면, 플래시 카드)가 호스트에 의해 제공된 패스워드를 검증할 수 있음을, 즉 디바이스가 디바이스에서 관리된 보안된 메모리 영역에 패스워드를 저장하게 한다는 것을 의미한다.

문제 및 제한

. 패스워드들은 리플레이 공격을 받는다. 패스워드는 각각의 제시 후에 바꾸지 않기 때문에, 동일하게 다시 보내질 수 있다. 이것은 보호될 데이터가 가치있고 통신 버스가 쉽게 액세스될 수 있다면 현 패스워드는 사용되지 않아야 함을 의미한다.

. 패스워드는 저장된 데이터에 액세스를 보호할 수도 있을 것이지만 데이터(키가 아닌)를 보호하는 데에는 사용되지 않아야 한다.

. 패스워드들에 연관된 보안 레벨을 증가시키기 위해서, 이들은 마스터 키를 사용하여 다양화될 수 있는데, 그 결과로 해킹하는 자는 전체 시스템을 크랙하지 못한다. 세션 키 기반의 보안 통신채널은 패스워드를 보내는데 사용될 수 있다.

도 19는 패스워드를 사용한 인증을 예시한 흐름도이다. 실체는 계정 id 및 패스워드를 시스템(10)(예를 들면, 플래시 메모리 카드)에 보낸다. 시스템은 패스워드가 자신의 메모리에 있는 것과 일치하는지를 알기 위해 체크한다. 일치한다면, 인증된 상태가 리턴된다. 그렇지 않다면, 이 계정에 대해 오류 카운터가 증분되고, 계정 id 및 패스워드를 재입력할 것이 실체에 요청된다. 카운터가 오버플로우하면, 시스템은 액세스가 거절된 상태를 리턴한다.

대칭 키

대칭 키 알고리즘은 암호화 및 해독을 위해 양측에서 동일 키가 사용됨을 의미한다. 이것은 통신하기에 앞서 키가 사전 동의되었음을 의미한다. 또한 각측은 서로간에 반대 알고리즘을 이행해야 하는데, 즉 한 측에선 암호화 알고리즘을 다른 측에선 해독 알고리즘을 이행해야 한다. 양측은 통신하기 위해 두 알고리즘들을 이행할 필요가 없다.

인증

. 대칭 키 인증은 디바이스(예를 들면 플래시 카드) 및 호스트가 동일 키를 공유하고 동일 크립토그래픽 알고리즘(다이렉트 및 리버스 예를 들면 DES 및 DES-1)을 구비함을 의미한다.

. 대칭 키 인증은 시도-응답(challenge-response)(리플레이 공격에 대한 보호)을 의미한다. 보호된 디바이스는 다른 디바이스에 대한 시도를 발생하고 둘 다 응답을 계산한다. 인증하는 디바이스는 역으로 응답을 보내고 보호된 디바이스는 응답을 체크하여 이에 따라 인증을 유효화한다. 이어서 인증에 연관된 권한들이 승인될 수 있다.

인증은,

외부: 디바이스(예를 들면, 플래시 카드)가 외부 세계를 인증한다. 즉, 디바이스가 주어진 호스트 또는 애플리케이션의 자격증명서들을 유효화한다,

상호: 양측에서 시도가 생성된다,

내부: 호스트 애플리케이션이 디바이스(예를 들면, 플래시 카드)를 인증한다. 즉, 호스트는 이의 애플리케이션에 대해 디바이스가 진본인지를 체크한다,

일 수도 있을 것이다.

전체 시스템의 보안 레벨을 증가시키기 위해서(즉, 하나를 해제(break)하는 것이 모두를 해제하지 않는다),

. 대칭키는 보통 마스터 키를 사용하여 다양화와 결합된다.

. 상호 인증은 시도가 실체 시도임을 보장하기 위해 양측으로부터의 시도를 사용한다.

암호화

대칭키 크립토그래피는 이것이 매우 효율적인 알고리즘이기 때문에, 즉 크립토그래피를 다루기 위해 강력한 CPU를 필요로 하지 않기 때문에 암호화에도 사용된다.

통신채널을 보안하는데 사용될 때:

. 두 디바이스들은 채널을 보안하는데(즉, 모든 나가는 데이터를 암호화하고 모든 들어오는 데이터를 해독한다) 사용되는 세션 키를 알아야 한다. 이 세션 키는 보통 사전에 공유된 비밀 대칭키를 사용하여 또는 PKI를 사용하여 설정된다.

. 두 디바이스들은 동일 크립토그래픽 알고리즘 서명을 알고 구현해야 한다.

대칭키는 데이터를 서명하는 데에도 사용될 수 있다. 이 경우 서명은 암호화 의 부분적 결과이다. 결과를 부분적으로 유지하는 것은 키값을 노출시키지 않고 필요한 만큼의 회수로 서명할 수 있게 한다.

문제들 및 제한들

대칭 알고리즘들은 매우 효율적이고 보안적이지만 이들은 사전에 공유되는 비밀에 기반한다. 문제는 이 비밀을 동적으로 그리고 아마도 이를 랜덤하게 하도록(세션 키처럼) 보안적으로 공유하는 것이다. 생각은 공유된 비밀은 장기간 안전하에 유지하기가 어렵고 복수의 사람들과 공유하는 것이 거의 불가능하다는 것이다.

이 동작을 용이하게 하기 위해서, 공개키는 비밀을 공유하지 않고 이들을 교환할 수 있도록 하기 때문에 공개키 알고리즘이 발명되었다.

비대칭 인증 절차

대칭키 기반 인증은 결국에 보안 채널 통신을 위한 세션 키를 구성하는 일련의 데이터 패싱 명령들을 사용한다. 기본 프로토콜은 SSA 시스템에 사용자를 인증한다. 프로토콜 변형들은 사용자가 사용하기를 원하는 ACR을 사용자가 검증해야 하는 상호 인증, 및 이중요소(two-factor) 인증을 할 수 있게 한다.

SSA의 비대칭 인증 프로토콜들은 바람직하게는 공개키 기반구조(PKI) 및 RSA 알고리즘들을 사용한다. 이들 알고리즘들에 의해 정의된 바와 같이, 인증 프로세스에서 각 당사자는 자신의 RSA 키 쌍을 생성하는 것이 허용된다. 각 쌍은 공개키와 사설키로 구성된다. PKI층은 공개키들의 각각을 서명하는 제 3의 신뢰된 측을 요구한다. 신뢰된 측의 공개키는 서로 인증해야 하는 당사자들간에 사전에 공유되고 이 들 당사자들의 공개키들을 검증하는데 사용된다. 일단 신뢰가 확립되면(두 당사자들은 다른 당사자에 의해 제공된 공개키가 신뢰될 수 있는 것으로 판정하였다), 프로토콜은 계속하여 인증(각 당사자는 일치하는 사설키를 보유함을 검증하는) 및 키 교환을 한다. 이것은 이하 기술되는 도 22 및 도 23에 도시된 시도 응답 메커니즘을 통해 행해질 수 있다.

서명된 공개키를 내장하는 구조는 증명서라고 한다. 증명서에 서명한 신뢰된 측은 증명서 당국(CA)이라고 한다. 당사자가 인증되기 위해서 당사자는 RSA 키 쌍 및 공개키의 진위를 입증하는 증명서를 구비한다. 증명서는 다른(인증하는) 당사자에 의해 신뢰되는 증명서 당국에 의해 서명된다. 인증하는 당사자는 이의 신뢰된 CA의 공개키를 소유하고 있을 것으로 예상된다.

SSA는 증명서 체인을 할 수 있게 한다. 이것은 확인되는 당사자의 공개키가 다른(확인하는 당사자에 의해 신뢰된 것과는 다른) CA에 의해 서명될 수도 있음을 의미한다. 이 경우 확인된 당사자는 자신의 증명서 외에도, 자신의 공개키를 서명한 CA의 증명서를 제공할 것이다. 이 제 2 레벨 증명서가 다른 당사자(신뢰된 CA에 의해 서명되지 않은)에 의해 여전히 신뢰되지 않는다면, 제 3 레벨 증명서가 제공될 수 있다. 이 증명서 체인 알고리즘에서, 각 당사자는 이의 공개키를 인증하는데 필요한 증명서들의 한 완전한 리스트를 소유할 것이다. 이것이 도 23 및 도 24에 도시되었다. 이러한 유형의 ACR에 의한 상호 인증에 필요한 자격증명서들은 선택된 길이의 RSA 키 쌍들이다.

SSA 증명서

SSA는 [X.509] 버전 3 디지털 증명서들을 채용한다. [X.509]는 범용 표준이며, 여기 기술된 SSA 증명서 프로파일은 증명서의 정의된 필드들의 내용들을 더욱 명시하고 제약한다. 증명서 프로파일은 또한, 증명서 체인의 관리, SSA 증명서들의 유효화 및 증명서 철회 리스트(CRL) 프로파일을 위해 정의된 신뢰 계층을 정의한다.

증명서는 공개된 정보인 것으로 간주되고(내부에 공개키로서) 그러므로 암호화되지 않는다. 그러나, 모든 다른 정보 필드들뿐만 아니라 공개키가 부정변조되지 않았음을 검증하는 RSA 서명을 포함한다.

[X.509]는 각 필드가 데이터 엔코딩을 위해 DER 포맷을 사용하는 ASN.1 표준을 사용하여 포맷됨을 정의한다.

SSA 증명서 개요

도 20 및 도 21에 도시된 SSA 증명서 관리 구조의 일 실시예는 호스트에 대해선 무제한 레벨의 계층과, 디바이스에 대해 3개보다 더 많은 또는 더 적은 수의 계층 레벨들이 사용될 수 있을지라도 디바이스에 대해 3-레벨까지의 계층으로 구성된다.

호스트 증명서 계층

디바이스는 두 요인들로서, 디바이스에 저장된 루트 CA 증명서(ACR의 생성시 저장된, ACR 자격증명서로서), 및 디바이스에 액세스하려고 시도하는(이 특정의 ACR에 대해서) 실체에 의해 공급된 증명서/증명서 체인에 기초하여 호스트들을 인증한다.

각 ACR에 대해서 호스트 증명서 당국은 루트 CA로서 작용한다(이것은 ACR 자격증명서들에 상주하는 증명서이다). 예를 들면, 한 ACR에 대해서 루트 CA는 "호스트 1 CA(레벨 2) 증명서"일 수도 있을 것이며 또 다른 ACR에 대해서 이것은 "호스트 루트 CA 증명서"일 수도 있을 것이다. 각각의 ACR에 대해서, 루트 CA에 의해 서명된 증명서(또는 루트 CA를 종단-실체 증명서에 연결하는 증명서 체인)을 보유하는 모든 실체는 ACR이 종단-실체 증명서에 대한 대응하는 사설키를 갖고 있다면 이 ACR에 로그인할 수 있다. 위에 언급된 바와 같이, 증명서들은 공개된 것으로 비밀로 유지되지 않는다.

루트 CA에 의해 발급된 모든 증명서 보유자들(및 대응하는 사설키)이 그 ACR에 로그인할 수 있다는 사실은 특정 ACR에 대한 인증이 ACR 자격증명서에 저장된 루트 CA의 발급자에 의해 결정됨을 의미한다. 즉, 루트 CA의 발급자는 ACR의 인증 방법을 관리하는 실체일 수 있다.

호스트 루트 증명서

루트 증명서는 로그인(호스트에)하려고 시도하는 실체의 공개키를 검증하기를 시작하기 위해 SSA가 사용하는 신뢰된 CA 증명서이다. 이 증명서는 ACR이 ACR 자격증명서들의 부분으로서 생성될 때 제공된다. 이것은 PKI 시스템에 대한 신뢰의 루트이며 따라서 신뢰된 실체(부 ACR 또는 제조/구성 신뢰된 환경)에 의해 제공된 것으로 가정된다. SSA는 증명서 서명을 검증하기 위해 자신의 공개키를 사용하여 이 증명서를 검증한다. 호스트 루트 증명서는 시스템(10)의 바람직하게는 도 1의 CPU(12)에 의해서만 액세스될 수 있는 디바이스의 비밀키들과 함께 비휘발성 메모 리(도 1에 도시되지 않음)에 암호화되어 저장된다.

호스트 증명서 체인

인증 동안 SSA에 제공되는 증명서들이 있다. 호스트 증명서 체인의 어떠한 재수집도 체인의 처리가 완료된 후엔 디바이스에 저장되지 않아야 한다.

도 20은 다수의 서로 다른 호스트 증명서 체인들을 도시한 호스트 증명서 레벨 계층의 개략도이다. 도 20에 도시된 바와 같이, 호스트 증명서는 많은 서로 다른 증명서 체인들을 구비할 수 있는데, 여기서 3가지만 예시된다.

A1. 호스트 루트 CA 증명서(502), 호스트 1 CA (레벨 2) 증명서(504) 및 호스트 증명서(506);

B1. 호스트 루트 CA 증명서(502), 호스트 n CA (레벨 2) 증명서(508), 호스트 1 CA (레벨 3) 증명서(510), 호스트 증명서(512);

C1. 호스트 루트 CA 증명서(502), 호스트 n CA (레벨 2) 증명서(508) 및 호스트 증명서(514).

위에 3개의 증명서 체인들 A1, B1, C1은 호스트의 공개키가 진본임을 입증하는데 사용될 수 있는 3가지 가능한 호스트 증명서 체인들을 도시한다. 위 및 도 10에 증명서 체인 A1을 참조하여, 호스트 1 CA (레벨 2) 증명서(504)에 공개키는, 공개키가 호스트 루트 CA 증명서(502)에 있는 호스트 루트 CA의 사설키에 의해 서명된다(즉, 공개키의 다이제스트를 암호화함으로써). 이어서 호스트 증명서(506)에 호스트 공개키는 공개키가 호스트 1 CA (레벨 2) 증명서(504)에 제공되는, 호스트 1 CA (레벨 2)의 사설키에 의해 서명된다. 그러므로, 호스트 루트 CA의 공개키를 갖는 실체는 위에 증명서 체인 A1의 진위를 검증할 수 있을 것이다. 제 1 단계로서, 실체는 호스트에 의해 그에 보내진 호스트 1 CA(레벨 2) 증명서(504)에 서명된 공개키를 해독하기 위해 소유하고 있는 호스트 루트 CA의 공개키를 사용하고 해독된 서명된 공개키를 호스트에 의해 보내진 호스트 1 CA (레벨 2) 증명서(504)에 비서명된 공개키의 다이제스트와 비교한다. 둘이 일치한다면, 호스트 1 CA (레벨 2)의 공개키가 인증되고, 실체는 호스트 1 CA (레벨 2)의 인증된 공개키를 사용하여, 호스트에 의해 보내진 호스트 증명서(506)에 호스트 1 CA (레벨 2)의 사설키에 의해 서명된 호스트의 공개키를 해독한다. 이 해독된 서명된 값이 호스트에 의해 보내진 호스트 증명서(506)에 공개키의 다이제스트의 값과 일치한다면, 호스트의 공개키가 또한 인증된다. 증명서 체인들(B1, C1)은 유사한 방식으로 인증을 위해 사용될 수 있다.

체인 A1을 수반하는 위에 프로세스로부터 유념되는 바와 같이, 실체에 의해 검증될 필요가 있는 호스트로부터의 제 1 공개키는 호스트 루트 CA 증명서가 아니라 호스트 1 CA (레벨 2) 내 공개키이다. 그러므로, 실체에 보낼 필요가 있는 모든 호스트는 호스트 1 CA (레벨 2) 증명서(504) 및 호스트 증명서(506)이며, 따라서 호스트 1 CA (레벨 2) 증명서는 보내질 필요가 있는 체인 내 첫 번째 것이 될 것이다. 위에 도시된 바와 같이, 증명서 검증의 순서(sequence)는 다음과 같다. 이 경우, 메모리 디바이스(10)인 검증 실체는 먼저, 체인에서 제 1 증명서, 이 경우엔 루트 CA 밑에 CA의 증명서(504) 내 공개키의 진위를 검증한다. 이러한 증명서에 공개키가 진본인 것으로 검증된 후, 디바이스(10)는 다음 증명서, 이 경우엔 호스트 증명서(506)를 검증을 진행한다. 동일 토큰에 의해서, 검증의 유사한 순서가 적용될 수 있는데 여기서 증명서 체인은 2보다 많은 증명서들을 내포하며, 루트 증명서 바로 밑에 증명서부터 시작하여 인증될 실체의 증명서로 끝난다.

디바이스 증명서 계층

호스트는 2개의 요인들로서, 호스트에 저장된 디바이스 루트 CA와, 디바이스에 의해 호스트에 공급되는(ACR의 생성시 자격증명서로서 디바이스에 공급되는) 증명서/증명서 체인에 기초하여 디바이스를 인증한다. 호스트에 의해 디바이스를 인증하는 프로세스는 위에 기술된 호스트를 인증하는 디바이스에 대한 것과 유사하다.

디바이스 증명서 체인

이들은 ACR의 키 쌍의 증명서들이다. 이들은 ACR이 생성될 때 카드에 제공된다. SSA는 이들 증명서들을 개별적으로 저장하고 이들을, 인증 동안, 하나씩, 호스트에 제공할 것이다. SSA는 호스트에 인증하기 위해 이들 증명서들을 사용한다. 디바이스는 3개와는 다른 다수의 증명서들이 사용될 수 있을지라도, 3개의 증명서들의 체인을 취급할 수 있다. 증명서들의 수는 ACR마다 다를 수 있다. 이것은 ACR이 생성될 때 결정된다. 디바이스는 증명서 체인을 호스트에 보낼 수 있는데, 그러나, 증명서 체인 데이터를 사용하지 않기 때문에 이들 증명서 체인을 파싱(parse)할 필요는 없다.

도 21은 저장 디바이스들과 같은 SSA를 사용하는 디바이스들을 위한 1 내지 n 개의 서로 다른 증명서 체인들을 예시하기 위한 디바이스 증명서 레벨 계층을 예 시한 개략도이다. 도 21에 도시된 n 개의 서로 다른 증명서 체인들은 다음과 같다.

A2. 디바이스 루트 CA 증명서(520), 디바이스 1 CA (제조자) 증명서(522) 및 디바이스 증명서(524);

B2. 디바이스 CA 증명서(520), 디바이스 n CA (제조자) 증명서(526) 및 디바이스 증명서(528).

SSA 디바이스는 각각이 자신의 디바이스 CA 증명서를 갖고 있는 1 내지 n의 서로 다른 제조업자들에 의해 제조될 수 있다. 그러므로, 특정 디바이스에 대한 디바이스 증명서에 공개키는 이의 제조자의 사설키에 의해 서명될 것이며, 이어 제조자의 공개키는 디바이스 루트 CA의 사설키에 의해 서명된다. 디바이스의 공개키가 검증되는 방법은 위에 기술된 호스트의 공개키의 경우에 방법과 유사하다. 호스트에 대해 위에 기술된 체인 A1의 검증의 경우에서처럼, 디바이스 루트 CA 증명서를 보낼 필요는 없으며, 보낼 필요가 있을 체인들에서 제 1 증명서는 디바이스 i CA(증명서) 증명서, 이에 이은 디바이스 증명서이며, i는 1 내지 n의 정수이다.

도 21에 도시된 실시예에서, 디바이스는 2개의 증명서들로서 디바이스 i CA(제조자) 증명서 및 이에 이은 자신의 디바이스 증명서를 제시할 것이다. 다바이스 i CA(제조자) 증명서는 이러한 디바이스를 제조하였고 디바이스의 공개키를 서명하기 위해 사설키를 제공하는 제조자인 제조자의 증명서이다. 디바이스 i CA(제조자) 증명서가 호스트에 의해 수신되었을 때, 호스트는 자신이 소유한 루트 CA의 공개키를 사용하여 디바이스 i CA(제조자) 공개키를 해독하고 검증할 것이다. 이 검증이 실패하면, 호스트는 프로세스를 중단(abort)하고 인증이 실패하였음을 디바 이스에 통보할 것이다. 인증이 성공하면, 호스트는 다음 증명서에 대해 요청을 디바이스에 보낸다. 이어서 디바이스는 유사한 방식으로 호스트에 의해 검증될 자신의 디바이스 증명서를 보낼 것이다.

위에 기술된 검증 프로세스들이 도 22 및 도 23에 보다 상세히 도시되었다. 도 22에서, "SSM 시스템"은 이하 기술되는 다른 기능들뿐만 아니라 여기 기술된 SSA 시스템을 구현하는 소프트웨어 모듈이다. SSM은 메모리(20) 또는 CPU(12) 내 비휘발성 메모리(도시되지 않음)에 저장된 데이터베이스와 함께 소프트웨어 또는 컴퓨터 코드로서 실현될 수도 있고 RAM(12a)에 읽혀져 CPU(12)에 의해 실행된다.

도 22에 도시된 바와 같이, 디바이스(10)에 SSM 시스템(542)이 호스트 시스템(540)을 인증하는 프로세스에서 3가지 국면들이 있다. 제 1 공개키 검증 국면에서, 호스트 시스템(540)은 SSM 명령에서 호스트 증명서 체인을 SSM 시스템(542)에 보낸다. SSM 시스템(542)은 호스트 증명서(544) 및 호스트 공개키(546)의 진본임을 ACR(5550)에 호스트 루트 증명서(548)에 위치된 루트 증명서 당국 공개키를 사용하여 검증한다(블록 552). 루트 증명서 당국과 호스트 간에 중간 증명서 당국이 연루되는 경우, 블록(552)에서 검증을 위해서 중간 증명서(549)도 사용된다. 검증 또는 프로세스(블록 5520)가 성공적이라고 한다면, SSM 시스템(542)은 제 2 국면으로 진행한다.

SSM 시스템(542)은 난수(554)를 발생하여 이를 시도(challenge)로서 호스트 시스템(540)에 보낸다. 시스템(540)은 호스트 시스템의 사설키(547)를 사용하여 난수(554)를 서명하고(블록 556) 서명된 난수를 시도에 대한 응답으로서 보낸다. 응 답은 호스트 공개키(546)를 사용하여 해독되고(블록 558) 난수(554)와 비교된다(블록 560). 해독된 응답이 난수(554)와 일치한다고 하면, 시도 응답은 성공적이다.

제 3 국면에서, 호스트 공개키(546)를 사용하여 난수(562)가 암호화된다. 그러면 이 난수(562)가 세션 키가 된다. 호스트 시스템(540)은 이의 사설키를 사용하여 SSM 시스템(542)으로부터 암호화된 수(562)를 해독함으로써(블록 564) 세션 키를 얻을 수 있다. 이 세션 키에 의해서, 호스트 시스템(540)과 SSM 시스템(542)간에 보안 통신이 개시될 수 있다. 도 22는 호스트 시스템(540)이 디바이스(10)에서 SSM 시스템(542)에 의해 인증되는 단방향 비대칭 인증을 도시한 것이다. 도 23은 도 22의 단방향 인증 프로토콜과 유사한 양방향(two-way) 상호 인증 프로세스를 도시한 프로토콜 도면으로서, 도 23에서 SSM 시스템(542)은 호스트 시스템(540)에 의해서 인증된다.

도 24는 발명의 일 실시예를 도시하는데 사용되는 증명서 체인(590)을 도시한 것이다. 위에 언급된 바와 같이, 검증을 위해 제시될 필요가 있는 증명서 체인은 다수의 증명서들을 포함할 수 있다. 이에 따라 도 24의 증명서 체인은 총 9개의 증명서들을 포함하며, 이들 모두는 증인을 위해 검증될 필요가 있을 수 있다. 배경부분에서 위에 설명될 바와 같이, 증명서 검증을 위한 현존의 시스템에서, 불완전한 증명서 체인이 보내지거나, 전체 증명서가 보내질 경우 증명서들은 전체 일 그룹의 증명서들이 수신되어 저장될 때까지 수신자가 증명서들을 분석할 수 있게 되도록 어떤 특정한 순서로 보내지지 않는다. 체인에 증명서들의 수는 사전에 알려지지 않기 때문에, 이것은 문제를 제시할 수 있다. 많은 량의 저장공간이 어떤 길이 의 증명서 체인을 저장하기 위해 유보될 필요가 있을 수 있다. 이것은 검증을 수행하는 저장 디바이스들에 있어선 문제가 될 수 있다.

발명의 일 실시예는 증명서 체인이 저장 디바이스에 의해 검증될 동일 순서로 호스트 디바이스들이 자신의 증명서 체인을 보내는 시스템에 의해 문제가 완화될 수 있다는 인식에 기초한다. 이에 따라 도 24에 도시된 바와 같이, 증명서들의 체인(590)은 호스트 루트 증명서 바로 밑의 증명서인 증명서 체인(590(1))으로 시작하고 호스트 증명서인 증명서(590(9))로 끝난다. 그러므로, 디바이스(10)는 증명서(590(1))에 공개키를 먼저 검증하고 이어서 증명서(590(2))에 공개키를 검증하고 등등을 증명서(590(9))에 호스트 공개키기 검증될 때까지 할 것이다. 그러면 이것은 전체 증명서 체인(590)의 검증 프로세스를 완료한다. 이에 따라 호스트 디바이스가 증명서 체인이 검증될 동일 순서로 증명서 체인(590)을 메모리 디바이스(10)에 보낸다면, 메모리 디바이스(10)는 체인(590)에 전체 9개의 증명서가 수신될 때까지 기다려야 할 필요 없이, 수신된 대로 각각의 증명서 검증을 시작한다.

이에 따라, 일 실시예에서, 호스트 디바이스는 체인(590)에 한번에 한 증명서를 메모리 디바이스(10)에 보낸다. 증명서가 검증된 후, 체인에 마지막 증명서를 제외하고, 호스트에 의해 보내지는 다음 증명서에 의해 덮어 쓰일 수 있다. 이러한 식으로, 메모리 디바이스(10)는 언제든 단일 증명서만을 저장하기 위한 공간을 유보할 필요가 있을 것이다.

메모리 디바이스는 전체 체인(590)가 언제 수신되었는지를 알 필요가 있을 것이다. 이에 따라, 바람직하게, 마지막 증명서(590(9))는 이것이 체인에 마지막 증명서라는 표시자 또는 표시를 내포한다. 이 특징은 호스트에 의해 메모리 디바이스(10)에 보내지는 증명서 버퍼 앞에 있는 제어 섹터 내 정보를 나타낸 테이블인 도 25에 도시되었다. 도 25에 도시된 바와 같이, 증명서(590(9))의 제어 섹터는 인수(argument) 이름 "'마지막임' 플래그"을 내포한다. 이어서 메모리 디바이스(10)는 수신된 증명서가 체인에 마지막 증명서인지 판정하기 위해 "마지막임" 플래그가 셋 되어 있는지를 체크함으로써 증명서(590(9))가 체인에 마지막 증명서임을 검증할 수 있다.

대안적 실시예에서, 체인(590)에 증명서는 하나씩이 아니라 하나, 둘, 또는 세 개 증명서들의 그룹들로 보내질 수도 있다. 자명하게, 다른 개수의 증명서들을 가진 그룹들, 또는 그룹들 내 동일 수의 증명서들이 사용될 수도 있다. 이에 따라, 체인(590)은 5개의 연속한 스트링들의 증명서들(591, 593, 595, 597, 599)을 포함한다. 스트링들 각각은 적어도 하나의 증명서를 내포한다. 연속한 한 스트링의 증명서들은 체인에 당면의 한 스트링 전에 스트링 다음인 증명서, 체인에 한 스트링 다음에 오는 스트링 바로 다음의 증명서(끝 증명서), 및 시작 증명서와 끝 증명서 간에 모든 증명서들을 스트링을 내포하는 스트링이다. 예를 들면, 스트링(593)은 모든 3개의 증명서들(590(2), 590(3), 590(4))을 내포한다. 5 스트링들의 증명서들은 591, 593, 595, 597 및 599로 끝나는 순서로 메모리 디바이스(10)에 의해 검증된다. 그러므로, 5 스트링들이 메모리 디바이스(10)에 의해 수행되는 검증과 동일 순서로 보내지고 수신된다면, 메모리 디바이스는 스트링들이 검증된 후에 이들 중 어느 것이든 저장할 필요가 없을 것이며, 마지막 스트링은 제외하고 모든 스트링들 은 호스트로부터 도착하는 다음 스트링에 의해 덮어 쓰일 수 있다. 이전 실시예에서처럼, 체인에 마지막 증명서임을 나타내기 위해 특정 값으로 설정되는 플래그와 같은 표시자를 체인에 마지막 증명서가 내포하는 것이 바람직하다. 이 실시예에서, 메모리 디바이스는 5 스트링들에서 가장 많은 수의 증명서들을 저장하는데 적절한 공간을 유보하는 것만이 필요할 것이다. 이에 따라, 호스트가 먼저 메모리 디바이스(10)에 가장 긴 스트링을 통지한다면, 메모리 디바이스(10)는 가장 긴 스트링을 위한 충분한 공간을 유보하는 것이 필요할 것이다.

바람직하게, 호스트에 의해 보내진 체인에 각 증명서의 길이는 증명서에 의해 증명되는 공개키의 길이에 4배보다 많지 않다. 마찬가지로, 메모리 디바이스의 공개키를 증명하기 위해 메모리 디바이스(10)에 의해 호스트 디바이스에 보내진 증명서의 길이는 증명서의 증명되는 공개키의 길이에 4배보다 많지 않은 것이 바람직하다.

증명서 체인들의 검증을 위한 위에 기술된 실시예가 도 26의 흐름도에 도시되었고, 여기서 간단하게 하기 위해서 각 그룹 내 증명서들의 수는 하나인 것으로 가정된다. 도 26에 도시된 바와 같이, 호스트는 체인에 증명서들을 순차적으로 카드에 보낸다. 체인에 제 1 증명서부터 시작하여(전형적으로 위에 설명된 바와 같이 루트 증명서에 이어지는 것). 카드는 인증되고 있는 증명서 체인을 호스트로부터 순차적으로 수신한다(블록 602). 이어서, 카드는 수신된 증명서들 각각을 검증하고 증명서들 어느 증명서든 검증에 실패한다면 프로세스를 중단한다. 증명서들 중 어느 증명서이든 검증에 실패한다면, 카드는 호스트에 통지한다(블록들 604, 606). 이어서 카드는 마지막 증명서가 수신되어 검증되었는지 여부를 검출할 것이다(마름모 608). 마지막 증명서가 수신되어 검증되지 않았다면, 카드는 블록(602)으로 되돌아가 호스트로부터 검증들을 수신하여 검증하는 것을 계속한다. 마지막 증명서가 수신되어 검증되었다면, 카드는 증명서 검증 후에 다음 국면으로 진행한다(610). 이하 도 26에 특징들 및 후속되는 도면들이 예들로서 메모리 카드들을 언급하지만, 메모리 카드가 아닌 물리적 형태들을 가진 메모리 디바이스들에도 이들 특징들이 적용될 수 있음이 이해될 것이다.

카드가 호스트를 인증하고 있을 때 호스트에 의해 수행되는 프로세스가 도 27에 도시되었다. 도 27에 도시된 바와 같이, 호스트는 체인에 다음 증명서를 카드에 보낸다(블록 620)(전형적으로 루트 증명서 다음에 오는 것부터 시작한다). 이어서 호스트는 인증 실패를 나타내는 중단 통지가 카드로부터 수신되었는지를 판정한다(마름모 622). 중단 통지가 수신되었다면, 호스트는 중지한다(블록 624). 중단 통지가 수신되지 않았다면, 호스트는 보내진 마지막 증명서에 "마지막임 플래그" 설정되었는지를 체크함으로써 체인에 마지막 증명서가 보내졌는지를 알기 위해 체크한다(마름모 626). 마지막 증명서가 보내졌다면, 호스트는 증명서 검증 후에 다음 국면에 진행한다(블록 628). 도 22 및 도 23에 도시된 바와 같이, 다음 국면은 세션 키 생성이 후속되는 시도 응답일 수 있다. 체인에 마지막 증명서가 아직 보내지지 않았다면, 호스트는 블록(620)으로 되돌아가 체인에 다음 증명서를 보낸다.

카드가 인증되고 있을 때 카드 및 호스트에 의해 취해지는 조치들이 도 28 및 도 29에 도시되었다. 도 28에 도시된 바와 같이, 시작 후, 카드는 체인에 증명 서를 보내기 위해 호스트로부터 요청을 기다린다(블록 630, 마름모 632). 호스트로부터 요청이 수신되지 않으면, 카드는 마름모(632)로 되돌아 갈 것이다. 호스트로부터 요청이 수신되면, 카드는 보내져야 할 제 1 증명서부터 시작하여(전형적으로 루트 증명서 다음의 것부터 시작한다, (블록 634)), 체인에 다음 증명서를 보낼 것이다. 카드는 호스트로부터 실패 통지가 수신되었는지를 결정한다(마름모 636). 실패 통지가 수신되었다면, 카드는 중지한다(블록 637). 어떠한 실패 통지도 수신되지 않으면, 카드는 마지막 증명서가 보내졌는지를 판정한다(마름모 638). 마지막 증명서가 보내지지 않았다면, 카드는 마름모 (632)로 되돌아가서 체인에 다음 증명서를 보내기 위해 호스트로부터 다음 요청을 수신할 때까지 기다린다. 마지막 증명서가 보내졌다면, 카드는 다음 국면으로 진행한다(블록 639).

도 29는 카드가 인증되고 있을 때 호스트에 의해 취해지는 조치들을 도시한 것이다. 호스트는 보내질 제 1 증명서에 대한 요청부터 시작하여, 체인에 다음 증명서에 대한 요청을 카드에 보낸다(블록 640). 이어서 호스트는 수신된 각 증명서를 검증하고, 프로세스를 중단하고 증명이 실패하면 카드에 통지한다(블록 642). 검증이 통과하면, 호스트는 마지막 증명서가 수신되어 성공적으로 검증되었는지를 알기 위해 체크한다(마름모 644). 마지막 증명서가 수신되어 성공적으로 검증되지 않았다면, 호스트는 블록 640으로 되돌아가 체인에 다음 증명서에 대한 요청을 보낸다. 마지막 증명서가 수신되어 성공적으로 검증되었다면, 호스트는 증명서 검증 후에 다음 국면으로 진행한다(블록 646).

증명서 철회

증명서가 발행될 때, 이의 전체 유효 기간동안 사용될 것으로 예상된다. 그러나, 다양한 환경들은 유효 기간의 만기에 앞서 증명서가 무효가 되게 할 수도 있다. 이러한 환경들은 이름의 변경, 주체와 CA간의 연관의 변경(예를 들면, 고용주가 조직에 채용을 종료한다), 및 대응하는 사설키의 손상(compromise) 또는 의심되는 손상을 포함한다. 이러한 상황들 하에서, CA는 증명서를 철회할 필요가 있다.

SSA는 서로 다른 방법들로 증명서 철회를 할 수 있게 하는데, 각 ACR은 증명서들을 철회하기 위한 특정 방법에 대해 구성될 수 있다. ACR은 철회방법을 지원하지 않게 구성될 수 있다. 이 경우, 각 증명서는 이의 만기일까지 유용한 것으로 간주된다. 아니면 증명서 철회 리스트들(CRL)이 채용될 수도 있다. 또 다른 대안으로서, 철회방법은 특정 애플리케이션에 특유하거나, 또는 애플리케이션에 특유한 것일 수 있는데, 이에 대해 이하 설명될 것이다. ACR은 철회 값을 명시함으로써 3가지 철회방법들 중 어느 것이 채택될 것인지를 명시한다. ACR이 철회 방법 없이 생성된다면, ACR 소유자에 의해 활성화될 수 있는 철회방법을 채택하는 것이 가능하다. 메모리 디바이스 증명서들의 철회는 SSA 보안 시스템이 아니라 호스트에 의해 시행된다. ACR 소유자는 호스트 루트 증명서의 철회를 관리해야 하며, 이에 의해 행해지는 메커니즘은 ACR의 자격증명서들을 업데이트함으로써 행해진다.

증명서 철회 리스트(CRL)

SSA 시스템은 각 CA가 증명서 철회 리스트(CRL)이라고 하는 서명된 데이터 구조를 주기적으로 발행하는 것을 수반하는 철회방법을 사용한다. CRL은 CA(해당 증명서들을 발행한 동일 CA)에 의해 서명되고 공중이 자유로이 사용할 수 있게 한 철회된 증명서들을 확인하는 시간 스탬프된 리스트이다. 각각의 철회된 증명서는 이의 증명서 일련번호에 의해 CRL에서 확인된다. CLR의 크기는 임의이며 철회된 비-만기된 증명서들의 수에 따른다. 디바이스가 증명서를 사용할 때(예를 들면, 호스트의 아이덴터티를 검증하기 위해), 디바이스는 증명서 서명(및 유효성)을 체크할 뿐만 아니라 CRL을 통해 수신된 일련번호들의 리스트에 대해 이를 검증도 한다. 증명서의 일련번호와 같은 확인 증명서를 발행한 CA에 의해 발행된 CRL에서 발견된다면, 이것은 증명서가 철회되었으며 더 이상 유효하지 않음을 나타낸다.

또한, CRL은 이것이 증명서들을 유효화하기 위한 목적에 사용하기 위해서 진본인 것으로 검증될 필요가 있을 것이다. CRL들은 CLR을 발행한 CA의 사설키를 사용하여 서명되며, 서명된 CLR을 CA의 공개키를 사용하여 해독함으로써 진본인 것으로 검증될 수 있다. 해독된 CRL이 비서명된 CRL의 다이제스트와 일치한다면, 이것은 CRL이 부정변조되지 않았으며 진본임을 의미한다. CRL들은 해싱 알고리즘을 사용하여 이들의 다이제스트들을 얻기 위해 자주 해시되며 다이제스트들은 CA의 사설키에 의해 암호화된다. CRL이 유효한지 검증하기 위해서, 서명된 CRL(즉, 해시되고 암호화된 CRL)은 CA의 공개키를 사용하여 해독되어 해독되고 해시된 CRL(즉, CLR의 다이제스트)를 내준다. 이어서 이것은 해시된 CRL과 비교된다. 이에 따라 검증 프로세스는 해독되고 해시된 CRL과 비교를 위해 CRL를 해싱하는 단계를 빈번히 수반할 수 있다.

CRL 방법의 특징들 중 하나는 증명서의 정당성(CRL에 대해서)은 CRL를 얻는 것과는 별개로 수행될 수 있다는 것이다. 또한, CRL들은 관계있는 증명서들의 발행 자들에 의해 서명되고 위에 기술된 방식으로, CRL들을 발행한 CA들의 공개키들을 사용하여, 증명서들의 검증과 유사한 방식으로 검증된다. 메모리 디바이스는 서명이 CRL의 것이며 CRL의 발행자가 증명서의 발행자와 일치함을 검증한다. CRL 방법의 또 다른 특징은 증명서들 자체들과 정확히 동일한 수단에 의해, 즉, 신뢰되지 않은 서버들 및 신뢰되지 않은 통신들을 통해, CRL들이 분배될 수 있다는 것이다. CRL들 및 이들의 특징들은 X.509 표준에서 상세히 설명된다.

CRL을 위한 SSA 기반구조

SSA는 CRL 방법을 사용하여 호스트들의 철회를 위한 기반구조를 제공한다. CRL 철회방법으로 RSA 기반 ACR에 인증할 때, 호스트는 추가 필드로서 한 CRL(잠재적으로 -발행자 CA에 의해 어떠한 증명서들도 철회되지 않는다면- 빈 것)을 증명서 셋(Set Certification) 명령에 추가한다. 이 필드는 증명서의 발행자에 의해 서명된 CRL를 내포할 것이다. 이 필드가 있을 때, 메모리 디바이스(10)는 먼저 증명서 준비 명령에서 증명서를 검증한다. CRL 저장소를 얻고 이에 액세스하는 것은 완전히 호스트의 의무이다. CRL들은 이들이 유효한 기간인 기간들(CRL 만기 기간들 또는 CET)에 발행된다. 검증 동안에, 현재 시간이 이 기간 내에 있지 않은 것으로 발견된다면, CRL은 결함이 있는 것으로 간주되고, 증명서 검증을 위해 사용될 수 없다. 이때 결과는 증명서의 인증이 실패한다는 것이다.

종래의 증명서 검증 방법들에서, 인증 또는 검증하는 실체는 증명서 당국들(CA)로부터 증명서 철회 리스트들을 소유하거나 검색하여 제시된 증명서가 철회되었는지를 판정하기 위해 인증을 위해 제시된 증명서의 일련번호들을 리스트에 대 해 체크할 수 있을 것으로 예상된다. 인증 또는 검증하는 실체가 메모리 디바이스인 경우, 메모리 디바이스는 CA들로부터 증명서 리스트들을 검색하기 위해 자신이 사용되지 않았을 수도 있다. 증명서 철회 리스트가 디바이스에 사전에 저장되어 있다면, 이러한 리스트는 설치일 후에 철회된 증명서들이 리스트 상에 나타나지 않게 되도록 업데이트될 수도 있다. 이것은 철회된 증명서를 사용하여 사용자들이 저장 디바이스에 액세스할 수 있게 할 것이다. 이것은 바람직하지 못하다.

위에 문제는 인증되기를 원하는 실체가 메모리 디바이스(10)일 수 있는 인증 실체에 인증되도록 증명서와 함께 증명서 철회 리스트를 제시하는 시스템에 의해 일 실시예에서 해결될 수 있다. 그러면 인증 실체는 증명서 및 수신된 증명서 철회 리스트의 진위를 검증한다. 인증 실체는 증명서의 일련번호와 같은 증명서의 확인이 리스트 상에 있는지를 체크함으로써 증명서가 철회 리스트 상에 있는지를 체크한다.

이상에 비추어, 호스트 디바이스와 메모리 디바이스(10)간에 상호 인증을 위해 비대칭 인증 방법이 사용될 수도 있다. 메모리 디바이스(10)에 인증되기를 원하는 호스트 디바이스는 이의 증명서 체인 및 대응하는 CRL들 둘 다를 제공하는 것을 필요로 할 것이다. 반면, 호스트 디바이스들을 CRL들을 얻기 위해서 CA들에 접속하는데 사용되었으며, 따라서 메모리 디바이스(10)가 호스트 디바이스들에 의해 인증되어야 할 때, 메모리 디바이스는 CLR들을 호스트들의 증명서들 또는 증명서 체인들과 함께 이들에 제시할 필요가 없다.

최근에, 이를테면 서로 다른 내장된 또는 독자형 음악 플레이어들, mp3 플레 이어들, 셀룰러 전화들, PDA들, 및 노트북 컴퓨터들과 같은, 콘텐트를 작동시키는데 사용될 수 있는 늘어나는 수의 서로 다른 유형들의 휴대 디바이스들이 있다. 증명서 당국들로부터 증명서 검증 리스트들에 액세스하기 위해서 월드 와이드 웹에 이러한 디바이스를 연결하는 것이 가능한 반면, 많은 사용자들은 전형적으로 매일 웹에 연결하는 것이 아니라 이를테면 매 몇 주에, 새로운 콘텐트를 얻기 위해서 또는 가입들을 갱신하기 위해서만 그렇게 할 것이다. 그러므로, 이러한 사용자들이 보다 빈번하게 증명서 당국들로부터 증명서 철회 리스트들을 얻어야 한다는 것은 성가실 수 있다. 이러한 사용자들을 위해서, 증명서 철회 리스트 및 선택적으로, 보호된 콘텐트에 액세스하기 위해 저장 디바이스에 제시될 필요가 있을 호스트 증명서도 저장 디바이스 자체의 바람직하게는 비보호된 영역에 저장될 수도 있다. 많은 유형들의 저장 디바이스들(예를 들면, 플래시 메모리들)에서 저장 디바이스들의 비보호된 영역들은 저장 디바이스들 자체들에 의해서가 아니라 호스트 디바이스들에 의해 관리된다. 이에 따라, 더 최신의 증명서 철회 리스트들을 얻기 위해서 사용자가 웹에 접속해야 할(호스트 디바이스를 통해서) 필요가 없다. 호스트 디바이스는 간단히 이러한 정보를 저장 디바이스의 비보안 영역으로부터 검색하여 저장 디바이스에 보호된 콘텐트에 액세스하기 위해 저장 또는 메모리 디바이스에 이러한 증명서 및 리스트를 우회하고 제시할 수도 있다. 보호된 콘텐트 및 이의 대응하는 증명서 철회 리스트에 액세스하기 위해 증명서는 전형적으로 어떤 기간들 동안 유효하기 때문에, 이들이 여전히 유효한 한, 사용자는 최신의 증명서들 또는 증명서 철회 리스트를 얻을 필요가 없을 것이다. 위에 특징은 업데이트된 정보를 위해 증 명서 당국에 접속해야 할 필요 없이, 증명서 및 증명서 철회 리스트 둘 다 여전히 유효한 동안 상당히 긴 기간들 동안 이들에 사용자들이 편리하게 액세스할 수 있게 한다.

위에 기술된 프로세스가 도 30 및 도 31에 흐름도로 도시되었다. 도 30에 도시된 바와 같이, 호스트(24)는 인증을 위해 메모리 디바이스에 호스트가 제시할 증명서에 관계된 CRL을 메모리 디바이스(10)의 비보안된 공개 영역으로부터 독출한다(블록 652). CRL이 메모리의 비보안된 영역에 저장되어 있기 때문에, CRL이 호스트에 의해 얻어질 수 있기 전에 인증할 필요는 없다. CRL이 메모리 디바이스의 공개 영역에 저장되어 있기 때문에, CRL의 독출은 호스트 디바이스(24)에 의해 제어된다. 이어서 호스트는 검증될 증명서와 함께 CLR을 메모리 디바이스에 보내고(블록 654) 메모리 디바이스(10)로부터 실패 통지를 수신하지 않는다면 다음 국면으로 진행한다(블록 656). 도 31을 참조하면, 메모리 디바이스는 CRL 및 증명서를 호스트로부터 수신하고(블록 658) 증명서 일련번호가 CLR에 있는지와, 뿐만 아니라 다른 점들에서(예를 들면, CRL이 만기되었는지를) 체크한다(블록 660). 증명서 일련번호가 CRL에서 발견되거나 다른 이유들로 실패한다면, 메모리 디바이스는 호스트에 실패 통지를 보낸다(블록 662). 이에 따라, 서로 다른 호스트들은 동일 CRL이 서로 다른 호스트들의 인증을 위해 사용될 수 있기 때문에, 메모리 디바이스의 공개 영역에 저장된 CLR을 얻을 수 있다. 위에 언급된 바와 같이, CRL을 사용하여 검증될 증명서는 사용자의 편의를 위해 바람직하게는 메모리 디바이스(10)의 보안된된 영역에 CLR과 함께 저장될 수도 있다. 그러나, 증명서는 호스트에 의해서만 증 명서가 발행되는 메모리 디바이스에 인증을 위해 사용될 수 있다.

CRL이 이의 필드들에 도 32에 도시된 바와 같이 다음 업데이트를 위한 시간을 내포하는 경우, 디바이스(10)에 SSA는 현재 시간이 이 시간 후인지를 알기 위해 이 시간에 대해 현재 시간을 체크하고, 그러하다면, 인증은 실패한다. 이에 따라 SSA는 현재 시간에 대해(또는 CRL이 메모리 디바이스(10)에 의해 수신될 때의 시간에 대해) CET 뿐만 아니라 다음 업데이트에 대한 시간 모두 체크한다.

위에 언급된 바와 같이, CRL이 철회된 증명서들의 긴 리스트의 확인들을 내포한다면, 호스트에 의해 제시된 증명서의 일련번호에 대해 리스트를 처리하고(예를 들면 해싱) 탐색하는 것은, 특히 처리 및 탐색이 순차로 수행된다면, 긴 기간이 걸릴 수 있다. 이에 따라 프로세스를 가속시키기 위해서, 이들은 동시에 수행될 수도 있다. 또한, 전체 CRL이 처리되어 탐색되기 전에 수신될 필요가 있다면, 프로세스는 시간 소비적이 될 수도 있다. 출원인은 프로세스가 CRL의 처리 및 탐색 부분들이 수신될 때(동작중에) 이들에 의해 급송될 수 있고, 따라서 CRL의 마지막 부분 수신되었을 때 프로세스는 거의 완료될 것임을 인식하였다.

도 33 및 도 34는 철회방법들의 위의 특징들을 도시한 것이다. 인증 실체(예를 들면, 메모리 카드와 같은 메모리 디바이스)에서, 증명서 및 CRL은 인증되기를 원하는 실체로부터 수신된다(블록 702). 암호화되지 않은 CRL의 부분들이 처리되고(예를 들면 해시되고) 제시된 증명서의 확인(예를 들면, 일련번호)을 위해 동시에 이러한 부분들에 대해 탐색이 수행된다. 처리된(예를 들면 해시된) CRL 부분들은 해시된 완전한 CRL에 컴파일되는데, 이것은 인증되기를 원하는 실체로부터 수신 된 부분들로부터 해독된 CRL 부분들을 컴파일함으로써 형성된 완전한 해독 및 해시된 CRL과 비교된다. 비교에서 일치가 없음을 비교가 나타낸다면 인증은 실패한다. 인증 실체는 현재 시간에 대한 CET뿐만 아니라 다음 업데이트를 위한 시간 둘 다를 체크한다(블록들 706, 708). 인증은 제시된 증명서의 확인이 CLR에서 발견되거나, 현재 시간이 CET 내에 있지 않거나, 다음 업데이트된 CRL에 대한 시간이 지났다면 실패한다(블록 710). 어떤 구현들에서 컴파일을 위해 해시된 CRL 부분들 및 해독된 해시된 CRL 부분들을 저장하는 것은 큰 량의 메모리 공간을 요구하지 않을 수 있다.

실체(예를 들면, 호스트)가 인증되기를 원할 때, 이의 증명서 및 CRL을 인증실체에 보낼 것이며(블록 722), 다음 국면으로 진행한다(블록 724). 이것이 도 34에 도시되었다.

전술한 바와 유사한 프로세스는 실체가 인증을 위해 증명서 체인을 제시한다면 구현될 수 있다. 이러한 이벤트에서, 위에 기술된 프로세스는 체인에 각 증명서에 대해 이의 대응하는 CRL과 함께 반복될 필요가 있을 것이다. 각 증명서 및 이의 CRL은 이들이, 증명서 체인의 나머지 및 이들의 대응하는 CRL들의 수신을 기다리지 않고 수신될 때 처리될 수 있다.

아이덴터티 오브젝트(IDO)

아이덴터티 오브젝트는 플래시 메모리 카드와 같은 메모리 디바이스(10)가 RSA 키-쌍 또는 이외 다른 유형들의 크립토그래픽 ID들을 저장할 수 있게 설계된 보호된 오브젝트이다. 아이덴터티 오브젝트는 아이덴터티들을 서명하고 검증하며 데이터를 암호화하고 해독하는데 사용될 수 있는 임의의 유형의 크립토그래픽 ID를 포함한다. 또한, 아이덴터티 오브젝트는 키 쌍에 공개키가 진본임을 증명하는 CA로부터의 증명서(또는 복수의 CA들로부터의 증명서 체인)을 포함하다. 아이덴터티 오브젝트는 외부 실체 또는 내부 카드 실체(즉, 아이덴터티 오브젝트의 소유자라고도 하는 디바이스 자체, 내부 애플리케이션 등)의 아이덴터티의 증거를 제공하는데 사용될 수 있다. 그러므로, 카드는 시도 응답 메커니즘을 통해 호스트를 인증하기 위해 RSA 키-쌍 또는 이외 다른 유형들의 크립토그래픽 ID들을 사용하는 것이 아니라, 그에 제공된 데이터 스트림들 서명을 통한 확인의 증거로서 사용한다. 아이덴터티 오브젝트에 크립토그래픽 ID에 액세스하기 위해서, 호스트는 먼저 인증될 필요가 있을 것이다. 이하 기술된 바와 같이, 인증 프로세스는 ACR에 의해 제어된다. 호스트가 성공적으로 인증된 후, 크립토그래픽 ID는 또 다른 당사자에 소유자의 아이덴터티를 확정하기 위해 아이덴터티 오브젝트 소유자에 의해 사용될 수 있다. 예를 들면, 크립토그래픽 ID(예를 들면, 공개-사설 키 쌍의 사설키)는 다른 당사자에 의해 호스트를 통해 제시된 데이터를 서명하는데 사용될 수 있다. 서명된 데이터 및 아이덴터티 오브젝트에 증명서는 다른 당사자에 아이덴터티 오브젝트 소유자 대신에 제시된다. 증명서에 공개-사설 키 쌍의 공개키는 CA(즉, 신뢰된 당국)에 의해 진본인 것으로 증명되고, 따라서 다른 당사자는 이 공개키가 진본임을 신뢰할 수 있다. 이어서 다른 당사자는 서명된 데이터를 증명서에 공개키를 사용하여 해독하고 해독된 데이터를 다른 당사자에 의해 보내진 데이터와 비교할 수 있다. 해독된 데이터가 다른 당사자에 의해 보내진 데이터와 일치한다면, 이것은 아이덴터티 오 브젝트의 소유자가 진본 사설키에 액세스할 수 있고 따라서 이것이 그러함을 나타내는 사실상의 실체이다.

아이덴터티 오브젝트의 두 번째 사용은 RSA 키 자체와 같은 크립토그래픽 ID를 사용하여 IDO의 소유자에 지정된 데이터를 보호하는 것이다. 데이터는 IDO 공개키를 사용하여 암호화될 것으로 예상된다. 메모리 카드와 같은 메모리 디바이스(10)는 데이터를 해독하기 위해 사설키를 사용할 것이다.

IDO는 임의의 유형의 ACR에 대해 생성될 수 있는 오브젝트이다. 일 실시예에서, ACR은 단지 하나의 IDO 오브젝트만을 가질 수도 있다. 데이터 서명 및 보호 특징들 둘 다는 SSA 시스템이 ACR에 인증할 수 있는 임의의 실체에 제공하는 서비스들이다. IDO의 보호 레벨은 ACR의 로그인 인증 방법만큼 높다. IDO를 가질 ACR에 대해 임의의 인증 알고리즘이 선택될 수 있다. 어떤 알고리즘이 IDO 사용을 더 잘 보호할 수 있는지를 판단하는 것은 생성자(호스트)에게 달려있다. IDO를 가진 ACR은 이의 증명서 체인을 IDO 공개키를 얻기 위한 명령에 응하여 제공한다.

IDO가 데이터 보호를 위해 사용되고 있을 때, 카드로부터 출력된 해독된 데이터는 더 보호를 필요로 할 수 있다. 이러한 경우에, 호스트는 가용 인증 알고리즘들 중 어느 것을 통해 확립된 보안 채널을 사용하기로 결정한다.

IDO를 생성할 때, PKCS#1 버전뿐만 아니라 키 길이가 선택된다. 일 실시예에서, 공개키 및 사설키는 PKCS#1 버전 2.1에 정의된 바와 같이 (지수, 모듈러) 표현을 사용한다.

일 실시예에서, IDO의 생성 동안 포함된 데이터는 선택된 길이에 RSA 키 쌍, 및 공개키의 진위를, 재귀적으로, 증명하는 증명서들의 체인이다.

IDO를 소유하는 ACR은 사용자 데이터의 서명을 허용할 것이다. 이것은 두 개의 SSA 명령들을 통해 행해진다.

. 셋(Set) 사용자 데이터: 서명될 자유 포맷의 데이터 버퍼를 제공한다.

. 겟(Get) SSA 서명. 카드는 RSA 서명을 제공할 것이다(ACR 사설키를 사용하여). 서명의 포맷 및 크기는 오브젝트 유형에 따라 PKCS#1 버전 1.5 또는 버전2.1에 따라 설정될 수 있다.

IDO를 사용하는 동작이 도 35 내지 도 37에 도시되었는데, 여기서 메모리 디바이스(10)는 플래시 메모리 카드이며, 카드는 IDO의 소유자이다. 도 35는 호스트에 보내진 데이터를 서명함에 있어 카드에 의해 수행되는 프로세스를 도시한다. 도 35를 참조하면, 위에 기술된 나무 구조의 노드에 ACR에 의해 제어되는 바와 같이 호스트가 인증된 후에(블록 802), 카드는 증명서에 대한 호스트 요청을 기다린다(마름모 804). 요청을 수신한 후, 카드는 증명서를 보내고 다음 호스트 요청을 위해 마름모 804로 되돌아간다(블록 806). 증명서들의 체인이 카드에 의해 소유된 IDO의 공개키를 증명하기 위해 보내질 필요가 있다면, 위에 작업들은 체인에 모든 증명서들이 호스트에 보내질 때까지 반복된다. 각 증명서가 호스트에 보내진 후, 카드는 호스트로부터 다른 명령들을 기다린다(마름모 808). 기설정된 기간 내에 호스트로부터 어떠한 명령도 수신되지 않는다면, 카드는 마름모(804)로 되돌아간다. 호스트로부터 데이터 및 명령을 수신하였을 때, 카드는 명령이 데이터를 서명하기 위한 것인지(마름모 810)를 알기 위해 체크한다. 명령이 데이터를 서명하기 위한 것이라면, 카드는 IDO에 사설키로 데이터를 서명하고 이어서 서명될 데이터를 호스트에 보내고(블록 812) 마름모 804로 되돌아간다. 호스트로부터 명령이 호스트로부터 데이터를 서명하기 위한 것이 아니라면, 카드는 수신된 데이터를 해독하기 위해 IDO에 사설키를 사용하고(블록 814), 마름모 804로 되돌아간다.

도 36은 호스트에 보내질 데이터에 대해 카드가 서명함에 있어 호스트에 의해 수행되는 프로세스를 도시한다. 도 36을 참조하면, 호스트는 인증 정보를 카드에 보낸다(블록 822). 위에 기술된 나무 구조의 노드에 ACR에 의해 제어된 성공적 인증 후, 호스트는 증명서 체인에 대한 요청들을 카드에 보내고 체인을 수신한다(블록 824). 카드의 공개키가 검증된 후, 호스트는 서명하기 위해 카드에 데이터를 보내고 카드의 사설키에 의해 서명된 데이터를 수신한다(블록 826).

도 37은 호스트가 카드의 공개키를 사용하여 데이터를 암호화하고 암호화된 데이터를 카드에 보낼 때 호스트에 의해 수행되는 프로세스를 도시한다. 도 37을 참조하면, 호스트는 인증 정보를 카드에 보낸다(블록 862). ACR에 의해 제어된 인증이 성공적으로 수행된 후, 호스트는 IDO에 카드의 공개키를 검증하는데 필요한 증명서 체인에 대한 요청들을 카드에 보내고(블록 864), 데이터에 대한 요청들을 카드에 보낸다. IDO에 카드의 공개키가 검증된 후, 호스트는 카드의 검증된 공개키를 사용하여 카드로부터 데이터를 암호화하고 이를 카드에 보낸다(블록들 866, 868).

조회들

호스트들 및 애플리케이션들은 시스템 동작들을 실행하기 위해서 이들이 함 께 작동하고 있는 메모리 디바이스 또는 카드에 관한 어떤 정보를 소유할 필요가 있다. 예를 들면, 호스트들 및 애플리케이션들은 메모리 카드에 저장된 어떤 애플리케이션들이 기동을 위해 사용가능한지를 알 필요가 있을 수 있다. 호스트에 의해 필요로 되는 정보는 종종 공개 지식이 아니며 이는 모든 사람이 이를 소유할 권한이 있는 것은 아님을 의미한다. 따라서, 권한이 있는 사용자와 권한이 없는 사용자간을 차별하기 위해서, 호스트에 의해 사용될 수 있는 조회들의 2가지 방법들을 제공할 필요성이 있다.

일반적인 정보 조회

이 조회는 제약 없이 시스템 공개 정보를 제공한다. 메모리 디바이스들에 저장된 기밀정보는 공유부분 및 비공유 부분인 2부분들을 포함한다. 기밀정보의 한 부분은 개개의 실체들에 전유일 수 있고 따라서 다른 실체들의 전유 기밀정보에 액세스할 수 없이, 자신의 전유 정보만을 액세스하는 것이 각 실체에게 허용되어야 하는 정보를 포함한다. 이러한 유형의 기밀정보는 공유되지 않으며 기밀정보의 비공유된 부분을 형성한다.

공개되는 것으로 보통 생각된 어떤 정보는 어떤 경우들에 있어서는 카드에 상주하는 애플리케이션들의 이름들 및 이들의 생활주기 상태와 같이 기밀로서 간주될 수도 있을 것이다. 이에 대한 또 다른 예는 공개되는 것으로 간주되나 어떤 SSA 사용 경우들에 있어선 기밀일 수도 있을 루트 ACR 이름들일 수도 있을 것이다. 이들 경우들에 있어서 시스템은 일반 정보 조회에 응하여, 비인증된 사용자들이 아닌, 모든 인증된 사용자들만이 이 정보를 계속하여 사용할 수 있게 하는 선택을 제 공할 것이다. 이러한 정보는 기밀정보의 공유 부분을 구성한다. 기밀정보의 공유부분의 예는 루트 ACR 리스트 - 디바이스 상에 현재 있는 모든 루트 ACR들의 리스트를 포함한다.

일반 정보 조회를 통해 공개 정보에 대한 액세스는 호스트/사용자가 ACR에 로그인할 필요가 없다. 이에 따라 SSA 표준에 해박한 어느 누구이든 정보를 실행하고 수신할 수 있다. SSA 용어들에서 이 조회명령은 세션 번호 없이 취급된다. 그러나, 실체에 의한 기밀 정보의 공유 부분에 대한 액세스가 요망된다면, 실체는 메모리 디바이스에 데이터에 액세스를 제어하는 제어구조들 중 어느 것(예를 들면, ACR들 중 어느 것)을 통해 먼저 인증될 필요가 있다. 성공적 인증 후, 실체는 일반 정보 조회를 통해 기밀정보의 공유부분에 액세스할 수 있을 것이다. 위에 설명된 바와 같이, 인증 프로세스는 액세스를 위한 SSA 세션번호 또는 id를 제공하게 될 것이다.

디스크리트 정보 조회

개개의 ACR들 및 이들의 시스템 액세스 및 자산들에 관한 사설 정보는 디스크리트인 것으로 간주되고 명확한 인증을 필요로 한다. 따라서 이러한 종류의 조회는 정보 조회에 대한 인증을 받기 전에 ACR 로그인 및 인증(인증이 ACR에 의해 명시된다면)을 요구한다. 이 조회는 SSA 세션 번호를 필요로 한다.

2가지 유형들의 조회들이 상세히 기술되기 전에, 조회들을 구현하기 위한 실제적 해결책으로서 색인 그룹들의 개념을 먼저 기술하는 것이 유용할 것이다.

색인 그룹들

잠재적 SSA 호스트들에서 작동하는 애플리케이션들은 독출하고자 하는 섹터들의 수를 명시하기 위해 호스트 상에 운영 시스템(OS) 및 시스템 구동기들에 의해 요청된다. 이때 이것은 호스트 애플리케이션들이 모든 SSA 독출동작을 위해 얼마나 많은 섹터들이 독출될 필요가 있는지 알 필요가 있음을 의미한다.

조회 동작들의 특성은 정보를 요청하는 자에게 일반적으로 알려지지 않은 정보를 공급하는 것이기 때문에, 호스트 애플리케이션이 조회를 발행하고 이 동작을 위해 필요한 섹터들의 량을 추측하는 어려움이 있다.

이 문제를 해결하기 위해서 SSA 조회 출력 버퍼는 조회 요청 당 단지 하나의 섹터(512 바이트)로 구성된다. 출력정보의 부분인 오브젝트들은 색인 그룹들이라고 하는 것으로 조직된다. 각 유형의 오브젝트는 단일 섹터에 들어맞을 수 있는 오브젝트들의 수를 고려하는 다른 바이트 크기를 가질 수도 있다. 이것은 이 오브젝트의 색인 그룹을 정의한다. 오브젝트가 20바이트의 크기를 가졌다면 이 오브젝트에 대한 색인 그룹은 25 오브젝트들까지를 내포할 것이다. 총 56개의 이러한 오브젝트들이 있었다면 이들은 3개의 색인 그룹들로 조직되었을 것이며 여기서 오브젝트 '0'(제 1 오브젝트)은 제 1 색인 그룹을 시작할 것이며, 오브젝트 '25'는 제 2 색인 그룹을 시작할 것이며 오브젝트 50은 제 3 및 마지막 색인 그룹을 시작할 것이다.

시스템 조회 (일반 정보 조회)

이 조회는 디바이스 내 지원된 SSA 시스템 및 서로 다른 나무들 및 디바이스에 작동하는 애플리케이션들처럼 셋업되는 현재 시스템에 관한 일반 공개 정보를 제공한다. 이하 기술되는 ACR 조회(디스크리트 조회)와 유사하게, 시스템 조회는 몇 개의 조회 선택들로 구성된다:

. 일반 - SSA 지원 버전.

. SSA 애플리케이션 - 동작상태를 포함하여 디바이스 상에 현재 있는 모든 SSA 애플리세이션들의 리스트.

위에 나열된 정보는 공개 정보이다. ACR 조회에서처럼, 조회 출력 버퍼에 대해 독출하기 위해 얼마나 많은 섹터들이 있어야 하는지를 호스트가 알 필요성을 없게 하기 위해서, 호스트가 여전히 추가의 색인 그룹들을 더 조회할 수 있게 하면서도 디바이스로부터 역으로 보내진 한 섹터가 있을 것이다. 따라서, 루트 ACR의 수가 색인 그룹 '0'에 대한 출력 버퍼 크기의 수를 초과한다면 호스트는 다음 색인 그룹('1')과 함께 또 다른 조회 요청을 보낼 수 있다.

ACR 조회 (디스크리트 정보 조회)

SSA ACR 조회 명령은 키 및 애플리케이션 ID들, 파티션들 및 자식 ACR들과 같은 ACR의 시스템 자원들에 관한 정보를 ACR 사용자에게 공급하기 위한 것이다. 조회 정보는 로그인 된 ACR에 관한 것일 뿐이며 시스템 나무 상에 다른 ACR들에 관한 것은 아무것도 없다. 즉, 액세스는 연루된 ACR의 허가들 하에 액세스될 수 있는 기밀 정보의 부분만으로 제한된다.

사용자가 조회할 수 있는 3개의 서로 다른 ACR 오브젝트들이 있다.

. 파티션들 - 이름 및 액세스 권한들(소유자, 독출, 기입).

. 키 ID들 및 애플리케이션 ID들 - 이름 및 액세스 권한들(소유자, 독출, 기 입)

. 자식 ACR들 - 직계 자식 ACR의 ACR 및 AGP 이름.

. IDO들 및 보안 데이터 오브젝트들(이하 기술됨) - 이름 및 액세스 권한들(소유자, 독출, 기입)

ACR에 연결된 오브젝트들의 수는 다양하기 때문에, 정보는 512 바이트 - 한 섹터보다 더 많을 수도 있을 것이다. 오브젝트들의 수를 미리 알 필요 없이, 사용자는 전체 리스트를 얻기 위해서 디바이스 내 SSA 시스템으로부터 얼마나 많은 섹터들이 독출되는 것이 필요한지를 알 방법은 없다. 따라서 SSA 시스템에 의해 제공된 각각의 개체 리스트는 위에 기술된 시스템 조회들의 경우와 유사하게, 색인 그룹들로 분할된다. 색인 그룹은 섹터에 들어맞는 오브젝트들의 수, 즉 디바이스 내 SSA 시스템으로부터 호스트에 한 섹터로 얼마나 많은 오브젝트들이 보내질 수 있는가 하는 것이다. 이것은 디바이스 내 SSA 시스템이 요청된 색인 그룹의 한 섹터를 보내게 하다. 호스트/사용자는 조회된 오브젝트들의 버퍼, 즉 버퍼에 오브젝트들의 수를 수신할 것이다. 버퍼가 충만되면 사용자는 다음 오브젝트 색인 그룹에 대해 조회할 수 있다.

도 38은 일반 정보 조회를 수반하는 동작을 도시한 흐름도이다. 도 38을 참조하면, SSA 시스템이 실체로부터 일반 정보 조회를 수신할 때(블록 902), 시스템은 실체가 인증되었는지 여부를 판정한다(마름모 904). 그렇다면, 시스템은 공개 정보 및 기밀정보의 공유부분을 실체에 공급한다(블록 906). 그렇지 않았다면, 시스템은 실체에 공개정보만을 공급한다(블록 908).

도 39는 디스크리트 정보 조회를 수반하는 동작을 도시한 흐름도이다. 도 39를 참조하면, SSA 시스템이 실체로부터 디스크리트 정보 조회를 수신하였을 때(블록 922), 시스템은 실체가 인증되었는지를 판정한다(마름모 924). 그렇다면, 시스템은 실체에 기밀정보를 공급한다(블록 926). 그렇지 않았다면, 시스템은 기밀정보에 실체의 액세스를 거절한다(블록 928).

특징 셋 확장(FSE)

많은 경우들에 있어서, 카드상에 SSA 내부에서 데이터 처리 활동들(예를 들면, DRM 라이센스 오브젝트 정당성)을 실행시키는 것이 매우 이점이 있다. 결과적인 시스템은 더 보안적이고, 더 효율적이고, 모든 데이터 처리 임무들이 호스트에서 실행되는 대안적 해결책에 관하여 호스트에 덜 의존적이 될 것이다.

SSA 보안 시스템은 메모리 카드에 의해 저장되고, 관리되고 보호되는 일군의 오브젝트들에 대한 액세스 및 이의 사용을 제어하게 설계된 한 세트의 인증 알고리즘들 및 인증 정책들을 포함한다. 일단 호스트가 액세스할 수 있게 되면, 호스트는 메모리 디바이스에 저장된 데이터에 대해 프로세스들을 수행할 것이며, 여기서 메모리 디바이스에 대한 액세스는 SSA에 의해 제어된다. 그러나, 데이터는 본래 매우 애플리케이션에 특정한 것이고 따라서 디바이스들 상에 저장된 데이터를 다루지 않는 SSA에는 데이터 포맷도 데이터 처리도 정의되어 있지 않은 것으로 가정된다.

발명의 일 실시예는 호스트들에 의해 정규로 수행되는 기능들 중 일부를 호스트들이 메모리 카드에서 실행할 수 있게 하도록 SSA 시스템이 강화될 수 있다는 인식에 기초한다. 그러므로 호스트들의 소프트웨어 기능들 중 일부는 두 부분들로 분할될 수 있는데, 한 부분은 호스트들에 의해 여전히 수행되는 것이고 다른 한 부분은 이제 카드에 의해 수행된다. 이것은 많은 애플리케이션들에 대한 데이터 처리의 보안 및 효율을 강화한다. 이 목적을 위해서, FSE로서 알려진 메커니즘이 SSA의 능력들을 강화하기 위해 추가될 수 있다. 이러한 식으로 카드에 의해 실행되는 FSE에 호스트 애플리케이션들은 여기에서는 내부 애플리케이션, 또는 디바이스 내부 애플리케이션들이라고도 한다.

강화된 SSA 시스템은 기본 SSA 명령 세트를 확장하는 메커니즘을 제공하는데, 이것은 카드 애플리케이션의 도입을 통해 카드의 인증 및 액세스 제어를 제공한다. 카드 애플리케이션은 SSA의 서비스들 외에도 서비스들(예를 들면, DRM 방법들, 전자 상거래들)을 구현하는 것으로 가정된다. SSA 특징 셋 확장(FSE)은 전유일 수 있는 데이터 처리 소프트웨어/하드웨어 모듈들에 의해 표준 SSA 보안 시스템을 강화하게 설계된 메커니즘이다. SSA FSE 시스템에 의해 정의된 서비스들은 가용한 애플리케이션에 대해 호스트 디바이스들이 카드를 조회하고, 위에 기술된 조회들을 사용하여 얻어질 수 있는 정보 외에도, 특정 애플리케이션을 선택하고 이와 통신할 수 있게 한다. 위에 기술된 일반 및 디스크리트 조회들은 이 목적을 위해 사용될 수 있다.

SSA FSE에 설정된 카드 특징을 확장하기 위해 두 가지 방법들이 이용된다:

. 서비스들을 제공 - 이 특징은 전유일 수 있는 통신 파이프로서 알려진 명령 채널을 사용하여 권한있는 실체들이 내부 애플리케이션과 직접 통신할 수 있게 함으로써 활성화된다.

. SSA 표준 액세스 제어 정책들의 확장들 - 이 특징은 내부에 보호된 데이터 오브젝트들(예를 들면, CEK들, 보안 데이터 오브젝트들 또는 이하 기술되는 SDO들)을 내부 카드 애플리케이션들에 연관시킴으로써 활성화된다. 이러한 오브젝트가 액세스될 때마다, 정의된 표준 SSA 정책들이 만족된다면, 연관된 애플리케이션이 기동되고 그럼으로써 표준 SSA 정책들 외에도 적어도 하나의 조건을 부가한다. 이 조건은 바람직하게는 표준 SSA 정책들과 충돌하지 않을 것이다. 액세스는 이 추가의 조건도 만족될 경우에만 승인된다. FSE의 능력들을 더 자세히 하기 전에, 통신 파이프 및 SDO 뿐만 아니라 SFE의 구조적 면들이 이제 기술될 것이다. SSM 모듈 및 관계된 모듈들

도 40a는 발명의 실시예를 예시하기 위해 호스트 디바이스(24)에 접속된 메모리 디바이스(10)(이를테면 플래시 메모리 카드) 내 시스템 구조(1000)의 기능 블록도이다. 카드(20)의 메모리 디바이스에 소프트웨어 모듈들의 주 성분들은 다음과 같다.

SSA 수송층(1002)

SSA 수송층은 카드 프로토콜에 의존한다. 이것은 카드(10)의 프로토콜층 상에 호스트측 SSA 요청들(명령들)을 취급하며 이어서 이들은 SSM API에 넘긴다. 모든 호스트-카드 동기화 및 SSA 명령 식별은 이 모듈에서 행해진다. 수송층은 호스트(24)와 카드(10)간에 모든 SSA 데이터 전송을 맡는다.

보안 서비스 모듈 코어(SSM 코어)(1004)

이 모듈은 SSA 구현의 중요한 부분이다. SSM 코어는 SSA 구조를 구현한다. 구체적으로 SSM 코어는 SSA 나무 및 ACR 시스템과 시스템을 구성하는 위에 기술된 모든 대응하는 규칙들을 구현한다. SSM 코어 모듈들은 암호화, 해독 및 해싱과 같은, SSA 보안 및 크립토그래픽 특징들을 지원하기 위해 크립토그래픽 라이브러리(1012)를 사용한다.

SM 코어 API(1006)

이것은 호스트 및 내부 애플리케이션들이 SSA 동작들을 수행하기 위해 SSM 코어와 인터페이스 할 층이다. 도 40a에 도시된 바와 같이, 호스트(24) 및 내부 디바이스 애플리케이션들(1010) 둘 다는 동일 API를 사용할 것이다.

보안 애플리케이션 관리자 모듈(SAMM)(1008)

SAMM은 SSA 시스템의 부분이 아니라 SSA 시스템과 인터페이스하는 내부 디바이스 애플리케이션들을 제어하는 카드에서 중요한 모듈이다.

SAMM은 다음을 포함하는 실행 애플리케이션들을 실행하는 모든 내부 디바이스를 관리한다.

1. 애플리케이션 수명 모니터 및 제어.

2. 애플리케이션 초기화.

3. 애플리케이션/호스트/SSM 인터페이스

디바이스 내부 애플리케이션(1010)

이들은 카드 측에서 동작하는 것이 승인된 애플리케이션들이다. 이들은 SAMM에 의해 관리되며 SSA 시스템에 액세스할 수 있다. SSM 코어는 또한, 호스트측 애플리케이션들과 내부 애플리케이션들간에 통신 파이프를 제공한다. 이러한 내부 동 작 애플리케이션들에 대한 예들은 DRM 애플리케이션들 및 후술하는 바와 같은 일회용 패스워드(OTP) 애플리케이션들이다.

디바이스 관리 시스템(DMS)(1011)

이것은 후 출하(일반적으로 후 발행이라고도 함) 모드에서, 추가/제거 서비스들뿐만 아니라 카드의 시스템 및 애플리케이션 펌웨어를 업데이트하는데 필요한 프로세스들 및 프로토콜들을 내포하는 모듈이다.

도 40b는 SSM 코어(1004)의 내부 소프트웨어 모듈들의 기능 블록도이다. 도 40b에 도시된 바와 같이, 코어(1004)는 SSA 명령 핸들러(1022)를 포함한다. 핸들러(1022)는 호스트로부터 또는 디바이스 내부 애플리케이션들(1010)으로부터 기원하는 SSA 명령들을, 이 명령들이 SSA 관리자(1024)에 전달되기 전에, 파싱(parse)한다. 모든 SSA 규칙들 및 정책들뿐만 아니라 AGP들 및 ACR들과 같은 모든 SSA 보안 데이터 구조들은 SSA 데이터베이스(1026)에 저장된다. SSA 관리자(1024)는 ACR들 및 AGP들에 의해 발휘되는 제어 및 데이터베이스(1026)에 저장된 그외 제어 구조들을 이행한다. IDO들, 및 보안 데이터 오브젝트들과 같은 그외 오브젝트들도 SSA 데이터베이스(1026)에 저장된다. SSA 관리자(1024)는 ACR들 및 AGP들에 의해 발휘되는 제어 및 데이터베이스(1026)에 저장된 그외 제어 구조들을 이행한다. SSA를 수반하지 않는 비보안 동작들은 SSA 비보안 동작 모듈(1028)에 의해 취급된다. SSA 구조 하에 보안 동작들은 SSA 보안 동작 모듈(1030)에 의해 취급된다. 모듈(1032)은 모듈(1030)을 크립토그래픽 라이브러리(1012)에 연결하는 인터페이스이다. 1034는 도 1에서 플래시 메모리(20)에 모듈들을(1026, 1028) 연결하는 층이다.

통신(또는 패스-스루(Pass-Through)) 파이프

패스-스루 파이프 오브젝트들은 SSM 코어 및 SAMM에 의해 제어되는 바와 같이, 권한이 있는 호스트측 실체들이 내부 애플리케이션들과 통신할 수 있게 한다. 호스트와 내부 애플리케이션 간에 데이터 전송은 SEND 및 RECEIVE 명령들(이하 정의됨)에 의해 전달된다. 실제 명령들은 애플리케이션에 특정하다. 파이프를 생성하는 실체(ACR)는 파이프 이름 및 채널을 오픈할 애플리케이션의 ID를 제공할 필요가 있을 것이다. 이외 모든 다른 보호된 오브젝트들에서처럼, ACR은 이이 소유자가 되며 소유권뿐만 아니라 사용권한들을 표준 위임 규칙들 및 제약들에 따라 다른 ACR에 위임하는 것이 허용된다.

인증된 실체는 CREATE_PIPE 허가들이 그의 ACAM에 설정되어 있다면 파이프 오브젝트들을 생성하는 것이 허용될 것이다. 내부 애플리케이션과의 통신은 이의 PCR에 기입 또는 독출 파이프 허가들이 설정되어 있을 경우에만 허용될 것이다. 소유권 및 액세스 권한 위임은 이의 PCR에 파이프 소유자 또는 위임 액세스 권한들이 설정되어 있을 경우에만 허용된다. 그외 모든 다른 허가들에서처럼 소유권 권한들을 다른 ACR에 위임할 때, 원소유자는 바람직하게는 이 디바이스 애플리케이션에 대한 모든 자신의 허가들이 없어질 것이다.

바람직하게 단지 한 통신 파이프만이 특정 애플리케이션에 대해 생성된다. 제 2 파이프를 생성하고 이를 이미 접속된 애플리케이션에 접속하려는 시도는 바람직하게는 SSM 시스템(1000)에 의해 거절될 것이다. 이에 따라, 바람직하게 디바이스 내부 애플리케이션들(1010) 중 하나와 통신 파이프 간에 1 대 1 관계가 있다. 그러나, 복수의 ACR들은 한 디바이스 내부 애플리케이션과 통신할 수 있다(위임 메커니즘을 통해). 단일 ACR은 몇 개의 디바이스 애플리케이션들과 통신할 수 있다(위임 또는 서로 다른 애플리케이션들에 연결된 복수의 파이프들의 소유권을 통해서). 서로 다른 파이프들을 제어하는 ACR들은 바람직하게는 완전히 분리된 나무들의 노드들에 위치되므로, 통신 파이프 간에 크로스토크는 없다.

호스트와 특정 애플리케이션 간에 데이터를 전송하는 것은 다음 명령들을 사용하여 행해진다.

. 기입 패스 스루 - 호스트에서 디바이스 내부 애플리케이션로 비-포맷된 데이터 버퍼를 전송할 것이다.

. 독출 패스 스루 - 호스트에서 디바이스 내부 애플리케이션으로 비-포맷된 데이터 버퍼를 전송할 것이며, 일단 내부 처리가 행해지면, 비-포맷된 데이터 버퍼를 다시 호스트로 출력할 것이다.

기입 및 독출 패스 스루 명령들은 디바이스 호스트들이 통신하기를 원하는 내부 애플리케이션(1008)의 ID를 파라미터로서 제공한다. 실체들 허가는 유효화될 것이며 요청하는 실체(즉, 이 실체를 사용하고 있는 세션을 호스트하는 ACR)이 요청된 애플리케이션에 접속된 파이프를 사용할 허가를 갖는다면 데이터 버퍼가 해석되고 명령이 실행될 것이다.

이 통신방법은 벤더/전유에 특정한 명령들을 SSA ACR 세션 채널을 통해 내부 디바이스 애플리케이션에 호스트 애플리케이션이 전달할 수 있게 한다.

보안 데이터 오브젝트(SDO)

FSE와 함께 채용될 수 있는 유용한 오브젝트는 SDO이다.

SDO는 민감 정보의 보안 저장을 위한 범용 컨테이너로서 사용된다. CEK 오브젝트들과 유사하게, 이것은 ACR에 의해 소유되며, 액세스 권한들 및 소유권은 ACR들간에 위임될 수 있다. 이것은 기정의된 정책 제약들에 따라 보호되고 사용되며, 선택적으로, 디바이스 내부 애플리케이션(1008)에 대한 링크를 갖는 데이터를 포함한다. 민감 데이터는 바람직하게는 SSA 시스템에 의해서 사용되거나 해석되는 것이 아니라 오브젝트의 소유자 및 사용자들에 의해 사용되거나 해석된다. 즉, SSA 시스템은 이에 의해 취급되는 데이터 내 정보를 분별하지 않는다. 따라서, 오브젝트 내 데이터의 소유자들 및 사용자들은 데이터가 호스트들과 데이터 오브젝트들간에 전달될 때, SSA 시스템과의 인터페이스에 기인하여 민감 정보의 유실에 관해 덜 우려할 수 있다. 그러므로, SDO 오브젝트들은 호스트 시스템(또는 내부 애플리케이션들)에 의해 생성되며 SEK들이 생성되는 방법과 유사하게 스트링 ID가 할당된다. 생성시 호스트는 이름 외에도, SDO에 링크되는 애플리케이션을 위한 애플리케이션 ID 및 SSA에 의해 저장되고, 무결성이 검증되고, 검색될 데이터 블록을 제공한다.

CEK들과 유사하게, SDO(들)은 바람직하게는 SSA 세션 내에서만 생성된다. 세션을 여는데 사용되는 ACR은 SDO의 소유자가 되며 이를 삭제하고, 민감 데이터를 기입 및 독출하고, 뿐만 아니라, 소유권 및 SDO에 액세스할 허가를 또 다른 ACR(이의 자식 또는 동일 AGP 내)에 위임하는 권한들을 갖는다.

기입 및 독출 동작들은 SDO의 소유자를 위해서만 독점적으로 유보된다. 기입 동작은 현존의 SDO 오브젝트 데이터를 제공된 데이터 버퍼로 덮어씌운다. 독출 동 작은 SDO의 완전한 데이터 레코드를 검색할 것이다.

SDO 액세스 동작들은 적합한 액세스 허가들을 갖는 비-소유자 ACR들에게 허용된다. 다음 동작들이 정의된다.

. SDO 셋, 애플리케이션 ID가 정의된다: 데이터는 애플리케이션 ID로 내부 SSA 애플리케이션에 의해 처리될 것이다. 애플리케이션은 SDO에 연관에 의해 기동된다. 선택적 결과로서, 애플리케이션은 SDO 오브젝트를 기입할 것이다.

. SDO 셋, 애플리케이션 ID가 눌(null)이다: 이 선택은 유효하지 않으며 일리걸(illegal) 명령 오류를 프롬프트할 것이다. 셋 명령은 카드에서 동작하는 내부 애플리케이션을 필요로 한다.

. SDO 겟(Get), 애플리케이션 ID가 정의된다: 요청은 애플리케이션 ID로 디바이스 내부 애플리케이션에 의해 처리될 것이다. 애플리케이션은 SDO에 연관에 의해 기동된다. 정의되지 않을지라도 출력은 요청자에게 다시 보내질 것이다. 애플리케이션은 선택적으로 SDO 오브젝트를 독출할 것이다.

. SDO 겟, 애플리케이션 ID가 눌이다: 이 선택은 유효하지 않으며 일리걸 명령 오류를 프롬프트할 것이다. 겟 명령은 카드에서 동작하는 내부 애플리케이션을 필요로 한다.

. SDO에 관계된 허가들: ACR은 SDO 소유자일 수 있으며 또는 액세스 허가들만을 가질 수 있다(셋, 겟 또는 둘 다). 또한, ACR은 그의 액세스 권한들을, 소유하지 않은 SDO에, 즉 또 다른 ACR에 전달하는 것이 허가될 수 있다. ACR은 SDO(들)을 생성하는 것이, 그리고 ACAM 허가를 갖고 있다면 액세스 권한들을 위임하는 것 이 명확하게 허가될 수 있다.

내부 ACR

내부 ACR은 디바이스(10)에 외부 실체들이 이 ACR에 로그인할 수 없다는 것을 제외하고, PCR을 가진 임의의 ACR과 유사하다. 대신에, 도 40b의 SSA 관리자(1024)는 이의 제어하에 오브젝트들 또는 이에 연관된 애플리케이션들이 기동될 때 내부 ACR에 자동으로 로그인한다. 액세스를 얻으려고 시도하는 실체는 카드 또는 메모리 디바이스 내부에 실체이기 때문에, 인증할 필요가 없다. SSA 관리자(1024)는 내부 통신을 할 수 있게 간단히 내부 ACR에 세션 키를 전달할 것이다.

FSE의 능력들은 일회용 패스워드 생성 및 디지털 권한 관리의 2개의 예들을 사용하여 예시될 것이다. 일회용 패스워드 생성 예가 기술되기 전에, 이중 요소 인증의 문제가 먼저 해결될 것이다.

OTP 실시예

이중 요소 인증(DFA)

DFA는 예로서 웹 서비스 서버에 개인적 로그인들의 보안을, 표준 사용자 자격증명서들(즉 사용자 이름 및 패스워드)에 추가의 비밀, 즉 "제 2 요소"를 추가함으로써 강화하게 설계된 인증 프로토콜이다. 제 2 비밀은 전형적으로 사용자가 소유하고 있는 물리적 보안 토큰에 저장된 어떤 것이다. 로그인 프로세스 동안 사용자는 로그인 자격증명서의 부분으로서 소유의 증거를 제공할 필요가 있다. 소유를 증명하는 공통적으로 사용되는 방법은 일회용 패스워드(OTP), 즉 보안 토큰에 의해 생성되고 이로부터 출력되는, 단일 로그인에만 소용되는 패스워드를 사용하는 것이 다. 사용자가 정확한 OTP를 제공할 수 있다면 이것은 토큰 없이 OTP를 계산하는 것이 크립토그래픽적으로 실행 불가능하기 때문에 토큰의 소유의 충분한 증거로서 간주된다. OTP는 단지 한 로그인에만 소용되기 때문에, 사용자는 이전 로그인으로부터 취득된 이전 패스워드의 사용이 더 이상 소용될 수 없기 않을 것이기 때문에 로그인할 때 토큰이 있어야 한다.

다음 절들에서 기술되는 제품은 복수의 "가상" 보안 토큰들로서 각각은 서로 다른 일련의 패스워드들(서로 다른 웹 사이트들에 로그인하기 위해 사용될 수 있는)을 생성하는 이들 토큰들을 가진 플래시 메모리 카드를 구현하기 위해서, SSA 보안 데이터 구조와, 이에 더하여 OTP 시리즈에서 다음 패스워드를 계산하기 위한 FSE 설계를 이용하고 있다. 이 시스템의 블록도가 도 41에 도시되었다.

완전한 시스템(1050)은 인증 서버(1052), 인터넷 서버(1054) 및 토큰(1058)을 가진 사용자(1056)를 포함한다. 제 1 단계는 인증서버와 사용자간에 공유된 비밀(시드(seed) 제공이라고 함)에 관해 동의하는 것이다. 사용자(1056)는 발행된 비밀 또는 시드를 요청할 것이며 이를 보안 토큰(1058)에 저장할 것이다. 다음 단계는 발행된 비밀 또는 시드를 특정 웹 서비스 서버에 결부시키는 것이다. 일단 이것이 행해지면, 인증이 행해질 수 있다. 사용자는 OTP를 생성할 것을 토큰에 지시할 것이다. 사용자 이름 및 패스워드와 함께 OTP는 인터넷 서버(1054)에 보내진다. 인터넷 서버(1054)는 사용자 아이덴터티를 검증할 것을 요청하는 인증서버(1052)에 OTP를 보낸다. 인증서버는 OTP도 생성할 것이며, 이것은 토큰과 함께 공유된 비밀로부터 생성되기 때문에, 토큰으로부터 생성된 OTP와 일치해야 한다. 일치가 발견 된다면 사용자 아이덴터티는 검증되며 인증서버는 인터넷 서버(1054)에 긍정확인응답(positive acknowledgement)을 리턴하여 사용자 로그인 프로세스를 완료할 것이다.

OTP 생성을 위한 FSE 구현은 다음의 특징들을 갖는다.

. OTP 시드는 카드에 보안적으로 저장된다(암호화된다).

. 패스워드 생성 알고리즘은 카드 내부에서 실행된다.

. 디바이스(10)는 복수의 가상 토큰들 각각이 상이한 시드를 저장하는 이들 토큰들을 에뮬레이트할 수 있고 서로 다른 패스워드 생성 알고리즘들을 사용할 수 있다.

. 디바이스(10)는 인증 서버로부터 시드를 디바이스에 수성하기 위한 보안 프로토콜을 제공하고 있다.

OTP 시드 공급 및 OTP 생성을 위한 SSA 특징들이 도 42에 도시되었으며 여기서 실선은 소유권 또는 액세스 권한들을 나타내며, 점선 화살표들은 연관들 또는 링크들을 나타낸다. 도 42에 도시된 바와 같이, SSA FSE 시스템(1100)에서, 소프트웨어 프로그램 코드 FSE(1102)는 N 애플리케이션 ACR들(1106)의 각각에 의해 제어되는 하나 이상의 통신 파이프들(1104)을 통해 액세스될 수 있다. 이하 기술되는 실시예들에서, 단지 한 FSE 소프트웨어 애플리케이션만이 도시되었고, 각각의 FSE 애플리케이션에 대해, 단지 한 통신 파이프만이 있다. 그러나, 하나보다 더 많은 FSE 애플리케이션이 이용될 수 있음이 이해될 것이다. 단지 한 통신 파이프만이 도 42에 도시되었으나, 복수의 통신 파이프들이 사용될 수 있음이 이해될 것이다. 모 든 이러한 변형들이 가능하다. 도 40a, 도 40b, 및 도 42를 참조하면, FSE(1102)는 OTP 제공을 위해 사용되는 애플리케이션일 수 있고, 도 40a의 디바이스 내부 애플리케이션들(1010)의 부분집합을 형성할 수 있다. 제어 구조들(ACR들(1101, 1103, 1106, 1110))은 SSA에 보안 데이터 구조들의 부분이며 SSA 데이터베이스(1026)에 저장된다. IDO(1120), SDO 개체들(1122), 및 통신 파이프(1104)와 같은 데이터 구조들은 SSA 데이터베이스(1026)에도 저장된다.

도 40a 및 도 43b를 참조하면, ACR들 및 데이터 구조들을 수반하는 보안에 관계된 동작들(예를 들면, 세션들에서 데이터 전송, 및 암호화, 해독 및 해싱과 같은 동작들)은 인터페이스(1032) 및 크립토그래픽 라이브러리(1012)의 도움으로, 모듈(1030)에 의해 취급된다. SSM 코어 API(1006)은 호스트들과 상호작용하는 ACR들(외부 ACR들)을 수반하는 동작들과 그렇지 않은 내부 ACR들 간을 구별하지 않으며, 이에 따라 디바이스 내부 애플리케이션들(1010)에 대해 호스트들을 수반하는 동작들 간을 구별하지 않는다. 그러므로, 호스트측 실체들에 의한 액세스 및 디바이스 내부 애플리케이션들(1010)에 의한 액세스를 제어하기 위해 동일 제어 메커니즘이 사용된다. 이것은 호스트측 애플리케이션들과 디바이스 내부 애플리케이션들(1010)간에 데이터 처리를 분할하는 융통성을 제공한다. 내부 애플리케이션들(1010)(예를 들면, 도 42에서 FSE(1102))은 내부 ACR들(예를 들면 도 42에서 ACR(1103))의 제어에 연관되고 이 제어를 통해 기동된다.

또한, 연관된 SSA 규칙들 및 정책들을 가진 이를테면 ACR들 및 AGP들과 같은 보안 데이터 구조들은 바람직하게는 SDO들에 콘텐트 또는 이 콘텐트로부터 도출될 수 있는 정보와 같은 중요한 정보에 액세스를 제어하며, 따라서 외부 또는 내부 애플리케이션들은 SSA 규칙들 및 정책들에 따라 이 콘텐트 또는 정보에만 액세스할 수 있다. 예를 들면, 2개의 서로 다른 사용자들이 데이터를 처리하기 위해 디바이스 내부 애플리케이션들(1010)의 개개의 것을 기동할 수 있다면, 개별 계층 나무들에 위치된 내부 ACR들은 두 사용자들에 의해 액세스를 제어하는데 사용되며, 따라서 이들 간에 크로스토크는 없다. 그러므로, 두 사용자들은 SDO들 내 콘텐트 또는 정보의 소유자들의 측에서 콘텐트 또는 정보의 제어를 잃을 우려 없이 데이터를 처리하기 위한 공통의 한 세트의 디바이스 내부 애플리케이션들(1010)에 액세스할 수 있다. 예를 들면, 디바이스 내부 애플리케이션들(1010)에 의해 액세스되는 데이터를 저장하는 SDO들에 대한 액세스는 개별적 계층 나무들에 위치된 ACR들에 의해 제어될 수 있고, 따라서 이들 간에 크로스토크는 없다. 제어의 이러한 방식은 위에 기술된 데이터에 대한 액세스를 SSA가 제어하는 방식과 유사하다. 이것은 데이터 오브젝트들에 저장된 데이터의 보안을 콘텐트 소유자들 및 사용자들에게 제공한다.

도 42를 참조하면, OTP에 관계된 호스트 애플리케이션을 위해 필요한 소프트웨어 애플리케이션 코드의 부분이 FSE(1102)에 애플리케이션으로서 메모리 디바이스(10)에 저장되는 것이(예를 들면, 메모리 카드 발급 전에 미리 저장되거나 발급 후 로딩된다) 가능하다. 이러한 코드를 실행하기 위해서, 호스트는 파이프(1104)에 액세스할 수 있기 위해서, 양의 정수인 N개의 인증 ACR들(1106) 중 하나를 통해 먼저 인증할 필요가 있을 것이다. 또한, 호스트는 기동하기를 원하는, OPT에 관계된 애플리케이션을 확인하기 위한 애플리케이션 ID를 제공하는 것이 필요할 것이다. 성공적 인증 후, 이러한 코드는 OTP에 관계된 애플리케이션에 연관된 파이프(1104)를 통한 실행을 위해 액세스될 수 있다. 위에 언급된 바와 같이, 바람직하게는 파이프(1104)와 특정 애플리케이션, 이를테면 OTP에 관계된 내부 애플리케이션 간에 1 대 1 관계가 있다. 도 42에 도시된 바와 같이, 복수의 ACR들(1106)은 공통 파이프(1104)의 제어를 공유할 수도 있다. ACR은 하나보다 많은 파이프를 제어할 수도 있다.

총괄하여 오브젝트(1114)라고 한 보안 데이터 오브젝트(SDO 1, SDO 2, SDO 3)가 도 42에 도시되었으므로, 각각은 OTP 생성을 위한 시드와 같은 데이터를 내포하고 있으며, 이 시드는 가치있으며 바람직하게는 암호화된다. 3개의 데이터 오브젝트들과 FSE(1102)간에 링크들 또는 연관(1108)은, 오브젝트들 중 어느 하나가 액세스될 때, SDO의 속성에 애플리케이션 ID을 가진 FSE(1102)에 애플리케이션이 기동될 것이고, 애플리케이션은 어떠한 다른 호스트 명령들의 수신을 요구하지 않고 메모리 디바이스의 CPU(12)에 의해 실행될 것이라는 점에서(도 1), 오브젝트들의 속성을 예시한다.

도 42를 참조하면, 사용자가 OTP 프로세스를 시작할 위치에 있기 전에, 보안 데이터 구조들(ACR들(1101, 1103, 1106, 1110))은 OTP 프로세스를 제어하는 이들의 PCR들에 의해 이미 생성되어 있다. 사용자는 인증 서버 ACR들(1106) 중 하나를 통해 OTP 디바이스 내부 애플리케이션(1102)을 기동하기 위해 액세스 권한들을 갖고 있을 필요가 있을 것이다. 또한, 사용자는 N 사용자 ACR들(1110) 중 하나를 통해, 생성될 OTP에 액세스 권한들을 가질 필요가 있을 것이다. SDO들(114)은 OTP 시드 공급 프로세스 동안 생성될 수도 있다. IDO(1116)은 이미 생성되어 내부 ACR(1103)에 의해 제어되는 것이 바람직하다. 또한, 내부 ACR(1103)은 SDO들(1114)이 생성된 후에 이들을 제어한다. SDO들(1114)이 액세스될 때, 도 40b에 SSA 관리자(1024)는 자동으로 ACR(1103)에 로그인 한다. 내부 ACR(1103)은 FSE(1102)에 연관된다. SDO들(1114)은 점선들(1108)로 나타낸 바와 같이 OTP 시드 공급 프로세스 동안 FSE에 연관될 수 있다. 연관이 설정된 후, SDO들이 호스트에 의해 액세스될 때, 연관(1108)은 호스트로부터 더 이상의 요청 없이 FSE(1102)가 기동되게 할 것이다. 또한, 도 40b에서 SSA 관리자(1024)는 통신 파이프(1104)가 N개의 ACR들(1106) 중 하나를 통해 액세스될 때, ACR(1103)에 자동으로 로그인할 것이다. 두 경우들에 있어서(SDO(1114) 및 파이프(1104)에 액세스), SSA 관리자는 세션 번호를 FSE(1102)에 전달할 것이며, 이 세션 번호는 내부 ACR(1103)에 대한 채널을 확인할 것이다.

OTP 동작은 2개의 국면들로서, 도 43에 도시된 시드 공급 국면과 도 44에 도시된 OTP 생성 국면을 수반한다. 설명을 돕기 위해 도 40 내지 도 42도 참조할 것이다. 도 43은 시드 공급 프로세스를 도시한 프로토콜도이다. 도 43에 도시된 바와 같이, 카드뿐만 아니라 호스트(24)와 같은 호스트에 의해 다양한 작업들이 취해진다. 다양한 작업들을 취하는 카드상에 한 실체는 SSM 코어(1004)를 포함하는 도 40a 및 도 40b의 SSM 시스템이다. 다양한 작업들을 취하는 카드상에 또 다른 실체는 도 42에 도시된 FSE(1102)이다.

이중 요소 인증에서, 사용자는 시드가 발행될 것을 요청하며, 일단 시드가 발행되면, 시드는 보안 토큰에 저장된다. 이 예에서, 보안 토큰은 메모리 디바이스 또는 카드이다. 사용자는 SSM 시스템에 대한 액세스를 얻기 위해서(화살표 1122) 도 42에 인증 ACR들(1106) 중 하나에 인증한다. 인증이 성공적이라고 하면(화살표 1124), 사용자는 시드에 대해 요청한다(화살표 1126). 호스트는 시드 요청에 서명하기 위한 요청을, 시드 요청을 서명하기 위해 특정 애플리케이션(1102)을 선택함으로써 카드에 보낸다. 사용자가 기동될 필요가 있는 특정 애플리케이션 ID를 모른다면, 이 정보는 예를 들면 디바이스에 대한 디스크리트 조회를 통해서, 디바이스(10)로부터 얻어질 수 있다. 이어서 사용자는 기동되어야 할 애플리케이션의 애플리케이션 ID를 입력하고, 그럼으로써 애플리케이션에 대응하는 통신 파이프를 선택한다. 이어서, 사용자 명령은 대응하는 통신 파이프를 통해 사용자로부터 애플리케이션 ID에 의해 명시된(화살표 1128) 애플리케이션에 패스 스루 명령으로 보내진다. 기동되는 애플리케이션은 도 42에 IDO(1112)와 같이, 명시된 IDO 내 공개키에 의한 서명을 요청한다.

SSM 시스템은 IDO의 공개키를 사용하여 시드 요청에 서명하고 서명이 완료된 것을 애플리케이션에 통지한다(화살표 1132). 이어서, 기동된 애플리케이션은 IDO의 증명서 체인을 요청한다(화살표 1134). 응답하여, SSM 시스템은 ACR(1103)에 의해 제어되는 IDO의 증명서 체인을 제공한다(화살표 1136). 이어서, 기동된 애플리케이션은 서명된 시드 요청 및 IDO의 증명서 체인을 이를 호스트에 보내는 SSM 시스템에 통신 파이프를 통해 제공한다(화살표 1138). 통신 파이프를 통해 서명된 시드 요청 및 IDO 증명서 체인의 발송은 도 40a의 SAMM(1008)과 SSM 코어(1004) 간에 수립되는 콜백 기능을 의하며, 여기서 콜백 기능은 이하 기술될 것이다.

이어서, 호스트에 의해 수신된 서명된 시드 요청 및 IDO 증명서 체인은 도 41에 도시된 인증 서버(1052)에 보내진다. 카드에 의해 제공된 증명서 체인은 서명된 시드 요청이 신뢰된 토큰으로부터 발원하여 인증 서버(1052)가 비밀 시드를 카드에 제공할 것임을 증명하였다. 그러므로 인증 서버(1052)는 사용자 ACR 정보와 함께 IDO의 공개키로 암호화된 시드를 호스트에 보낸다. 사용자 정보는 N 사용자 ACR들 중 어느 ACR 하에 사용자가 생성될 OTP에 액세스할 권한들을 갖는지를 나타낸다. 호스트는 애플리케이션 ID를 공급하고 그럼으로써 애플리케이션에 대응하는 통신 파이프를 선택함으로써 FSE(1102)에 OTP 애플리케이션을 기동하고 사용자 ACR 정보를 SSM 시스템에 보낸다(화살표 1140). 암호화된 시드 및 사용자 ACR 정보는 선택된 애플리케이션에 통신 파이프를 통해 보내진다(화살표 1142). 기동된 애플리케이션은 IDO의 사설키를 사용하여 시드의 해독을 위해 요청을 SSM 시스템에 보낸다(화살표 1144). SSM 시스템은 시드를 해독하고 해독이 완료되었다는 통지를 애플리케이션에 보낸다(화살표 1146). 이어서, 기동된 애플리케이션은 보안된 데이터 오브젝트의 생성과, 보안된 데이터 오브젝트에 시드의 저장을 요청한다. 또한, 일회용 패스워드를 생성하기 위해 OTP 애플리케이션(요청을 행하고 있는 것과 동일한 애플리케이션일 수 있다)의 ID에 SDO가 연관될 것을 요청한다(화살표 1148). SSM 시스템은 SDO들(1114) 중 하나를 생성하고 시드를 SDO 내부에 저장하고 SDO를 OTP 애플리케이션의 ID에 연관시키고, 완료되었을 때 통지를 애플리케이션에 보낸다(화살표 1150). 이어서 애플리케이션은 SDO(1114)에 액세스하기 위해 내부 ACR(1103)에 의한 액세스 권한들을 호스트에 의해 공급된 사용자 정보에 기초하여 적합한 사 용자 ACR에 위임할 것을 SSM 시스템에 요청한다(화살표 1152). 위임이 완료된 후, SSM 시스템은 애플리케이션을 통지한다(화살표 1154). 이어서 애플리케이션은 SDO의 이름(슬롯 ID)을 통신 파이프를 통해 SSM 시스템에 콜백기능을 통해 보낸다(화살표 1156). 이어서 SSM 시스템은 같은 것을 호스트에 보낸다(화살표 1158). 이어서 호스트는 SDO의 이름을 사용자 ACR에 결합함으로써 사용자는 이제 SDO에 액세스할 수 있다.

OTP 생성 프로세스를 도 44에 프로토콜도를 참조하여 이제 기술한다. 일회용 패스워드를 얻기 위해서, 사용자는 액세스 권한이 있는 사용자 ACR에 로그인할 것이다(화살표 1172). 인증이 성공적이라고 한다면, SSM 시스템은 호스트에 통지하고 호스트는 "겟 SDO" 명령을 SSM에 보낸다(화살표들 1174, 1176). 위에 언급된 바와 같이, 시드를 저장하는 SDO는 OTP를 생성하기 위해 애플리케이션에 연관되었다. 그러므로, 전처럼 통신 파이프를 통해 애플리케이션을 선택하는 대신에, OTP 생성 애플리케이션은 화살표(1176)에서 명령에 의해 액세스되는 SDO와 OTP 생성 애플리케이션(화살표 1178)간에 연관에 의해 기동된다. 이어서 OTP 생성 애플리케이션은 SDO로부터 콘텐트(즉, 시드)를 독출할 것을 SSM 시스템에 요청한다(화살표 1180). 바람직하게, SSM은 SDO의 콘텐트에 내포된 정보는 모르며 단순히 FSE에 의해 지시된 바와 같이 SDO에 데이터를 처리할 것이다. 시드가 암호화된다면, 이것은 FSE에 의해 명령되는 바와 같이 독출 전에 시드를 해독하는 것을 수반할 수 있다. SSM 시스템은 SDO로부터 시드를 독출하고 시드를 OTP 생성 애플리케이션에 제공한다(화살표 1182). 이어서 OTP 생성 애플리케이션은 OTP를 생성하고 이를 SSM 시스템에 제 공한다(화살표 1184). 이어서 OTP는 SSM에 의해 호스트에 보내지며(화살표 1186) 이어서 호스트는 OTP를 인증 서버(1052)에 보내어 이중 요소 인증 프로세스를 완료한다.

콜백 기능

도 40a의 SSM 코어(1004)와 SAMM(1008)간에 일반 콜백 기능이 설정된다. 서로 다른 디바이스 내부 애플리케이션들 및 통신 파이프들에 이러한 기능이 등록될 수도 있다. 이에 따라 디바이스 내부 애플리케이션이 기동되며, 애플리케이션은 처리 후에 데이터를, 애플리케이션에 호스트 명령을 전달하는데 사용되었던 것과 동일한 통신 파이프를 통해서 SSM 시스템에 전달하기 위해서 이 콜백 기능을 사용할 수 있다.

DRM 시스템 실시예

도 45는 통신 파이프(1104'), FSE 애플리케이션들(1102')에 대한 링크들(1108')을 가진 CEK들(1114'), DRM 기능들을 구현하기 위한 기능들을 제어하기 위한 제어 구조들(1101', 1103', 1106')을 도시한 기능 블록도이다. 언급되는 바와 같이, 도 45에 구조는 보안 데이터 구조가 이제 인증 서버 ACR들 및 사용자 ACR들 대신 라이센스 서버 ACR들(1106') 및 플레이백 ACR들(1110')과, SDO들 대신 SEK들(1114')를 포함하는 것을 제외하곤, 도 42의 구조와 매우 유사하다. 또한, IDO는 수반되지 않으며 이에 따라 도 45에서 생략된다. CEK들(1114')은 라이센스 공급 프로세스에서 생성될 수도 있다. 프로토콜도 도 46은 라이센스 공급 및 콘텐트 다운로드를 위한 프로세스를 도시한 것으로 여기서 키는 라이센스 오브젝트에 제공된 다. OTP 실시예에서처럼, 라이센스를 얻기를 원하는 사용자는 콘텐트가 미디어 플레이어 소프트웨어 애플리케이션과 같은 미디어 플레이어에 의해 렌더링될 수 있도록 먼저 N개의 ACR들(1106') 중 하나와 N개의 ACR들(1110') 중 하나 하에 액세스 권한들을 얻을 필요가 있을 것이다.

도 46에 도시된 바와 같이, 호스트는 라이센스 서버 ACR 1(1067)에 인증한다(화살표 1202). 인증이 성공적이라고 할 때(화살표 1204), 라이센스 서버는 CEK(키 ID 및 키값)와 함께 라이센스 파일을 호스트에 제공한다. 또한, 호스트는 카드상에 SSM 시스템에 애플리케이션 ID를 공급함으로써, 기동될 애플리케이션을 선택한다. 또한, 호스트는 플레이어 정보(예를 들면, 미디어 플레이어 소프트웨어 애플리케이션에 관한 정보)를 보낸다(화살표 1206). 플레이어 정보는 N 플레이백 ACR들(1110') 중 어느 것 하에 플레이어가 액세스 권한들을 갖는지를 나타낼 것이다. SSM 시스템은 DRM 애플리케이션에 라이센스 파일 및 CEK를, 선택된 애플리케이션에 대응하는 통신 파이프를 통해 보낸다(화살표 1208). 이어서, 기동된 애플리케이션은 은닉된 파티션에 라이센스 파일을 기입할 것을 SSM 시스템에 요청한다(화살표 1210). 라이센스 파일이 이와 같이 하여 기입되었을 때, SSM 시스템은 애플리케이션에 통지한다(화살표 1212). 이어서 DRM 애플리케이션은 CEK 오브젝트(1114')가 생성될 것을 요청하고 이에 라이센스 파일로부터 키값을 저장한다. 또한, DRM 애플리케이션은 제공된 키에 연관된 라이센스들을 체크하는 DRM 애플리케이션의 ID에 CEK 오브젝트가 연관될 것을 요청한다(화살표 1214). SSM 시스템은 이들 임무들을 완료하고 애플리케이션에 통지한다(화살표 1216). 이어서 애플리케이션은 호스트에 의해 보내진 플레이어 정보에 기초하여 플레이어가 콘텐트에 액세스할 허가를 갖는 플레이백 ACR에, CEK(1114')에 대한 상기 독출 액세스 권한들이 위임될 것을 요청한다(화살표 1218). SSM 시스템은 위임을 수행하고 애플리케이션에 통지한다(화살표 1220). 라이센스의 저장이 완료되었다는 메시지는 애플리케이션에 의해 통신 파이프를 통해 SSM 시스템에 보내지고 SSM 시스템은 이를 라이센스 서버에 보낸다(화살표들 1222, 1224). 콜백 기능은 통신 파이프를 통해 이 작업을 위해 사용된다. 이 통지를 수신하였을 때, 라이센스 서버는 카드에 제공된 CEK에 키값으로 암호화된 콘텐트 파일을 제공한다. 암호화된 콘텐트는 공개 카드 영역에 호스트에 의해 저장된다. 암호화된 콘텐트 파일의 저장은 보안 기능들을 수반하지 않으므로 SSM 시스템은 저장에 연루되지 않는다.

플레이백 동작이 도 47에 도시되었다. 사용자는 적합한 플레이백 ACR(즉, 화살표들 1152, 1154에서 위에서 독출 권한들이 위임되었던 플레이백 ACR)에 호스트를 통해 인증한다(화살표 1242). 인증이 성공적이라고 하면(화살표 1244) 사용자는 키 ID에 연관된 콘텐트를 독출하기 위해 요청을 보낸다(화살표 1246). 요청을 수신하였을 때, SSM 시스템은 DRM 애플리케이션 ID가 액세스되는 CEK 오브젝트에 연관되고 따라서 확인된 DRM 애플리케이션이 기동되게 할 것임을 발견할 것이다(화살표 1248). DRM 애플리케이션은 키 ID에 연관된 데이터(즉, 라이센스)를 독출할 것을 SSM 시스템에 요청한다(화살표 1250). SSM은 독출이 요청된 데이터에 정보를 모르며, 단순히 데이터 독출 프로세스를 수행하기 위해 FSE로부터 요청을 처리한다. SSM 시스템은 은닉된 파티션으로부터 데이터(즉, 라이센스)를 독출하고 데이터를 DRM 애플리케이션에 제공한다(화살표 1252). 이어서 DRM 애플리케이션은 데이터를 해석하고 라이센스가 유효한지를 알기 위해서 데이터 내 라이센스 정보를 체크한다. 라이센스가 여전히 유효하다면, DRM 애플리케이션은 콘텐트 해독이 승인된 것을 SSM 시스템에 알릴 것이다(화살표 1254). 이어서 SSM 시스템은 CEK 오브젝트에 키값을 사용하여, 요청된 콘텐트를 해독하고, 해독된 콘텐트를 플레이백을 위해 호스트에 공급한다(화살표 1256). 라이센스가 더 이상 유효하지 않다면, 콘텐트 액세스를 위한 요청은 거절된다.

라이센스 서버로부터 라이센스 파일에 어떠한 키도 제공되어 있지 않은 경우에, 라이센스 공급 및 콘텐트 다운로드는 도 46에 도시된 것과는 다소 다를 것이다. 이러한 상이한 방식이 도 48의 프로토콜도에 도시되었다. 도 46과 도 48간에 동일한 단계들은 동일 참조부호로 표시하였다. 이에 따라 호스트 및 SSM 시스템이 먼저 인증에 연루된다(화살표들 1202, 1204). 라이센스 서버는 라이센스 파일 및 키 ID를 제공하는데 호스트에 키값 없이 제공하며, 호스트는 같은 것을 SSM 시스템에 기동하기를 원하는 DRM 애플리케이션의 애플리케이션 ID와 함께 보낼 것이다. 또한, 호스트는 플레이어 정보를 함께 보낸다(화살표 1206'). 이어서 SSM 시스템은 선택된 애플리케이션에 대응하는 통신 파이프를 통해 라이센스 파일 및 키 ID를, 선택된 DRM 애플리케이션에 보낸다(화살표 1208). DRM 애플리케이션은 라이센스 파일이 은닉된 파티션(화살표 1210)에 기입될 것을 요청한다(화살표 1210). 라이센스 파일이 그와 같이 기입되었을 때, SSM 시스템은 DRM 애플리케이션에 통지한다(화살표 1212). 이어서 DRM 애플리케이션은 SSM 시스템이 키값을 발생하고, CEK 오브젝 트를 생성하고, 그에 키값을 저장하고 CEK 오브젝트를 DRM 애플리케이션의 ID에 연관시킬 것을 요청한다(화살표 1214'). 요청이 컴파일된 후, SSM 시스템은 통지를 DRM 애플리케이션에 보낸다(화살표 1216). 이어서 DRM 애플리케이션은 호스트로부터 플레이어 정보에 기초하여 SSM 시스템이 CEK 오브젝트에 대한 독출 액세스 권한들을 플레이백 ACR에 위임할 것을 요청할 것이다(화살표 1218). 이것이 완료되었을 때, SSM 시스템은 그러함을 DRM 애플리케이션에 통지한다(화살표 1220). DRM 애플리케이션은 라이센스가 저장되었음을 SSM 시스템에 통지하며 여기서 통지는 콜백 기능에 의해 통신 파이프를 통해 보내진다(화살표 1222). 이 통지는 SSM 시스템에 의해 라이센스 서버에 보내진다(화살표 1224). 이어서 라이센스 서버는 키 ID에 연관된 콘텐트 파일을 SSM 시스템에 보낸다(화살표 1226). SSM 시스템은 어떠한 애플리케이션들도 수반함이 없이, 키 ID에 의해 확인된 키값으로 콘텐트 파일을 암호화한다. 이와 같이 암호화되고 카드에 저장된 콘텐트는 도 47의 프로토콜을 사용하여 플레이백될 수 있다.

위에 OTP 및 DRM 실시예들에서, FSE(1102, 1102')는 호스트 디바이스들에 의한 선택을 위해 많은 서로 다른 OTP 및 DRM 애플리케이션들을 내포할 수 있다. 사용자들은 요망되는 디바이스 내부 애플리케이션을 선택하고 기동하는 선택을 갖는다. 그럼에도 불구하고, SSM 모듈과 FSE간에 전체 관계는 동일한 그대로이며, 따라서 사용자들 및 데이터 제공자들은 SSM 모듈과 상호작용하고 FSE를 기동하기 위한 표준 한 세트의 프로토콜들을 사용할 수 있다. 사용자들 및 제공자들은 일부 전유일 수도 있는 많은 서로 다른 디바이스 내부 애플리케이션들의 특이성들에 연루될 필요가 없다.

또한, 공급 프로토콜들은 도 46 및 도 48에 경우와 같이, 따로 다를 수 있다. 라이센스 오브젝트는 도 46의 경우에서 키값을 내포하나 도 48의 경우엔 키값을 내포하지 않는다. 이 차이는 위에 예시된 바와 같이 약간 다른 프로토콜들을 요구한다. 그러나, 도 47에서 플레이백은 라이센스가 어떻게 공급되었는가에 관계없이 동일하다. 그러므로 이 차이는 콘텐트 제공자들 및 분배자들에게만 중요하고 전형적으로 플레이백 국면에만 연루되는 소비자들에겐 중요하지 않을 것이다. 이에 따라 이 구조는 소비자들에 의해 사용의 용이성은 그대로이면서 프로토콜들을 커스터마이즈하는 콘텐트 제공자들 및 분배자들에게 큰 융통성을 제공한다. 자명하게 2 이상의 세트들의 공급 프로토콜들에 의해 공급된 데이터로부터 도출되는 정보는 제 2 프로토콜을 사용하여 여전히 액세스될 수 있다.

위에 실시예들에 의해 제공된 또 다른 이점은 사용자들 및 디바이스 내부 애플리케이션들과 같은 외부 실체들이 보안 데이터 구조에 의해 제어되는 데이터의 사용을 공유할 수 있으면서도 사용자는 저장 데이터로부터 디바이스 내부 애플리케이션들에 의해 도출된 결과들에만 액세스할 수 있다는 것이다. 이에 따라, OTP 실시예에서, 호스트 디바이스들을 통해 사용자는 시드 값은 아니고 OTP만을 얻을 수 있을 뿐이다. DRM 실시예에서, 호스트 디바이스들을 통해 사용자는 렌더링된 콘텐트만을 얻을 수 있을 뿐이고, 라이센스 파일 또는 크립토그래픽 키에 액세스할 수 없다. 이 특징은 보안을 손상(compromise)시키지 않고 소비자들에게 편의를 허용한다.

DRM 실시예에서, 디바이스 내부 애플리케이션들도 호스트들도 크립토그래픽 키들에 액세스할 수 없는데, 보안 데이터만이 이러한 액세스를 할 수 있다. 다른 실시예들에서, 보안 데이터 구조 외에 실체들은 크립토그래픽 키들에도 액세스할 수 있다. 또한, 키들은 디바이스 내부 애플리케이션들에 의해 생성되고, 이어서 보안 데이터 구조에 의해 제어될 수도 있다.

디바이스 내부 애플리케이션들 및 정보(예를 들면, OTP 및 렌더링된 콘텐트)에 대한 액세스는 동일 보안 데이터 구조에 의해 제어된다. 이것은 제어 시스템들에 복잡성 및 비용들을 감소시킨다.

디바이스 내부 애플리케이션들에 대한 액세스를 제어하는 내부 ACR에서, 디바이스 내부 애플리케이션들을 기동하는 것으로부터 얻어진 정보에 호스트들에 의한 액세스를 제어하는 ACR로, 액세스 권한들을 위임하는 능력을 제공함으로써, 이 특징으로 위에 특징들 및 기능들을 달성할 수 있게 된다.

애플리케이션에 특정한 철회방법

보안 데이터 구조의 액세스 제어 프로토콜은 디바이스 내부 애플리케이션이 기동될 때에 수정될 수도 있다. 예를 들면, 증명서 철회 프로토콜은 CRL을 사용하는 표준 프로토콜이거나 전유 프로토콜일 수 있다. 이에 따라, FSE를 기동함으로써, 표준 CRL 철회 프로토콜은 FSE 전유 프로토콜에 의해 대체될 수 있다.

CRL 철회방법을 지원하는 것 외에도, SSA는 디바이스에 상주하는 특정한 내부-애플리케이션이 디바이스 내부 애플리케이션과 CR 또는 이외 어떤 다른 철회 당국 간에 사설 통신 채널을 통해 호스트들을 철회할 수 있게 한다. 내부 애플리케이 션 전유 철회 방법은 호스트-애플리케이션의 관계로 국한된다.

애플리케이션에 특정한 철회 방법이 구성될 때, SSA 시스템은 CRL(제공된다면)를 거절할 것이며 그렇지 않다면 주어진 증명이 철회되었는지 여부를 판단하기 위해서 증명서 및 전유 애플리케이션 데이터(애플리케이션에 특정한 통신 파이프를 통해 이전에 제공된)를 사용할 것이다.

위에 언급된 바와 같이, ACR은 3개의 철회 방법들(철회방법 없음, 표준 CRL 방법, 및 애플리케이션에 특정한 철회방법) 중 어느 것이 철회 값을 명시함으로써 채택되는지를 명시한다. 애플리케이션에 특정한 철회방법 선택이 선택되었을 때, ACR은 철회방법을 맡고 있는 내부 애플리케이션 ID에 대해 ID를 명시할 것이며, CET/APP_ID 필드에 값은 철회방법을 맡고 있는 내부 애플리케이션 ID에 대응할 것이다. 디바이스를 인증할 때, SSA 시스템은 내부 애플리케이션의 전유 방법을 고수할 것이다.

한 세트의 프로토콜들을 다른 것으로 대체하는 대신에, 디바이스 내부 애플리케이션의 기동은 SSA에 의해 이미 발휘된 액세스 제어에 추가의 액세스 조건들을 부과할 수도 있다. 예를 들면, CEK에 키값에 액세스하는 권한은 FSE에 의해 더욱 세밀히 조사될 수 있다. ACR이 키값에 액세스 권한들을 갖고 있는 것으로 SSA 시스템이 판정한 후, FSE는 액세스가 승인되기 전에 참조될 것이다. 이 특징은 콘텐트에 액세스를 제어하기 위해 콘텐트 소유자에 큰 융통성을 가능하게 한다.

발명이 다양한 실시예들을 참조하여 기술되었으나, 첨부된 청구항들 및 이들의 등가물들에 의해서만 정의되는, 발명이 범위 내에서 변경들 및 수정들이 행해질 수 있음이 이해될 것이다.

상술한 바와 같이, 본 발명은, 다기능 제어 특징을 구비한 메모리 시스템을 제공하는데 사용된다.

Claims (9)

1. 비휘발성 메모리 시스템으로서,

   적어도 하나의 제어 데이터 구조와,

   적어도 하나의 상기 제어 데이터 구조를 이용하여 메모리 디바이스의 동작을 제어하는 제어기와,

   비밀 키와 공개 키로 구성된 키 쌍과, 적어도 하나의 인증서와, 적어도 하나의 상기 제어 데이터 구조를 포함하는 오브젝트 저장용 비휘발성 메모리로서, 적어도 하나의 상기 제어 데이터 구조는 상기 오브젝트에 대한 액세스를 제어하고, 상기 제어기는 데이터 또는 상기 데이터로부터 유도되는 신호에 서명하기 위해 상기 비밀 키를 사용하는, 비휘발성 메모리와,

   상기 비휘발성 메모리와 제어기를 둘러싸는 하우징을

   포함하는, 비휘발성 메모리 시스템.
2. 제 1항에 있어서, 적어도 하나의 상기 제어 데이터 구조는 상기 오브젝트에 대한 액세스를 제어하는 인증 메커니즘을 명시하여, 오직 인증된 엔티티(authenticated entity)만이 상기 오브젝트에 액세스될 수 있는, 비휘발성 메모리 시스템.
3. 제 1항에 있어서, 상기 하우징은 카드 모양을 갖는, 비휘발성 메모리 시스 템.
4. 제 1항에 있어서, 상기 비휘발성 메모리는 플래시 메모리를 포함하는, 비휘발성 메모리 시스템.
5. 비휘발성 메모리 시스템으로서,

   적어도 하나의 제어 데이터 구조와,

   적어도 하나의 상기 제어 데이터 구조를 이용하여 메모리 디바이스의 동작을 제어하는 제어기와,

   비밀 키와 공개 키로 이루어진 키 쌍과, 적어도 하나의 인증서와, 인증된 엔티티만이 상기 오브젝트에 액세스할 수 있도록 인증 메커니즘에 의해 상기 오브젝트에 대한 액세스를 제어하는 적어도 하나의 상기 제어 데이터 구조를 포함하는 오브젝트 저장용 비휘발성 메모리로서, 상기 제어기는 상기 인증 메커니즘을 사용하여 엔티티를 인증하고, 상기 공개 키를 보증하기 위해 적어도 하나의 상기 인증서를 인증 엔티티에 제공하며, 상기 시스템은 상기 공개 키에 의해 암호화된 데이터를 수신하고, 상기 제어기는 상기 공개 키에 의해 암호화된 상기 데이터를 상기 비밀 키를 이용하여 암호 해제하는, 비휘발성 메모리와,

   상기 비휘발성 메모리와 제어기를 둘러싸는 하우징을

   포함하는, 비휘발성 메모리 시스템.
6. 제 5항에 있어서, 상기 하우징은 카드 모양을 갖는, 비휘발성 메모리 시스템.
7. 제 5항에 있어서, 상기 비휘발성 메모리는 플래시 메모리를 포함하는, 비휘발성 메모리 시스템.
8. 적어도 하나의 제어 데이터 구조와,

   상기 엔티티가 소유하는 키 쌍과, 상기 엔티티를 식별하는 적어도 하나의 인증서와, 적어도 하나의 상기 제어 데이터 구조를

   포함하는 비휘발성 메모리 시스템에 의해 엔티티의 아이덴터티를 증명하는 방법으로서,

   호스트 디바이스에 상기 메모리 시스템을 착탈 가능하게 접속하는 단계와,

   적어도 하나의 상기 제어 데이터 구조에 의해 상기 메모리 시스템에 상기 호스트 디바이스를 인증하는 단계와,

   상기 호스트 디바이스가 성공적으로 인증된 후, 상기 호스트 디바이스의 데이터 또는 상기 데이터로부터 유도된 신호를 암호화하기 위해 상기 비밀 키를 사용하는 단계와,

   적어도 하나의 상기 인증서와 상기 암호화된 데이터 또는 신호를 상기 호스트 디바이스에 전송하는 단계를

   포함하는, 방법.
9. 적어도 하나의 제어 데이터 구조와,

   비밀 키와 공개 키로 구성된 키 쌍과, 적어도 하나의 인증서와, 적어도 하나의 제어 데이터 구조를 포함하는 오브젝트 저장용 비휘발성 메모리를

   포함하는 비휘발성 메모리 시스템에 의해 엔티티에 대한 데이터를 보호하는 방법으로서,

   호스트 디바이스에 상기 메모리 시스템을 착탈 가능하게 접속하는 단계와,

   적어도 하나의 상기 제어 데이터 구조에 의하여 상기 메모리 시스템에 상기 호스트 디바이스를 인증하는 단계와,

   상기 호스트 디바이스가 성공적으로 인증된 후, 상기 공개 키를 보증하기 위해 적어도 하나의 상기 인증서를 상기 호스트 디바이스에 공급하는 단계와,

   상기 공개 키에 의해 암호화된 데이터를 수신하는 단계와,

   상기 공개 키를 이용하여 상기 데이터를 암호 해제하는 단계를

   포함하는, 방법.

Images