KR20240047377A - 보안 엘리먼트에서 오퍼레이팅 시스템의 업데이트 - Google Patents

Abstract

본 발명은 보안 엘리먼트 (SE) (100) 에서 파일 시스템 (32) 을 관리하는 오퍼레이팅 시스템 (OS) (30) 을 업데이트하는 방법에 관한 것이다. 그 방법은, SE (100) 에 업데이트 에이전트 (10) 를 제공하는 단계 (S1); 오퍼레이팅 시스템 (30) 으로부터 업데이트 에이전트 (10) 에 의해 SE (100) 의 제어를 인수하는 단계 (S3); 오퍼레이팅 시스템 (30) 의 업데이트를 나타내는 OS 이미지 (31) 를 SE (100) 상에 로딩하는 단계 (S4); OS 이미지 (31) 를 설치함으로써 업데이트된 오퍼레이팅 시스템 (30) 을 제공하는 단계 (S5); 및 업데이트 에이전트 (10) 에 의한 SE (100) 의 제어를 업데이트된 오퍼레이팅 시스템 (30) 에 핸드오버하는 단계 (S6) 를 포함한다. 상기 업데이트 프로세스 내에서, 업데이트 에이전트 (10) 는 SE (100) 에 임시 파일 시스템 (12) 을 제공하고 (S1a), 업데이트 에이전트 (10) 가 SE (100) 를 제어하고 있는 한, 임시 파일 시스템 (12) 을 관리한다 (S5a). 본 발명은 또한 각각의 보안 엘리먼트 (100), 각각의 업데이트 에이전트 (10), 및 각각의 컴퓨터 프로그램 제품에 관한 것이다.

Description

보안 엘리먼트에서 오퍼레이팅 시스템의 업데이트

본 발명은 일반적으로 보안 엘리먼트들에 관한 것으로, 특히 보안 엘리먼트의 오퍼레이팅 시스템을 업데이트하기 위한 방법, 업데이트 능력들을 갖는 업데이트 에이전트가 장착된 보안 엘리먼트뿐만 아니라, 그에 따른 업데이트 에이전트 및 컴퓨터-프로그램 제품에 관한 것이다.

스마트 카드는 모바일 폰, 결제 카드, 액세스 카드와 같은 다양한 시스템에서 신원 확인, 인증 및 데이터 저장 서비스뿐만 아니라 애플리케이션 프로세싱을 제공하기 위해 널리 사용되고 있다.

스마트 카드가 결제 카드 등의 경우와 같이 보안에 중요한 애플리케이션 및 민감한 데이터를 포함하는 경우, 데이터를 저장하기 위해 보안 엘리먼트가 사용된다. 보안 엘리먼트는 애플리케이션 코드 및 애플리케이션 데이터가 안전하게 저장되고 관리될 수 있는 보안 메모리 및 실행 환경을 제공하는 변조 방지 엘리먼트 (tamper resistant element, TRE) 이다. 보안 엘리먼트는 카드에 저장된 데이터에 대한 액세스가 인가된 경우에만 제공되는 것을 보장한다. 이러한 보안 엘리먼트는 UICC, 임베디드 SE, 스마트SD, 스마트 마이크로SD 등과 같은 임의의 폼 팩터로 존재할 수도 있다.

보안 엘리먼트는 하나 이상의 보안 도메인을 포함할 수도 있으며, 이들 각각은 보안 키를 사용하여 인증되는 오퍼레이팅 시스템, 개인화 데이터, 패키지, 애플릿, 애플리케이션 등과 같은 데이터의 집합을 포함한다. 따라서, 오퍼레이팅 시스템 및 애플리케이션은 휘발성 및 비휘발성 메모리 모듈의 보안 엘리먼트 내에 저장되고, 보안 엘리먼트의 보안 프로세서에 의해 실행된다.

보안 엘리먼트는 ISO/IEC 7816-4 에 따른 파일 시스템을, 각각 디렉토리 및 데이터 파일로서 다수의 전용 파일 (DF) 및 기본 파일 (EF) 과 마스터 파일로 구성된 계층적 파일 구조 형태로 더 포함할 수도 있다. 보안 엘리먼트 또는 보안 엘리먼트에 연결된 외부 단말에서 실행되는 애플리케이션은 EF 를 선택하고 EF 의 데이터에 대한 읽기/쓰기 동작을 수행할 수도 있다. 보안 엘리먼트의 통신 인터페이스들뿐만 아니라 외부 단말과의 그의 상호작용은 예를 들어, 버전 v15.2.0 의 표준 ETSI TS 102 221 (스마트 카드들; UICC-단말 인터페이스; 물리적 및 논리적 특징들) 에 명시된다.

또한, 명세서 Global Platform Card Technology Open Firmware Loader for Tamper Resistant Element v1.3 은 펌웨어 (오퍼레이팅 시스템 및 애플리케이션 데이터를 포함할 수도 있는 사용 케이스 의존 데이터) 를 보안 엘리먼트 내로 로딩하기 위한 표준화된 메커니즘을 설명한다. 특히, 보안 엘리먼트 내부에 제공된 Image Trusted Loader, ITL, 또는 업데이트 에이전트는 오퍼레이팅 시스템 이미지를 수신하고, 이미지에 대한 진위 및 무결성 검사들을 수행하고, 보안 엘리먼트의 메모리 내로의 이미지의 설치를 트리거하도록 구성된다.

오퍼레이팅 시스템을 수신, 검사 및 설치하는 이러한 프로세스를 통해, ITL 또는 업데이트 에이전트는 보안 엘리먼트를 제어하고 있고, 특히 외부 엔티티 또는 단말과의 통신을 담당하며, 보안 엘리먼트는 예를 들어 ISO/IEC 7816-4 에 따른 착신 및 발신 APDU 메시지들을 통해 연결될 수도 있다. 마찬가지로, 오퍼레이팅 시스템 업데이트 과정에서, 오퍼레이팅 시스템이 동작하지 않거나 업데이트 과정이 완료되지 않았기 때문에, 업데이트 에이전트가 보안 엘리먼트를 담당하는 기간이 존재한다.

도 1 은 펌웨어 (예를 들어, 오퍼레이팅 시스템, OS) 를 보안 엘리먼트 내로 로딩하는 종래의 프로세스의 개략도를 도시한다. 상부 행은 대응하는 생산 단계 (I, II, III, IV) 를 담당하는 엔티티들을 도시하는 반면, 하부 행은 특정 생산 단계에서 보안 엘리먼트 (즉, 칩) 의 콘텐츠를 도시한다. 칩 생산 사이트 (즉, 칩 공장) 에서 제 1 생산 단계 (I) 동안, 칩 제조업체는 보안 오퍼레이팅 시스템과 같은 신뢰된 소프트웨어가 로딩되는 보안 엘리먼트 (100) 를 제공한다. 초기 보안 OS (30) 는 크리덴셜들 (13) 로 개인화되고, 개인화된 보안 OS 이미지 (도 1 에서 "maxiInit" 로 식별됨) 는 칩 내부에 업데이트 에이전트와 함께 로딩된다. 그 후, OS 를 갖는 칩은 휴대용 디바이스에 임베딩되거나 (단계 II), 다른 디바이스 제조사에 전달되어 스마트폰, 컴퓨터, 자동차, 측정 장비 등과 같은 더 큰 전자 장치에 포함될 수 있고 (단계 III), 마지막으로 시장에 출시될 수 있다 (단계 IV).

이러한 종래의 접근법에 보완적으로, 임베딩된 칩이 시장에 전달될 때까지 그리고 심지어 그 후에, 칩 상에 로딩된 OS 를 변경 또는 업데이트하는 것이 요구될 수도 있는데, 이는 오퍼레이팅 시스템과 같은 신뢰되는 소프트웨어가 SE 의 업데이트 에이전트를 통해 어디에나 로딩될 수도 있기 때문이다. 그러나, OS 이미지가 SE 상에 로딩되고 업데이트된 OS 로서 설치되는 시나리오에서, 보안 엘리먼트에 접속된 외부 단말에 의한 커맨드들 또는 요청들은, 정규 파일 시스템 및 관련 데이터가 오퍼레이팅 시스템 업데이트 동안 이용가능하지 않기 때문에, 적절하게 응답되지 않을 수도 있다.

