KR101297527B1

KR101297527B1 - 회로 카드 데이터 보호

Info

Publication number: KR101297527B1
Application number: KR1020117016265A
Authority: KR
Inventors: 올리비에 동
Original assignee: 닛본 덴끼 가부시끼가이샤
Priority date: 2009-01-16
Filing date: 2009-12-28
Publication date: 2013-09-16
Also published as: EP2387767A1; WO2010082450A1; US20110277041A1; CN102282566A; GB0900664D0; JP2015043231A; JP2012515372A; GB2466969A; GB2466969B; KR20110104959A

Abstract

본 발명은 복수의 데이터 엘리먼트들의 저장을 위해 구성된 UICC와 같은 회로 카드에서의 보호를 이루고, 데이터 엘리먼트 상에 허용될 수 있는 동작들을 정의하는 역할을 하는 도메인 보호 엘리먼트에 기초하여, 그리고 데이터 엘리먼트에 대한 액세스를 제어하는 역할을 하는 패스워드 보호 엘리먼트에 기초하여 보호를 제공하는 방법 데이터를 제공하며 여기서 상기 복수의 데이터 엘리먼트들 중 적어도 하나는 도메인 보호 엘리먼트 및 패스워드 보호 엘리먼트 양자 모두에 연관되고, 본 발명은 또한, 그러한 데이터 엘리먼트들의 보안 저장을 위해 구성된 회로 카드를 제공하고 그러한 회로 카드를 이용하도록 구성된 ME를 제공한다.

Description

회로 카드 데이터 보호 {CIRCUIT CARD DATA PROTECTION}

본 발명은 회로 카드에 관한 것이고 특히 회로 카드에 저장된 데이터의 보호를 위한 장치 및 방법에 관한 것이다.

셀 폰 핸드셋과 같은 휴대 디바이스 및 다른 형태의 이동 장비 (ME) 는, 그들의 기능성의 지속적인 증가에 따라, 대량의 (개인) 데이터의 저장 및 유지를 위한 인기있는 디바이스/인터페이스가 되었다.

그러한 데이터는 예를 들면 개인적 (private) 사진, 비디오 및 SMS 메시지를 포함할 수 있고 사용자들은 일반적으로 그러한 데이터를 ME 안에, 가입자 식별 모듈 (SIM) 카드와 같은 범용 집적 회로 카드 (UICC) 의 관련 부분 안에, 또는 실제로 네트워크 오퍼레이터에 의해 제공되는 네트워크-측 저장 영역들에, 또는 메모리 카드와 같은 다른 미디어 디바이스 상 중에서 어느 한 쪽에 저장하는 옵션을 갖는다.

저장될 데이터의 양 및 잠재적으로 개인적/민감한 성질을 고려하여, 최종 사용자 관점으로부터, 저장 영역은 충분한 저장 용량, 적절한 레벨의 보안을 제공해야 하고 또한 손쉽게 액세스 가능해야 한다.

ME 그자체는 적절한 정도의 보안을 제공하는 것으로 고려될 수 있지만, 그러한 레벨의 보안은 구체적인 ME 제조자에 특정된 경향이 있고 저장 용량은 모든 타입의 사용자 데이터, 특히 멀티미디어 데이터에는 충분한 것으로 생각되지 않는다. 마찬가지로 데이터에 대한 액세스가능성은 일반적으로 또한 제조자-전용 케이블 및 관련 접속 소프트웨어를 필요로 한다.

메모리 카드와 같은 디바이스들은 대 저장 용량 및 손쉬운 액세스가능성 (ready accessibility) 을 제공할 수 있지만, 사용자 데이터에 대한 적당한 보호를 제공하거나 보호하기 위한 손쉬운 수단이 존재하지 않는다.

네트워크 측 저장 영역에 관하여, 고도의 보안이 충분한 저장 용량과 함께 달성될 수 있지만, 액세스가능성은 물론 네트워크 액세스 이용가능성에 의존하게 되는데 이는 보장되지 않을 수도 있다.

3GPP/ETSI Rel-7로부터 발생되는 것과 같은 근래 개발로부터, UICC 지원 고 밀도 메모리가 이용가능하고, 동일한 사양 (specification) 으로부터, USB 2.0/USB 인터-칩 (Inter-Chip) 에 기초한 새로운 인터페이스의 제공이 UICC와 ME 사이에 제안되어 있고 이는 UICC와의 데이터 교환을 크게 용이하게 하고 속도를 높여, 예를 들면 PC에 대한 데이터 검색이 간단한 어댑터에 의해 손쉽게 이루어질 수 있게 된다는 점에서, UICC와 같은 회로 카드는 잠재적으로 매력적인 저장 로케이션을 포함한다.

선행기술문헌

특허문헌

특허문헌 1: 국제 특허공개공보 WO2008/139615

특허문헌 2: 미국 특허 공개 공보 2008/254834

특허문헌 3: 미국 특허 공개 공보 2008/256629

특허문헌 4: 미국 특허 공개 공보 2008/155830

그러나, UICC는 특히 개인 식별 번호 (PIN) 코드의 사용을 통해 상대적으로 안정한 것으로 생각되기는 하지만, 단지 사용자가 USIM/GSM 어플리케이션을 활성화시키기 원할 때 일반적으로 일어나는, PIN이 검증되고 나면, 그 다음 저장된 사용자 데이터는 마찬가지로 임의의 추가 보안 체크를 요하지 않고서 자유롭게 액세스가능하다는 점에서, 한계가 여전히 남아 있다.

즉, 일단 예를 들면 USIM 를 지니는 ME가 옳은 PIN의 기입에 의해 사용을 위해 적절히 "활성화" (activated) 되고 나면, USIM 상에 저장된 모든 다른 데이터는 손쉽게 액세스가능 한데, 이는 특히 현재 최종 사용자가 단지 ME에 대해 일시적인 액세스를 가지도록 의도된 경우에 적절하지 않을 수도 있다.

국제특허공개공보 제WO2008/139615호는 메모리 카드, 액세스 제어 시스템, 및 액세스 제어 방법을 개시하는데, 이들은 서비스 범위의 동적인 변화를 가능하게 하고, 다운로드될 콘텐트와 연관된 정보에 따라 액세스 관리의 성능을 통하여 사용자에 의존하는 다양한 서비스들의 제공을 가능하게 하고, 여기서 회로 카드가 데이터 관리 섹션을 포함하고 카드상에 데이터를 보호하기 위한 보안 메카니즘의 제공 보다는 오히려 서비스의 동적인 변화 범위에 의존한다.

또한, US 특허공개공보 제2008/254834호, 제2008/256629호 및 제2008/155830호 각각은 사용자 식별자들의 비교의 제공을 통하여 콘텐트의 보안 저장을 제공하고 그래서 위에서 더 논의된 바와 같은 종래 기술의 제한들을 나타내는 메모리 카드를 개시한다.

본 발명은 회로 카드, 그리고 그 다음 그러한 카드를 포함하는 ME, 및 그러한 카드 내에서의 데이터 보호 방법으로서, 알려진 그러한 카드 및 방법들에 비해 장점을 갖는, 회로 카드, 그리고 그 다음 그러한 카드를 포함하는 ME, 및 그러한 카드 내에서의 데이터 보호 방법을 제공하고자 한다.

특히, 본 발명은 UICC 및 거기에 데이터와 보안을 제공하기 위한 방법으로서, 알려진 그러한 카드 및 방법들에 비해 이점을 갖는, UICC 및 거기에 데이터와 보안을 제공하기 위한 방법을 제공하고자 한다.