업데이트 에이전트가 이러한 외부 요청들을 프로세싱할 수 없는 것은 OS 업데이트 동안 SE 로부터 유의미한 응답을 수신하지 않기 때문에 단말에 의한 보안 엘리먼트의 비활성화를 초래할 수도 있다. 보안상의 이유로, 이것은 심지어 SE 를 완전히 사용할 수 없게 할 수도 있다.

따라서, 상기 언급된 단점들을 해결하는 보안 엘리먼트의 오퍼레이팅 시스템을 업데이트하기 위한 솔루션을 제공하는 것이 필요하다.

본 발명은 독립항들에 의해 커버되는 주제에 의해 상기 목적을 해결한다. 본 발명의 바람직한 실시형태들이 종속항들에 정의되어 있다.

본 발명의 제 1 양태에 따르면, 보안 엘리먼트 (SE) 에서 파일 시스템을 관리하는 오퍼레이팅 시스템 (OS) 을 업데이트하기 위한 방법이 제안된다. 그 방법은 제 1 단계에서 SE 에 업데이트 에이전트를 제공하는 단계를 포함한다. 추가 단계에서, 업데이트 에이전트는 오퍼레이팅 시스템으로부터 SE 의 제어를 인수한다. 또한, 현재 설치된 오퍼레이팅 시스템의 업데이트를 나타내는 OS 이미지가 SE 내로 로딩된다. OS 이미지를 설치함으로써, 업데이트된 오퍼레이팅 시스템이 SE 상에 제공된다. 최종 단계에서, 업데이트 에이전트는 SE 의 제어를 업데이트된 오퍼레이팅 시스템으로 핸드오버한다. 위에서 다뤄진 단점들을 극복하기 위해, 업데이트 에이전트는 SE 에 임시 파일 시스템을 제공하고, 업데이트 에이전트가 SE 를 담당하는 한, 즉 OS 로부터 제어를 인수하는 것과 업데이트된 OS 로 제어를 다시 핸드오버하는 것 사이의 기간 동안 임시 파일 시스템을 관리한다.

본 출원에서 용어 "오퍼레이팅 시스템" 은 보안 엘리먼트를 동작시키기 위해 요구되는 그리고 보안 엘리먼트에서 로딩 및 실행되기 위한 임의의 신뢰되는 시스템 핵심 소프트웨어 또는 그 일부를 커버한다. 이러한 신뢰되는 소프트웨어의 예들은 펌웨어, 오퍼레이팅 시스템, 및 SE 를 동작시키기 위해 요구되는 임의의 다른 사용-케이스 의존 보안 애플리케이션들을 포함한다. "OS 이미지" 라는 표현은 본 발명에 따른 업데이트 에이전트와 같은, SE 의 오퍼레이팅 시스템 또는 에이전트에 의해 사용될 소프트웨어 버전 및 암호 데이터를 캡슐화하는 일반적인 데이터 포맷을 의미한다.

제안된 방법은 오퍼레이팅 시스템이 업데이트되는 동안 외부 단말기와 보안 엘리먼트의 상호 작용을 방해하지 않고, 결과적으로 SE 가 비활성화 또는 연결해제되지 않고 신뢰되는 소프트웨어를 업데이트하기 위한 효율적이고 안전한 솔루션을 제공한다.

임시 파일 시스템은 업데이트 에이전트가 SE 를 제어하고 있고 외부 단말과 통신하고 있는 한 관리되므로, 일시적으로 이용불가능한 정규 파일 시스템을 대체하고 업데이트 에이전트가 외부 단말로부터의 커맨드들 또는 요청들을 유의미하게 프로세싱할 수 있도록 한다. 즉, 임시 파일 시스템은 접속된 단말이 그 커맨드들 및 요청들에 대한 응답으로 유의미한 응답들을 수신할 정도로 정규 파일 시스템을 시뮬레이션하거나 심지어 '모의 (mock) 들' 로 종결할 수도 있다. 결과적으로, SE 와 단말 사이의 상호작용이 중단되지 않으므로, 보안 엘리먼트는 외부 단말에 의해 비활성화되거나 연결해제될 필요가 없다.

일부 실시형태들에서, 업데이트 에이전트에 의해 제공되는 임시 파일 시스템은 외부 단말로부터의 커맨드들을 프로세싱할 수 있게 하는 최소 기능 및/또는 최소 데이터만을 포함할 수도 있다. 임시 파일 시스템의 최소 기능 및/또는 데이터 때문에, 필요한 메모리 공간이 또한 최소화되어, 임시 파일 시스템은 업데이트 프로세스 동안 업데이트 에이전트에 이용가능한 제한된 메모리 공간 내에 적합하다.

일부 실시형태들에서, 임시 파일 시스템은, 정규 파일 시스템 대신에 임시 파일 시스템만이 이용가능한 외부 단말에 대해 투명하도록 충분히 구조화되고 및/또는 충분한 데이터가 구비될 수도 있다. 바람직하게, 이용가능한 파일 시스템을 관리하고 있는 것이 SE 의 오퍼레이팅 시스템이 아니라 업데이트 에이전트라는 것이 외부 단말에 특히 투명하다. 이에 의해, 외부 단말에 의한 SE 의 비활성화 또는 연결해제를 확실하게 방지할 수 있다.

본 발명은 임시 파일 시스템이 정규 파일 시스템보다 훨씬 적은 메모리 공간이 요구하지만, 업데이트 에이전트가 SE 와 그 통신 및 인터페이스들을 담당할 때 OS 업데이트 동안 SE 를 어드레싱하는 외부 단말로부터의 커맨드들 또는 요청들에 대한 유의미한 응답들을 허용하도록 충분히 구성되는 장점을 제공한다.

실제로, 더 넓은 범위에서, 본 발명의 또 다른 장점은, 본 발명에 따른 업데이트 에이전트를 구비한 SE 가 보안 엘리먼트를 동작시키기 위해 요구되는 오퍼레이팅 시스템 또는 다른 신뢰되는 시스템-관련 소프트웨어의 중간 비-기능 상태들을 처리하는 것을 지원한다는 것이다. 예를 들어, 본 발명은 시스템의 하나의 상태로부터 다른 상태로의 트랜지션 시에, 적절한 잘-정의된 거동을 제공함으로써 외부 엔티티 또는 단말이 트랜지션 상황에서 SE 와 결합하거나 또는 계속해서 결합하는 것을 보장한다.

업데이트 에이전트는 (도 1 에서 단계 I 로 지칭된) 칩 공장에서의 초기 생산 단계에서, 즉, 칩 제조 사이트의 보안 환경 내에서 SE 내로 로딩된다. 바람직하게는, 보안 크리덴셜들을 포함하는 개인화 데이터가 업데이트 에이전트와 함께 보안 엘리먼트 내로 로딩되어, 엄격한 안전 조건들 및 기밀 데이터의 허가되지 않은 수정으로부터의 보호를 보장한다. 보안 조치가 적용되어 변조 방지를 보장하는 경우, 초기 오퍼레이팅 시스템은 초기 생산 단계 또는 후속 단계에서 SE 에 로딩, 개인화되고, 설치될 수도 있다. 그러나, 초기 오퍼레이팅 시스템은 SE 의 수명 사이클의 후속 단계, 예를 들어 초기 생산 단계에 후속하는 단계 (도 1 에서 단계 II, III, IV 로 지칭됨) 에서 업데이트될 필요가 있을 수도 있다.

바람직하게, 임시 파일 시스템은 업데이트 에이전트 내에 또는 업데이트 에이전트의 일부로서, 예를 들어, 업데이트 에이전트의 개인화 데이터의 일부로서 또는 그 개인화 데이터에 포함되어 제공된다. 따라서, 임시 파일 시스템은 업데이트 에이전트의 일부로서 실현되기 때문에, 후자는 업데이트 에이전트가 SE 를 제어하고 있는 한, 임시 파일 시스템이 업데이트 에이전트에 의해 관리될 수 있도록 그리고 이에 의해 이용불가능한 정규 파일 시스템을 일시적으로 대체할 수 있도록 임시 파일 시스템을 제공한다. 그 경우, 임시 파일 시스템은 업데이트 에이전트의 암호화 키들의 개인화 과정에서 제공된다. 따라서, 임시 파일 시스템은 보안 엘리먼트의 생산 단계 동안 보안 환경 내에 제공된다.

신뢰되는 업데이트 에이전트에 의해 수행되는, 설치된 오퍼레이팅 시스템을 업데이트하는 프로세스는 반복될 수도 있다. 따라서, 필요한 경우, 이미 업데이트된 오퍼레이팅 시스템이 다시 업데이트된다. 원칙적으로, 설치될 때, 현재 설치된 오퍼레이팅 시스템 및/또는 각각의 개인화 데이터의 업데이트를 제공하는 오퍼레이팅 시스템 이미지는 초기 생산 단계 동안 로딩될 수도 있거나, 또는 그러한 로딩이 변조 방지되는 및 신뢰되는 방식으로 수행된다면 후속 단계에서 로딩될 수도 있다.

어느 경우든, 임의의 시점에서, 업데이트 에이전트는 업데이트될 오퍼레이팅 시스템으로부터 SE 에 대한 제어를 인수하여, 사실상, 이 시점에서 오퍼레이팅 시스템이 더 이상 SE 를 담당하지 않고 그의 프로세싱 및 상호작용을 제어하지 않게 한다. 특히 정규 파일 시스템은 SE 가 정규 오퍼레이팅 시스템의 제어 하에 있지 않는 한 이용가능하지 않기 때문에, 업데이트 에이전트는 임시 파일 시스템을 제공하고 관리함으로써 정규 오퍼레이팅 시스템의 부재 시에 SE 의 다른 제한된 기능을 극복하도록 구성된다. 업데이트 에이전트는 업데이트를 고려하여 오퍼레이팅 시스템이 비활성화될 때 오퍼레이팅 시스템으로부터 제어를 인수한다.

본질적으로, 업데이트 에이전트가 담당하는 경우, 임시 파일 시스템이 관리되고, 따라서 활성화된다. OS 의 업데이트가 완료되자마자, 제어는 업데이트된 OS 로 스위칭하고, 임시 파일 시스템이 더 이상 활성화되지 않는 동안 정규 파일 시스템은 관리되고/활성이 된다.

또한, 현재 오퍼레이팅 시스템이 더 이상 존재하지 않고, 업데이트된 오퍼레이팅 시스템이 아직 SE 를 제어하고 있지 않는 기간에서의 임시 파일 시스템의 이용가능성으로 인해, 본 발명은 임시 파일 시스템이 SE 의 최소한의 기능 및 상호운용성을 보장하여, 외부 단말이 SE 를 비활성화 또는 연결해제하는 것을 방지할 수 있으므로, 현장에서 오퍼레이팅 시스템의 업데이트를 위한 효율적이고 안전한 솔루션을 제공한다. 따라서, 칩 공장에서 SE 의 초기 생산 단계 동안 업데이트 에이전트가 SE 내로 로딩되는 동안, OS 이미지가 SE 내로 로딩될 수도 있고 및/또는 로딩된 OS 이미지가 SE 의 초기 생산 단계 이후, 보안 엘리먼트의 수명 사이클의 후속 단계에서 SE 상에 설치될 수도 있으며, 따라서 보안 엘리먼트의 수명 동안 언제든지 오퍼레이팅 시스템을 업데이트하기 위한 유연한 솔루션을 제공하고 종래의 업데이트 방식들의 단점들을 방지한다.

일부 실시형태들에서, 임시 파일 시스템은 특정 데이터 레코드로서, 바람직하게는 데이터 그룹화 식별자 DGI 에 의해 식별된 데이터 그룹핑으로서 구조화된다. DGI 는 데이터 그룹핑이 어떻게 구성되는지 및 어떻게 액세스되고 프로세싱될 수 있는지를 결정한다. 임시 파일 시스템 및 각각의 DGI 를 나타내는 데이터 그룹핑은, 바람직하게는, SE 의 제조업체에 의해 정의되고 업데이트 에이전트에서 코딩된 독점 구조일 수도 있다. 임시 파일 시스템의 제공시, 각각의 데이터 그룹핑은 DGI 에 의해 식별되는 바와 같은 그 사양에 기초하여 SE 내에서 생성된다. 데이터 그룹핑은, 그 특정된 구조에 따라, SE 의 메모리에, 예를 들어, 그 비휘발성 메모리에 저장된다. 바람직하게는, 임시 파일 시스템을 나타내는 데이터 그룹핑은 업데이트 에이전트의 특정 메모리 구조에 저장된다.

바람직하게는, 데이터 그룹핑은 전용 파일 (DF) 및 기본 파일 (EF) 을 포함하는 ISO/IEC 7816-4 에 따른 계층적 스마트 카드 파일 시스템을 나타내는 내부 구조를 제공한다. 임시 파일 시스템의 DF들 및 EF들은 일시적으로 이용가능하지 않은 정규 파일 시스템의 DF들 및 EF들의 최소 선택을 나타내는 반면, 임시 파일 시스템의 계층적 파일 구조는 임시 파일 시스템이 일시적으로 대체하거나 시뮬레이션하는 정규 파일 시스템의 구조 및 파일들을 반영한다.

바람직하게, 데이터 그룹핑 및 제공되는 계층적 파일 구조는 각각의 파일의 계층적 부모/자식 관계를 반영하는 TLV 포맷 (태그, 길이, 값) 으로 논리적으로 구성된다. 즉, 임시 파일 시스템의 각각의 파일은 TLV 아이템으로서 코딩되고, 파일 타입 (태그), 바이트 크기 (길이) 의 표시 및 각각의 파일의 데이터를 전달하는 지정된 크기의 데이터 필드 (값) 를 식별하는 이진 코드를 갖는다.

업데이트 에이전트가 SE 를 제어하고 있는 동안, 외부 단말이 기본 파일을 향하는 (예를 들어, 커맨드-APDU 에 의해) 커맨드를 SE 에 전송하면, EF 는 각각의 파일을 나타내는 TLV 아이템의 태그에 포인터를 제공함으로써 선택된다. 선택된 파일에 대한 포인터는 업데이트 에이전트에 의해 유지되어, 선택된 파일을 향하는 외부 단말의 커맨드들이 업데이트 에이전트에 의해 프로세싱되고 (예를 들어, 응답-APDU 에 의해) 응답될 수 있다.

업데이트 에이전트가 SE 를 제어하고 있는 동안, 외부 단말이 임시 파일 시스템의 특정 파일과 관련되지 않은 커맨드를 SE 로 전송하면, 업데이트 에이전트는 사실상, 커맨드가 업데이트 에이전트에 의해 프로세싱되지 않거나 또는 프로세싱이 정규 파일 시스템이 이용가능할 때까지 연기되는 동안 커맨드가 프로세싱되는 것을 시그널링하는 상태 코드 또는 상태 바이트에 응답할 수도 있다. 그럼에도 불구하고, 상태 코드는 외부 단말과 비교하여 SE 가 동작가능하고 비활성화될 필요가 없다는 것을 시그널링한다.

본 발명의 제 2 양태에 따르면, 파일 시스템을 관리하는 오퍼레이팅 시스템 및 전술한 바와 같은 방법을 수행하도록 구성된 업데이트 에이전트를 포함하는 보안 엘리먼트가 제공된다. 특히, 업데이트 에이전트는 오퍼레이팅 시스템으로부터 SE 의 제어를 인수하고; 오퍼레이팅 시스템의 업데이트를 나타내는 OS 이미지를 SE 내로 로딩하고; OS 이미지를 설치하고, 그것에 의해 업데이트된 오퍼레이팅 시스템을 제공하고; 마지막으로 SE 의 제어를 업데이트된 오퍼레이팅 시스템으로 핸드오버하도록 구성된다. 외부 단말이 단말의 요청들에 대한 응답의 부족 또는 잘못된 응답으로 인해 보안 엘리먼트를 비활성화 또는 연결해제하는 것을 방지하기 위해, 업데이트 에이전트는 SE 에 임시 파일 시스템을 제공하거나 제공하도록 구성되고, 업데이트 에이전트가 SE 를 제어하고 있는 기간 동안, 즉 업데이트된 오퍼레이팅 시스템이 SE 에 대한 제어를 인수하고 그것의 정규 기능성 및 상호운용성을 제공할 때까지 임시 파일 시스템을 관리하도록 구성되다.