본 발명의 일 양태에 따르면, 복수의 데이터 엘리먼트들을 저장하기 위해 구성된 회로 카드에서의 데이터 보호의 방법으로서; 데이터 엘리먼트 상에서 허가될 수 있는 오퍼레이션들을 정의하는 역할을 하는 도메인 보호-엘리먼트 및 데이터 엘리먼트에 대한 액세스를 제어하는 역할을 하는 패스워드 보호-엘리먼트 중 하나에 기초하여 보호를 제공하는 단계를 포함하고, 상기 복수의 데이터 엘리먼트들 중 적어도 하나는 상기 도메인 보호 엘리먼트 및 상기 패스워드 보호 엘리먼트 양자 모두와 연관되는, 회로 카드에서의 데이터 보호의 방법이 제공된다.

하나 이상의 도메인 보호-엘리먼트들의 제공을 통하여, 회로 카드 상에 저장되는 데이터의 보안의 정도가 손쉽게 강화될 수 있고, 실제로 유연하고 손쉽게 적응가능한 방식으로 제공될 수 있다는 점에서, 본 발명은 유리하다.

따라서, 그러한 회로 카드는 유리하게도 최종 사용자에게 특히 사용자-특정 및 민감한 데이터를 위한 적절한 레벨의 보안, 용량 및 액세스가능성을 제공할 수 있다.

파티션, 디렉토리 또는 파일과 같은, 데이터 엘리먼트에 대한 보호를, 조합하여, 제공할 수 있다는 점에 있어서 위에 언급된 "패스워드" 및 "도메인" 특징들의 조합을 통해 특정 향상된 레벨의 보안성이 제공된다. "패스워드" 특징은 일단 패스워드가 검증되고 나면 허용될 수 있는 오퍼레이션들의 성질에 독립한 방식의 보호와 허용된 데이터 엘리먼트에 대한 액세스를 제공하는 반면, "도메인" 특징은 전술한 파티션, 디렉토리 또는 파일과 같은 데이터 엘리먼트들 상에서 허용될 수 있는 가능한 오퍼레이션들을 정의한다.

일 특정 예에서, 회로 카드는 UICC를 포함한다.

또한, 추가의 레벨의 보안이 PIN 액세스 코드의 사용을 통해 회로 카드의 하나 이상의 어플리케이션들에 제공될 수 있다.

바람직하게는, 상기 복수의 데이터 엘리먼트들 각각은 도메인 보호-엘리먼트와 연관된다.

유리하게는, 도메인 보호 엘리먼트에 의해 정의된 허용된 오퍼레이션들은 하나 이상의 읽기 및/또는 쓰기 액세스 오퍼레이션들을 포함할 수 있다.

또한, 본 발명의 방법에 따르면, 회로 카드에서 데이터를 액세스할 수 있는 엔티티 (entity) 가 고유 식별자 (unique identifier) 와 연관되도록 구성된다.

방법은 또한 데이터 엘리먼트를 생성하는 엔티티의 식별을 저장하는 것을 포함할 수 있다.

또한, 본 발명을 구현하는 회로 카드에 대한 사용을 위해 구성된 ME에 관한여, 방법은 ME 내에서, 상기 데이터에 대한 액세스를 요구하는 엔티티를 식별하는 단계를 포함할 수 있다.

유리하게는, 본 방법은 데이터 보호 단계가 ME와 회로카드 사이의 USB 인터페이스 클래스들에 대해 적용되도록 한다.

유리하게는, 데이터 엘리먼트는 표준 파일 포맷 파일 시스템에 따른 회로 카드 상에 저장될 수 있다.

또한, 데이터 엘리먼트들의 생성 및 관리는 회로 카드 내에서의 데이터 엘리먼트들의 생성 및 관리에 의해 이루어질 수 있고 ME에 의해 제공될 수 있다.

또한, ME-회로 카드 인터페이스 기능들은 생성 기능 (create function), 읽기 기능 (read function), 업데이트 기능 (update function), 이름 바꾸기 기능 (rename function), 이동 기능 (move function), 삭제 기능 (delete function) 및 소거 기능 (cleaning function) 중 하나 이상을 포함하는 것으로 정의될 수 있다.

본 발명의 다른 양태에 따르면, 복수의 보호가능한 데이터 엘리먼트를 저장하기 위해 구성된 회로 카드로서, 데이터 엘리먼트에 대해 허가될 수 있는 오퍼레이션들을 정의하는 역할을 하는 도메인 보호-엘리먼트와 데이터 엘리먼트에 대한 액세스를 제어하는 역할을 하는 패스워드 보호-엘리먼트 양자 모두와 연관되도록 구성되는 상기 복수의 보호가능한 데이터 엘리먼트 중 적어도 하나를 포함하는, 회로 카드가 제공된다.

바람직하게는, 회로 카드는 UICC를 포함한다.

상기 적어도 하나의 데이터 엘리먼트는 도메인 보호-엘리먼트에 의해 허가되는 오퍼레이션을 개시하기 위해 패스워드가 요구되도록 구성될 수 있다.

바람직하게는, 복수의 데이터 엘리먼트들 각각은 도메인 보호-엘리먼트와 연관될 수 있다.

또한, 도메인 보호-엘리먼트에 의해 정의된 전술한 오퍼레이션은 읽기 및/또는 쓰기 액세스 오퍼레이션 중 적어도 하나를 포함한다.

유리하게는, 회로 카드는 USB 인터페이스에 의해 상기 데이터 엘리먼트들에 대한 액세스를 허용하도록 구성될 수 있다.

또한, 회로 카드는 그 파일 시스템 상의 표준 파일 내에 저장된 상기 데이터 엘리먼트들을 갖도록 구성될 수 있다.

또한, 본 발명은 위에 정의된 바와 같은 회로 카드를 수용하기 위해 구성된 ME를 제공한다.

유리하게는, ME는 USB 인터페이스 클래스에 의해 회로 카드와 통신하도록 구성될 수 있다.

유리하게는, ME는 상기 저장된 데이터 엘리먼트들을 생성 및/또는 관리하도록 구성될 수 있다.

바람직하게는, ME-회로 카드 인터페이스 기능은 하나 이상의 생성 기능, 읽기 기능, 업데이트 기능, 이름 바꾸기 기능, 이동 기능, 삭제 기능 및 소거 기능 중 하나 이상에 의해 정의된다.

본 발명은 첨부 도면을 참조하여, 오직 예시로서, 이하에서 더 설명된다.

본 발명에 따르면, 하나 이상의 도메인 보호-엘리먼트들의 제공을 통하여, 회로 카드 상에 저장된 데이터의 보안의 정도가 쉽게 향상될 수 있고, 실로, 유연하고 손쉽게 적응가능한 방식으로 제공된다.

도 1은 본 발명의 실시 형태에 따른 UICC의 개략적인 평면도이다;
도 2는 도 1의 UICC와의 오퍼레이션을 위해 구성되고 셀 폰 헤드셋 형태의, ME 또는 이동 라디오 통신 디바이스의 개략 평면도이다;
도 3은 본 발명에 따른 UICC 내의 UICC 내 디렉토리의 생성에 관한 시그널링 타이밍 도 (signalling timing diagram) 이다.
도 4는 그러한 UICC를 위한 파일의 생성을 위한 시그널링 타이밍 도이다.
도 5는 부정확한 패스워드를 사용하여 보호된 파일의 시도된 읽기에 대한 시그널링 타이밍 도를 나타낸다.
도 6은 정확한 패스워드를 사용하여 보호된 파일의 시도된 읽기에 대한 시그널링 타이밍 도를 나타낸다.