본 발명의 제 3 양태에 따르면, 상기 명시된 바와 같은 방법을 수행하도록 구성되는 업데이트 에이전트가 제공된다. 업데이트 에이전트는, 바람직하게는, 본 발명의 제 1 양태 하에 개시된 바와 같은 방법을 수행하기 위해, 제 2 양태 하에 개시된 바와 같은 보안 엘리먼트 상에 설치되고 보안 엘리먼트의 프로세서에 의해 실행되도록 구성된 실행가능한 소프트웨어 제품으로서 실현된다.

본 발명의 또 다른 양태에 따르면, 보안 엘리먼트가 내장되거나 내장될 수 있는 전자 디바이스에서 제 2 양태에 따른 보안 엘리먼트와 함께 사용하기 위한 컴퓨터 프로그램이 제공된다. 컴퓨터 프로그램 제품은 전자 디바이스 내의 보안 엘리먼트 내로 소프트웨어를 로딩하기 위해 비일시적 컴퓨터 판독가능 저장 매체 및 내장된 컴퓨터 프로그램 메커니즘을 포함한다. 컴퓨터 프로그램 메커니즘은, 오퍼레이팅 시스템으로부터 SE 의 제어를 인수하기 위한 명령들; 오퍼레이팅 시스템의 업데이트를 나타내는 OS 이미지를 SE 내로 로딩하기 위한 명령들; OS 이미지를 설치함으로써 업데이트된 오퍼레이팅 시스템을 제공하기 위한 명령들; 업데이트 에이전트에 의한 SE 의 제어를 업데이트된 오퍼레이팅 시스템으로 핸드오버 하기 위한 명령들; 및 SE 에 임시 파일 시스템을 제공하고 업데이트 에이전트가 SE 의 제어하고 있는 한 임시 파일 시스템을 관리하기 위한 명령들을 포함한다.

본 출원에서 설명된 모든 프로세스들, 디바이스들, 엘리먼트들, 유닛들 및 수단들은 소프트웨어 또는 하드웨어 엘리먼트들 또는 이들의 조합으로 구현될 수 있다는 점에 유의해야 한다. 본 출원에서 설명된 다양한 엔티티들에 의해 수행되는 모든 단계들 뿐만 아니라 설명된 기능들은 각각의 엔티티가 각각의 단계들 및 기능들을 수행하도록 적응되거나 구성된다는 것을 의미하는 것으로 의도된다.

본 발명의 추가 양태들, 특징들, 및 장점들은, 첨부 도면들과 연계한 본 발명의 바람직한 실시형태들 및 변형들의 이하 상세한 설명을 검토하면, 당업자들에게 자명해질 것이다.

이제 첨부된 도면들을 참조할 것이다:
도 1 은 업데이트 에이전트를 갖는 보안 엘리먼트의 종래의 생산 흐름의 개략적인 표현을 도시한다.
도 2 는 본 발명의 바람직한 실시형태에 따른 보안 엘리먼트의 구조를 도시한다.
도 3 은 본 발명에 따른 임시 파일 시스템의 바람직한 구조 및 외부 단말과 보안 엘리먼트의 통신을 도시한다.
도 4 는 본 발명에 따른 방법을 예시하는 흐름도를 도시한다.

본 발명의 구체적인 실시형태 예들을 예시하는 첨부된 도면들을 참조하여 본 발명의 상세한 설명이 아래에 제공된다. 이들 실시형태들은 당업자가 본 발명을 실시할 수 있도록 충분히 상세하게 설명된다. 본 발명의 다양한 실시형태들은 상이하지만, 반드시 상호 배타적인 것은 아님을 이해해야 한다. 예를 들어, 일 실시형태와 관련하여 본 명세서에 설명된 특정한 피처, 구조 또는 특징은 본 발명의 범위로부터 벗어나지 않고 다른 실시형태들 내에서 구현될 수도 있다. 또한, 각각의 개시된 실시형태 내의 개별 엘리먼트들의 위치 또는 배열은 본 발명의 범위를 벗어나지 않고 수정될 수도 있다는 것이 이해되어야 한다. 그러므로, 이하의 상세한 설명은 제한적 의미로 취해지지 않으며, 본 발명의 범위는 청구항들이 부여되는 등가물들의 전체 범위와 함께, 적절하게 해석되는 첨부된 청구항들에 의해서만 정의된다. 도면들에서, 동일한 부호는 여러 도면에 걸쳐 동일하거나 유사한 기능을 지칭한다.

도 2 는 바람직한 실시형태에 따른 보안 엘리먼트 (SE) (100) 의 구조를 보다 상세하게 나타낸다. SE (100) 의 업데이트 에이전트 (10) 에 의해 관리되는 임시 파일 시스템 (12) 뿐만 아니라 SE (100) 와 외부 단말 (200) 사이의 상호작용이 도 3 에 도시된다. 결과적으로, 도 4 는 도 2 및 도 3 과 관련하여, 본 발명에 따른 방법의 단계들을 도시한다.

도 2 에 도시된 SE (100) 는 업데이트 에이전트 (10), 오퍼레이팅 시스템 (OS) (30) 및 프로세서 (CPU) (40) 를 포함하는 변조 방지 엘리먼트 (TPE) 이다. 업데이트 에이전트 (10) 와 OS (30) 양자는 SE (100) 의 메모리, 예컨대 비휘발성 메모리 (50) 에 저장될 수도 있다. OS (30) 및 업데이트 에이전트 (10) 는 적절한 인터페이스, 예를 들어 애플리케이션 프로그래밍 인터페이스 (API) 를 통해 서로 통신할 수 있는 독립적인 엔티티들이다. 메모리 (50) 는 SE (100) 상에 업로드되어 설치되고 CPU (40) 에 의해 실행가능한 소프트웨어를 저장하는 SE (100) 의 메모리이다. 이러한 설치된 소프트웨어는 SE (100) 에 특정 기능을 제공하는 실행가능한 애플리케이션 또는 프로그램일 수도 있거나, 심지어 보안 엘리먼트 (100) 의 OS (30) 일 수도 있다. OS (30) 는 예를 들어, 자바 카드 플랫폼 기반의 표준 스마트 카드 오퍼레이팅 시스템이다. 개인화 데이터 (13) 에 의해 개인화된 OS (30) 는 도 1 에서 "maxInit" 로 식별된다. SE (100) 상에 설치된 임의의 다른 소프트웨어와 마찬가지로, OS (30) 는 또한 SE (100) 의 수명 사이클의 특정 지점에서 업데이트될 필요가 있을 수도 있다.

업데이트 에이전트 (10) 는 SE (100) 내의 (예를 들어, 사용 케이스 의존 펌웨어와 같은) 소프트웨어의 프로비저닝을 허용하는 독립형 로더 엔티티 또는 오퍼레이팅 시스템 (30) 의 기능 모듈일 수도 있다. 이러한 로더 엔티티들은 또한 당업계에서 ITL (Image Trusted Loader) 로 지칭된다. 도 1 내지 도 3 에서 도면 부호 10 으로 식별된 것과 같은 업데이트 에이전트들은 보안 엘리먼트 (100) 내로 소프트웨어 또는 소프트웨어 이미지들을 로딩하는 것은 물론, 설치된 소프트웨어의 업데이트, 복원 또는 롤백 (rollback) 과 같은 관련된 임의의 다른 절차를 담당하는 주요 엔티티들이다. 도 2 에서 OS (30) 를 업데이트하기 위한 소프트웨어 이미지는 도면 부호 31 로 나타낸다. OS 이미지 (31) 는 SE (100) 상에 업로드되어 SE (100) 의 비휘발성 메모리, 예를 들어 메모리 (50) 에 저장되었다. 업데이트 에이전트 (10) 는 또한 공장 생산 (도 4 의 단계 S1 참조) 동안 SE (100) 상에 로딩되었는데, 그 이유는 SE (100) 의 보안에 중요한 엔티티를 반영하기 때문이다.

업데이트 에이전트 (10) 는 메모리 구조 (11) 의 형태로 그 자신의 예약된 메모리 공간을 포함하여, 그 위에 감지가능한 데이터, 예를 들어 개인화 데이터 및/또는 인증 데이터를 저장할 수도 있으며, 후자는 그것이 개인화되기 전에 OS 이미지 (31) 와 같은 소프트웨어 이미지를 인증 및/또는 복호화하는데 사용된다.

SE (100) 에 의해 사용, 생성 및 프로세싱되는 데이터는 임의의 다른 컴퓨터 엔티티에서와 같이, 그 컴퓨터 엔티티의 오퍼레이팅 시스템 (30) 에 의해 관리되는 파일 시스템 (32) 의 형태로 논리적으로 구성된다. 보안 및 변조 방지 엘리먼트와 같은 스마트 카드의 맥락에서, 파일 시스템은 ISO/IEC 7816-9 에 따라 구성될 수도 있다. 따라서, 스마트 카드 파일 시스템 (32) 은 루트 엘리먼트가 마스터 파일 (MF) 이고 리프 엘리먼트들이 전용 디렉토리 파일들 (DF) 및 기본 데이터 파일들 (EF) 인 트리 구조를 가정하며, 후자는 스마트 카드 또는 보안 엘리먼트 (100) 의 애플리케이션들에 의해 요구되는 모든 데이터를 포함한다.

도 2 및 도 3 에 도시된 외부 단말 (200) 은 보안 엘리먼트 (100) 와 통신하는 엔티티를 나타낼 수도 있다. 이는 LPA (Local Profile Assistant), 서버, 또는 SE (100) 가 연결될 수도 있는 임의의 디바이스일 수 있다. 특히, 외부 단말 (200) 은 이미지 전달 서버이거나 이를 포함하고, 후속 생산 단계 (도 1, 단계 II, III, IV) 동안 OS 이미지 (31) 를 커스터마이즈드 인터페이스를 통해 제공한다. 보다 넓게 말하면, 도 2 및 도 3 의 단말 (200) 은 SE (100) 가 접속되는 네트워크를 나타내며, 때때로 본 기술 분야에서 "광대역" 인프라로 지칭된다.

보안 엘레먼트 (100) 와 외부 단말 (200) 간의 상호작용 및 메시지 교환은 ISO/IEC 7816-12 에 따라 구성될 수도 있으며, APDU 컨테이너 메시지들 (Application Protocol Data Unit) 로 구성된다. 이에 따라, 단말 (200) 은 커맨드 (14) (cmd), 이른바 커맨드-APDU 또는 C-APDU 를 전송할 수도 있고, OS (30) 로부터 응답 (15) (rsp), 이른바 응답-APDU 또는 R-APDU 를 단말의 요청에 대한 응답으로 수신할 수도 있다.

도 2 에 예시된 상태의 SE (100) 는 초기 칩 생산을 완료하고 (도 1, 단계 I), 칩 제조업체의 인증된 환경을 벗어나 후속 생산 단계 (도 1, 단계 II, II, 또는 IV) 로 진행한다. 이러한 상황에서, 개인화 데이터 (13) 는 SE (100) 상에 업로드되었고 (도 4 의 단계 S2 참조), OS 이미지 (31) 는 메모리 (50) 내로 업로드되었으며 (도 4 의 단계 S4 참조), 후자는 SE (100) 의 새로운 업데이트된 오퍼레이팅 시스템 (30) 으로서 업데이트 에이전트 (10) 에 의해 설치된다.

이 상황에서, OS (30) 는 업데이트 동안 이용가능하지 않고, 따라서 적어도 일시적으로 파일 시스템 (32) 을 관리하는 것 또는 단말 (200) 로부터 수신된 커맨드들 (14) 을 프로세싱하는 것과 관련하여 그 통상적인 기능성 및 상호운용성을 제공할 수 없다. 따라서, 업데이트 에이전트 (10) 는 OS (30) 로부터 SE (100) 의 제어를 인수한다. OS 업데이트 동안 SE (100) 를 담당할 때, 업데이트 에이전트 (10) 는 임시 파일 시스템 (12) 을 제공함으로써 SE (100) 의 동작가능성을 유지하며, 그럼에도 불구하고 단말 (200) 이 커맨드들 (14) 에 대한 반응으로 유의미한 응답들 (15) 을 수신하고 이러한 응답들의 부족으로 인해 SE (100) 가 단말 (200) 에 의해 비활성화되거나 연결해제되지 않도록 보장한다.

도 4 는 OS 이미지 (31) 에 의해 보안 엘리먼트 (100) 내의 설치된 OS (30) 를 업데이트하기 위한 방법의 주요 단계들의 흐름도를 도시한다. 방법의 단계들은 도 2 에 도시된 SE (100) 및 도 3 에 도시된 상세도를 참조하여 상세히 설명된다.

이하에서 설명되는 바와 같이, 본 발명에 따른 방법은 오퍼레이팅 시스템 업데이트의 특정 상황에 제한되지 않는다. 실제로, SE 동작의 추가 중단들 또는 오퍼레이팅 시스템 또는 다른 중요한 신뢰되는 소프트웨어의 중간 비-기능 상태는 본 발명에 따라 처리될 수 있어서, 외부 단말 (200) 또는 이러한 SE (100) 와 통신하는 다른 엔티티가 중단 또는 상태 트랜지션에 의해 영향을 받지 않지만, SE (100) 의 적절하고, 응답적이며, 잘-정의된 거동을 계속해서 경험하게 된다.

단계들 S1, S1a 및 S2 는 SE (100) 의 공장 생산 단계 동안 인증된 환경 내에서 수행되어, 그의 소프트웨어 컴포넌트들 및 데이터의 보안 및 인증을 보장한다. 단계들 S3 내지 S6 은 칩 제조업체의 인증된 환경 밖에서, 후속 단계 II, 또는 III 에서, 또는 훨씬 나중에 수행될 수 있는 OS 업데이트 프로세스를 나타낸다 (도 1 참조).

도 3 을 참조하면, 초기 칩 생산 단계 (I) 에서 수행되는 제 1 단계 (S1) 에서, 업데이트 에이전트 (10) 는 아마도 SE (100) 상에 업로드함으로써 SE (100) 에 제공된다. 업데이트 에이전트 (10) 는 공장 생산 단계 (I) 동안 칩 제조업체의 인증된 환경 내에서 SE (100) 상에 로딩되는 SE (100) 의 보안 중요 엔티티를 반영한다.

별개의 단계로서 구현될 수도 있거나 또는 단계 S1 에서 SE (100) 에 업데이트 에이전트 (10) 를 제공하는 부분일 수도 있는 단계 S1a 에서, 임시 파일 시스템 (12) 은 SE (100) 에 제공된다. 임시 파일 시스템 (12) 은 업데이트 에이전트 (10) 자신의 개인화의 일부이며, 이것은 단계 S1 의 과정에서 동작가능한 업데이트 에이전트 (10) 를 프로비저닝하는 기능적 결과일 수도 있다. 특히, 임시 파일 시스템 (12) 은 업데이트 에이전트 (10) 가 그의 크리덴셜들 및 암호 키들을 제공하는 것과 동일한 방식으로 제공된다.

제 2 단계 S2 에서, 개인화 데이터 (13) 가 SE (100) 상에 업로드된다. 개인화 데이터 (13) 는 보안에 매우 중요하고, 특히 크리덴셜들 및 암호 키들을 포함한다. 공장 생산 단계 (I) 동안, 신뢰된 소프트웨어, 예를 들어 SE (100) 의 초기 오퍼레이팅 시스템 (30) 이 SE (100) 상에 업로드되고 설치된다. 초기 설치 과정에서, 업로드된 오퍼레이팅 시스템은 개인화 데이터 (13) 를 사용하여 개인화되고, 도 1 에서 "maxInit" 로 지칭되는 동작 오퍼레이팅 시스템 (30) 이 렌더링된다.

후속 생산 단계 II, III, IV 에서 칩 제조업체의 인증된 환경 외부에서 OS 이미지 (31) 에 의해 설치된 OS (30) 를 업데이트하기 위해, 업데이트 에이전트 (10) 는 단계 S3 에서 OS (30) 로부터 SE (100) 에 대한 제어를 인수한다. 단계 S4 에서, OS 이미지 (31) 는 업데이트 에이전트 (10) 에 의해 메모리 (50) 내로 업로드된다. OS 이미지 (31) 는 SE (100) 상에 업데이트될 소프트웨어의 이미지들을 제공하는 것을 담당하는 전용 소프트웨어 이미지 서버 또는 단말 (200) 에 의해 제공될 수도 있다.