위의 기재로부터 인식되는 바처럼, 그리고 특정 실시형태에 대한 다음의 추가 상세한 설명으로부터, 유리하게 본 발명은 간단하게 PIN 코드에 기초하여 데이터 보호 메카니즘의 제공에 관한 것들과 같은 현재 회로 카드에서 찾아낸 한계들을 처리하고자 한다. 언급된 바처럼, 그것들은 주로 어플리케이션, 예를 들면 GSM/USIM, 및 그의 관련 데이터 이를 테면 IMSI 또는 PLMN 리스트 등에 관한 것이고, 여기서 어느 그러한 어플리케이션과 직접 연결되지 않는 데이터, 예를 들면 사용자 사적인 파일 사진, 비디오, 개인 메시지 등이 그 동일한 보안 체제하에 속한다.

본 발명은, 회로 카드 상에 저장된 모든 타입의 데이터들에 대해 향상된 레벨의 보안을 제공하기 위하여, 필요한 경우, 기존 PIN 보호에 더하여 사용될 수 있는 데이터 보호 메카니즘을 정의한다.

또한, 현재 회로 카드 내의 데이터 저장은 대량의 데이터의 저장에 적응되지 않는 요소 파일 (Elementary File) 에 기초한다. 또한, 그러한 파일들은 종종 비디오 및 음악 파일과 같은 일정한 타입의 데이터를 저장하도록 명시되지 않는다. 따라서, 새로운 데이터 저장 장치가 본 발명의 일부로서 제안되고 개선된 회로-카드 보안과 관련하여 특히 유리하게 사용된다.

먼저 도 1을 참조하면, 본 발명이 유리하게 구현될 수 있는 것과 관련된 회로 카드의 일 예의 개략적인 예시가 제공된다.

회로 카드는 저장 영역 (14) 과 ME 인터페이스 (16) 사이에 제공된 프로세싱 기능 (12) 을 포함하는 UICC (10) 를 포함한다.

아래에 더 설명될 바처럼, 인터페이스 (16) 는 유리하게 USP 2.0/USP 인터-칩에 기초하고, 이는 예를 들면 도 2의 셀 폰 핸드셋 (18) 이 간단한 전기 어댑터에 의해 접속될 수 있는 PC 와 UICC (10) 사이의 데이터 교환을 용이하게 하고 속도를 높인다.

도 2를 참조하면, 이동 무선 통신 디바이스의 개략도가 제공되며, 이는 임의의 형태의 이동 장비 (ME), 이를 테면 셀 폰 핸드셋 (18) 을 포함할 수 있고, 그 안에 표시된 바처럼 표준 메모리 (22), 프로세서 (20) 및 송신/수신 기능 (24) 과 함께 도 1의 UICC (10) 이 제공된다.

셀 폰 핸드셋 (18) 에 의해 제공될 수 있는 다양한 저장 옵션들 중, UICC (10) 는 위에 언급되고 아래에서 더 논의될 도메인 보안-엘리먼트 및 패스워드 보안-엘리먼트의 조합에 기초하여 유리한 보안성, 손쉬운 액세스가능성 그리고 알맞게 큰, 저장 로케이션을 제공할 수 있다.

본 발명의 현재 설명 및 정의에 관하여, "패스워드"는 일단 패스워드가 체크되고 나면 오퍼레이션들이 허용되는 것으로부터 독립적으로 파일/디렉토리/파티션에 대한 액세스를 보호하는 것으로 인식되야 한다. 대조적으로, 도메인은 특정 엔티티가 파일/디렉토리/파티션 상에서 수행할 수 있는 상이한 오퍼레이션들에 대한 역할 (serve) 을 정의한다.

따라서, 일 특정 예에서, 파일, 디렉토리 또는 심지어 파티션과 같은 각 데이터 엘리먼트는 도메인과 관련될 수 있고 (관련 도메인이 패스워드를 필요로하는 경우) 가능하게는 패스워드에 의해 보호될 수 있다. 허용된 오퍼레이션들의 각각의 정의를 갖는 다양한 도메인들이 일반적으로 상호운용성 (interoperability) 을 가능하게 하기 위하여 표준화된 방식으로 제공될 수 있다.

예로서, 가능한 도메인들은 다음과 같을 수 있다:

"사적인" (Private) 에서는 오직 소유자 (파일/디렉토리/파티션을 생성한 엔티티) 만이 액세스할 수 있다. 일단 패스워드가 성공적으로 체크되고 나면 모든 권한이 수여된다.

"제한된 읽기 쓰기" (Restricted Read Write) 에서는 어느 엔티티가 패스워드 체크를 성공적으로 통과하면, 읽기 및 쓰기 액세스 권한이 그 엔티티에 수여된다.

"제한된 읽기" (Restricted Read) 에서는 어느 엔티티가 패스워드 체크를 성공적으로 통과하면, 읽기 액세스 권한이 그 엔티티에 수여된다.

"읽기 전용" (Read Only) 은 패스워드 없이 어느 엔티티에 의해서도 읽기가능하다.

"공개" (Public) 에서는 읽기 및 쓰기 액세스 권한이 패스워드 없이 어느 엔티티에게도 수여된다.

UICC 에서 데이터에 액세스할 수 있는, 특정 사용자 및/또는 다른 디바이스/장비와 같은 임의의 엔티티는 "엔티티_id" (entity_id) 로 불리는 고유 식별자와 연관된다. 이 식별자는 바람직하게는 ME로부터의 요청시 UICC에 의해 할당되고 "요청/결과" (request/result) 구조는 다음과 같을 수 있다:

ME에서 UICC로 : Generate_Entity_Id_Req (entity_name),

UICC에서 ME로 : Generate_Entity_Id_Res (result, entity_name , entity_id);

"entity_name" 은 UICC에서 데이터에 액세스할 수 있는 엔티티들의 공개적으로 이용가능한 이름이다.

이 특정 예시된 예는 적어도 각각의 entity_name을 갖는 다음의 공개 엔티티들이 정의되는 것을 제안한다:

- 사용자 (USER)

- ME (ME)

- 원격 서버 (REMOTE_SERVER)

- ME 내 써드 파티 어플리케이션 (third party application) (ME_THIRD_PARTY)

물론, 리스트는 하나도 빠짐없이 철저한 것은 아니고 따라서 다른 엔티티들을 포함할 수도 있음이 인식되야 한다.

"entity_id" 는 주어진 "entity_name" 에 대한 UICC에 의해 할당된 사적인 식별자이다.

"entity_name, entity_id" 쌍은 ME의 메모리에 저장되고 ME는 이들 쌍들의 기밀성 (confidentiality) 을 보장하게 된다.

유리하게는, ME는 요청 엔티티 (UICC에서 데이터를 액세스하기 원하는 엔티티) 를 정확히 식별하는 책임을 맡는데, 예를 들면 요청이 ME 어플리케이션으로부터 오는 경우, ME는 본 문서에 정의된 인터페이스 기능들에서 ME와 연관된 entity_id를 사용하게 된다.

ME가 상이한 요청 엔티티들을 식별하기 위한 간단한 방법은 ME 운영 시스템에 의해 할당된 그들 각각의 스레드 (thread) 또는 프로세스 식별자의 사용에 기초할 수도 있다.

ME에 의해 통과된 "entity_id" 는 일부 오퍼레이션들이 직접 이 entity_id에 의존하므로 정확하다는 사실에 UICC가 의존할 수 있다. 따라서, 그러한 정확한 "entity_id" 를 ME로부터 UICC로 제공하는 것은 본 제안에 정의된 보안 메카니즘을 향상시키는 역할을 한다.