이 때, OS (30) 대신, 업데이트 에이전트 (10) 가 특히 SE 의 단말 (200) 과의 통신을 담당한다. 또한, SE (100) 의 OS (30) 에 의해 주로 관리되는 정규 파일 시스템 (32) 은 더 이상 사용할 수 없고, 파일 시스템 (32) 의 전용 파일 (DF) 또는 기본 파일 (EF) 에 관련된 동작들은 프로세싱될 수 없다. 이는 한편으로는, OS (30) 가 일시적으로 담당하지 않고, 다른 한편으로는, 정규 파일 시스템 (32) 이 파일 시스템 (32) 과 관련된 단말기 (200) 로부터의 요청들 또는 커맨드들 (14) 을 프로세싱하기 위해 업데이트 에이전트 (10) 에 이용가능하지 않기 때문이다.

유의미한 응답 (15) 의 부족으로 인해 SE (100) 가 단말 (200) 에 의해 비활성화되는 것을 방지하기 위해, 단계 S1a 에서, 오퍼레이팅 시스템 (30) 이 업데이트되고 다시 완전히 담당할 때까지 정규 파일 시스템 (32) 을 대체할 수도 있는 임시 파일 시스템 (12) 이 제공된다.

대안적인 실시형태들에 따르면, 단계 S3 및 S4 는 도 4 에 도시된 것과 비교하여 상이한 순서로 수행될 수 있다. 예를 들어, OS 이미지 (31) 는 업데이트 에이전트 (10) 가 OS (30) 로부터 제어를 인수하기 전에 업로드될 수도 있다. 그러나, 어느 경우이든지, 임시 파일 시스템 (12) 은 업데이트 에이전트 (10) 가 SE (100) 의 제어를 인수하기 전에 제공되는데, 이는 전자는 생산 단계 I 동안 발생하는 반면 후자는 단계 I 에 후속하는 나중의 생산 단계에서 발생하기 때문이다.

마찬가지로, 정규 파일 시스템 (32) 이 더 이상 이용가능하지 않은 단계들 S3 및 S4 의 과정 동안의 정확한 시점은 변화할 수도 있다. 도 3 의 실시형태에 따르면, 단계 S3 에서 업데이트 에이전트 (10) 가 제어를 인수함으로써 파일 시스템 (32) 이 이용가능하지 않은 것으로 가정되지만, 다른 실시형태들에 따르면, 파일 시스템 (32) 은 OS 이미지의 설치가 실제로 시작될 때, 단계 S4 에서 OS 이미지가 업로드될 때 또는 심지어 그 후에 이용가능하지 않을 수도 있다.

도 3 은 단계 S1a 에서 업데이트 에이전트 (10) 에 의해 제공되고 메모리 구조 (11) 에 저장되는 임시 파일 시스템 (12) 의 바람직한 실시형태를 도시한다. 도 3 은 또한 단계 S5 에 따른 업데이트 에이전트 (10) 에 의한 임시 파일 시스템 (12) 의 관리 및 SE (100) 와 단말 (200), 또는 SE (100) 가 연결된 네트워크 또는 광대역 기반구조 각각 사이에 APDU 메시지들 (14, 15) 의 교환을 도시한다.

논리적으로, 도 3 의 임시 파일 시스템 (12) 은 데이터 그룹핑 식별자 (DGI) 에 의해 식별된 데이터 그룹핑으로서 실현된다. 스마트 카드 컨텍스트에서, 데이터 그룹핑은 그 DGI 에 의해 구조가 특정되는 데이터 레코드이다. 그러므로, 데이터 그룹핑의 DGI 를 참조함으로써, 업데이트 에이전트 (10) 와 같은 애플리케이션은 데이터 그룹핑의 내부 구조를 인식할 수 있고, 그룹핑의 특정 데이터 아이템들, 예를 들어, 임시 파일 시스템 (12) 의 DF 또는 EF 파일들을 액세스하거나 프로세싱할 수 있다. 바이트 레벨에서, 임시 파일 시스템 (12) 을 나타내는 데이터 그룹핑은 TLV 포맷으로 실현되고, 이에 따라 임시 파일 시스템 (12) 의 임의의 파일은 TLV 구조의 타입을 제공하는 리딩 태그 바이트 (T), 이어서 특정 TLV 구조에 의해 저장된 데이터의 바이트 크기를 제공하는 2 개의 길이 바이트들 (L), 및 실제 사용 데이터 또는 값을 저장하는 특정 수의 바이트들 (V) 로 구성된 바이트 시퀀스로 표현된다.

도 3 에 도시된 임시 파일 시스템은 업데이트 에이전트 (10) 에 의해 제공되어, 일시적으로 대체하거나 시뮬레이션하는 이용가능하지 않은 파일 시스템 (32) 의 최소 수의 파일들을 커버한다. 따라서, 임시 파일 시스템 (12) 을 나타내는 데이터 구조는 마스터 파일 (MF) 로 시작하고, 기본 파일 (EF1) 및 추가적인 전용 및 기본 파일들의 시퀀스가 뒤따르며, 그 중 기본 파일 (EFn) 은 전용 파일 (DF) 내에 논리적으로 놓여 있다. 이 TLV 구조 내에 표현된 파일들은 그것이 또한 어떤 기본 파일들 (EF) 이 전용 파일 (DF) 내에 논리적으로 위치하는지 또는 그 경우를 반영한다는 점에서 정규 파일 시스템 (32) 의 계층적 부모/자식 구조를 관찰한다. 파일 시스템의 계층 구조는 전용 파일 (DF) 의 태그 (T) 에 코딩될 수도 있다.

단계 S5 에서 임시 파일 시스템 (12) 의 관리의 필수적인 부분으로서, 업데이트 에이전트 (10) 는 컨텍스트로도 알려진 현재 선택된 파일, 즉 다음 커맨드에 의해 조종될 특정 파일을 나타내는 포인터 (pt) 를 유지한다.

초기에 마스터 파일 (MF) 이 선택되는 도 3 의 임시 파일 시스템 (12) 이 주어지면, 단말 (200) 은 예를 들어, 파일 (EFn) 의 선택을 지시하는 C-APDU (14) 를 전송할 것이다. 업데이트 에이전트 (10) 가, 단계 S3 에서 SE (100) 의 제어를 인수받은 후에, 임시 파일 시스템 (12) 을 관리하지 않는다면, OS (30) 및 파일 시스템 (32) 의 이용불가능성으로 인해, 커맨드 (14) 가 프로세싱되지 않고 적절하게 응답되지 않을 것이다. 실제로, 단말 (200) 은 SE (100) 를 비활성화시킬 것이다.

그러나, 단계 S1a 에서 임시 파일 시스템 (12) 을 제공하고 단계 S5 에서 그것을 관리하는 것은 SELECT 커맨드 (14) 의 적절한 프로세싱 및 응답을 허용한다. 첫 번째로, 업데이트 에이전트 (10) 는 포인터 (pt) 가 마스터 파일 (MF) 로부터 단말 (200) 에 의해 선택된 기본 파일 (EFn) 을 가리키도록 이동되는 컨텍스트 변경을 호출한다. 두 번째로, 성공적인 컨텍스트 변경이 업데이트 에이전트 (10) 에 의해 단말 (200) 로, 요청된 컨텍스트 변경이 수행되었음을 나타내는 적절한 상태 코드 (SW), 예를 들어 상태 코드 '9000' 를 전달하는 R-APDU (15) 를 통해 보고된다. 즉, 정규 파일 시스템 (32) 의 원본 파일 (EFn) 이 사용가능하지 않더라도, 단말 (200) 은 임시 파일 시스템 (12) 의 파일 (EFn) 에 기초하여 유의미한 응답 (15) 을 수신한다.

또한, 단말 (200) 에 의한 요청이 업데이트 에이전트 (100) 에 의해 성공적으로 프로세싱될 수 없는 경우에도, 예를 들어, 정규 파일 시스템 (32) 에 존재하지만 임시 파일 시스템 (12) 의 일부로서 생성되지 않은 파일 (EFx) 을 선택하는 커맨드 (14) 의 경우에도, 업데이트 에이전트 (10) 는 커맨드 (14) 를 캡처하고, SE (100) 가 비활성화되는 것을 방지하기 위해 단말 (200) 에 의해 해석가능한 적절한 '에러 코드' 에 응답한다.

임시 파일 시스템 (12) 의 특정 파일에 관련되지 않은 단말 (200) 의 커맨드들 (14) 은 표준 상태 코드가 응답된다는 점에서 업데이트 에이전트 (10) 에 의해 프로세싱되는 반면, 이러한 커맨드 (14) 는 단계 S6 에서 SE (100) 의 제어를 회복하면, 전체적으로 무시되거나 OS (30) 에 의한 이후의 프로세싱을 위해 등록된다.

메모리 소비와 다용성 및 정도의 균형을 맞추기 위해, 업데이트 에이전트 (10) 는 외부 단말 (200) 의 커맨드들 (14) 을 가능한 많이 프로세싱하기 위한 최소 기능 및 최소 데이터만을 커버하는 임시 파일 시스템 (12) 을 제공한다. 명백하게, 단말 (200) 이 도 3 에서 선택하도록 명령한 파일 EFx 는, 정규 파일 시스템 (32) 에 존재할 수도 있지만, 명백하게, 임시 파일 시스템 (12) 이 제공하기로 되어 있는 최소 기능에 기여하지 않기 때문에 임시 파일 시스템 (12) 의 프로비저닝시에 남겨진다. 일반적으로, 임시 파일 시스템 (12) 은 단말 (200) 이 오퍼레이팅 시스템 (30) 및 파일 시스템 (32) 양자의 시간적 이용불가능성을 인지하지 않도록 설계된다.

단계 S5 에서, 임시 파일 시스템 (12) 이 관리되어 오퍼레이팅 시스템 (30) 의 이용불가능성이 단말기 (200) 에 투명하게 되는 동안, 단계 S4 에서 비휘발성 메모리 (50) 내로 업로드된 OS 이미지 (31) 는 단계 S5a 에서 업데이트 에이전트 (10) 에 의해 새로운, 업데이트된 오퍼레이팅 시스템 (30) 이 되도록 설치된다. OS (30) 의 설치는 다양한 단계들 및 프로세스들을 수반할 수 있으며, 그 중에서 단계 S2 에서 업데이트 에이전트 (10) 의 메모리 구조 (11) 내로 업로드된 개인화 데이터 (13) 를 사용하여 OS 이미지 (31) 를 개인화한다.

마지막으로, OS 업데이트가 완료되면, 업데이트 에이전트 (10) 는 단계 S6 에서 SE (100) 의 제어를 업데이트된 OS (30) 로 다시 핸드오버할 수도 있다. 이 시점에서, 단말 (200) 로부터의 커맨드들 (14) 은 단계 (S6) 에서 제어를 핸드오버한 결과로서 복귀되는 정규 파일 시스템 (32) 에 기초하여 업데이트된 OS (30) 에 의해 프로세싱되고 응답된다.

본질적으로, 임시 파일 시스템 (12) 은 정규 파일 시스템 (32) 의 제한된 시뮬레이션으로서, 또는 심지어 업데이트 에이전트 (10) 가 OS (30) 를 대체하고 정규 파일 시스템 (32) 의 전체 범위에 액세스하지 않고 SE 를 담당하는 한, SE (100) 와 단말 (200) 사이의 상호작용이 유지될 수 있는 정도로만 요구되는, 그의 '모의 버전' 으로서 간주될 수 있다.

상기 실시형태들을 통해 설명된 바와 같은 방법들 및 장치는 칩 제조업체의 사이트의 인증된 환경 외부에서 신뢰된 소프트웨어 이미지를 개인화하기 위한 효율적이고 안전한 솔루션을 제공한다. 소프트웨어 이미지를 차후 단계 및 칩 제조업체의 환경 외부에서 개인화할 수 있기 때문에, 보안 엘리먼트의 수명 사이클 동안 언제든지 소프트웨어를 개인화하기 위한 유연한 솔루션이 제공된다.

전술한 명세서에 있어서, 본 발명은 그 특정 실시형태들을 참조하여 설명되었다. 하지만, 다양한 수정들 및 변경들이 본 발명의 더 넓은 범위로부터 일탈함없이 행해질 수도 있음이 명백할 것이다. 예를 들어, 상기 설명된 프로세스 플로우들은 프로세스 액션들의 특정 순서화를 참조하여 설명된다. 하지만, 다수의 설명된 프로세스 액션들의 순서화는 본 발명의 범위 또는 동작에 영향을 주지않고 변경될 수도 있다. 명세서 및 도면들은, 이에 따라, 제한적 의미보다는 예시적으로 간주될 것이다.

Claims (15)

1. 보안 엘리먼트 (SE) (100) 에서 파일 시스템 (32) 을 관리하는 오퍼레이팅 시스템 (OS) (30) 을 업데이트하기 위한 방법으로서,
   - 상기 SE (100) 에 업데이트 에이전트 (10) 를 제공하는 단계 (S1);
   - 상기 오퍼레이팅 시스템 (30) 으로부터 상기 업데이트 에이전트 (10) 에 의해 상기 SE (100) 의 제어를 인수하는 단계 (S3);
   - OS 이미지 (31) 를 상기 SE (100) 내로 로딩하는 단계 (S4) 로서, 상기 OS 이미지 (31) 는 상기 오퍼레이팅 시스템 (30) 의 업데이트를 나타내는, 상기 OS 이미지 (31) 를 로딩하는 단계 (S4);
   - 상기 OS 이미지 (31) 를 설치함으로써 업데이트된 오퍼레이팅 시스템 (30) 을 제공하는 단계 (S5a); 및
   - 상기 업데이트 에이전트 (10) 에 의한 상기 SE (100) 의 제어를 상기 업데이트된 오퍼레이팅 시스템 (30) 으로 핸드오버하는 단계 (S6)
   를 포함하고,
   상기 업데이트 에이전트 (10) 는 상기 SE (100) 에 임시 파일 시스템 (12) 을 제공 (S1a) 하고, 상기 업데이트 에이전트 (10) 가 상기 SE (100) 를 제어하고 있는 한, 상기 임시 파일 시스템 (12) 을 관리 (S5a) 하는 것을 특징으로 하는 오퍼레이팅 시스템을 업데이트하기 위한 방법.
2. 제 1 항에 있어서,
   상기 업데이트 에이전트 (10) 는 외부 단말 (200) 의 커맨드들을 프로세싱하기 위해 필요한 최소 기능을 포함하도록 상기 임시 파일 시스템 (12) 을 제공 (S1a) 하는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
3. 제 1 항 또는 제 2 항에 있어서,
   상기 업데이트 에이전트 (10) 는, 상기 SE (100) 에 전송된 커맨드에 반응하여 상기 SE (100) 가 외부 단말 (200) 에 의해 비활성화 및/또는 연결해제되지 않도록, 상기 임시 파일 시스템 (12) 을 제공 (S1a) 하는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
4. 제 1 항 내지 제 3 항 중 어느 한 항에 있어서,
   상기 업데이트 에이전트 (10) 는, 상기 업데이트 에이전트 (10) 가 상기 SE (100) 를 제어하고 있는 한 상기 오퍼레이팅 시스템 (30) 및/또는 상기 파일 시스템 (32) 이 이용가능하지 않다는 것이 외부 단말 (200) 에 투명하도록, 상기 임시 파일 시스템 (12) 을 제공 (S1a) 하는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
   상기 업데이트 에이전트 (10) 는 상기 업데이트 에이전트 (10) 의 메모리 구조 (11) 에 상기 임시 파일 시스템 (12) 을 제공 (S1a) 하는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
6. 제 1 항 내지 제 5 항 중 어느 한 항에 있어서,
   상기 업데이트 에이전트 (10) 는 데이터 그룹핑 식별자 (DGI) 를 갖는 데이터 그룹핑으로서, 그리고 상기 파일 시스템 (32) 의 부모/자식 파일 관계를 유지하는 TLV 포맷으로 상기 임시 파일 시스템 (12) 을 제공 (S1a) 하는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