파일/디렉토리/파티션이 생성될 때, UICC는 생성된 엘리먼트에 대해 "소유자"의 개념을 연관시킬 수 있다. 그러한 목적으로, UICC는 단순히 생성 요청 기능에서 통과된 "entity_id" 를 취하고 그것을 생성된 엘리먼트의 소유자 entity_id 로서 저장한다.

이러한 소유의 개념은 중요할 수도 있는데, 왜냐하면 많은 오퍼레이션들이 파일/디렉토리/파티션의 소유자에 대해서만 허용되기 때문이다 (예를 들면, 위에서 정의된 "사적" 도메인에 정의된 엘리먼트는 오직 소유자에게만 액세스가능하다).

다양한 보안 인터페이스 기능이 채용될 수 있다. 먼저, 세팅 패스워드 기능, 여기서, 엔티티는 이 기능을 오직 그 자신의 파일/디렉토리/파티션에 대해서만 사용할 수 있다. UICC가, 요청을 수신할 때, 수신된 entity_id가 소유자 entity_id에 매칭되지 않음을 인식하면, 요청은 거절되고 "요청/결과" 구조는 다음과 같을 수 있다:

ME에서 UICC로 : Set_Password_Req (entity_id, pathname, password)

UICC에서 ME로 : Set_Password_Res (result, entity_id, pathname)

유리하게는 오직 파티션/디렉토리/파일의 소유자만이 요청을 실행하는 것이 허용되도록 entity_id가 제공된다. 경로이름은 파티션/디렉토리/파일의 이름을 포함하는 경로를 포함하고, 패스워드는 파티션/디렉토리/파일에 설정된 패스워드를 포함한다. 종료 결과는 성공 또는 실패 중 어느 한쪽이 된다.

변경 패스워드 기능은 엔티티에 의해서 사용될 수 있지만 오직 그 자신의 파일/디렉토리/파티션에 대해서만 사용될 수 있다. UICC가 요청을 수신하는 경우에, 수신된 entity_id가 소유자 entity_id에 매칭되지 않음을 인식하면, 요청은 거절되고, 이어지는 "요청/결과" 구조를 갖는다.

ME에서 UICC로 : Change_Password_Req (entity_id, pathname, old_password, new_password)

UICC에서 ME로 : Change_Password_Res (result, entity_id, pathname)

위에 언급된 것들에 유사한 파라미터들이 파티션/디렉토리/파일의 현재 패스워드를 포함하는 old_password 및 파티션/디렉토리/파일에 설정될 새로운 패스워드를 포함하는 new_password 와 함께 이용된다.

검증 패스워드 기능을 위한 요청/결과 구조는 다음과 같을 수 있다.

ME에서 UICC로 : Verify_Password_Req (entity_id, pathname, password)

UICC에서 ME로 : Verify_Password_Res (result, entity_id, pathname)

일 구성에서, "시도" (attempt) 의 수는 하나의 주어진 보호된 엘리먼트 (파일 또는 디렉토리 또는 파티션) 에 맞서 각 엔티티를 위한 패스워드 검증에 대해 3회로 제한될 수 있다. 3회 실패된 시도후, 엘리먼트에 대한 액세스 조건이 변경될 (예를 들면, 이 엘리먼트의 소유자가 패스워드를 변경하거나 제거할) 때까지 그러한 시도들을 한 엔티티에 대해서 엘리먼트는 더 이상 액세스가능하지 않다.

엔티티는 오직 그 자신의 파일/디렉토리/파티션에 대해서만 "세트 도메인" (set domain) 기능을 이용할 수 있도록 구성될 수 있다. UICC가 요청을 수신할 때, 수신된 entity_id가 소유자 entity_id와 매칭되지 않음을 인식하면, 요청이 거절되고 "요청/결과" 구조는 다음과 같다.

ME에서 UICC로 : Set_Domain_Req (entity_id, pathname, domain)

UICC에서 ME로 : Set_Domain_Res (result, entity_id, pathname)

겟 도메인 기능 (get domain function) 에는 또한 다음의 "요청/결과" 구조가 구비될 수 있다.

ME에서 UICC로 : Get_Domain_Req (entity_id, pathname)

UICC에서 ME로 : Get_Domain_Res (result, entity_id, pathname, domain)

또한 액세스 조건 통보 기능에는 다음과 같은 대응 구조가 구비될 수 있다.

UICC에서 ME로 : Access_Condition_Notification (entity_id, pathname, condition)

위에 언급된 것들에 유사한 파라미터들이 (예를 들면, 패스워드를 요구하는) 경로이름 (pathname) 에 의해 나타내어진 엘리먼트에 대해 검증될 필요가 있는 조건을 포함하는 조건 파라미터의 부가와 함께 이용된다.

하나의 엔티티 식별자 생성 기능에는 아래의 "요청/결과" 구조가 구비될 수 있다.

ME에서 UICC로 : Generate_Entity_Id_Req (entity_name)

UICC에서 ME로 : Generate_Entity_Id_Res (result, entity_name, entity_id);

관련 파라미터들에 대해, entity_name 은 다시 엔티티의 공개 이름을 포함하고, entity_id는 각 엔티티-이름에 대해 UICC에 의해 할당된 고유 식별자를 포함한다.

본 발명의 이러한 양태의 예의 추가 예시로서, 위에 언급된 가능한 도메인들과 관련한 본 발명의 구현 예가 아래에 주어진다.

먼저, 사용자는 사진을 찍고 이미지 파일을 "/partition1/directory1/image1. jpg" 에 저장한다. partition1 도메인은 "제한된 읽기 쓰기"로서 정의된다. "directory1" 및 "image1.jpg" 은 패스워드에 의해 보호되지 않는다.

사용자 또는 기타의 엔티티는 "image1.jpg" 파일에 액세스하려 하고 유일한 조건은 그것들이 "partition1" 에 대한 패스워드를 알 필요가 있다는 것이다.

제 2 예로서, 사용자는 사진을 찍고 이미지 파일을 "/partition1/directory1/image1.jpg" 에 저장한다. "partition1" 및 "directory1" 도메인은 "공개"(public) (따라서 패스워드 없음) 로 정의된다. "image1.jpg" 은 패스워드에 의해 보호된다 (도메인 "제한된 읽기").

사용자 또는 기타의 엔티티는 "image1.jpg" 파일을 읽으려 하고 유일한 조건은 그것들이 "image1.jpg" 에 대한 패스워드를 알 필요가 있다는 것이다.

제 3 예에서, 사용자는 사진을 찍고 이미지 파일을 "/partition1/directory1/image1.jpg"에 저장한다. "partition1" 도메인은 "private"으로 정의된다."directory1" 및 "image1.jpg"는 패스워드에 의해 보호되지 않는다.

사용자 또는 기타의 엔티티는 "image1.jpg" 파일에 액세스하려 한다. 하지만, 오직 사용자만이 성공적인 패스워드 검증 후에 파일에 액세스할 수 있을 것이다. 다른 엔티티는, 정확한 패스워드를 가진다 할지라도, (그의 entity_id가 소유자 entity_id 에 매칭되지 않으므로) 파일에 액세스할 수 없다.

제 4 예에서, 사용자는 사진을 찍고 이미지 파일을 "/partition1/directory1/image1.jpg"에 저장한다. "partition1" , "directory1" 및 "image1.jpg" 도메인은 "읽기 전용" 으로 정의된다.

본 예에 대한 제 1 오퍼레이션에 대해, 사용자 또는 기타의 엔티티는 "image1.jpg" 파일을 읽으려 하고 파일을 읽는데 패스워드가 요구되지 않으므로 파일 데이터는 직접 액세스가능하다.

하지만, 제 2 오퍼레이션에 대해, 사용자 또는 기타 엔티티는 "image1.jpg" 파일을 업데이트하려 하지만 오직 소유자 (사용자) 만이 성공적인 패스워드 검증 후에 파일에 액세스할 수 있을 것이다.

본 발명은 미래의 UICC-ME 대량 데이터 오퍼레이션이 주로 USB 인터페이스를 통해 주로 이루어질 것이라는 사실을 손쉽게 고려할 수 있음을 인식하게 될 것이다. 따라서 예시된 예는 USB에 기초한 ME-UICC 인터페이스를 통한 구현을 목적으로 하고 EEM (Ethernet Emulation Mode) 인터페이스 클래스를 지원한다. 하지만, 본 솔루션의 원리는 또한 스마트 카드 CCID (Integrated Circuit (s) Cards Interface Device) 와 같은 다른 USB 인터페이스 클래스에 대해 적용될 수 있다.

이 점에서, USB 패킷이 포맷을 갖는데, 그 포맷에서 EEM 패킷이 USB 패킷의 페이로드 (payload)를 포함한다는 것이 인식되야 한다. EEM 패킷은 그 자체로 EEM 데이터 또는 EEM 커맨드 포맷 중 어느 한쪽으로 정의된 포맷을 갖는다.

EEM 커맨드 패킷은 로컬 USB 링크 관리에 사용되고, 따라서, USB 디바이스 드라이버 계층을 넘을 수 없다. 따라서, 본 예시된 예의 정의된 모든 인터페이스 기능은 EEM 데이터 타입 패킷의 페이로드 부에 캡슐화될 것이다.

위에 언급된 바처럼, 본 발명은 또한, 요소 파일에 기초한 현재 파일 시스템이 일부 제한들을 갖고 있는, 큰 사이즈/멀티미디어 데이터의 지원을 향상시키기 위해, 향상된 데이터 저장을 가능하게 하는 역할을 하는 특징들을 포함한다. 본 발명의 이러한 양태는 대부분의 기존 요소 파일 파일 시스템을 표준 파일 포맷 파일 시스템으로 교체하는 것을 제안한다.

그러한 목적으로, ME가 UICC에서 파티션/디렉토리/파일을 생성하고 관리하기 위해 특정 ME-UICC 인터페이스 기능이 정의된다.

그러한 ME-UICC 기능의 예는 아래에서 윤곽이 그려진다.

(파티션 또는 디렉토리 또는 파일을 생성하기 위하여) 이용된 생성 기능은 다음과 같은 "요청/결과" 구조와 연관될 수 있다.

ME에서 UICC로 : Create_Element_Req (entity_id, element_type , pathname, element_parameters)

UICC에서 ME로 : Create_Element_Res (result, entity_id, pathname, additional_info)

거기에 채용된 파라미터들은 다음과 같이 정의될 수 있다.

- entity_id : 생성 요청을 전송한 엔티티를 나타낸다

- element_type : 파티션 또는 디렉토리 또는 파일

- 경로 이름 (pathname) : 생성될 엘리먼트의 "경로+이름" 예를 들면, "/partition/global_directory/directory1/image1.jpg" 를 포함한다.

- element_parameters : 주어진 엘리먼트 타입에 특정된 파라미터 (예를 들면, 파티션의 경우 사이즈, 파일의 경우 파일 타입 등)

- 결과 (result) : 요청 실행 결과를 포함한다 (성공, 실패, 수정을 이용한 성공,...)

- additional_info : UICC가 단순 실행 결과 보다 많은 정보를 전송할 때, (예를 들면, UICC 가 요청된 것과 다른 사이즈를 갖는 파티션을 생성한 경우) 이들 추가의 데이터가 이 파라미터에 포함된다

(파티션 또는 디렉토리 또는 파일을 읽기 위해) 이용된 읽기 기능은 다음의 요청/결과/구조와 연관될 수 있다.

ME에서 UICC로 : Read_Element_Req (entity_id, pathname)

UICC에서 ME로 : Read_Element_Res (result, entity_id, pathname, data)

그리고 여기서 파라미터들은 다음과 같이 정의될 수 있다:

- entity_id : 읽기 요청을 전송한 엔티티를 나타낸다

- 경로 이름 (pathname) : 읽혀질 엘리먼트의 "경로+이름"을 포함한다

- 결과 (result) : 엘리먼트 읽기 결과 (성공 또는 실패)

- 데이터 (data) : (예를 들면, 읽혀진 파티션/디렉토리하에 위치된 파일 및 디렉토리의 리스트 또는 파일의 경우 콘텐트 그 자체인) 읽혀진 엘리먼트의 데이터를 포함한다

업데이트 기능이 제공될 수 있지만 오직 파일들에 대해서 정의될 뿐이고 다음의 요청/결과 구조에 관련된다.

ME에서 UICC로: Update_File_Req (entity_id, pathname, data_type, data)

UICC에서 ME로 : Update_File_Res (result, entity_id, pathname)

여기서 파라미터들은 다음을 포함한다:

- entity_id : 업데이트 요청을 전송한 엔티티를 나타낸다

- 경로 이름 (pathname) : 업데이트될 파일의 "경로+이름" 예를 들면 "/partition/global_directory/directory1/image1.jpg" 을 포함하다

- data_type : 파일에서 데이터의 타입, 예를 들면 jpg, mpeg, txt, 등...을 나타낸다.

- 데이터 (data) : 파일의 콘텐트

- 결과 (result) : 파일 업데이트 결과 (성공 또는 실패)

이름 바꾸기 기능은 다음의 요청/결과 구조에 관련될 수 있다.

ME에서 UICC로 : Rename_Element_Req (entity_id, old_pathname , new_name)

UICC에서 ME로 : Rename_Element_Res (result, entity_id, new_pathname)

그리고 파라미터들은 다음과 같이 정의될 수 있다:

- entity_id : 이름 바꾸기 요청을 전송한 엔티티를 나타낸다

- old_pathname : 이름이 바꿔질 엘리먼트의 구 "경로 + 이름" 을 포함한다

- new_name : 이름이 바꿔질 엘리먼트의 단지 새 이름 (무 경로) 을 포함한다

- 결과 (result) : 이름 바꾸기 실행 결과 (성공 또는 실패)

- new_pathname : 이름이 바꿔진 엘리먼트의 "경로 + 새 이름" 을 포함한다

이동 기능은 다음에 의해 구현될 수 있다

ME에서 UICC로 : Move_Element_Req (entity_id, old_pathname, new_pathname)

UICC에서 ME로 : Move_Element_Res (result , entity_id , new_pathname)

그리고 파라미터 정의 관련하여

- entity_id : 이동 요청을 전송한 엔티티를 나타낸다

- old_pathname : 이동될 엘리먼트의 구 "경로 + 이름" 을 포함한다

- new_pathname : 이동된 엘리먼트의 새 "경로 + 이름" 을 포함한다

- result : 이동 실행 결과 (성공 또는 실패)

삭제 기능은 마찬가지로 다음과 같은 요청/결과 구조에 따라 제공될 수 있다

ME에서 UICC로 : Delete_Element_Req (entity_id, pathname)

UICC에서 ME로 : Delete_Element_Res (result, entity_id, pathname)

파라미터 정의는

- entity_id : 삭제 요청을 전송한 엔티티를 나타낸다