7. 제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
   상기 업데이트 에이전트 (10) 는, 예를 들어, 외부 단말 (200) 로부터 수신된 파일-관련 커맨드 (14) 에 반응하여 상기 임시 파일 시스템 (12) 의 선택된 파일 (EFn) 에 포인터 (pt) 를 유지하고, 및/또는 외부 단말 (200) 로부터 수신된 파일-비관련 커맨드 (14) 에 반응하여 상태 바이트 (SW) 를 응답 (15) 하는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
8. 제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
   상기 업데이트 에이전트 (10) 는 상기 SE (100) 의 생산 단계 (I) 동안 상기 업데이트 에이전트 (10) 를 상기 SE (100) 내로 로딩 (S1) 함으로써 제공되는 반면, 상기 OS 이미지 (31) 는 상기 SE (100) 의 생산 단계 (I) 이후에 후속 단계 (II, III, IV) 에서 상기 SE (100) 내로 로딩 (S4) 되고 상기 SE (100) 상에 설치 (S5a) 되는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
9. 제 1 항 내지 제 8 항 중 어느 한 항에 있어서,
   상기 임시 파일 시스템 (12) 은, 바람직하게는 상기 업데이트 에이전트 (100) 의 개인화 데이터에 포함된 상기 업데이트 에이전트 (100) 의 일부로서, 및/또는 상기 SE (100) 의 생산 단계 (I) 동안 상기 업데이트 에이전트 (10) 를 상기 SE (100) 내로 로딩 (S1) 할 때, 제공 (S1a) 되는, 오퍼레이팅 시스템을 업데이트하기 위한 방법.
10. 파일 시스템 (32) 을 관리하는 오퍼레이팅 시스템 (OS) (30) 및 업데이트 에이전트 (10) 를 포함하는 보안 엘리먼트 (100) 로서, 상기 업데이트 에이전트 (10) 는,
    - 상기 오퍼레이팅 시스템 (30) 으로부터 SE (100) 의 제어를 인수하고;
    - OS 이미지 (31) 를 상기 SE (100) 내로 로딩하는 것으로서, 상기 OS 이미지 (31) 는 상기 오퍼레이팅 시스템 (30) 의 업데이트를 나타내는, 상기 OS 이미지 (31) 를 로딩하고;
    - 상기 OS 이미지 (31) 를 설치함으로써 업데이트된 오퍼레이팅 시스템 (30) 을 제공하며; 그리고
    - 상기 업데이트 에이전트 (10) 에 의한 상기 SE (100) 의 제어를 상기 업데이트된 오퍼레이팅 시스템 (30) 으로 핸드오버하도록
    구성되고,
    상기 업데이트 에이전트 (10) 는 추가로, 상기 SE (100) 에 임시 파일 시스템 (12) 을 제공하고, 상기 업데이트 에이전트 (10) 가 상기 SE (100) 를 제어하고 있는 한 상기 임시 파일 시스템 (12) 을 관리하도록 구성되는 것을 특징으로 하는 오퍼레이팅 시스템 및 업데이트 에이전트를 포함하는 보안 엘리먼트.
11. 제 10 항에 있어서,
    상기 업데이트 에이전트 (10) 는 상기 보안 엘리먼트 (100) 의 프로세서 (40) 에 의해 실행될 때 제 1 항 내지 제 9 항 중 어느 한 항에 기재된 방법을 수행하도록 구성되는, 오퍼레이팅 시스템 및 업데이트 에이전트를 포함하는 보안 엘리먼트.
12. 보안 엘리먼트 (100) 에서 사용하기 위한 업데이트 에이전트 (10) 로서,
    - 오퍼레이팅 시스템 (30) 으로부터 SE (100) 의 제어를 인수하고;
    - OS 이미지 (31) 를 상기 SE (100) 내로 로딩하는 것으로서, 상기 OS 이미지 (31) 는 상기 오퍼레이팅 시스템 (30) 의 업데이트를 나타내는, 상기 OS 이미지 (31) 를 로딩하고;
    - 상기 OS 이미지 (31) 를 설치함으로써 업데이트된 오퍼레이팅 시스템 (30) 을 제공하며; 그리고
    - 상기 업데이트 에이전트 (10) 에 의한 상기 SE (100) 의 제어를 상기 업데이트된 오퍼레이팅 시스템 (32) 으로 핸드오버하도록
    구성되고,
    상기 업데이트 에이전트 (10) 는 추가로, 상기 SE (100) 에 임시 파일 시스템 (12) 을 제공하고, 상기 업데이트 에이전트 (10) 가 상기 SE (100) 를 제어하고 있는 한 상기 임시 파일 시스템 (12) 을 관리하도록 구성되는 것을 특징으로 하는 보안 엘리먼트에서 사용하기 위한 업데이트 에이전트.
13. 제 12 항에 있어서,
    상기 업데이트 에이전트 (10) 는 제 1 항 내지 제 9 항 중 어느 한 항에 기재된 방법을 수행하도록 구성되고, 및/또는 제 10 항 또는 제 11 항에 기재된 보안 엘리먼트 (100) 상에 설치되고 상기 보안 엘리먼트 (100) 의 프로세서 (40) 에 의해 실행되도록 구성된 실행가능한 소프트웨어 제품으로 구현되는, 보안 엘리먼트에서 사용하기 위한 업데이트 에이전트.
14. 제 10 항 또는 제 11 항에 기재된 보안 엘리먼트에 있어서, 또는 제 12 항 또는 제 13 항에 기재된 업데이트 에이전트에 있어서, 상기 업데이트 에이전트 (10) 는,
    외부 단말 (200) 의 커맨드들 (14) 을 프로세싱하는데 필요한 최소 기능을 포함하도록 및/또는 상기 SE (100) 로 전송된 커맨드들 (14) 에 반응하여 상기 SE (100) 가 외부 단말 (200) 에 의해 비활성화 및/또는 연결 해제되지 않도록 및/또는 상기 업데이트 에이전트 (10) 가 상기 SE (100) 를 제어하고 있는 한 상기 오퍼레이팅 시스템 (30) 및/또는 상기 파일 시스템 (32) 이 이용가능하지 않다는 것이 외부 단말 (200) 에 투명하게 하도록 상기 임시 파일 시스템 (12) 을 제공하고, 그리고
    상기 업데이트 에이전트 (10) 의 메모리 구조 (11) 에, 바람직하게는, 데이터 그룹핑 식별자 (DGI) 를 갖는 데이터 그룹핑으로서, 상기 파일 시스템 (32) 의 부모/자식 파일 관계를 유지하는 TLV 포맷으로, 상기 임시 파일 시스템 (12) 을 제공하도록
    구성되는, 보안 엘리먼트 또는 업데이트 에이전트.
15. 전자 디바이스에서 보안 엘리먼트 (100) 와 함께 사용하기 위한 컴퓨터 프로그램 제품으로서,
    상기 컴퓨터 프로그램 제품은 상기 전자 디바이스 내의 상기 보안 엘리먼트 (100) 내로 소프트웨어를 로딩하기 위해, 비일시적 컴퓨터 판독가능 저장 매체 및 내장된 컴퓨터 프로그램 메커니즘을 포함하고, 상기 컴퓨터 프로그램 메커니즘은,
    - 오퍼레이팅 시스템 (30) 으로부터 SE (100) 의 제어를 인수하기 위한 명령들;
    - OS 이미지 (31) 를 상기 SE (100) 내로 로딩하기 위한 명령들로서, 상기 OS 이미지 (31) 는 상기 오퍼레이팅 시스템 (30) 의 업데이트를 나타내는, 상기 OS 이미지 (31) 를 로딩하기 위한 명령들;
    - 상기 OS 이미지 (31) 를 설치함으로써 업데이트된 오퍼레이팅 시스템 (30) 을 제공하기 위한 명령들; 및
    - 상기 업데이트 에이전트 (10) 에 의한 상기 SE (100) 의 제어를 상기 업데이트된 오퍼레이팅 시스템 (32) 으로 핸드오버하기 위한 명령들을 포함하고,
    상기 컴퓨터 프로그램 메커니즘은 추가로, 상기 SE (100) 에 임시 파일 시스템 (12) 을 제공하고, 상기 업데이트 에이전트 (10) 가 상기 SE (100) 를 제어하고 있는 한 상기 임시 파일 시스템 (12) 을 관리하기 위한 명령들을 포함하는 것을 특징으로 하는, 보안 엘리먼트와 함께 사용하기 위한 컴퓨터 프로그램 제품.

Images