- 경로 이름 (pathname) : 삭제될 엘리먼트의 "경로+이름"을 포함한다

- 결과 (result) : 삭제 실행 결과 (성공 또는 실패)

일 수 있다

경로 이름이 보호되는 몇몇 모 디렉토리들을 포함하면, 이 요청을 프로세싱하기 전에 이들 디렉토리들에 대한 액세스 조건들이 먼저 이행되야 한다는 것에 유념해야 한다.

소거 기능들이 또한 제공될 수 있고 소유자가 관련 패스워드를 분실/잊어 버린 경우 (그래서 파티션/디렉토리/파일에 있는 어느 데이터에도 액세스할 수 없는 경우) 파티션/디렉토리/파일을 삭제하는 역할을 한다.

오직 파티션/디렉토리/파일의 소유자만이 이 오퍼레이션을 수행할 수 있다.

UICC는 통과된 entity_id 가 소유자 entity_id에 대응하는지를 체크해야 하고 관련 "요청/결과" 구조는 아래와 같다.

ME에서 UICC로 : Clean_Element_Req (entity_id, pathname)

UICC에서 ME로 : Clean_Element_Res (result, entity_id, pathname)

파라미터 정의는 다음과 같이 주어질 수 있다

- entity_id : 오직 소유자만이 이 요청을 이룰 수 있을 것이다

- 경로 이름 (pathname) : 소거 (즉 삭제) 될 엘리먼트의 "경로 + 이름" 을 포함한다

- result : 소거 요청 결과 (성공, 실패)

예를 들면 리사이즈 파티션에 관한 것과 같은 추가의 기능들이 또한 제공될 수 있고 다음과 같은 "요청/결과" 구조가 구비될 수 있다.

a) 리사이즈 (resize) 파티션

ME에서 UICC로 : Resize_Partition_Req (entity_id, name, new_size)

UICC에서 ME로 : Resize_Partition_Res (result, entity_id, new_allocated_size)

관련 파라미터들은 다음과 같이 정의될 수 있다:

- entity_id : 리사이즈 요청을 전송한 엔티티를 나타낸다

- 이름 (name) : 파티션의 이름

- new_size : 파티션에 새로이 요구되는 메모리 사이즈를 포함한다

- 결과 (result) : 파티션 리사이징 결과 (성공, 실패, 수정을 이용한 성공 (예를 들면, 할당된 사이즈가 요청된 사이즈와 다른 경우))

- new_allocated_size : UICC에 의해 할당된 파티션의 실제 메모리 크기를 나타낸다.

물론 이들 인터페이스 기능들은 필요할 때 조합하여 제공될 수 있음을 인식되야 한다.

이제 도 3을 참조하면, 도 1의 UICC (10) 의 메모리 저장 영역 내 디렉토리의 생성을 위해 발생되는 신호들의 시퀀스에 관한 시그널링 타이밍 도가 제공되어 있다.

시그널의 시퀀스는 최종 사용자 (26), ME (28) 이를 테면 셀 폰 핸드셋과 UICC (30) 이를 테면 도 1의 UICC (10) 사이에 발생되는 것들이다.

도 3에 예시된 시퀀스는 기존 파티션/디렉토리에서 디렉토리의 생성을 위한 사용자 (26) 로부터의 요청 (32) 으로 시작되고 그래서 적절한 요청 오퍼레이션 (34) 이 ME (28) 로 전송되고 그것은 패스워드 이름, 도메인 및 패스워드를 포함할 수 있다.

사용자 (26) 는 도메인이 "공개" 되도록 요구되는 경우 디렉토리에 대한 패스워드를 설정하지 않고 그래서 "패스워드" 파라미터가 널 스트링 (null string) 이 되게 된다.

ME (28) 는 다음에 Create_Element_Request (36) 를 UICC (30) 으로 전달하고 그 것은 entity_id, element_type, pathname 및 element_parameters 들을 포함한다.

디렉토리의 생성을 위해 "element_type" 이 "directory" 로 설정되고 "element_parameters"가 널 값 (null value) 을 갖는다는 것을 본 예의 안에서 유념해야 한다.

시그널링 (signaling) 의 다음 패시지 (passage) 는 패스워드 검증 시퀀스 (38) 를 포함하는데, 이는 모 디렉토리와 관련되지만 모 디렉토리가 패스워드에 의해 보호되지 않을 경우 필요하지 않게 된다. 하지만, 보호되는 수개 레벨의 디렉토리들이 존재하는 경우, 각 디렉토리를 위한 패스워드가 검증되야 한다.

패스워드 검증 시퀀스 (38) 는 모-디렉토리-경로를 포함하고 또한 패스워드가 필요한 조건을 확인하는 access_condition_notification 신호 (40) 로 시작된다.

패스워드가 필요하다는 통보 (42) 가 ME (28) 로부터 ME 사용자 (26) 에게로 전달되고 그 다음 ME 사용자 (26) 는 패스워드 (44) 를 다시 ME (28) 로 제공하고, 그 다음 ME (28)는 verify_password_request 신호 (46) 를 UICC (30) 에 전달한다. 그 다음 이것은 verify_password_result 신호 (48)를 ME (28) 에 제공하고 그 다음 추가의 시그널링 교환이 UICC (30) 와 ME (28) 사이에서 일어나고 그것은 create_element result 신호 (50), set_domain_request 신호 (52), set_domain_result 신호 (54), set_password_request 신호 (56) 및 set_password_result 신호 (58) 를 포함하지만, 그러한 세팅 패스워드 기능은 패스워드 값이 널 (null) 이면 발생할 수 없음을 인식해야 한다.

시퀀스는 ME (28) 로부터 사용자 (26) 으로 전달되는 생성적 디렉토리 결과 신호 (60) 로 끝난다.

비교에 의해, 파일의 생성에 관하여 발생되는 신호들의 시퀀스를 예시하는 도 4를 참조하여 본 발명의 본 실시형태의 추가의 상세한 특징들이 도시된다.

시그널링은 다시 사용자 (26), ME (28) 및 UICC (30) 에 관하여 예시되어 있다.

본 예에서, 최종 사용자가 ME의 카메라 기능을 사용하여 사진을 찍고 사진을 기존 파티션/디렉토리에 저장할 것을 결정하는 것으로 가정된다. 62에서 사진을 기존 파티션/디렉토리에 저장하기 위한 결정이 내려지고 그래서 사용자 (26) 는 이동 장비 (28) 에 생성 파일 요청 (64) 을 제공하고 그것은 경로 이름, 도메인, 패스워드 및 data_type을 관련 데이터와 관련하여 포함하는 파일 요청 (64) 을 생성한다.

다음에, create_element_request (66) 이 ME (28) 에서 UICC (30) 로 전달되고 거기에서, 파일의 생성을 위해, element_type은 "file"로 설정되고, element_parameters 는 file_type 이를 테면 JPG 또는 MP3, 및 데이터, 즉 파일 콘텐트 자체를 포함한다.

68에서, 파일을 생성하기 위해 로케이션에 도달하기 전에 패스워드에 의해 보호되는 디렉토리가 존재함을 알게 되면, 각 디렉토리를 위한 패스워드는 검증되야하고 도 3에 예시된 바와 같은 검증 시퀀스 (38) 는 마찬가지로 도 4의 시퀀스로 이용될 수 있다.

즉, create_element_result (70) 은 UICC (30)에서 ME (28) 로 전달되고, 응답으로, set_domain__request 신호 (72) 는 UICC (30) 로 전달되고 이 것은 그 다음 set_domain_results 신호 (74) 를 개시한다. 패스워드가 "널" 로 설정되지 않는 것으로 가정하면, set_password_request (76) 가 ME (28) 로부터 UICC (30) 로 전달되고, 응답하여, set_password_result (78) 가 UICC (30) 로부터 ME (28) 로 전달된다. ME (28) 와 UICC (30) 사이에 시그널링 교환 (70-78) 이 끝날 때, 파일 결과 표시 (80) 의 생성이 ME (28) 에 의해 최종 사용자 (26) 에 제공된다.

마지막으로 도 5 및 도 6을 참조하면, 올바른 패스워드가 이용되는 경우 (도 5) 그리고 비교로서, 액세스 조건이 이행되지 않는 경우 (도 6) 에서, 보호된 파일의 시도된 읽기에 관한 시그널링 도가 제공되어 있다.

따라서 도 5를 먼저 참조하면, 적절한 엔티티 (26) 는 엔티티가 "제한 읽기" 도메인에서 정의된 파일을 읽기 원한다는, 82에서의 표시를 읽기 파일의 제공 (84) 에 의해 ME (28) 로 제공한다. 읽기 파일 표시 (84) 내 경로 이름은 "/partition I/directory I/picture 1.jpg" 과 같은 읽혀질 파일에 대한 특정 경로를 포함한다.

read_element_request (86) 은 나중에 ME (28)에서 UICC (30) 로 전송된다.

도 5 내에 예시된 바처럼, 패스워드 검증 시퀀스 (88) 은 파일 자체에 적용되고 또한 선행 디렉토리에 적용되고 그것은 패스워드에 의해 보호될 수도 있고, 이 경우에, 도 5에 예시된 것과 같은 표시 (90-98) 및 시그널링을 포함하는 패스워드 검증 시퀀스가 제공된다.

초기에, access_condition_notification 신호 (90) 가 UICC (30) 에서 ME (28) 로 전달되고, 그 다음, 패스워드 요구 표시 (92) 가 ME (28) 에서 엔티티 (26) 로 제공되고, 그것은 검증된 패스워드 시도 (94) 를 반환하고, 그 다음, 그것은 ME (28) 에서 UICC (30) 로 verify_password_request (96) 를 개시한다.

그 다음 verify password_result (98) 는 패스워드 검증 시퀀스 (88) 를 완료 하도록 UICC (30) 에서 ME (28) 로 반환된다.

패스워드가 검증됨에 따라, 요구된 데이터를 포함하는 읽기 엘리먼트 결과 (100) 가 UICC (30) 로부터 ME (28) 로 전달되어 요청된 데이터를 포함하는 읽기 파일 결과가 그 다음 요청 엔티티 (26) 로 전달 (102) 될 수 있다.

이제 도 6을 참조하면, 104에서의 다른 상이한 엔티티에 의해 "사적" 영역에서 정의된 파일을 읽기 위한 일 엔티티에 의한 시도에 관한 시퀀스가 예시되어 있고 읽기 파일 표시 (106) 가 ME (28) 에 제공된다.

그 다음 read_element_request (108) 이 ME (28) 에서 UICC (30) 전달되는데, 여기에서, entity_id는 파일-소유자 entity_id와 다르다는 것을 인식해야 한다.

UICC (30) 는 파일의 도메인이 "사적" 도메인을 포함하고 따라서 오직 파일의 소유자 만이 그에 액세스할 수 있다는 것을 인식한다. 수신된 entity_id가 소유자 entity_id와 매칭되지 않으므로, 읽기 요청이 UICC (30) 에서 ME (28) 로 전달된 read_element_result (110) 내에서 거절된다.

그 다음 읽기 파일 결과 표시 (112) 가 ME (28)에서 요청 엔티티 (26) 로 제공되고 결과는 읽기 실패를 표시하여 그 안의 데이터 파라미터가 널이 된다.

본 발명은 전술한 실시형태의 상세들로 제한되지 않는다는 것이 물론 인식되야 한다.

비록 USB 스마트 카드 ICCD 인터페이스 클래스를 통해 실행되는 어플리케이션을 위한 (본 문헌에 설명된 바와 같은 특징들을 지원하는 새로운 APDU 커맨드를 생성하는 것을 수반하는) 구현이 명시적으로 설명되어 있지 않지만, 위에 윤곽이 그려진 것들과 같은 원리들이 그러한 ICCD 클래스에 적용될 수 있다.

또한, USB 대용량 저장 인터페이스 클래스를 지원하는 UICC의 수반하는 시나리오를 위해, 그러한 UICC에서 (ME와 같은) 엔티티에 의해 절약되는 데이터 엘리먼트가 패스워드 검증 없이 액세스가능, 즉 데이터 엘리먼트 그 자체 뿐만 아니라 그의 모 데이터 엘리먼트에 대해 패스워드가 요구되지 않으면, USB 대용량 저장 디바이스와 같이 구성되고 거동하는 UICC가 예를 들면 PC와 같은 디바이스에 접속될 때, 이 데이터 엘리먼트는 또한 액세스가능해야 한다.

UICC가 USB 대용량 저장 디바이스로서 구성되고 패스워드 검증 프로세스를 지원하지 않는 디바이스에 접속될 때 패스워드-보호되는 데이터 엘리먼트는 액세스가능하지 않은 상태로 남아야 한다.

따라서, 더 상세하게는, UICC가 USB 대용량 저장 디바이스로서 구성되게 구현되고 PC와 같은 원격 디바이스에 접속됨에 따라, UICC는 간단한 USB 메모리 스틱의 방식으로 거동할 수 있다. 그 다음 패스워드 없이, 즉 위에 윤곽이 그려진 "공개" 도메인에서 ME 또는 실제로 기타 디바이스에 의해 절약된 UICC 상의 데이터 엘리먼트는 PC에서 액세스가능한 상태로 남아야 한다.

하지만, 패스워드에 의해 보호되는 데이터 엘리먼트들에 대해, 그것들은, 메모리 스틱의 방식으로 거동하는, UICC가 PC에 접속될 때 액세스가능하지 않은 상태로 남는다.

예를 들면, 사용자는 ME의 카메라를 사용하여 사진을 찍고, 그것을 패스워드 없이 UICC에 저장한다. 그 다음, 전기 어댑터에 의해, 사용자가 UICC의 플러그를 PC에 꽂을 때, UICC는 USB 메모리 스틱과 같이 거동할 것이고, 사진은 PC 상에서 액세스가능할 것이다. 하지만, 사용자가 사진을 패스워드로 저장하면, UICC의 플러그가 PC에 꽂혀질 때 이 사진은 보이지 않을 것이다.

<참조에 의한 포함>

본 출원은 2009년 1월 16일자로 출원된 UK 특허 출원 제0900664.4호로부터의 우선권에 이익을 주장하고 이에 기초하는데, 그의 개시는 전체적으로 참조에 의해 본원에 포함된다.

10 UICC
12 프로세싱 기능 (processing functionality)
14 저장 영역 (storage area)
16 인터페이스 (interface)
20 프로세서 (processor)
22 표준 메모리 (standard memory)
24 송신/수신 기능 (transmit/receive functionality)
26 사용자 (user)
28 ME
30 UICC
32 요청 (request )
34 적절한 요청 오퍼레이션 (appropriate request operation)
36 생성_엘리먼트_요청 (Create_Element_Request)
38 패스워드 검증 시퀀스8 (password verification sequence8)
40 액세스_조건_통보 신호10 (access_condition_notification signa1O)
46 검증_패스워드_요청 신호6 (verify_password_request signal6)
48 검증_패스워드_결과 신호8 (verify_password_result signal8)
50 생성_엘리먼트 결과 신호0 (create_element result signal0)
52 설정_도메인_요청 신호 (set_domain_request signal)
54 설정_도메인_결과 신호 (set_domain_result signal)
56 설정_패스워드_요청 신호 (set_password_request signal)
60 생성적 디렉토리 결과 신호 (creative directory result signal)
64 생성 파일 요청 (create file request)
66 생성_엘리먼트_요청 (create_element_request)
70 생성_엘리먼트_결과 (create_element_result)
72 설정_도메인_요청 신호 (set_domain_request signal)
74 설정 도메인 결과 신호(set domain results signal)
76 설정_패스워드_요청 (set_password_request)
78 설정_패스워드_결과 (set_password_result)
80 파일 결과 표시 (file result indication)
82 2에서의 표시 (indication at2)
84 읽기 파일 표시 (read file indication)
86 읽기_엘리먼트_요청 (read_element_request)
90 액세스_조건_통보 신호 (access_condition_notification signal)
92 패스워드 요청 표시 (password required indication)
94 검증된 패스워드 시도 (verified password attempt)
96 검증-패스워드_요청 (verify_password_request)
98 검증 패스워드_결과 (verify password_result)
100 읽기 엘리먼트 결과0 (read element resultO)
102 전달됨 (delivered)
106 읽기 파일 표시 (read file indication)
108 읽기_엘리먼트_요청 (read_element_request)
110 읽기_엘리먼트_결과 (read_element_result)
112 읽기 파일 결과 표시 (read file result indication)

Claims

USB 대용량 저장 디바이스로서 구성되고 원격 디바이스에 대해 접속하도록 구성되고 복수의 데이터 엘리먼트들의 저장하도록 구성된 회로 카드에서의 데이터 보호 방법으로서,
데이터 엘리먼트 상에서 허용될 수 있는 오퍼레이션을 정의하는 역할을 하는 도메인 보호 엘리먼트 및 데이터 엘리먼트에 대한 액세스를 제어하는 역할을 하는 패스워드 보호 엘리먼트 중 하나에 기초하여 보호를 제공하는 단계를 포함하고,
상기 복수의 데이터 엘리먼트들 중 적어도 하나는 상기 도메인 보호 엘리먼트 및 상기 패스워드 보호 엘리먼트 양자 모두와 연관되며,
상기 패스워드 보호 엘리먼트와 연관되지 않은 데이터 엘리먼트들은 상기 원격 디바이스에서 액세스가능하고, 상기 패스워드 보호 엘리먼트와 연관된 데이터 엘리먼트들은 상기 디바이스가 패스워드 검증 메카니즘을 지원하지 않으면 상기 원격 디바이스에서 액세스가능하지 않는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 적어도 하나의 데이터 엘리먼트에 대해, 허용된 상기 오퍼레이션을 개시하기 위해 패스워드가 요구되고, 상기 오퍼레이션은 상기 도메인 보호 엘리먼트에 의해 정의되는, 회로 카드에서의 데이터 보호 방법.
제 1 항 또는 제 2 항에 있어서,
상기 회로 카드의 하나 이상의 어플리케이션에 대한 PIN 코드 액세스를 사용하는 단계를 더 포함하는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 복수의 데이터 엘리먼트들의 각각은 상기 도메인 보호 엘리먼트와 연관되는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 도메인 보호 엘리먼트에 의해 정의된 허용된 오퍼레이션은 하나 이상의 읽기 및/또는 쓰기 액세스 오퍼레이션을 포함하는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 회로 카드에서 데이터에 액세스할 수 있는 엔티티는 고유 식별자와 연관되는, 회로 카드에서의 데이터 보호 방법.
제 6 항에 있어서,
상기 데이터 엘리먼트를 생성하는 상기 엔티티의 상기 식별자를 저장하는 단계를 더 포함하는, 회로 카드에서의 데이터 보호 방법.
제 6 항 또는 제 7 항에 있어서,
상기 회로 카드는 상기 데이터 엘리먼트의 상기 엔티티의 상기 식별자를 저정하도록 구성된, 회로 카드에서의 데이터 보호 방법.
제 6 항에 있어서,
이동 장비 (Mobile Equipment; ME) 내에서, 상기 데이터에 대한 액세스를 필요로 하는 엔티티를 식별하는 단계를 더 포함하는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 데이터 보호는 USB 인터페이스 클래스를 통하여, 상기 USB 인터페이스가 이동 장비(Mobile Equipment; ME)와 상기 회로 카드 사이에 활성화될 때 적용되는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
표준 파일 포맷 파일 시스템에 따라 상기 회로 카드 상에 상기 데이터 엘리먼트를 저장하는 단계를 포함하는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 회로 카드 내의 상기 데이터 엘리먼트들의 생성 및 관리는 이동 장비(Mobile Equipment; ME)를 통해 제어되는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
ME 회로-카드 인터페이스 기능들은 하나 이상의 생성 기능, 읽기 기능, 업데이트 기능, 이름 바꾸기 기능, 이동 기능, 삭제 기능 및 소거 기능 중 하나 이상을 포함하는 것으로서 정의되는, 회로 카드에서의 데이터 보호 방법.
제 1 항에 있어서,
상기 회로 카드는 UICC를 포함하는, 회로 카드에서의 데이터 보호 방법.
USB 대용량 저장 디바이스로서 구성되고 원격 디바이스에 대해 접속하도록 구성되고 복수의 보호가능한 데이터 엘리먼트들을 저장하도록 구성된 회로 카드로서,
상기 데이터 엘리먼트 상에 허용될 수 있는 오퍼레이션들을 정의하는 역할을 하는 도메인 보호 엘리먼트 및 상기 데이터 엘리먼트에 대한 액세스를 제어하는 역할을 하는 패스워드 보호 엘리먼트 양자 모두와 연관되도록 구성된 상기 복수의 보호가능한 데이터 엘리먼트들중 적어도 하나를 포함하고,
상기 패스워드 보호 엘리먼트와 연관되지 않은 데이터 엘리먼트들은 상기 원격 디바이스에서 액세스가능하고, 상기 패스워드 보호 엘리먼트와 연관된 데이터 엘리먼트들은 상기 디바이스가 패스워드 검증 메카니즘을 지원하지 않으면 상기 원격 디바이스에서 액세스가능하지 않는, 회로 카드.
제 15 항에 있어서,
상기 도메인 보호 엘리먼트에 의해 허용되는 상기 오퍼레이션을 개시하기 위해 패스워드가 요구되는, 회로 카드.
제 15 항에 있어서,
상기 복수의 데이터 엘리먼트들의 각각은 상기 도메인 보호 엘리먼트와 연관되는, 회로카드.
제 15 항 내지 제 17 항 중 어느 한 항에 있어서,
상기 회로 카드는 USB 인터페이스 클래스를 통해 상기 데이터 엘리먼트에 대한 액세스를 허용하도록 구성된, 회로 카드.
제 15 항에 있어서,
UICC를 더 포함하는, 회로 카드.
삭제
제 15 항에 정의된 회로 카드를 이용하여 동작하도록 구성된, 이동 무선 통신 디바이스.
제 21 항에 있어서,
상기 이동 무선 통신 디바이스는 USB 인터페이스 클래스를 통해 상기 회로 카드와 통신하도록 구성된, 이동 무선 통신 디바이스.
제 21 항 또는 제 22 항에 있어서,
상기 이동 무선 통신 디바이스는 상기 저장된 데이터 엘리먼트들을 생성 및/또는 관리하도록 구성된, 이동 무선 통신 디바이스.