KR20010101622A

KR20010101622A - 런타임 환경 특권을 사용해서 소형 풋프린트 장치의콘텍스트 배리어를 넘어선 액세스를 허용하기 위한 기술

Info

Publication number: KR20010101622A
Application number: KR1020017009171A
Authority: KR
Inventors: 조수아 스서; 미첼 비. 버틀러; 앤디 스트라이치
Original assignee: 썬 마이크로시스템즈, 인코포레이티드
Priority date: 1999-01-22
Filing date: 2000-01-20
Publication date: 2001-11-14
Also published as: JP2013030175A; WO2000043878A1; EP1163579A1; CN1316360C; US6922835B1; DE60002687D1; CN1351728A; JP2002535772A; EP1163579B1; DE60002687T2; KR100716699B1; JP5483768B2; JP5132853B2; ATE240549T1; AU771765B2; AU2617600A; DE1163579T1

Abstract

소형 풋프린트 장치는 프로그램들의 실행을 아이솔레이트하는 콘텍스트 배리어를 포함함으로써 비관련 벤더들로부터 다수의 프로그램들을 안전하게 실행시킨다. 콘텍스트 배리어는 주체 및 객체가 동일한 명칭 스페이스 또는 메모리 스페이스에 속하는지를 알기 위해 또는 동작될 객체에 대한 요청 액션이 승인된 것인지를 알기 위해 보안 점검들을 실행한다. 각각의 프로그램 또는 프로그램 집합은 개별 콘텍스트으로 실행되지만, 하나의 콘텍스트는 콘텍스트 배리어 제약이 없이 모든 프로그램 모듈에 액세스를 갖는다.

Description

런타임 환경 특권을 사용해서 소형 풋프린트 장치의 콘텍스트 배리어를 넘어선 액세스를 허용하기 위한 기술{TECHNIQUES FOR PERMITTING ACCESS ACROSS A CONTEXT BARRIER ON A SMALL FOOTPRINT DEVICE USING RUN TIME ENVIRONMENT PRIVILEGES}

<관련 출원에 대한 참고 문헌>

본 출원은 본 명세서에 전체가 참조용으로 인용되었으며 발명인이 모쉬 레비(Moshe Levy) 및 쥬디 슈웨이브(Judy Schwabe)(접수 번호 제50253-221/P3263호)이고 "안전 분산 바이트 코드 검사 버츄얼 머신(VIRTUAL MACHINE WITH SECURELY DISTRIBUTED BYTE CODE VERIFICATION)"라는 제목으로 1997년 4월 15일에 출원된 미국 특허 출원 일련 번호 제08/839,621호와 관련된다.

본 출원은 본 명세서에 전체가 참조용으로 인용되었으며 발명인이 죠수아 써셔(Joshua Susser), 미첼 비. 버틀러(Mitchel B. Butler) 및 앤디 스트라히(Andy Streich)(접수 번호 제50253-216/P3708호)이고 "콘텍스트 배리어를 사용해서 소형 풋프린트 장치에 보안을 구현하기 위한 기술(TECHNIQUES FOR IMPLEMENTING SECURITY ON A SMALL FOOTPRINT DEVICE USING A CONTEXT BARRIER)"이라는 제목으로 1999년 1월 22일에 출원된 미국 특허 출원 일련 번호 제09/235,158호와 관련된다.

본 출원은 본 명세서에 전체가 참조용으로 인용되었으며 발명인이 죠수아 써셔, 미첼 비. 버틀러 및 앤디 스트라히(접수 번호 제50253-217/P3709호)이고 "엔트리 포인트 객체를 사용해서 소형 풋프린트 장치에서 콘텍스트 배리어를 넘어선 액세스를 허용하기 위한 기술(TECHNIQUES FOR PERMITTING ACCESS ACROSS A CONTEXT BARRIER ON A SMALL FOOTPRINT DEVICE USING AN ENTRY POINT OBJECT)"이라는 제목으로 1999년 1월 22일에 출원된 미국 특허 출원 일련 번호 제09/235,157호와 관련된다.

본 출원은 본 명세서에 전체가 참조용으로 인용되었으며 발명인이 죠수아 써셔, 미첼 비. 버틀러 및 앤디 스트라히(접수 번호 제50253-218/P3710호)이고 "런타임 환경 특권을 사용해서 소형 풋프린트 장치에서 콘텍스트 배리어를 넘어선 액세스를 허용하기 위한 기술(TECHNIQUES FOR PERMITTING ACCESS ACROSS A CONTEXT BARRIER ON A SMALL FOOTPRINT DEVICE USING RUN TIME ENVIRONMENT PRIVILEGES)"이라는 제목으로 1999년 1월 22일에 출원된 미국 특허 출원 일련 번호 제09/235,155호와 관련된다.

본 출원은 본 명세서에 전체가 참조용으로 인용되었으며 발명인이 죠수아 써셔, 미첼 비. 버틀러 및 앤디 스트라히(접수 번호 제50253-219/P3711호)이고 "글로벌 데이터 구조를 사용해서 소형 풋프린트 장치에서 콘텍스트 배리어를 넘어선 액세스를 허용하기 위한 기술(TECHNIQUES FOR PERMITTING ACCESS ACROSS A CONTEXT BARRIER IN A SMALL FOOTPRINT DEVICE USING GLOBAL DATA STRUCTURES)"이라는 제목으로 1999년 1월 22일에 출원된 미국 특허 출원 일련 번호 제09/235,157호와 관련된다.

본 기술 분야에는 다수의 객체 지향 프로그래밍 언어들이 공지되어 있다. 이러한 언어들의 일례들은 C++ 언어 및 스몰토크 언어(Smalltalk language)를 포함한다.

다른 객체 지향 언어는 자바(JAVA)^TM언어이다. 이 언어는 애디슨-웨슬리(Addison-Wesley)에 의해 출판되고 제임스 고슬링(James Gosling) 외 다수가 저서한 책자바 ^TM 언어 설명서(Java ^TM Language Specification)에 기술되어 있다. 이 책은 본 명세서에 전체가 참조용으로 인용되었다. 자바^TM언어는 특히 자바^TM버츄얼 머신에서 실행되기에 적합하다. 이 머신은 본 명세서에 전체가 참조용으로 인용되었으며 애디슨-웨슬리에 의해 출판되고 팀 린돔(Tim Lindholm) 및 프랭크 옐린(Frank Yellin)이 저서한 책자바 ^TM 버츄얼 머신 설명서(Java ^TM Virtual Machine Specification)에 기술되어 있다.

본 기술 분야에 다수의 소형 풋프린트 장치들이 널리 공지되어 있다. 상기 장치들은 스마트 카드, 셀룰러 폰 및 다양한 다른 소형 또는 초소형 장치들을 포함한다.

스마트 카드들은 크기와 형태가 신용 카드와 유사하지만, 전형적으로 카드내에 데이터 프로세싱 장치(예를 들면, 프로세싱 함수들을 실행하는 프로세서 또는 논리 회로) 및 프로그램, 데이터 및 스마트 카드와의 다른 통신들이 달성될 수 있는 접점 집합(a set of contacts)을 포함한다. 전형적으로, 접점 집합은 전원 접속부 및 리턴부와 클록 입력부, 데이터 통신이 달성될 수 있는 리셋 입력부 및 데이터 포트를 포함한다.

정보는 카드 수용 장치(card acceptance device)를 사용해서 스마트 카드에 기록될 수 있고 스마트 카드로부터 검색될 수 있다. 카드 수용 장치는 전형적으로 호스트 컴퓨터 주변에 부착되어 있으며 스마트 카드가 삽입될 수 있는 슬롯과 같은 카드 포트를 포함한다. 일단 삽입되면, 커넥터로부터의 접점들 또는 브러시들은 스마트 카드 상의 표면 접속 영역에 대하여 가압되어 전력이 제공되고 스마트 카드에서 전형적으로 발견되는 프로세서 및 메모리와의 통신이 허용된다.

스마트 카드들 및 카드 수용 장치들(이하, 'CAD'라 함)은 광범위한 표준화 시도들, 예를 들면 ISO 7816의 대상이다.

비승인 사용자들로부터 승인된 사용자들을 분리하기 위해 파이어월(firewall)을 사용하는 것은 네트워크 환경에서 널리 공지된 것이다. 예를 들어, 파이어월은 본 명세서에 전체가 참조용으로 인용되었으며 발명인이 데이빗 브라우넬(David Brownell)(접수 번호 제50435-023/P2789/TJC호)이고 "인증 파이어월 터널링 프레임워크(AUTHENTICATED FIREWALL TUNNELLING FRAMEWORK)"라는 제목으로 1998년 12월 1일에 출원된 미국 특허 출원 일련 번호 제09/203,719호에 기술되어 있다.

풀 자바^TM플랫폼 기능 서브셋(subset of the full Java^TMplatform capabilities)은 스마트 카드와 같은 소형 풋프린트 장치를 위해 정의되었다. 이 서브셋은 자바 카드^TM플랫폼이라고 한다. 자바 카드^TM플랫폼의 사용은 이하의 출판물에 기술되어 있다.

Java Card^TM2.0 - 언어 서브셋 및 버츄얼 머신 설명서(LANGUAGE SUBSET AND VIRTUAL MACHINE SPECIFICATION);

Java Card^TM2.1 - 응용 프로그래밍 인터페이스(APPLICATION PROGRAMMING INTERFACES);

Java Card^TM2.0 - 프로그래밍 컨셉(PROGRAMMING CONCETPS);

Java Card^TM애플릿 개발자 가이드(APPLET DEVELOPER'S GUIDE).

이 출판물들은 본 명세서에 전체가 참조용으로 인용되었다.

ISO 7816의 작업 드래프트(working draft) - 파트 11은 코멘트를 위해 배부되었다. 상기 드래프트는 개별 실행 콘텍스트들이 스마트 카드에서 동작할 수 있도록 허용하기 위한 표준들에 대해 기술하고 있다. 상기 작업 드래프트의 복사본이 본 명세서에 전체가 참조용으로 인용되었다.

실행 콘텍스트의 개념(notion of an execution context)은 컴퓨터 과학 분야에서 널리 공지되어 있다. 일반적으로, 컴퓨팅 환경에서의 다수의 실행 콘텍스트들의 사용은 상이한 프로그램 모듈들 또는 프로세스들을 서로 분리시키거나 아이솔레이트(isolate)하는 방법을 제공함으로써, 각각이 서로 과도한 간섭 없이 동작할 수 있게 해준다. 상이한 콘텍스트들 간의 상호 작용들(만약 있다면)은 우연이라기 보다는 고의적인 것이며, 각각의 콘텍스트의 완전성(integrity)을 보존하도록 신중하게 제어된다. 다수의 콘텍스트들의 일례는 메인프레임들과 같이 보다 큰 하드웨어 장치들에서 볼 수 있는데, 다수의 버츄얼 머신들이 정의될 수 있고, 각각의 버츄얼 머신은 자체 실행 콘텍스트를 갖는다. 다른 일례는 스마트 카드 상의 다수의 실행 콘텍스트들의 사용에 대해 기술하고 있는 발명인이 드 종(De Jong)인 미국 특허 제5,802,519호에서 볼 수 있다. 당업자들은 다수의 실행 콘텍스트들을 제공하는 컴퓨팅 환경에서 임의의 소정의 실행 코드를 대응 콘텍스트과 연관시키기 위한 메카니즘을 제공할 필요가 있음을 알 것이다.

또한, 현재 콘텍스트의 개념(notion of a current context)이 널리 공지되어 있다. 다수의 콘텍스트들을 지원하는 특정 컴퓨팅 환경들은 임의의 소정의 시간에 특히 계산의 능동 포커스로서 한 콘텍스트를 처리한다. 상기 콘텍스트는 "현재 콘텍스트"이라고 언급될 수 있다. 현재 콘텍스트가 변경되어, 다른 콘텍스트가 현재 콘텍스트가 될 때, "콘텍스트 스위칭(context switch)"이 발생했다고 말한다. 당업자들이 알 수 있는 바와 같이, 컴퓨팅 환경들은 어떤 콘텍스트가 현재 콘텍스트인지를 추적하고 콘텍스트 스위칭을 용이하게 하기 위한 메카니즘들을 제공한다.

종래 기술에서, 소형 풋프린트 장치 분야에서, 특히, 스마트 카드 분야에 있어서, 소형 풋프린트 장치들에서 동작하는 콘텍스트들 간에는 상호 작용(inter-operation)이 없다. 각각의 콘텍스트는 완전히 개별적으로 동작됨으로써 상이한 콘텍스트의 다른 애플리케이션들 또는 프로세스들에게 영향을 주지 않고 콘텍스트 스페이스 내에서 동작 또는 오동작(malfunction)할 수 있다.

자바^TM플랫폼이 사용하는 보안 프로텍션 층은 통상 샌드박스 모델(sandbox model)과 관련된다. 비신용(untrusted) 코드는 "실 세계(real world)" 또는 풀 자바^TM환경에 어떠한 손상도 끼치지 않고 안전하게 "동작(play)"할 수 있는 "샌드박스(sandbox)"에 배치된다. 이러한 환경에서, 자바^TM애플릿들은 통신하지 않지만, 각각이 자체 명칭 스페이스(name space)를 갖는다.

몇몇 스마트 카드 오퍼레이팅 시스템들은 실행 콘텍스트들이 직접 통신하는 것을 허용하지 않지만, 오퍼레이팅 시스템을 통하거나 서버를 통해서는 통신을 허용한다.

문제점들

컴퓨터 프로그램들 및 다른 정보를 소형 풋프린트 장치에 배치하고자 할 때 다양한 문제점들이 발생한다. 어쩔 수 없는 문제점들 중 하나는 메모리 스페이스가 매우 제한적이라는 점이다. 이는 종종 메모리 스페이스에 필요한 기능들을 제공하기 위해 특별한 노력을 기울이게 한다.

소형 풋프린트 장치들과 관련된 두번째 문제점은 상이한 소형 풋프린트 장치 제조자들이 상이한 오퍼레이팅 시스템들을 이용할 수 있다는 점이다. 그 결과, 하나의 오퍼레이팅 시스템을 위해 개발된 애플리케이션들이 상이한 제조자들에 의해제조된 소형 풋프린트 장치에 항상 이식될 수 있는 것은 아니다.

2개 이상의 프로그램 소스(제조자 또는 벤더)로부터의 프로그램들이 단일 소형 풋프린트 장치에 응용되면, 새로운 프로그램이 소형 풋프린트 장치에 로드될 때 보안은 현존 프로그램들 및 데이터가 손상되는 것을 방지하려고 시도하는 요소(factor)가 된다. 해커 또는 악의 있는 사람이 프로그램 및 데이터에 액세스하는 것을 방지하기를 희망할 때도 동일한 원리가 적용된다.

스마트 카드와 같은 소형 풋프린트 장치들은 개별 버츄얼 머신들을 구현하는데 필요한 리소스들을 갖지 않음이 명백하다. 그럼에도 불구하고, 개별 실행 콘텍스트들 간에 엄격한 보안을 유지할 필요가 있다.

과거에는, 동일한 소스 또는 신뢰성 있는 것으로 알려진 소스로부터의 애플리케이션들만을 스마트 카드 또는 다른 소형 풋프린트 장치에 로드함으로써 보안이 유지되었다.

따라서, 프로그래머에게 과도한 부담을 주지 않으면서도 신뢰성 없는 소스에 의해 상이한 시간에 기록된 애플릿들의 동적 로딩을 용이하게 하는 신속하고 효율적인 피어 투 피어 통신을 통한 안전한 방식으로, 선택된 실행 콘텍스트들 사이에서만 객체-지향 인터랙션(interaction)을 허용하는 것이 바람직할 것이다.

<요약>

본 발명의 목적은 한 콘텍스트를 다른 콘텍스트으로부터 분리 및 아이솔레이션하기 위해 콘텍스트 배리어(파이어월(firewall)이라고도 함)을 제공하고 필요할 때 장벽을 넘는 제어된 액세스를 제공하는데 있다.

본 발명에 따르면, 예를 들면, 각각 하나 이상의 애플릿들을 포함하고, 동일한 로지컬(즉, 버츄얼 또는 리얼) 머신에서 실행되며, 서로로부터 보호되는 2개의 실행 콘텍스트들은 객체-지향 언어 메카니즘들과 같은 언어 메카니즘들을 사용해서 제어된 보안 방식으로 정보를 공유할 수 있다. 예를 들어, 보안은 객체 단위로 이루어 질 수 있다. 따라서, 제1 실행 콘텍스트의 메소드는 제2 실행 콘텍스트의 제1 객체 A에 액세스할 수 있지만, 선택적으로 제2 실행 콘텍스트의 제2 객체 b에는 액세스할 수 없다.

일 실시예에 따르면, 인헨스드 자바^TM버츄얼 머신(VM)은 VM의 실행 콘텍스트들을 넘어선 액세스 시도에 대한 확실한 실시간 점검을 제공한다. 점검은 VM에 의해 자동으로 이루어질 수 있고 또는 VM으로부터 지원된 프로그래머에 의해 코드화될 수 있다. 이는 언어-레벨 통신 메카니즘들을 사용해서 달성될 수 있다. 이러한 방법으로, 언어를 사용해서 다른 객체 액세스가 이루어지는 방법과 동일한 방법으로 실행 콘텍스트들을 넘어선 객체 액세스를 표현할 수 있다. 이러한 실시간 점검은 자바^TM언어 및 플랫폼이 이미 제공한 것 외에 제 2 차원의 방어/보안(second dimension of defense/security)을 제공한다.

상기 메카니즘들은 프로그래밍 버그들(예를 들면, 모든 콘텍스트들에게 액세스할 수 없을 때 "퍼블릭"(글로벌) 데이터로 선언됨)로 인한 보안의 결함에 대항하는 프로텍션(protection)을 제공한다. 또한 상기 메카니즘들은 공유(공유 객체 및 공유 애플릿 선택)에 대한 미세한 제어를 가능케 한다.

본 발명은 또한 본 발명의 다른 양상들과 관련된 컴퓨터 프로그램 제품 및 캐리어 웨이브들과 관련된다.

본 발명의 여타 특징들, 양상들 및 장점들은 첨부된 도면들과 관련해서 기술된 이하의 상세한 설명으로부터 더욱 명백해질 것이다.

본 발명은 컴퓨터 보안에 관한 것으로, 특히 스마트 카드와 같은 소형 풋프린트 장치에서 보안을 구현하기 위한 기술들에 관한 것이다.

본 발명의 특징 및 장점들은 이하의 설명으로부터 명백해질 것이다:

도 1은 카드 수용 장치가 설치된 컴퓨터 및 카드 수용 장치를 통해 사용되는 스마트 카드를 도시한 것이다.

도 2는 네트워크에 접속된 카드 수용 장치가 설치된 컴퓨터를 도시한 것이다.

도 3은 종래 기술의 스마트 카드와 같은 소형 풋프린트 장치의 일례의 하드웨어 구조를 도시한 것이다.

도 4는 종래 기술에서 실행되는 주체(principal)들에 의해 액세스되는 객체들을 도시한 것이다.

도 5는 본 발명의 다양한 실시예들을 설명하기 위해 사용될 수 있는 일례의 보안 모델이다.

도 6은 본 발명의 한 양상에 따른 파이어월 또는 콘텍스트 배리어에 의한 실행 콘텍스트들의 분리를 도시한 블록도이다.

도 7은 본 발명을 구현하는데 유용한 소프트웨어 아키텍쳐를 도시한 것이다.

도 8은 본 발명의 한 양상에 따른 파이어월을 구현하는 보안 강화 프로세스의 순서도이다.

도 9는 본 발명의 한 양상에 따른 파이어월을 넘어선 객체 액세스를 도시한 블록도이다.

도 10은 파이어월을 넘어선 캐스케이드 객체를 도시한 블록도이다.

도 11은 한 콘텍스트의 주체에 의해 파이어월을 넘어서 다른 콘텍스트에 액세스하는 것을 허용하기 위한 프로세스의 순서도이다.

도 12는 파이어월을 넘어선 액세스를 허용하도록 엔트리 포인트 객체를 사용하는 것을 도시한 블록도이다.

도 13은 파이어월을 넘어선 액세스를 위해 어레이 등의 글로벌 데이터 구조를 사용하는 것을 도시한 블록도이다.

도 14는 파이어월을 넘어선 액세스를 허용하기 위해 슈퍼콘텍스트를 사용하는 것을 도시한 블록도이다.

도 15는 파이어월을 넘어선 액세스를 허용하기 위해 공유 가능 인터페이스 객체들을 사용하는 것을 도시한 블록도이다.

도 16은 파이어월을 넘어선 액세스를 허용하는 보안 강화 프로세스의 순서도이다.

도 17은 도 16의 블록(1620)을 상세히 도시한 순서도이다.

도 18은 도 17의 블록(1629)의 일례의 구현을 도시한 순서도이다.

표기법 및 명칭(NOTATIONS AND NOMENCLATURE)

이하의 상세한 설명은 컴퓨터 또는 컴퓨터 네트워크에서 실행되는 프로그램프로시져들이라는 용어로 표현될 수 있다. 프로시져 설명 및 도면들은 작업의 내용을 당업자들에게 가장 효율적으로 전달하기 위해 당업자들에 의해 사용되는 수단이다.

본 프로시져는 일반적으로 소망하는 결과를 야기하는 일관성 있는 일련의 단계들로 고안된다. 상기 단계들은 물리적인 양들에 대한 물리적인 조정을 필요로 한다. 통상, 꼭 필요하지 않더라도, 물리적인 양들은 저장, 전송, 결합, 비교 및 조정될 수 있는 전기 또는 자기 신호들의 형태를 취한다. 주로 일반적인 사용을 위해 상기 신호들을 비트, 값, 성분(elements), 심볼, 문자, 용어, 숫자들 등으로서 언급하는 것이 편리함을 증명한다. 그러나, 상기 용어들 및 유사한 용어들 모두는 적합한 물리적인 양들과 관련되고 단지 상기 양들에게 적용되는 편리한 레이블들임을 주지해야 한다.

또한, 조정(manipulations)은 일반적으로 인간 오퍼레이터에 의해 실행되는 지능적인 오퍼레이션과 관련된 가산(adding) 또는 비교(comparing)와 같은 용어들로 종종 언급된다. 대부분의 경우 본 발명의 일부를 형성하는 본 명세서에 기술된 임의의 오퍼레이션들은 인간 오퍼레이터에 의해 실행될 필요가 없고; 머신 오퍼레이션으로 이루어진다. 본 발명의 오퍼레이션을 실행하기 위한 유용한 머신들은 범용 디지털 컴퓨터 또는 다른 계산 장치들을 포함한다.

본 발명은 또한 상기 오퍼레이션들을 실행하기 위한 장치들에 관한 것이다. 이 장치는 요구된 목적을 위해 특별히 구성되거나, 또는 컴퓨터에 기억된 컴퓨터 프로그램에 의해 선택적으로 활성화되거나 재구성되는 범용 컴퓨터를 포함할 수 있다. 본 명세서에 제시된 프로시져들은 본래부터 특정 컴퓨터 또는 다른 장치에만 관련된 것은 아니다. 본 명세서의 기술에 따라 기록된 프로그램들을 갖는 다양한 범용 머신들이 사용될 수도 있고, 또는 요구된 메소드 단계들을 실행하는 보다 특정한 장치를 구성하는 것이 보다 편리함을 입증할 수도 있다. 다양한 메카니즘들을 위한 요구된 구조는 소정의 설명으로부터 명백해질 것이다.

자바 카드 런타임 환경 2.1 설명서(JAVA CARD RUNTIME ENVIRONMENT 2.1 SPECIFICATOIN)라는 제목인 문서의 공개되지 않은 드래프트가 본 명세서에 부록으로 첨부되어 있다. 본 발명의 특정 실시예들에 대한 또 다른 상세한 설명을 제공하는 상기 드래프트 문서는 본 명세서의 절대 필요한 파트로서 전체가 인용되었다.

이제부터 본 발명의 기술들이 스마트 카드 일례로서 기술되지만, 일례는 단지 설명을 위한 것으로 본 발명의 범위를 제한하는 것이 아니다.

도 1은 카드 수용 장치(110)가 장치된 컴퓨터(120) 및 카드 수용 장치(110)를 통해 사용되는 스마트 카드(100)를 도시한 것이다. 동작시, 스마트 카드(100)는 카드 수용 장치(110)에 삽입되고, 전력 및 데이터 접속부는 스마트 카드(100)의 표면의 액세스 가능한 접점 집합(105)을 통해 인가된다. 카드가 삽입될 때, 카드 수용 장치(110)로부터의 상대 접점들(mating contacts)이 카드를 파워-업하도록 표면 접점들(105)과 상호 접속되고 온보드 프로세서 및 메모리 기억 장치와의 통신을 허용한다.

도 2는 네트워크(200)에 접속된 카드 수용 장치가 설치된 도 1의컴퓨터(120)를 도시한 것이다. 또한, 서버(210)와 같은 다수의 다른 컴퓨팅 장치들이 네트워크에 접속되어 있다. 카드가 장치된 장치(120)를 사용해서 네트워크(200)를 통해 스마트 카드에 데이터 및 소프트웨어를 로드할 수 있다. 이러한 속성의 다운로드는 스마트 카드 및 디지털 캐시에 로드될 애플릿들 또는 다른 프로그램들 및 다양한 전자 상거래 및 다른 애플리케이션들에 따라 사용되는 다른 정보를 포함할 수 있다. 카드 수용 장치 및 스마트 카드의 프로세싱 소자들을 제어하는데 사용되는 명령들 및 데이터는 휘발성 또는 비휘발성 메모리에 기억될 수도 있고 또는 명령들 및/또는 데이터를 포함하는 캐리어 웨이브로서 통신 링크를 통해 직접 수신될 수도 있다. 또한, 예를 들어, 네트워크는 인터넷 또는 다른 네트워크와 같은 LAN 또는 WAN일 수 있다.

도 3은 종래 기술의 스마트 카드와 같은 소형 풋프린트 장치의 일례의 하드웨어 구조를 도시한 것이다. 도 3에 도시된 바와 같이, 프로세서(300)는 판독 전용 메모리(315) 및/또는 랜덤 액세스 메모리(316)를 포함할 수도 있는 제1 기억 장치(310)와 상호 접속된다. 프로세서는 또한 EEPROM 등의 제2 기억 장치(320) 및 직렬 포트 등의 입출력부(330)와 접속되어 있다. 이러한 속성의 소형 풋프린트 장치들은 매우 간단할 수 있음을 알 수 있다.

도 4는 종래 기술에서 실행되는 주체들에 의해 액세스되는 객체들을 도시한 것이다. 도 4에 도시된 바와 같이, 소형 풋프린트 장치와 같은 피지컬 디바이스(400)는 실행 콘텍스트(420)을 실행하는 하나 이상의 프로세싱 머신들(버츄얼 또는 피지컬)을 포함할 수도 있다. 실행 콘텍스트는 예를 들면 특정 애플릿과 관련된 콘텍스트일 수도 있다. 실행 콘텍스트의 하나 이상의 주체들(430)(예를 들면, 애플릿들 또는 애플리케이션들)은 실행 콘텍스트 내의 다른 객체들에 액세스하고자 할 수 있다. 실행 콘텍스트 내에서 액세스가 발생하는 한, 액세스들이 허용되고 모든 것이 정상적으로 작동하게 된다.

도 5는 본 발명의 다양한 실시예들을 설명하기 위해 사용될 수 있는 일례의 보안 모델이다. 이는 단지 사용될 수 있는 다수의 모델들 중 하나이고 설명을 목적으로한 편리한 모델이다. 도 5의 모델에서, 주체(엔티티라고도 함)(500)는 객체(520)와 같은 객체에 액션(510)을 취한다. 보안 점검은 주체, 객체, 및/또는 취해질 액션에 부가될 수 있다.

도 5에서, 주체에 따라 액션이 취해질 수 있는 2가지 타입의 객체들이 도시되어 있다. 이들은 데이터 객체들(예를 들면, 데이터1(520) 및 데이터2(520')) 및 엔티티(530)를 포함한다. 주체는 상기 객체들 중 임의의 객체에 대해 동작하거나 동작을 시도할 수 있다.

데이터가 수동적일 때, 엔티티(530)는 능동적이 된다. 주체로부터 능동 엔티티로 이어지는 선은 "액션"이라고 레이블링되는데, 이는 펑션 또는 메소드 호출을 실행한다던가 또는 메시지를 송신하는 것과 같이 데이터 객체에 대한 액션에 비해 보다 정교하고 임의적인 복합 액션일 수 있다. 데이터의 경우와 같이, 오퍼레이팅 시스템에 의해 강화된 보안 점검은 주체의 아이덴티티, 엔티티의 아이덴티티, 및/또는 액션 타입을 사용할 수도 있다. 또한, 능동 엔티티는 자체 추가 보안 점검을 실행할 수 있다. 이들은 희망대로 임의적이고 복합적인 것일 수 있고, 주체의 아이덴티티, 엔티티 자체의 아이덴티티, 액션, 및/또는 유용한 임의의 다른 정보를 사용할 수 있다.

객체-지향 시스템(예를 들면, 자바 카드^TM플랫폼)에서, "객체들"은 전형적으로 데이터 및 엔티티의 조합이다. 주체가 객체의 필드에 액세스하고자 할 때, 이는 매우 간단한 보안 점검에 의해 보호되는 매우 간단한 데이터 액세스이다. 주체가 객체의 메소드에 액세스하고자 할 때, 이는 액션 및 보안 점검의 임의적인 복합일 수 있는 엔티티 액세스이다.

도 6은 본 발명의 한 양상에 따른 파이어월 또는 콘텍스트 배리어에 의한 실행 콘텍스트들의 분리를 도시한 블록도이다. 피지컬 디바이스(400) 및 머신(410)는 도 4에 도시된 동일한 아이템들과 대응한다. 실행 콘텍스트(420)은 콘텍스트 내의 객체(440)에 액세스하고자 하는 주체(430)를 도시하고 있다. 이 액세스는 정상적으로 성공하게 된다. 그러나, 실행 콘텍스트(420)은 또한 콘텍스트 배리어(600)을 넘어서 실행 콘텍스트(62)의 객체(640)에 액세스하고자 하는 주체(630)를 도시하고 있다. 정상적으로, 이 액세스는 액션(635)이 콘텍스트 배리어(600)을 교차하는 지점에 X(636)로 표시된 것과 같이 금지된다.

도 7은 본 발명을 구현하는데 유용한 소프트웨어 아키텍쳐를 도시한 것이다. 상기 소프트웨어 아키텍쳐는 런타임 환경(700)으로 도시되어 있다. 소형 풋프린트 장치를 위한 오퍼레이팅 시스템(710)이 통상 사용된다. 본 발명의 실시예의 버츄얼 머신(720)는 오퍼레이팅 시스템을 통해 구현된다. 버츄얼 머신은 자바 카드^TM버츄얼 머신 또는 다른 버츄얼 머신일 수 있다. 표준 버츄얼 머신의 기능들은 본 명세서에 기술된 추가의 기능을 제공하도록 확장될 수 있고 또는 기능이 개별 모듈들로 제공될 수 있다. 버츄얼 머신(720)는 런타임 시스템(740)에 대한 액세스를 제공하는 인터프리터 또는 고유 구현(730; native implementation)을 포함할 수도 있다. 런타임 시스템은 객체 지향 구현의 객체들을 관리하기 위한 객체 시스템(750)을 포함한다. 3개의 콘텍스트들(760, 770, 780)이 도시되어 있다. 각각의 콘텍스트는 실행 콘텍스트들 간의 콘텍스트 배리어(종종 파이어월이라고 함)에 의해 서로 분리된다. 한 특정 실시예에서, 콘텍스트(760)은 슈퍼콘텍스트이다. 즉, 콘텍스트(760)은 엔트리 포인트 객체들 또는 글로벌 데이터 구조들을 생성하는 특권, 및 종속 콘텍스트들(770, 780)의 객체들에 액세스하는 특권을 잠정적으로 포함해서, 종속 콘텍스트들(770, 780)에게는 유효하지 않은 특권들 및 기능들을 갖는다.

모든 객체는 하나의 특정 콘텍스트과 관련된다. 콘텍스트는 콘텍스트과 연관된 각각의 객체를 소유한다고 할 수 있다. 런타임 시스템(740)은 콘텍스트들을 유일하게 식별하기 위한 수단, 및 현재 실행 콘텍스트를 규정하고 식별하기 위한 수단을 제공한다. 객체 시스템(750)은 소유 콘텍스트들과 객체들을 연관시키기 위한 메카니즘을 제공한다.

예를 들어, 런타임 시스템(740)은 유일한 명칭으로 콘텍스트들을 식별할 수 있고, 이에 대응해서 객체 시스템(750)은 객체 헤더에 콘텍스트 명칭을 기록함으로써 객체들을 콘텍스트과 연관시킬 수 있다. 객체 헤더의 정보는 객체 지향 언어로기록된 프로그램들에 의해서는 액세스될 수 없지만, 버츄얼 머신(720) 자체에는 유효하다. 대안으로, 런타임 시스템(740)은 메모리 스페이스를 개별 영역들로 분할함으로써 콘텍스트들을 식별할 수 있는데, 각각의 영역은 특정 콘텍스트를 위한 것이고, 이에 대응해서 객체 시스템(750)은 콘텍스트 메모리 스페이스내에 객체 기억 장치를 할당함으로써 콘텍스트과 객체들을 연관시킬 수 있다.

도 8은 본 발명의 한 양상에 따른 콘텍스트 배리어를 구현하는 보안 강화 프로세스의 순서도이다. 주체가 객체에 대한 액션을 호출할 때(800), 객체가 주체의 콘텍스트에 속하는지의 여부를 결정하기 위해 점검이 이루어진다(810). 아니면, 액션은 금지된다(840). 다른 경우, 액션이 허가된다(830). 이는 콘텍스트 배리어 또는 파이어월의 가장 간단한 형태이다. 한 특정 실시예에서, 객체가 콘텍스트 요청 액세스의 명칭 스페이스 또는 메모리 스페이스 외부에 있으면 보안 예외(security exception)를 던짐(throwning)으로써 액션은 금지된다(840).

도 9는 본 발명의 한 양상에 따른 파이어월을 넘어선 객체 액세스를 도시한 블록도이다. 도 9는 도 6과 상당히 유사하다. 그러나, 도 9는 객체(910)에 대한 액션(905)을 실행하기 위해 객체(910)에 액세스하고자 하는 주체(900)를 도시하고 있다. 본 발명에 따라, 파이어월(600)에 의해 액세스가 차단되기 보다는, 액션(630)이 차단되는 방식으로, 액세스 포인트(920)를 통해 파이어월을 넘어선 액션(905)이 허가됨으로써 주체 및 객체가 상이한 실행 콘텍스트들임에도 불구하고 주체(900)가 객체(910)에 대한 액션(905)을 실행할 수 있다. 액세스 포인트(920) 후의 메카니즘들은 도 12 내지 도 18을 참조해서 이하에 기술된다. 액세스포인트(920)가 X(636)와 같은 차단 액세스들과 공존할 수 있음을 주지하자. 따라서 액세스 포인트(920)는 콘텍스트 배리어(600)을 넘어선 미세한 공유(객체 단위 보안) 제어를 제공한다.

객체 액세스(900)가 개시될 때, 현재 콘텍스트 설정은 콘텍스트(420)이다. 객체(910)가 데이터 객체이면, 액션(905)은 간단한 데이터 액세스이고, 제2 콘텍스트(620)에서 실행되는 코드가 없다. 객체(910)가 엔티티 객체이고, 액션이 객체 코드가 실행되도록 야기하면, 제2 콘텍스트(620)에서 코드가 실행된다. 정확한 콘텍스트(620)의 객체(910)의 코드를 실행하기 위해, 버츄얼 머신(410)는 콘텍스트 스위칭을 실행한다. 콘텍스트 스위칭은 현재 콘텍스트 설정이 콘텍스트(620)이 되도록 변경하고, 현재 콘텍스트 설정의 이전 값은 후에 복원될 수 있도록 기억된다. 이때부터, 새로운 현재 콘텍스트에서 코드가 실행된다. 액션(905)이 완료될 때, 제어는 액세스(900)가 개시되는 시점으로 리턴된다. 리턴 중에, 버츄얼 머신(420)는 현재 콘텍스트 설정의 값을 이전 값으로 복원해야만 한다.

도 10은 파이어월을 넘어선 캐스케이드 객체를 도시한 블록도이다. 도 10은 3개의 실행 콘텍스트들(1000, 1010, 1020)을 도시하고 있다. 실행 콘텍스트 1의 주체(1030)는 실행 콘텍스트 2의 객체(1050)에 대한 액션(1035)을 호출할 때, 콘텍스트 배리어(600)의 액세스 포인트(1070)를 통해 액션을 호출한다. 실행 콘텍스트 2의 객체(1050)는 실행 콘텍스트 3의 객체(1060)에 대한 액션(1045)을 실행하고자 하는 객체 액세스(1040)를 갖는다. 이는 실행 콘텍스트 2 및 실행 콘텍스트 3을 분리하는 콘텍스트 배리어(600')의 액세스 포인트(1080)를 사용해서 달성된다. 또한 실행 콘텍스트 2의 객체(1050)는 동일한 실행 콘텍스트, 즉, 실행 콘텍스트 2의 객체(1099)에 대한 액션(1095)을 호출하는 다른 객체 액세스(1090)를 갖는다. 액션들(1035, 1045)은 도 9의 설명에 기술된 바와 같이 콘텍스트 스위칭들을 야기한다. 그러나, 액션(1095)은 콘텍스트 배리어를 교차하지 않아서, 실행을 위해 콘텍스트 스위칭이 필요하지 않기 때문에, 콘텍스트 스위칭이 발생하지 않는다.

도 11은 한 콘텍스트의 주체에 의해 파이어월을 넘어서 다른 콘텍스트에 액세스하는 것을 허용하기 위한 프로세스의 순서도이다. 상기 프로세스에는 본래 3개의 단계들이 있다. 실행 콘텍스트 2에서, 액세스될 객체가 생성되어 공유 객체로서 지정된다(1100). 실행 콘텍스트 1에서, 주체는 실행 콘텍스트 2의 객체에 대한 참조를 획득한다(1110). 실행 콘텍스트 1의 주체는 그 후 실행 콘텍스트 2의 공유 객체로서 지정된 객체에 대한 액션을 호출한다(1120).

도 11의 단계(1100)에 기술된 바와 같이 생성된 객체를 공유 가능한 객체로서 식별하고 지정하는 것에 있어서, 이는 본 발명의 특정 실시예에 따라 객체 표현 헤더에 공유 가능한 속성을 포함함으로써 달성될 수 있다. 객체 헤더의 정보는 객체 지향 언어로 기록된 프로그램에 의해서는 액세스될 수 없지만, VM 자체에는 유효하다.

다른 콘텍스트의 객체에 대한 참조를 획득하는 것은 다른 콘텍스트의 객체에 액세스하는 특별한 경우이다. 다른 콘텍스트의 객체에 대한 액세스를 제공하는 메카니즘은 다른 객체들에게도 유효하다. 예를 들어, 다른 콘텍스트의 객체에 대한 메소드를 호출함으로써 참조를 상이한 콘텍스트의 제2 객체로 리턴시킬 수 있다.상이한 콘텍스트의 객체에 대한 초기 참조를 획득될 수 있게 하는 다른 메카니즘이 필요하다. 특정 실시예에서, 공지된 특정 엔트리 포인트 객체들에 대한 참조들은 퍼블릭 API를 사용해서 획득될 수 있다. 상이한 콘텍스트의 객체에 대한 초기 참조가 일단 획득되면, 다른 참조들은 상기 객체로부터 획득될 수 있다.

본 발명에 따라 콘텍스트 배리어를 넘어서 정보를 획득하는 방법에는 일반적으로 4가지 방법들이 있다. 상기 방법들은 콘텍스트 배리어를 넘어서 객체에 액세스하거나 또는 콘텍스트 배리어를 넘어서 액세스될 객체의 참조를 획득하기 위해 개별적으로 또는 결합되어 사용될 수 있다(1110). 상기 방법들은 도 12 내지 도 18을 참조하여 기술된다.

도 12는 콘텍스트 배리어를 넘어선 액세스를 허용하도록 엔트리 포인트 객체를 사용하는 것을 도시한 블록도이다. 도 12에 도시된 바와 같이, 콘텍스트(770)(콘텍스트 1)의 소정의 객체(1200)는 슈퍼콘텍스트(760)의 정보에 액세스하고자 한다. 특정 실시예에서, 슈퍼콘텍스트(760)는 적어도 하나의 엔트리 포인트 객체(1210)를 포함한다. 엔트리 포인트 객체(1210)는 퍼블릭 API의 파트로서 공개될 수 있거나, 또는 공개 API를 통해(예를 들면, 도 11을 참조해서 상술된 메카니즘들에 따라) 간적접으로 유효해져서, 슈퍼콘텍스트에 종속된 각각의 콘텍스트가 슈퍼콘텍스트의 엔트리 포인트 객체와 통신할 수 있게 된다. (다른 실시예들에서, 엔트리 포인트 객체들은 슈퍼콘텍스트 이외의 다른 콘텍스트 내에 존재할 수도 있음을 알게 될 것이다.)

도 13은 파이어월을 넘어선 액세스를 허용하기 위해 글로벌 데이터 구조를사용하는 것을 도시한 블록도이다. 이 방식으로, 슈퍼콘텍스트(760)는 글로벌 어레이 등의 글로벌 데이터 구조를 생성한다. 특정 실시예에서, 슈퍼콘텍스트(760)는 글로벌 데이터 구조를 생성하도록 허용된 콘텍스트만을 의미한다. (다른 실시예들에서, 글로벌 데이터는 슈퍼콘텍스트 이외의 콘텍스트에 존재할 수도 있음을 알게 될 것이다.) 글로벌 상태로 인해, 각각의 콘텍스트들(770, 780)은 글로벌 데이터 구조를 판독하고 기록할 수 있다. 따라서, 한 콘텍스트에 의해 글로벌 데이터 구조로 기록된 정보는 다른 콘텍스트에 의해 판독될 수 있다. 예를 들어, 이 메카니즘은 콘텍스트들 간에 바이너리 데이터 또는 객체들에 대한 참조들을 전달하는데 사용될 수 있다.

도 14는 콘텍스트 배리어를 넘어선 액세스를 허용하기 위해 슈퍼콘텍스트 특권들을 사용하는 것을 도시한 블록도이다. 도 14에서, 슈퍼콘텍스트(760)의 객체는 2개의 콘텍스트들을 분리하는 콘텍스트 배리어를 넘어서 콘텍스트(780)에 대한 액세스를 시도하고 있다. 슈퍼콘텍스트(760)는 슈퍼콘텍스트와 연관된 특권들 덕분에 콘텍스트(780)의 메소드들 중 임의의 메소드를 호출할 수 있고 콘텍스트(780) 내에 포함된 임의의 데이터에 액세스할 수 있다.

도 15는 파이어월을 넘어선 액세스를 허용하기 위해 공유 가능 인터페이스 객체들을 사용하는 것을 도시한 블록도이다. 공유 가능 인터페이스는 공유 가능 인터페이스 메소드들의 집합을 정의한다. 공유 가능 인터페이스 객체는 적어도 공유 가능 인터페이스에서 정의된 메소드들의 집합을 구현하는 객체이다. 도 15에서, 콘텍스트 2(780)의 객체(1210)는 공유 가능 인터페이스 객체이다. 객체 액세스(1200)의 주체가 객체(1210) 자체에 의해 승인되면, 다른 콘텍스트(770)의 객체 액세스(1200)는 객체(1210)에 대한 공유 가능 인터페이스 메소드들 중 임의의 메소드를 호출할 수 있다. 상기 승인은 도 18을 참조하여 이하에 기술된다.

본 발명에 따른 버츄얼 머신은자바 ^TM 버츄얼 머신 설명서에 기술된 버츄얼 머신과 같은 초기 버츄얼 머신들이 제공하는 기능 이외의 기능들을 제공한다. 특히, 본 발명에 따라, 버츄얼 머신은 파이어월을 넘어선 액세스를 허용하는 보안 강화 프로세스를 구현하거나 용이하게 하는 기능을 제공한다. 이 프로세스는 도 16 내지 도 18을 참조하여 이하에 기술된다. 도 12 내지 도 15를 참조해서 상술된 4가지 방법들을 포함해서(그러나 이에만 제한되지 않음) 파이어월을 넘어선 액세스를 제공하기 위한 임의의 방법에 적용될 수 있음을 주지하자.

도 16은 파이어월을 넘어선 액세스를 허용하는 보안 강화 프로세스의 순서도이다. 주체가 객체(1600)에 대한 액션을 호출하고자 할 때, 객체가 주체의 콘텍스트에 속하는지를 결정하기 위해 점검이 이루어진다(1610). 속하면(1610-예), 액션이 허용된다(1630). 그렇지 않으면(1610-아니오), 주체에 의한 객체에 대한 액션이 허용되는 경우(1620) 점검이 이루어진다. 그런 경우(1620-예), 액션이 허용된다(1630). 그렇지 않은 경우(1620-아니오), 액션은 금지된다. 특정 실시예에서, 보안 예외가 발생된다(1640).

도 17은 도 16의 블록(1620)을 상세히 도시한 순서도이다. 객체가 주체의 콘텍스트에 속하지 않으면(1610-아니오), 다수의 테스트들(1621, 1622, 1623,...1629)이 주체에 의한 객체에 대한 액션이 허용되는 지를 알기 위해 실시된다. 상기 테스트들은 버츄얼 머신 객체 지향 구현에서 버츄얼 머신만으로 또는 버츄얼 머신와 객체에 의해 실행될 수 있다. 임의의 테스트 결과 통과되면, 액션이 허가된다(1630). 그러나, 모든 테스트 결과가 부정적이면(162X--아니오), 액션은 금지된다. 특정 실시예에서, 보안 예외가 던져진다(1640). 상기 테스트들은 도 12 내지 도 15를 참조하여 기술된 허용된 액세스와 관련된다.

도 18은 도 15에 기술된 액세스 메소드와 함께 사용되는 도 17의 블록(1629)의 일례의 구현을 도시한 순서도이다. 테스트(829 또는 1629)와 같은 테스트에서, 버츄얼 머신은 객체가 공유 객체인지를 점검한다(1810). 만약 아니면(1810-아니오), 테스트는 실패한다. 그러나, 만약 그렇다면(1810-예), 버츄얼 머신은 객체 O에 대한 메소드 A를 호출한다(1820). 객체 O에 대한 메소드 A가 주체가 승인된 것으로 결정하면(1830), 테스트는 통과되고(1840) 액세스가 허용된다. 그렇지 않으면, 테스트는 실패한다(1850). 이는 승인 텍스트가 객체 자체의 코드로 프로그램될 수 있게 해준다.

본 발명이 스마트 카드 구현에 대해 설명되었지만, 본 발명은 단지 스마트 카드 뿐만 아니라 다른 소형 풋프린트 장치들에도 적용된다. 소형 풋프린트 장치들은 일반적으로 메모리 또는 컴퓨팅 파워 또는 속도에 있어서 제한적인 것으로 생각된다. 이러한 소형 풋프린트 장치들은 경계 스캔 장치들, 필드 프로그램 가능 장치들, 페이저 및 셀룰러 폰들을 포함할 수 있다.

일반적으로, 소형 풋프린트 장치들은 실행 콘텍스트들의 안전한 상호 동작이중요한 리소스 제한 컴퓨팅 장치들 및 시스템들이다. 이러한 소형 풋프린트 장치들은 제한된 리소스 때문에 보안 측정 구현에 있어서 제한적이다. 리소스 한계 때문에, 버츄얼 머신 구현에서, 다수의 버츄얼 머신들에 대립해서 단일의 버츄얼 또는 피지컬 머신이 사용되어야만 한다.

본 발명은 또한 본 발명의 특징들을 장점으로 입증할 수 있는 대형 풋프린트 장치들에도 적용될 수 있다. 예를 들어, 본 발명은 공유 객체가 있는 경우 서블릿(servlet)을 사용할 때 유익함을 입증할 수 있다. 몇몇 데스크탑 시스템들도 본 발명의 기술을 유익하게 이용할 수 있다.

자바^TM언어 및 플랫폼이 본 발명에 적합하지만, 특정한 특성들을 갖는 임의의 언어 또는 플랫폼도 본 발명의 구현에 적합하다. 상기 특성들은 타입 안전성, 포인터 안전성, 객체 지향, 동적 링크, 및 버츄얼 머신 베이스를 포함한다. 상기 특성들 모두가 특정 구현에 나타날 필요는 없다. 몇몇 실시예들에서, 하나 이상의 특성이 부족한 언어들 또는 플랫폼들이 사용될 수도 있다. "버츄얼 머신"는 비트(버츄얼 머신) 또는 실리콘(실제/피지컬 머신)으로 구현될 수 있다.

본 발명이 객체 단위의 보안에 대해 설명되었지만, 클래스 단위의 보안과 같은 다른 방법들이 사용될 수 있다.

본 발명이 상세히 기술되고 설명되었지만, 이는 단지 설명을 위한 것으로 제한의 의미가 아니고, 본 발명의 원리 및 범위가 첨부됨 청구항들 및 그와 등가물에 의해서만 제한됨을 명백하게 알 수 있다.

자바 ^TM 카드 ^TM 런타임 환경(JCRE) 2.1 설명서(Java ^TM Card ^TM Runtime Environment(JCRE) 2.1 Specification)

드래프트 2

Sun Microsystems, Inc.

901 San Antonio Road

Palo Alto. CA 94303 USA

650 960-1300

Draft 2, December 14, 1998

목차(Contents)

서문(Preface)

1. 개요(Introduction)

2. 자바 카드 버츄얼 머신의 수명(Java Card Virtual Machine)

3. 자바 카드 애플릿 수명(Java Card Applet Lifetime)

3.1 install 메소드(The Method install)

3.2 select 메소드(The Method select)

3.3 process 메소드(The Method process)

3.4 deselect 메소드(The Method deselect)

3.5 전력 손실 및 리셋(Power Loss and Reset)

4. 일시 객체들(Transient Objects)

4.1 일시 객체의 클리어 이벤트(Events That Clear Transient Objects)

5. 선택(Selection)

5.1 디폴트 애플릿(The Default Applet)

5.2 SELECT 명령 프로세싱(SELECT Command Processing)

5.3 Non-Select 명령 프로세싱(Non-Select Command Processing)

6. 애플릿 아이솔레이션 및 객체 공유(Applet Isolation and Object Sharing)

6.1 애플릿 파이어월(Applet Firewall)

6.1.1 콘텍스트 및 콘텍스트 스위칭(Contexts and ContextSwitching)

6.1.2 객체 소유(Object Owernership)

6.1.3 객체 액세스(Object Access)

6.1.4 파이어월 프로텍션(Firewall Protection)

6.1.5 정적 필드 및 메소드(Static Fields and Methods)

6.2 콘텍스트를 넘어선 객체 액세스(Object Access Across Contexts)

6.2.1 JCRE 엔트리 포인트 객체(JCRE Entry Point Objects)

6.2.2 글로벌 어레이(Global Arrays)

6.2.3 JCRE 특권(JCRE Privileges)

6.2.4 공유 가능 인터페이스(Shareable Interfaces)

6.2.5 이전 콘텍스트 결정(Determining the Previous Context)

6.2.6 공유 가능 인터페이스 세부 사항(Shareable Interface Details)

6.2.7 공유 가능 인터페이스 객체 획득(Obtaining Shareable Interface Objects)

6.2.8 객체 액세스 동작(Object Access Behavior)

6.3 일시 객체 및 애플릿 콘텍스트(Transient Objects and Applet Contexts)

7. 트랜잭션 및 애터미시티(Transaction and Atomicity)

7.1 애터미시티(Atomicity)

7.2 트랜잭션(Transaction)

7.3 트랜잭션 존속 기간(Transaction Duration)

7.4 중첩 트랜잭션(Nested Transactions)

7.5 티어 또는 리셋 트랜잭션의 실패(Tear or Reset Transaction Failure)

7.6 트랜잭션 중지(Aborting a Transaction)

7.6.1 프로그램에 의한 중지(Programmatic Abortion)

7.6.2 JCRE에 의한 중지(Abortion by the JCRE)

7.6.3 JCRE 클린업 책임(Cleanup Resposibilities of the JCRE)

7.7 일시 객체(Transient Objects)

7.8 커미트 용량(Commit Capacity)

8. API 토픽(API Topics)

8.1 APDU 클래스(The APDU Class)

8.1.1 출력 데이터 전송을 위한 T = 0 사양(T = 0 specifics for outgoing data transfers)

8.1.2 출력 데이터 전송을 위한 T = 1 사양(T = 1 specifics for outgoing data transfers)

8.2 보안 및 암호 패키지(The security and crypto packages)

8.3 JCSystem 클래스(JCSystem Class)

9. 버츄얼 머신 토픽(Virtual Machine Topics)

9.1 리소스 실패(Resource Failures)

10. 애플릿 인스톨러(Applet Installer)

10.1 인스톨러(The Installer)

10.1.1 인스톨러 구현(Installer Implementation)

10.1.2 인스톨러 AID(Installer AID)

10.1.3 인스톨러 APDU(Installer APDUs)

10.1.4 인스톨러 동작(Installer Behavior)

10.1.5 인스톨러 특권(Installer Privileges)

10.2 새롭게 설치된 애플릿(The Newly Installed Applet)

10.2.1 인스톨레이션 파라미터(Installation Parameters)

11. API 상수(API Constants)

서문

자바^TM카드^TM기술은 자바 프로그래밍 언어의 일부를 스마트 카드 및 관련 소형-메모리 내장 장치들을 위해 최적화된 런타임 환경과 결합시킨다. 자바 카드 기술의 목적은 리소스 제한 스마트 카드 분야에 자바 소프트웨어 프로그래밍의 다수의 장점들을 제공하는데 있다.

본 문서는 자바 카드 런타임 환경(JCRE) 2.1의 설명서이다. 자바 카드 인에이블 장치의 벤더는 JCRE 구현을 제공한다. 본 설명서의 내용에 속하는 JCRE 구현은 자바 카드 버츄얼 머신(VM)의 벤더 구현, 자바 카드 애플리케이션 프로그래밍 인터페이스(API), 또는 자바 카드 기술을 근거로 한 다른 구성 소자 사양들과 관련된다.참조 구현은 선 마이크로시스템 주식회사(Sun Microsystems, Inc.)에 의해 생산된 구현이다. 자바 카드 플랫폼을 위해 기록된 애플릿들은 자바 카드 애플릿이라고 한다.

누가 이 설명서를 사용해야 하는가?

본 설명서는 JCRE 구현자들이 구현을 생성하거나, 자바 카드 기술 설명서를 확장시키기 위해 사양을 개발하거나, 자바 카드 런타임 환경(JCRE)에 대한 확장을 실시하는 것을 돕도록 의도된 것이다. 본 설명서는 또한 자바 카드 기술 사양을 더 잘 이해하기 원하는 자바 카드 애플릿 개발자들을 위한 것이다.

본 설명서를 읽기 전에

본 설명서를 읽기 전에, 독자는 자바 프로그래밍 언어, 자바 카드 기술 사양, 및 스마트 카드 기술과 친숙해야만 한다. 자바 기술 및 자바 카드 기술과 친숙해지기 위한 좋은 리소스는 선 마이크로시스템 주식회사 웹사이트, http://java.sun.com에 있다.

본 설명서의 구성

1장, "JCRE의 범위 및 책임"은 JCRE 구현에 필요한 서비스들의 개요를 제공한다.

2장, "버츄얼 머신 수명"은 버츄얼 머신의 수명을 정의한다.

3장, "애플릿 수명"은 애플릿의 수명을 정의한다.

4장, "일시 객체"는 일시 객체의 개요를 제공한다.

5장, "선택"은 JCRE가 애플릿 선택을 처리하는 것에 대해 기술하고 있다.

6장, "애플릿 아이솔레이션 및 객체 공유"는 애플릿 아이솔레이션과 객체 공유에 대해 기술하고 있다.

7장, "트랜잭션 및 애터미시티"는 트랜잭션 중의 애터미시티의 개요를 제공한다.

8장, "API 토픽"은 JCRE에는 필요하지만 자바 카드 2.1 API 설명서에 규정되어 있지 않은 API 기능에 대해 기술하고 있다.

9장, "버츄얼 머신"는 버츄얼 머신 사양에 대해 기술하고 있다.

10장, "애플릿 인스톨러"는 애플릿 인스톨러의 개요를 제공한다.

11장, "API 상수"는 자바 카드 API 2.1 설명서에 규정되어 있지 않은 상수들의 수치를 제공한다.

용어 해설(Glossary)은 독자가 본 문서를 사용하는 것을 돕기 위해 본문에 나오는 단어들 및 그 정의의 리스트이다.

관련 문서 및 출판물

본 문서는 다양한 문서들 및 출판물을 참조했다. 참고 문헌은 다음과 같다:

■ Java Card 2.1 API Draft 2 Specification, Sun Microsystems, Inc.

■ Java Card 2.0 Lanugage Subset and Virtual Machine Specification, October 13, 1997, Revision 1.0 Final, Sun Microsystems, Inc.

■ Java Card Applet Developer's Guide, Sun Microsystems, Inc.

■ The Java Language Specification by James Gosling, Bill Joy, and Guy L. Steele. Addison-Wesley, 1996, ISBN 0-201-63451-1

■ The Java Virtual Machine Specification(Java Series) by Tim Lindholm and Frand Yellin. Addison-Wesley, 1996, ISBN 0-201-63452-X.

■ The Java Class Libraries: An Annotated Reference(Java Series) by Patrick Chan and Rosanna Lee.

■ ISO 7816 Specification Parts 1-6

■ EMV '96 Integrated Circuit Card Specification for Payment Systems.

1. 개요

자바 카드 런타임 환경(JCRE) 2.1은 자바 카드 버츄얼 머신(VM), 자바 카드 애플리케이션 프로그래밍 인터페이스(API) 클래스들(및 산업 사양 확장), 및 지원 서비스들을 포함한다.

본 문서, JCRE 2.1 설명서는 자바 카드 기술에 의해 요구되는 JCRE 기능을 규정한다. 자바 카드 기술의 임의의 구현은 필요한 동작 및 환경을 제공한다.

2. 자바 카드 버츄얼 머신의 수명

PC 또는 워크스테이션에서, 자바 버츄얼 머신은 오퍼레이팅 시스템 프로세스로서 작동한다. OS 프로세스가 종료될 때, 자바 애플리케이션 및 객체들은 자동으로 파괴된다.

자바 카드 기술에서, 버츄얼 머신(VM)의 실행 수명은 카드의 수명이다. 카드에 기억된 대부분의 정보는 카드에 전력이 제공되지 않을 때라도 보존된다. 영구 메모리 기술(예를 들면, EEPROM)은 스마트 카드가 전력이 제거될 때에도 정보를 기억할 수 있게 해준다. 버츄얼 머신 및 카드에 생성된 객체들이 영구적인 애플리케이션 정보를 나타내는데 사용되기 때문에, 자바 카드 버츄얼 머신은 명백하게 영구히 작동된다. 전력이 제거될 때, 버츄얼 머신은 일시적으로만 정지한다. 카드가 다시 리셋되면, 버츄얼 머신은 다시 작동하기 시작하고 이전 객체 히프(heap)를 영구 기억 장치로부터 복구한다.

영구적인 속성 외에도 자바 카드 버츄얼 머신은 자바 버츄얼 머신와 유사하다.

카드 초기화 시간은 마스킹 후 및 카드 개인화 및 발행 시간 전 시간이다. 카드를 초기화할 때, JCRE가 초기화된다. JCRE에 의해 생성된 프레임워크 객체들은 버츄얼 머신 수명 동안 존재한다. 버츄얼 머신 및 JCRE 프레임워크의 실행 수명이 카드의 CAD 세션 기간이기 때문에, 애플릿에 의해 생성된 객체들의 수명도 또한 CAD 세션 기간이다. (CAD는 카드 수용 장치 또는 카드 판독기를 의미한다. 카드 세션은 카드가 CAD에 삽입되어, 파워 업되고 APDU 스트림들을 CAD와 교환하는기간이다. 카드 세션은 카드가 CAD로부터 제거될 때 종료된다.) 이러한 속성을 갖는 객체를 영구 객체라고 한다.

JCRE 구현자는 이하의 상황일 때 객체를 영구적이게 한다:

ㆍ Applet.register 메소드가 호출된다. JCRE는 애플릿 객체의 인스턴스에 대한 참조를 기억한다. JCRE 구현자는 클래스 Applet의 인스턴스들이 영구적임을 보장한다.

ㆍ 객체 참조는 임의의 다른 영구 객체 필드 또는 클래스의 정적 필드에 기억된다. 이 요구 사항은 JCRE 내부 데이터 구조의 완전성을 보존할 필요성으로 인한 것이다.

3. 자바 카드 애플릿 수명

본 설명서를 위해, 자바 카드 애플릿의 수명은 카드 메모리에 정확하게 로드되고 링크되어 실행할 준비가 된 순간부터 시작한다. (본 설명서의 나머지 부분에서, 애플릿은 자바 카드 플랫폼을 위해 기록된 애플릿과 관계된다.) Applet.register 메소드에 의해 등록된 애플릿들은 카드 수명 동안 존재한다. JCRE는 애플릿의 퍼블릭 메소드들, install, select, deselect, 및 process 메소드들을 통해 애플릿과 상호 동작한다. 애플릿은 정적 install 메소드를 구현한다. install 메소드가 구현되지 않으면, 애플릿의 객체들은 생성되거나 초기화될 수 없다. JCRE 구현은 이하에 기술된 애플릿의 install, select, deselect, 및 process 메소드들을 호출한다.

애플릿이 스마트 카드에 설치될 때, 정적 install 메소드는 생성된 각각의 애플릿 인스턴스를 위해 JCRE에 의해 일단 호출된다.

3.1 install 메소드

install이 호출될 때, 애플릿 객체는 존재하지 않는다. 애플릿 내의 install 메소드의 주요 태스크는 Applet 클래스의 인스턴스를 생성하고 인스턴스를 등록하는데 있다. 애플릿이 수명 중에 필요로 하는 모든 다른 객체들은 적합하게 생성될 수 있다. CAD에 의해 선택되고 액세스될 애플릿을 위해 필요한 임의의 다른 준비 사항들도 적합하게 갖춰질 수 있다. install 메소드는 입력 바이트 어레이 파라미터의 콘텐츠로부터 초기화 파라미터들을 획득한다.

전형적으로, 애플릿은 다양한 객체들을 생성하고 상기 객체들을 선정된 값들로 초기화하고, 몇몇 내부 상태 변수들을 설정하고, Applet.register 메소드를 호출해서 선택을 위해 사용될 AID(ISO 7816-5에 의해 정의된 애플릿 식별자(Applet IDentifier))를 규정한다. 이 인스톨레이션은 Applet.register 메소드에 대한 호출이 예외 없이 완료될 때 성공적이라고 간주된다. 인스톨레이션은 install 메소드가 Applet.register 메소드를 호출하지 않는 경우, 또는 Applet.register 메소드가 호출되기 전에 install 메소드 내에서 예외가 발생되는 경우, 또는 Applet.register 메소드가 예외를 시키는 경우에는 성공하지 못한것으로 간주된다. 인스톨레이션이 성공하지 못하면, JCRE는 제어를 다시 획득할 때 모든 클린업을 실행한다. 즉, 모든 영구 객체들은 install 메소드를 호출하기 이전의 상태로 리턴된다. 인스톨레이션이 성공적이면, JCRE는 애플릿이 선택을 위해 유효하다고 마크할 수 있다.

3.2 select 메소드

애플릿들은 명시적으로 선택될 때까지 중지 상태에 머문다. 명칭 데이터가 애플릿의 AID와 일치하는 SELECT APDU를 JCRE가 수신할 때 선택이 발생한다. 선택은 애플릿이 현재 선택 애플릿이 되게 한다.

SELECT를 호출하기 전에, JCRE는 이전 선택 애플릿을 선택 해제한다. JCRE는 애플릿의 deselect 메소드를 호출함으로써 애플릿에게 이전 선택 애플릿의 선택 해제를 알린다.

JCRE는 select 메소드를 호출함으로써 선택을 애플릿에게 알려준다.

애플릿은 select 메소드에 대한 호출로부터 false를 리턴함으로써 또는 예외를 발생시켜 선택되는 것을 거절할 수도 있다. 애플릿이 true를 리턴하면, 실제 SELECT APDU 명령은 process 메소드에 대한 다음 호출시 애플릿에 제공되어서, 애플릿이 APDU 콘텐츠를 검사할 수 있게 된다. 임의의 다른 APDU 명령을 프로세스하는 것과 똑같은 방식으로 애플릿은 SELECT APDU 명령을 프로세스할 수 있다. 애플릿은 데이터로 SELECT APDU에 응답할 수 있고(자세한 설명을 원하면 process 메소드를 참조하라), 또는 적합한 SW(상태 단어(status word)를 리턴)로 ISOException을 발생시켜 에러들을 플래그할 수 있다. SW 및 선택 응답 데이터는 CAD로 리턴된다.

Applet.selectingApplet 메소드는 select 메소드 중에 호출될 때 true를 리턴한다. Applet.selectingApplet 메소드는 SELECT APDU 명령을 프로세스하도록 호출되는 다음 process 메소드 중에 계속해서 true를 리턴한다.

애플릿이 선택되기를 거절하면, JCRE는 ISO.SW_APPLET_SELECT_FAILED라는 APDU 응답 상태 단어를 CAD에게 리턴한다. 선택 실패시, JCRE 상태는 애플릿이 선택되지 않았음을 나타내도록 설정된다.

성공적인 선택 후에, 모든 다음 APDU들은 process 메소드를 통해 현재 선택 애플릿에게 전달된다.

3.3 process 메소드

모든 APDU들은 APDU 클래스의 인스턴스를 현재 선택 애플릿의 process 메소드에게 전달하는 JCRE에 의해 수신된다.

주지 사항 - SELECT APDU는 process 메소드에 대한 호출 전에 현재 선택 애플릿의 변경을 야기할 수도 있다.

정상 리턴시, JCRE는 애플릿에 의해 이미 송신된 임의의 데이터에 완료 응답 SW로서 0x9000을 자동으로 부가한다.

process 중 임의의 시간에, 애플릿은 적합한 SW로 ISOException을 발생시킬 수도 있는데, 이러한 경우에, JCRE는 예외를 획득해서 SW를 CAD에게 리턴한다.

process 중에 임의의 다른 예외가 발생되면, JCRE는 예외를 획득해서 상태 단어 ISO7816.SW_UNKNOWN을 CAD에게 리턴한다.

3.4 선택 해제 메소드

JCRE가 명칭이 애플릿의 AID와 일치하는 SELECT APDU 명령을 수신할 때, JCRE는 현재 선택 애플릿의 DESELECT 메소드를 호출한다. 이는 다른 몇몇 애플릿의 실행을 가능케하기 위해 필요할 수 있는 임의의 클린업 오퍼레이션들을 애플릿이 실행하게 한다.

Applet.selectingApplet 메소드는 deselect 메소드 중에 호출될 때 false를 리턴한다. deselect 메소드에 의해 던져진 예외는 JCRE에 의해 획득되지만, 애플릿은 선택해제된다.

3.5 전력 손실 및 리셋

카드가 CAD로부터 빠져나올 때 또는 몇몇 다른 기계적 또는 전기적 고장이 발생하면, 전력 손실이 발생한다. 전력이 카드에 다시 인가되어 카드가 리셋되면(따뜻해지거나 또는 차가워짐), JCRE는 다음을 보장한다:

ㆍ 일시 데이터가 디폴트 값으로 리셋된다.

ㆍ 만약 전력이 손실되면(또는 리셋이 발생되면) 진행중인 트랜잭션이 중지된다.

ㆍ 전력이 손실될 때(또는 리셋이 발생될 때) 선택된 애플릿은 암시적으로 선택 해제된다. (이러한 경우에, deselect 메소드가 호출되지 않는다.)

ㆍ JCRE가 디폴트 애플릿 선택을 구현하면(5.1절 참조), 디폴트 애플릿이 현재 선택 애플릿으로 선택되고, 디폴트 애플릿의 select 메소드가 호출된다. 그렇지 않으면, JCRE는 애플릿이 선택되지 않았음을 나타내도록 상태를 설정한다.

4. 일시 객체들

애플릿들은 종종 CAD 세션 후에도 지속될 필요가 없는 임시(일시) 데이터를 포함하는 객체들을 필요로 한다. 자바 카드는 자바 키워드 transient를 지원하지 않는다. 그러나, 자바 카드 기술은 원시 컴포넌트들 또는 객체 참조들을 갖는 일시 어레이들을 생성하는 메소드들을 제공한다.

"일시 객체"라는 용어는 오칭이다. 객체 자체가 일시적이라고 의미한다고 잘못 해석될 수 있다. 그러나, 객체 필드들(길이 필드는 제외)의 콘텐츠는 일시적인 속성을 갖는다. 자바 프로그래밍 언어로 된 임의의 다른 객체의 경우와 같이, 이하의 사항들과 관계되는 한 자바 카드 플랫폼 내에 일시적인 객체들은 계속 존재한다:

ㆍ 스택

ㆍ 로컬 변수

ㆍ 클래스 정적 필드

ㆍ 다른 현존 객체의 필드

자바 카드 플랫폼 내의 일시 객체는 이하의 요구 사항들을 갖는다:

ㆍ 일시 객체의 필드들은 특정 이벤트 발생시 필드의 디폴트 값(0, false, 또는 null)로 클리어된다(이하 참조).

ㆍ 보안을 위하여, 일시 객체의 필드들은 "영구 메모리 기술"로 결코 기억되지 않는다. 일례로서 현재의 스마트 카드 기술을 사용해서, 일시 객체들의 콘텐츠들은 RAM에 기억될 수 있지만, EEPROM에는 결코 기억될 수 없다. 이러한 요구사항들의 목적은 일시 객체가 세션 키들을 기억하는데 사용되도록 하는데 있다.

ㆍ 일시 객체의 필드 기록은 퍼포먼스 패널티(performance penalty)를 갖지 않는다. (일례로서 현재 스마트 카드 기술을 사용해서, 일시 객체들의 콘텐츠들은 RAM에 기억될 수 있고, 비일시적인 객체들의 콘텐츠들은 EEPROM에 기억될 수 있다. 전형적으로, RMA 기술은 EEPROM 보다 훨씬 빠른 기록 주기를 갖는다.)

ㆍ 일시 객체의 필드 기록은 "트랜잭션"에 의해 영향을 받지 않는다. 즉, abortTransaction은 결코 일시 객체의 필드가 이전 값으로 복원되게 하지 않는다.

상기 사항들은 일시 객체들이 종종 수정되지만 CAD 또는 선택 세션 후에는 보존될 필요가 없는 소량의 임시 애플릿 데이터에 적합하게 한다.

4.1 일시 객체의 클리어 이벤트

영구 객체들은 카드 리셋 후에 보존될 상태들을 유지하기 위해 사용된다. 일시 객체가 생성될 때, 2개의 이벤트들 중에 한 이벤트가 지정되어 필드가 클리어되게 한다. CLEAR_ON_RESET 일시 객체들은 애플릿 선택 후에는 보존되어야 하지만 카드 리셋 후에는 보존될 필요가 없는 상태들을 유지하기 위해 사용된다. CLEAR_ON_DESELECT 일시 객체들은 애플릿이 선택되는 동안 유지되어야만 하지만, 애플릿 선택 또는 카드 리셋 후에는 보존될 필요가 없는 상태들을 유지하기 위해 사용된다.

2가지 클리어 이벤트들의 세부 사항은 다음과 같다:

ㆍ CLEAR_ON_RESET - 객체 필드들은 카드가 리셋될 때 클리어된다. 카드가 파워 온 될 때, 카드가 리셋된다.

주지 사항 - 전원이 카드로부터 제거되기 전에 일시 객체들의 필드들을 클리어할 필요는 없다. 그러나, 일단 전력이 손실되면, 상기 필드들의 이전 콘텐츠가 복구될 수 없음을 보장할 필요는 있다.

ㆍ CLEAR_ON_DESELECT - 객체 필드들은 임의의 애플릿이 선택해제될 때마다 클리어된다. 카드 리셋이 현재 선택 애플릿을 암시적으로 선택 해제하기 때문에, CLEAR_ON_DESELECT 객체 필드들은 CLEAR_ON_RESET을 위해 지정된 동일한 이벤트들에 의해 클리어된다.

현재 선택 애플릿은 SELECT 명령이 프로세스될 때만 명시적으로 선택 해제된다(deselect 메소드가 호출된다). 현재 선택 애플릿이 선택 해제된 후, 모든 CLEAR_ON_DESELECT 일시 객체들의 필드들이 선택 명령의 이하의 사항들과 무관하게 클리어된다:

ㆍ 애플릿 선택에 실패.

ㆍ 상이한 애플릿 선택.

ㆍ 동일한 애플릿 재선택.

5. 선택

카드들은 APDU 형태로 CAD로부터 서비스 요청을 수신한다. SELECT APDU는 현재 선택 애플릿을 지정하기 위해 JCRE에 의해 사용된다. 일단 선택되면, 애플릿은 애플릿이 선택 해제될 때까지 모든 다음 APDU들을 수신한다.

이하의 사항이 발생할 때 현재 선택 애플릿은 존재하지 않는다:

ㆍ 카드가 리셋되고 디폴트 애플릿으로서 선정된 애플릿이 하나도 없는 경우.

ㆍ SELECT 명령이 애플릿을 선택하고자할 때 실패한 경우.

5.1 디폴트 애플릿

정상적으로, 애플릿들은 성공적인 SELECT 명령을 통해서만 선택된다. 그러나, 몇몇 스마트 카드 CAD 애플리케이션들은 매 카드 리셋 후에 암시적으로 선택된 디폴트 애플릿이 존재할 것을 요구한다. 동작은 다음과 같다:

1. 카드 리셋(또는 일종의 리셋 형태인 파워 온) 후, JCRE는 초기화를 실행하고 내부 상태가 특정 애플릿이 디폴트 애플릿임을 나타내는지를 점검한다. 만약 그렇다면, JCRE는 이 애플릿이 현재 선택 애플릿이 되게 하고, 애플릿의 select 메소드가 호출된다. 애플릿의 select 메소드가 예외를 발생시키거나 false를 리턴하면, JCRE는 애플릿이 선택되지 않았음을 나타내는 상태를 설정한다. (SELECT APDU가 없기 때문에 애플릿의 process 메소드는 디폴트 애플릿 선택 중에는 호출되지 않는다.) 디폴트 애플릿이 카드 리셋시 선택될 때, process 메소드가 호출될 필요는 없다.

2. JCRE는 ATR이 송신되었고 카드가 현재 APDU 명령들을 수용할 준비가 된 상태임을 보장한다.

디폴트 애플릿이 성공적으로 선택되었으면, APDU 명령들은 애플릿으로 직접 송신될 수 있다. 디폴트 애플릿이 선택되지 않았으면, SELECT 명령들만이 프로세스될 수 있다.

디폴트 애플릿을 규정하기 위한 메카니즘은 자바 카드 API 2.1에는 정의되어 있지 않다. 이는 JCRE 구현 세부 사항으로 개별 JCRE 구현자들의 몫이다.

5.2 SELECT 명령 프로세싱

SELECT APDU 명령은 애플릿을 선택하는데 사용된다. 그 동작은 다음과 같다:

1. SELECT APDU는 만약 어떠한 애플릿이 능동 상태가 되더라도 그와 상관 없이 항상 JCRE에 의해 프로세스된다.

2. JCRE는 일치하는 AID를 찾기 위해 내부 표를 탐색한다. JCRE는 SELECT 명령에서 전체 AID가 존재하는 애플릿을 선택하는 것을 지원한다.

JCRE 구현은 다른 선택 기준을 지원하도록 JCRE를 강화하는데 자유롭다. 이 일례는 ISO 7816-4에 규정된 부분 AID 일치를 통한 선택이다. 특정 요구사항들은 다음과 같다:

주지사항- *는 ISO7816에서 매겨진 바이너리 비트를 나타낸다. 최상위 비트는 b8이다. 최하위 비트는 b1이다.

a) 애플릿 SELECT 명령은 CLA = 0x00, INS = 0xA4를 사용한다.

b) 애플릿 SELECT 명령은 "DF 명칭에 의한 선택"을 사용한다. 따라서, P1 = 0x04 이다.

c) P1의 임의의 다른 값은 애플릿 선택이 아니다. APDU는 현재 선택 애플릿에 의해 프로세스된다.

d) JCRE는 정확한 DF 명칭(AID) 선택, 즉, P2 = %b0000 xx00을 지원한다(b4, b3*는 상관하지 않는다).

e) 모든 다른 부분 DF 명칭 SELECT 옵션들(b2, b1*)은 JCRE 구현에 종속된다.

f) 모든 파일 제어 정보 옵션 코드들(b4, b3*)은 JCRE에 의해 지원되고 애플릿에 의해 해석되고 프로세스된다.

3. 일치하는 AID가 없는 경우:

a. 현재 선택 애플릿이 없는 경우, JCRE는 상태 코드 0x6999(SW_APPLET_SELECT_FAILED)로 SELECT 명령에 응답한다.

b. 다른 경우, SELECT 명령은 현재 선택 애플릿의 process 메소드로 발송된다. 이 때에 애플릿 콘텍스트으로의 콘텍스트 스위칭이 발생한다. (애플릿 콘텍스트는 6.1.1절에 정의되어 있다.) 애플릿들은 자체 내부 SELECT 프로세싱을 위해 SELECT APDU 명령을 사용할 수도 있다.

4. 일치하는 AID가 있으면, JCRE는 새로운 애플릿을 선택할 준비를 한다. 현재 선택 애플릿이 있으면, deselect 메소드를 호출함으로써 현재 선택 애플릿이 선택 해제된다. 선택 해제된 애플릿의 콘텍스트으로의 콘텍스트 스위칭은 이 때에발생한다. JCRE 콘텍스트는 deselect 메소드 종료시 복원된다.

5. JCRE는 새로운 현재 선택 애플릿을 설정한다. 새로운 애플릿은 select 메소드를 호출함으로써 선택되고, 새로운 애플릿의 콘텍스트으로의 콘텍스트 스위칭이 발생한다.

a. 애플릿의 select 메소드가 예외를 던지거나 false를 리턴하면, JCRE 상태는 애플릿이 선택되지 않도록 설정된다. JCRE는 상태 코드 0x6999(SW_APPLET_SELECT_FAILED)로 SELECT 명령에 응답한다.

b. 새로운 현재 선택 애플릿의 process 메소드가 입력 파라미터인 SELECT APDU로 호출된다. 애플릿의 콘텍스트으로의 콘텍스트 스위칭이 발생한다.

주지사항

- 일치하는 AID가 없으면, SELECT 명령은 정상 애플릿 APDU 명령으로서 프로세싱을 위해 현재 선택 애플릿(만약 있으면)으로 발송된다.

- 일치하는 AID가 있고, SELECT 명령이 실패하면, JCRE는 항상 애플릿이 선택되지 않은 상태가 된다.

- 일치하는 AID가 현재 선택 애플릿과 동일하면, JCRE는 애플릿을 선택 해제한 후 선택하는 프로세스를 실행하게 된다. 재선택이 실패하면, 카드는 애플릿이 선택되지 않은 상태로 남게 된다.

5.3 Non-SELECT 명령 프로세싱

non-SELECT APDU가 수신되고 현재 선택 애플릿이 없을 때, JCRE는 상태 코드 0x6999(SW_APPLET_SELECT_FAILED)로 APDU에게 응답한다.

non-SELECT APDU가 수신되고 현재 선택 애플릿이 있을 때, JCRE는 APDU를 파라미터로서 전달하는 현재 선택 애플릿의 process 메소드를 호출한다. 이는 JCRE 콘텍스트으로부터 현재 선택 애플릿의 콘텍스트으로의 콘텍스트 스위칭을 야기한다. process 메소드가 종료될 때, VM은 JCRE 콘텍스트으로 다시 전환한다. JCRE는 응답 APDU를 송신하고 다음 명령 APDU를 대기한다.

6. 애플릿 아이솔레이션 및 객체 공유

JCRE의 임의의 구현은 콘텍스트들 및 애플릿들의 아이솔레이션을 지원한다. 아이솔레이션은 다른 애플릿이 액세스를 위한 인터페이스를 명시적으로 제공하지 않는 한 하나의 애플릿이 다른 콘텍스트의 애플릿의 필드들 또는 객체들에 액세스할 수 없음을 의미한다. 애플릿 아이솔레이션 및 객체 공유를 위한 JCRE 메카니즘들이 이하의 섹션에 상세히 기술되어 있다.

6.1 애플릿 파이어월

자바 카드 기술 내의 애플릿 파이어월은 런타임-강화 프로텍션이고 자바 기술 프로텍션과 분리된다. 자바 언어 프로텍션들은 자바 카드 애플릿들에게 적용된다. 자바 언어들은 강력한 타이핑 및 프로텍션 속성들이 강화된 것임을 보장한다.

애플릿 파이어월들은 항상 자바 카드 버츄얼 머신에서 강화된 것이다. 이들은 버츄얼 머신들이 런타임에서 추가 보안 점검을 자동으로 실행하게 한다.

6.1.1 콘텍스트 및 콘텍스트 스위칭

파이어월들은 본래 자바 카드 플랫폼의 객체 시스템을 콘텍스트가라고 하는 개별적인 프로텍션 객체 공간들로 분할한다. 파이어월은 콘텍스트들 간의 경계이다. JCRE는 카드에 설치된 각각의 애플릿에 대한 애플릿 콘텍스트를 할당하고 관리한다. (그룹 콘텍스트들에 대한 설명은 이하의 6.1.1.2절을 참조하라.)

또한, JCRE는 자체 JCRE 콘텍스트를 유지한다. 이 콘텍스트는 애플릿 콘텍스트과 매우 유사하지만, 특별한 시스템 특권들을 갖고 있어서 애플릿 콘텍스트들에게 거절된 오퍼레이션들을 실행할 수 있게 한다.

임의의 시간에, 버츄얼 머신 내에는 오직 하나의 능동 콘텍스트만이 존재한다. (이를 현재 능동 콘텍스트가라고 한다.) 객체들에 액세스하는 모든 바이트코드들은 런타임에서 액세스가 허가된 것인지를 결정하기 위해 현재 능동 콘텍스트에 대해 점검된다. 액세스가 금지될 때 java.lang.SecurityException이 던져진다.

6.2.8절에 기술된 바와 같이 호출형(invoke-type) 바이트코드들의 실행 중에 특정하게 정의된 조건들이 만족되었을 때, 버츄얼 머신은 콘텍스트 스위칭을 실행한다. 이전 콘텍스트가 내부 버츄얼 머신 스택에 푸시되고, 새로운 콘텍스트가 현재 능동 콘텍스트가 되고, 호출된 메소드가 새로운 콘텍스트에서 실행된다. 메소드 종료시, 버츄얼 머신은 복원 콘텍스트 스위칭을 실행한다. 고유 콘텍스트(메소드 호출자의)이 스택으로부터 팝되고 현재 능동 콘텍스트으로서 복원된다. 콘텍스트 스위칭들은 중첩될 수 있다. 최대 깊이는 유효한 버츄얼 머신 스택 공간의 양에 좌우된다.

자바 카드 기술의 대부분의 메소드 호출은 콘텍스트 스위칭을 야기하지 않는다. 콘텍스트 스위칭들은 특정 메소드 호출 및 리턴 중에만 또한 상기 메소드들로부터의 예외 종료 중에만 발생한다(6.2.8 참조).

콘텍스트 스위칭 메소드 호출 중에, 현재 능동 콘텍스트를 나타내는 추가 데이터가 리턴 스택에 푸시된다. 이 콘텍스트는 메소드가 종료될 때 복원된다.

콘텍스트 및 콘텍스트 스위칭에 대한 더 자세한 설명은 본 장의 다음 절들에서 제공된다.

6.1.1.1 그룹 콘텍스트들

통상, 자바 카드 애플릿의 각각의 인스턴스는 개별 콘텍스트를 정의한다. 자바 카드 2.1 기술에서는, 그룹 콘텍스트가라는 개념이 도입되었다. 하나 보다 많은 애플릿이 단일 자바 패키지에 포함되면, 애플릿들은 동일한 콘텍스트를 공유한다. 또한, 동일한 애플릿 클래스의 모든 인스턴스들은 동일한 콘텍스트를 공유한다. 다시 말해서, 한 그룹 콘텍스트의 2개의 애플릿 인스턴스들 간에는 파이어월이 없다.

6.1.1 섹션에 상술된 콘텍스트 및 콘텍스트 스위칭에 대한 설명은 각각의 애플릿 인스턴스가 개별 콘텍스트과 연관된다고 생각한다. 자바 카드 2.1 기술에서, 콘텍스트들은 파이어월을 강화하기 위해 비교되고 인스턴스 AID가 스택에 푸시된다. 또한, 이는 콘텍스트가 전환될 때뿐만 아니라 한 애플릿 인스턴스에 의해 소유된 객체로부터 동일한 패키지 내의 다른 인스턴스에 의해 소유된 객체로 제어가 전환될 때에도 발생한다.

6.1.2 객체 소유

새로운 객체가 생성될 때, 새로운 객체는 현재 능동 콘텍스트과 연관된다. 그러나, 객체는 객체가 인스턴스화될(instantiated) 때 현재 능동 콘텍스트 내의 애플릿 인스턴스에 의해 소유된다. 객체는 애플릿 인스턴스 또는 JCRE에 의해서 소유된다.

6.1.3 객체 액세스

일반적으로, 객체는 소유 콘텍스트에 의해서만 액세스될 수 있다. 즉, 소유 콘텍스트가 현재 능동 콘텍스트일 때만 액세스될 수 있다. 파이어월은 객체가 상이한 콘텍스트의 다른 애플릿에 의해서 액세스되는 것을 방지한다.

구현이라는 점에서, 객체가 액세스될 때마다, 객체의 소유자 콘텍스트는 현재 능동 콘텍스트과 비교된다. 서로 일치하지 않으면, 액세스가 실행되지 않고 SecurityException이 던져진다.

객체 참조를 사용해서 이하의 바이트코드들 중 하나가 실행될 때 객체가 액세스된다:

<T>는 baload, sastore 등과 같은 어레이 바이트코드들의 다양한 타입들과 관련된다.

상기 리스트는 getfield_b, sgetfield_s_this 등과 같은 자바 카드 버츄얼 머신에서 구현된 임의의 특정한 또는 최적화된 바이트코드들을 포함한다.

6.1.4 파이어월 프로텍션

자바 카드 파이어월은 가장 빈번하게 예측되는 이하의 보안 문제에 대한 프로텍션을 제공한다: 민감한 데이터가 다른 애플릿에게 "리크되게(leaked)" 할 수 있는 개발자 실수 및 설계 실수. 애플릿은 퍼블릭 액세스 가능 로케이션으로부터 객체 참조를 획득할 수도 있지만, 객체가 상이한 애플릿에 의해 소유된 경우, 파이어월은 보안을 보장한다.

파이어월은 또한 부정확한 코드에 대한 프로텍션도 제공한다. 부정확한 코드가 카드에 로드되면, 파이어월은 여전히 상기 코드에 의해 액세스 되는 것으로부터 객체를 보호한다.

자바 카드 API 2.1은 콘텍스트들 및 파이어월들의 기본적인 최소 프로텍션 요구 사항들을 규정하고 있는데 이는 상기 특징들이 애플릿 개발자에게 명백하지 않은 방식으로 지원되기 때문이다. 개발자들은 객체의 동작, API들 및 파이어월과 관련된 예외들을 알고 있어야 한다.

메카니즘들이 애플릿들에게 명백하고 버츄얼 머신의 외부적으로 가시적인 오퍼레이션을변경시키지 않는 한 JCRE 구현자들은 애플릿 파이어월의 메카니즘 외에 추가 보안 메카니즘들을 구현하는데 자유롭다.

6.1.5 정적 필드 및 메소드

또한 클래스들이 콘텍스트들에 의해 소유되지 않음을 주지해야만 한다. 클래스 정적 필드가 액세스될 때 실행될 수 있는 런타임 콘텍스트 점검은 존재하지 않는다. 정적 메소드가 호출될 때 콘텍스트 스위칭도 존재하지 않는다. (유사하게, invokespecial이 콘텍스트 스위칭을 야기하지 않는다.)

퍼블릭 정적 필드들 및 퍼블릭 정적 메소드들은 임의의 콘텍스트으로부터 액세스 가능하다: 정적 메소드들은 호출자와 동일한 콘텍스트에서 실행된다.

정적 필드의 참조 객체들은 정규 객체들이다. 이 객체들은 생성한 자들에 의해 소유되고 표준 파이어월 액세스 규칙이 적용된다. 다수의 애플릿 콘텍스트들에 걸쳐 객체들을 공유할 필요가 있는 경우, 상기 객체들은 공유 가능 인터페이스 객체(SIO; Shareable Interface Object)들이 될 필요가 있다. (이하의 6.2.4절을 참조하라.)

물론, 종래의 자바 기술 프로텍션들도 여전히 정적 필드들 및 메소드들을 위해 강화된다. 또한, 애플릿들이 설치될 때, 인스톨러는 각각의 애플릿이 외부 정적 필드와 링크되고자 하는지를 또는 메소드가 허가된 것인지를 검증한다. 링크에 대한 인스톨레이션 및 규정들은 본 설명서의 범위 밖이다.

6.1.5.1 선택적인 정적 액세스 점검

JCRE는 검증기에 의해 강화된 제약 조건들로 여분의 선택적인 런타임 점검들을 실행한다. 자바 카드 버츄얼 머신은 다른 클래스의 사적인 메소드를 호출하는 것과 같이 코드가 기본 언어 제약 조건들을 위반했을 때를 검출하고, 상기 위반을 보고하거나 처리한다.

6.2 콘텍스트를 넘어선 객체 액세스

애플릿들이 서로 상호작용하거나 JCRE와 상호작용할 수 있도록, 몇몇 정의된 보안 메카니즘들이 제공되어 한 콘텍스트가 다른 콘텍스트에 속한 객체에 액세스할 수 있게 해준다.

상기 메카니즘들은 자바 카드 API 2.1에 제공되어 있고 이하의 섹션들에서 논의된다:

ㆍ JCRE 엔트리 포인트 객체

ㆍ 글로벌 어레이

ㆍ JCRE 특권

ㆍ 공유 가능 인터페이스

6.2.1 JCRE 엔트리 포인트 객체

보안 컴퓨터 시스템들은 비특권 사용자 프로세스들(리소스들의 서브셋에 한정됨)이 특권 "시스템" 루틴들에 의해 실행되는 시스템 서비스들을 요청하는 방법을 갖고 있다.

자바 카드 API 2.1에서, 이는 JCRE 엔트리 포인트 객체들을 사용해서 달성된다. 이 객체들은 JCRE 콘텍스트에 의해 소유되는 객체들이지만, 엔트리 포인트 메소드들을 포함하는 것으로 플래그화되었다.

파이어월은 애플릿에 의해 액세스되는 것으로부터 객체들을 보호한다. 엔트리 포인트 지정은 상기 객체들의 메소드들이 임의의 콘텍스트으로부터 호출되게 해준다. 그러한 상황이 발생할 때, JCRE 콘텍스트으로의 콘텍스트 스위칭이 실행된다. 상기 메소드들은 애플릿들이 특권 JCRE 시스템 서비스들을 요청하는 게이트웨이들이다.

2가지 카테고리의 JCRE 엔트리 포인트 객체들이 있다:

ㆍ 임시 JCRE 엔트리 포인트 객체

모든 JCRE 엔트리 포인트 객체들처럼, 임시 JCRE 엔트리 포인트 객체들의 메소드들은 임의의 애플릿 콘텍스트으로부터 호출될 수 있다. 그러나, 상기 객체들에 대한 참조들은 클래스 변수들, 인스턴스 변수들 또는 어레이 컴포넌트들로 기억될 수 없다. JCRE는 승인되지 않은 재사용을 방지하기 위해 상기 객체들에 대한 참조들을 파이어월 기능의 파트로서 기억하고자 하는 시도들을 검출하고 제한한다.

APDU 객체 및 모든 JCRE 소유 예외 객체들은 임시 JCRE 엔트리 포인트객체의 일례들이다.

ㆍ 영구 JCRE 엔트리 포인트 객체

모든 JCRE 엔트리 포인트 객체들처럼, 영구 JCRE 엔트리 포인트 객체들의 메소드들은 임의의 애플릿 콘텍스트으로부터 호출될 수 있다. 또한, 상기 객체들에 대한 참조들도 기억되어 자유롭게 재사용될 수 있다.

JCRE 소유 AID 인스턴스들은 영구 JCRE 엔트리 포인트 객체들의 일례들이다.

JCRE는 이하의 책임이 있다:

ㆍ 특권 서비스들이 애플릿들에게 제공되었는지를 결정할 책임.

ㆍ 상기 서비스들을 위한 엔트리 포인트 메소드들을 포함하는 클래스들을 정의할 책임.

ㆍ 상기 클래스들의 하나 이상의 객체 인스턴스들을 생성할 책임.

ㆍ 상기 인스턴스들을 JCRE 엔트리 포인트 객체들로서 지정할 책임.

ㆍ JCRE 엔트리 포인트 객체들을 임시 또는 영구 객체들로 지정할 책임.

ㆍ 필요한 경우 애플릿들에게 유용한 상기 객체들에 대한 참조들을 달성할 책임.

주지 사항 - 상기 객체들의 메소드들만이 파이어월을 통해 액세스될 수 있다. 상기 객체들의 필드들은 여전히 파이어월에 의해 보호되고 JCRE 콘텍스트에 의해서만 액세스될 수 있다.

JCRE 자체만이 엔트리 포인트 객체들을 지정하고 상기 객체들이 임시적인지영구적인지를 지정할 수 있다. JCRE 구현자들은 JCRE 엔트리 포인트 객체들이 지정되고 상기 객체들이 임시적인지 또는 영구적인지를 지정하는 메카니즘을 구현할 책임이 있다.

6.2.2 글로벌 어레이

몇몇 객체들의 글로벌 속성은 임의의 애플릿 콘텍스트들로부터 액세스될 수 있도록 요구한다. 파이어월은 통상 상기 객체들이 유연한 방식으로 사용되는 것을 방지한다. 자바 카드 버츄얼 머신은 오브젝트가 글로벌로서 지정되게 한다.

모든 글로벌 어레이들은 임시 글로벌 어레이 객체들이다. 상기 객체들은 JCRE 콘텍스트에 의해 소유되지만, 임의의 애플릿 콘텍스트으로부터 액세스될 수 있다. 그러나, 상기 객체들에 대한 참조들은 클래스 변수들, 인스턴스 변수들 또는 어레이 컴포넌트들로 기억될 수 없다. JCRE는 승인되지 않은 재사용을 방지하기 위해 상기 객체들에 대한 참조들을 파이어월 기능의 파트로서 기억하고자 하는 시도들을 검출하고 제한한다.

부가된 보안을 위해, 어레이들만이 글로벌로서 지정될 수 있고 JCRE 자체만이 글로벌 어레이들을 지정할 수 있다. 애플릿들이 글로벌 어레이들을 생성할 수 없기 때문에, API 메소드들은 정의되지 않는다. JCRE 구현자들은 글로벌 어레이들이 지정되는 메카니즘들을 구현할 책임이 있다.

본 설명서를 공개할 때, 자바 카드 API 2.1에 필요한 글로벌 어레이들은 APDU 버퍼 및 애플릿의 install 메소드에 대한 바이트 어레이 입력 파라미터(bArray)이다.

주지 사항 - 글로벌 상태 때문에, JCRE가 새로운 APDU 명령을 수용하기 전에, API는 애플릿이 선택될 때마다 APDU 버퍼가 0으로 클리어될 것을 규정한다. 이는 애플릿의 잠정적으로 민감한 데이터가 글로벌 APDU 버퍼를 통해 다른 애플릿에게 "리크되는" 것을 방지하기 위한 것이다. APDU 버퍼는 공유 인터페이스 객체 콘텍스트으로부터 액세스될 수 있고 애플릿 콘텍스트들에 걸쳐 데이터를 전달하기에 적합하다. 애플릿은 APDU 버퍼로부터 액세스될 수도 있는 비밀 데이터를 보호할 책임이 있다.

6.2.3 JCRE 특권

JCRE 콘텍스트가 "시스템" 콘텍스트가기 때문에, JCRE 콘텍스트는 특별한 특권을 갖는다. 이는 카드의 임의의 객체의 메소드를 호출할 수 있다. 예를 들어, 객체 X가 애플릿 A에 의해 소유되었다고 가정하자. 일반적으로, 콘텍스트 A만이 X의 필드들 및 메소드들에 액세스할 수 있다. 그러나, JCRE 콘텍스트도 X의 임의의 메소드들을 호출할 수 있다. 상기와 같은 호출 중에, JCRE 콘텍스트으로부터 X를 소유한 애플릿 콘텍스트으로의 콘텍스트 스위칭이 발생한다.

주지 사항 - JCRE는 X의 메소드들 및 필드들 모두에 액세스할 수 있다. access 메소드는 JCRE가 애플릿 콘텍스트를 엔터(enter)하는 메카니즘이다. JCRE가 파이어월을 통해 임의의 메소드를 호출하더라도, Applet 클래스에 정의된 select, process, deselect, 및 getShareableInterfaceObject(6.2.7.1 참조) 메소드들만을 호출해야 한다.

버츄얼 머신이 카드 리셋후 실행을 개시할 때 JCRE 콘텍스트는 현재 능동 콘텍스트가다. JCRE 콘텍스트는 "루트" 콘텍스트가고 항상 현재 능동 콘텍스트가거나 또는 스택에 저장된 바텀(bottom) 콘텍스트가다.

6.2.4 공유 가능 인터페이스

공유 가능 인터페이스들은 애플릿 인터랙션을 가능케 해주는 자바 카드 API 2.1의 새로운 기능이다. 공유 가능 인터페이스는 공유 인터페이스 메소드들의 집합을 정의한다. 상기 인터페이스 메소드들은 상기 메소드들을 구현하는 객체가 다른 애플릿 콘텍스트에 의해 소유되더라도 한 애플릿 콘텍스트으로부터 호출될 수 있다.

본 설명서에서, 공유 가능 인터페이스를 구현하는 클래스의 객체 인스턴스는 공유 가능 인터페이스 객체(SIO)라고 한다.

소유 콘텍스트에 대해, SIO는 필드들 및 메소드들이 액세스될 수 있는 정상 객체이다. 임의의 다른 콘텍스트에 대해, SIO는 공유 가능 인터페이스의 인스턴스이고, 공유 가능 인터페이스에서 정의된 메소드들만이 액세스될 수 있다. SIO의 모든 다른 필드들 및 메소드들은 파이어월에 의해 보호된다.

공유 가능 인터페이스들은 다음과 같이 애플릿 간 통신을 위한 보안 메카니즘을 제공한다:

1. 다른 애플릿에 유용한 객체를 생성하기 위해, 애플릿 A는 먼저 공유 가능 인터페이스, SI를 정의한다. 공유 가능 인터페이스는 인터페이스 javacard.framework.Shareable을 확장한다. 공유 가능 인터페이스, SI에서 정의된 메소드들은 애플릿 A가 다른 애플릿들에게 액세스될 수 있게 해주는 서비스들을 나타낸다.

2. 그 후 애플릿 A는 공유 가능 인터페이스, SI를 구현하는 클래스 C를 정의한다. C는 SI에서 정의된 메소드들을 구현한다. C는 또한 다른 메소드들 및 필드들을 정의할 수도 있지만, 이들은 애플릿 파이어월에 의해 보호된다. SI에서 정의된 메소드들만이 다른 애플릿들에게 액세스될 수 있다.

3. 애플릿 A는 클래스 C의 객체 인스턴스 O를 생성한다. O는 애플릿 A에 속하고, 파이어월은 A가 O의 임의의 필드들 및 메소드들에 액세스하게 해준다.

4. 애플릿 A의 객체 O에 액세스하기 위해, 애플릿 B는 타입 SI의 객체 참조 SIO를 생성한다.

5. 애플릿 B는 애플릿 A로부터 공유 인터페이스 객체 참조를 요청하기 위해 특정 메소드(6.2.7.2절에 기술된 JCSystem.getAppletShareableInterfaceObject)를 호출한다.

6. 애플릿 A는 Applet.getShareableInterfaceObject를 통해 요청자(B)의 요청 및 AID를 수신하고, 애플릿 B와 객체 O를 공유할 것인지의 여부를 결정한다.

7. 애플릿 A가 애플릿 B와 공유할 것을 동의하면, A는 O에 대한 참조로 요청에 응답한다. 상기 참조는 타입 Shareable로 캐스트되어서 O의 필드들 또는 메소드들 중 어느 것도 가시적이지 않게 한다.

8. 애플릿 B는 애플릿 A로부터 객체 참조를 수신하고, 타입 SI로 상기 참조를 캐스트하고, 객체 참조 SIO에 기억시킨다. SIO가 실제로 A의 객체 O를 참조하더라도, SIO는 타입 SI이다. SI에서 정의된 공유 가능 인터페이스 메소드들만이 B에게 가시적이다. 파이어월은 O의 다른 필드들 및 메소드들이 B에 의해 액세스되는 것을 방지한다.

9. 애플릿 B는 SIO의 공유 가능 인터페이스 메소드들 중 하나를 호출함으로써 애플릿 A으로부터의 서비스를 요청할 수 있다. 호출 중에, 자바 카드 버츄얼 머신은 콘텍스트 스위칭을 실행한다. 고유 현재 능동 콘텍스트(B)은 스택에 저장되고 실제 객체(O)의 소유자(A)의 콘텍스트가 새로운 현재 능동 콘텍스트가 된다. A의 공유 가능 인터페이스 메소드(SI 메소드) 구현은 A의 콘텍스트에서 실행된다.

10. SI 메소드는 JCSystem.getPreviousContextAID 메소드를 통해 클라이언트(B)의 AID를 찾아낼 수 있다. 이는 6.2.5절에 기술되어 있다. 메소드는 애플릿 B을 위해 서비스를 실행할지의 여부를 결정한다.

11. 콘텍스트 스위칭 때문에, 파이어월은 SI 메소드가 객체 O 및 A에 의해 소유된 임의의 다른 객체의 모든 필드들 및 메소드들에 액세스하게 해준다. 동시에, 파이어월은 메소드가 B에 의해 소유된 비공유 객체들에 액세스하는 것을 방지한다.

12. SI 메소드는 B에 의해 전달된 파라미터들에 액세스할 수 있고 리턴 값을 B에게 제공할 수 있다.

13. 리턴 중에, 자바 카드 버츄얼 머신은 복원 콘텍스트 스위칭을 실행한다. 고유 현재 능동 콘텍스트(B)이 스택으로부터 팝되어서, 다시 현재 능동 콘텍스트가 된다.

14. 콘텍스트 스위칭 때문에, 파이어월은 다시 B가 임의의 객체들에게 액세스할 수 있게 해주고 B가 A에 의해 소유된 비공유 객체에 액세스하는 것을 방지한다.

6.2.5 이전 콘텍스트 결정

애플릿이 JCSystem.getPreviousContextAID를 호출할 때, JCRE는 최종 콘텍스트 스위칭시 능동 애플릿 인스턴스의 인스턴스 AID를 리턴한다.

6.2.5.1 JCRE 콘텍스트

JCRE 콘텍스트는 AID를 갖지 않는다. 애플릿 콘텍스트가 JCRE 콘텍스트으로부터 직접 엔터되었을 때 애플릿이 getPreviousContextAID 메소드를 호출하면, 메소드는 null을 리턴한다.

애플릿이 애플릿 자체 내에서 액세스될 수 있는 메소드로부터 getPreviousContextAID를 호출하면, 또는 외부 애플릿으로부터 공유 가능 인터페이스를 통해 액세스될 때, 호출자 AID 인증을 실행하기 전에 null 리턴을 점검한다.

6.2.6 공유 가능 인터페이스 세부 사항

공유 가능 인터페이스는 단지 태깅(tagging) 인터페이스 javacard.framework.Shareable을 (직접적으로 또는 간접적으로) 확장한 것이다. 공유 가능 인터페이스는 인터페이스 메소드들에 대한 호출이 로컬/원격 경계를 넘어서 발생하는 RMI 설비에서 사용되는 원격 인터페이스와 유사하다.

6.2.6.1 자바 카드 공유 가능 인터페이스

공유 가능 태깅 인터페이스를 확장한 인터페이스들은 특별한 속성을 갖는다: 인터페이스 메소드들에 대한 호출이 콘텍스트 스위칭을 통해 자바 카드의 애플릿파이어월 경계를 넘어서 발생한다.

공유 가능 인터페이스는 모든 공유 객체들을 식별하는 것을 돕는다. 애플릿 파이어월을 통해 공유될 필요가 있는 임의의 객체는 직접 또는 간접적으로 상기 인터페이스를 구현한다. 공유 가능 인터페이스에서 규정된 메소드들만이 파이어월을 통해 유효하다.

구현 클래스들은 임의의 수의 공유 가능 인터페이스들을 구현할 수 있고 다른 공유 가능 구현 클래스들을 확장할 수 있다.

임의의 자바 플랫폼 인터페이스처럼, 공유 가능 인터페이스는 단지 서비스 메소드들의 집합을 정의한다. 서비스 프로바이더 클래스는 공유 가능 인터페이스를 "구현하고" 인터페이스의 서비스 메소드들 각각에 구현들을 제공한다고 선언한다. 서비스 클라이언트 클래스는 객체 참조를 획득하고, 필요한 경우 공유 가능 인터페이스 타입으로 객체 참조를 캐스트하고, 인터페이스의 서비스 메소드들을 호출함으로써 서비스들에 액세스한다.

자바 카드 기술 내의 공유 가능 인터페이스들은 이하의 속성들을 갖는다:

ㆍ 공유 가능 인터페이스의 메소드가 호출될 때, 객체 소유자의 콘텍스트으로의 콘텍스트 스위칭이 발생한다.

ㆍ 메소드가 종료될 때, 호출자의 콘텍스트가 복원된다.

ㆍ 예외가 던져짐으로 인해 발생하는 스택 프레임 언와인딩(unwinding) 중에 현재 능동 콘텍스트가 정확하게 복원되도록 예외 처리가 강화된다.

6.2.7 공유 가능 인터페이스 객체 획득

애플릿 간 통신은 클라이언트 애플릿이 서버 애플릿에 속한 SIO의 공유 가능 인터페이스 메소드를 호출할 때 달성된다. 이를 위해, 클라이언트 애플릿이 먼저 서버 애플릿으로부터 SIO를 획득하는 방법이 있어야만 한다. JCRE는 이를 가능케하는 메카니즘을 제공한다. Applet 클래스 및 JCSystem 클래스는 클라이언트가 서버로부터의 서비스들을 요청할 수 있게 해주는 메소드들을 제공한다.

6.2.7.1 Applet.getShareableInterfaceObject 메소드

본 메소드는 서버 애플릿 인스턴스에 의해 구현된다. 이는 다른 애플릿에 속한 객체를 사용할 것을 요청하는 클라이언트 애플릿과 객체가 공유될 수 있게 하는 서버 애플릿 간의 중재를 위해 JCRE에 의해 호출된다.

디폴트 동작은 null을 리턴해서, 애플릿이 애플릿 간 통신에 참여하지 않음을 나타낸다.

다른 애플릿으로부터 호출되도록 의도된 서버 애플릿은 본 메소드를 오버라이드할 필요가 있다. 본 메소드는 clientAID 및 파라미터를 검사해야 한다. clientAID가 예측 AID들 중 하나가 아니면, 메소드는 null을 리턴해야 한다. 유사하게, 파라미터가 인식되지 않거나 clientAID를 위해 허용되지 않으면, 메소드는 또한 null을 리턴해야 한다. 그렇지 않으면, 애플릿은 클라이언트가 요청한 공유 가능 인터페이스 타입의 SIO를 리턴해야 한다.

서버 애플릿은 동일한 SIO로 모든 클라이언트들에게 응답할 필요는 없다. 서버는 상이한 목적을 위한 다수의 타입의 공유 가능 인터페이스들을 지원할 수 있고 어떤 종류의 SIO를 클라이언트에게 리턴할 것인지를 결정하기 위해 clientAID및 파라미터를 사용할 수 있다.

6.2.7.2 JCSystem.getAppletShareableInterfaceObject 메소드

JCSystem 클래스는 서버 애플릿과의 통신을 위해 클라이언트 애플릿에 의해 호출되는 getAppletShareableInterfaceObject 메소드를 포함한다.

JCRE는 다음과 같이 동작하도록 본 메소드를 구현한다:

1. JCRE는 serverAID를 갖는 애플릿을 찾기 위해 내부 애플릿 표를 탐색한다. 발견되지 않으면, null이 리턴된다.

2. JCRE는 애플릿의 getShareableInterfaceObject 메소드를 호출해서, 호출자의 clientAID 및 파라미터를 전달한다.

3. 서버 애플릿으로의 콘텍스트 스위칭이 발생하고, getShareableInterfaceObject의 구현이 이전 섹션에 기술된 대로 진행된다. 서버 애플릿은 SIO(또는 null)를 리턴한다.

4. getAppletShareableInterfaceObject는 동일한 SIO(또는 null)를 호출자에게 리턴한다.

보안을 강화하기 위해, 구현은 이하의 조건들 중 어떤 조건이 null 값이 리턴되도록 야기하는지를 클라이언트가 이야기할 수 없게 한다:

ㆍ serverAID가 발견되지 않았음.

ㆍ 서버 애플릿이 애프릿 간 통신에 참여하지 않음.

ㆍ 서버 애플릿이 clientAID 또는 파라미터를 인식하지 않음.

ㆍ 서버 애플릿이 클라이언트와 통신하지 않음.

ㆍ 서버 애플릿이 파라미터에 의해 규정된 클라이언트와 통신하지 않음.

6.2.8 클래스 및 객체 액세스 동작

정적 클래스 필드는 이하의 자바 바이트코드들 중 하나가 실행될 때 액세스된다:

getstatic, putstatic

객체는 객체 참조를 사용해서 이하의 자바 바이트코드들 중 하나가 실행될 때 액세스된다:

상기 리스트는 getfield_b, sgetfield_s_this 등과 같은 자바 카드 버츄얼 머신에서 구현될 수도 있는 임의의 특정한 또는 최적화된 형태의 바이트코드들을 포함한다.

자바 버츄얼 머신에 의해 규정된 바이트코드들의 작업을 실행하기 전에, 자바 카드 버츄얼 머신은 참조 객체에 대한 액세스 점검을 실행한다. 액세스가 거부되면, SecurityException이 던져진다.

자바 카드 버츄얼 머신에 의해 실행되는 액세스 점검은 참조 객체의 타입 및 소유자, 바이트코드, 및 현재 능동 콘텍스트에 좌우된다. 이들은 이하의 섹션들에 기술되어 있다.

6.2.8.1 정적 클래스 필드 액세스

바이트코드들:

getstatic, putstatic

■ JCRE가 현재 능동 콘텍스트가면, 액세스가 허용된다.

■ 그렇지 않으면, 바이트코드가 putstatic이고 기억된 필드가 참조 타입이고 기억된 참조가 임시 JCRE 엔트리 포인트 객체이거나 글로벌 어레이에 대한 참조이면, 액세스가 거부된다.

■ 그렇지 않으면, 액세스가 허용된다.

6.2.8.2 어레이 객체 액세스

바이트코드들:

<T>aload, <T>astore, arraylength, checkcast, instanceof

■ JCRE가 현재 능동 콘텍스트가면, 액세스가 허용된다.

■ 그렇지 않으면, 바이트코드가 astore이고 기억된 컴포넌트가 참조 타입이고 기억된 참조가 임시 JCRE 엔트리 포인트 객체이거나 글로벌 어레이에 대한 참조이면, 액세스가 거부된다.

■ 그렇지 않으면, 어레이가 현재 능동 콘텍스트에 의해 소유되면, 액세스가 허용된다.

■ 그렇지 않으면, 어레이가 글로벌로 지정되면, 액세스가 허용된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.3 클래스 인스턴스 객체 필드 액세스

바이트코드들:

getfield, putfield

■ JCRE가 현재 능동 콘텍스트가면, 액세스가 허용된다.

■ 그렇지 않으면, 바이트코드가 putfield이고 기억된 필드가 참조 타입이고 기억된 참조가 임시 JCRE 엔트리 포인트 객체이거나 글로벌 어레이에 대한 참조이면, 액세스가 거부된다.

■ 그렇지 않으면, 객체가 현재 능동 콘텍스트에 의해 소유되면, 액세스가 허용된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.4 클래스 인스턴스 객체 메소드 액세스

바이트코드들:

invokevirtual

■ 객체가 현재 능동 콘텍스트에 의해 소유되면, 액세스가 허용된다. 콘텍스트는 객체 소유자 콘텍스트으로 전환된다.

■ 그렇지 않으면, 객체가 JCRE 엔트리 포인트 객체로 지정되면, 액세스가 허용된다. 콘텍스트는 객체 소유자 콘텍스트(JCRE일 수 있다)으로 전환된다.

■ 그렇지 않으면, JCRE가 현재 능동 콘텍스트가면, 액세스가 허용된다. 콘텍스트는 객체 소유자 콘텍스트으로 전환된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.5 표준 인터페이스 메소드 액세스

바이트코드들:

invokeinterface

■ 객체가 현재 능동 콘텍스트에 의해 소유되면, 액세스가 허용된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.6 공유 가능 인터페이스 메소드 액세스

바이트코드들:

invokeinterface

■ 그렇지 않으면, 객체 클래스가 공유 가능 인터페이스를 구현하고, 호출된 인터페이스가 공유 가능 인터페이스를 확장하면, 액세스가 허용된다. 콘텍스트는 객체 소유자 콘텍스트으로 전환된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.7 예외 객체 던짐

바이트코드들:

athrow

■ 그렇지 않으면, 객체가 JCRE 엔트리 포인트 객체로 지정되면, 액세스가 허용된다.

■ 그렇지 않으면, JCRE가 현재 능동 콘텍스트가면, 액세스가 허용된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.8 클래스 인스턴스 객체 액세스

바이트코드들:

checkcast, instaceof

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.9 표준 인터페이스 액세스

바이트코드들:

checkcast, instaceof

■ 그렇지 않으면, 액세스가 거부된다.

6.2.8.10 공유 가능 인터페이스 액세스

바이트코드들:

checkcast, instaceof

■ 그렇지 않으면, 객체 클래스가 공유 가능 인터페이스를 구현하고, 객체가 (checkcast)로 캐스트되거나 또는 공유 가능 인터페이스를 확장한 인터페이스의 인스턴스(instanceof)이면, 액세스가 허용된다.

■ 그렇지 않으면, 액세스가 거부된다.

6.3 일시 객체 및 애플릿 콘텍스트

CLEAR_ON_RESET 타입의 일시 객체들은 현재 능동 애플릿 콘텍스트가 객체(객체가 생성되었을 때의 현재 능동 애플릿 콘텍스트)의 소유자와 동일할 때만 액세스될 수 있는 영구 객체처럼 동작한다.

CLEAR_ON_DESELECT 타입의 일시 객체들은 현재 능동 애플릿 콘텍스트가 현재 선택 애플릿 콘텍스트일 때만 생성되거나 액세스될 수 있다. 현재 능동 애플릿 콘텍스트가 현재 선택 애플릿 콘텍스트가 아닐 때 makeTransient 팩토리 메소드들 중 임의의 메소드가 CLEAR_ON_DESELECT 타입의 일시 객체를 생성하도록 호출되면, 메소드는 ILLEGAL_TRANSIENT라는 이유 코드로 SystemException을 던진다. 현재 능동 애플릿 콘텍스트가 현재 선택 애플릿 콘텍스트가 아닐 때 CLEAR_ON_DESELECT 타입의 일시 객체에 액세스하고자 하는 시도가 이루어지면, JCRE는 SecurityException을 던진다.

동일한 패키지의 파트인 애플릿들은 동일한 그룹 콘텍스트를 공유한다. 패키지로부터의 모든 애플릿 인스턴스는 동일한 패키지로부터의 모든 다른 인스턴스들과 모든 객체 인스턴스들을 공유한다. (이는 상기 애플릿 인스턴스들에 의해 소유된 CLEAR_ON_RESET 타입 및 CLEAR_ON_DESELECT 타입 모두의 일시 객체들을 포함한다.)

동일한 패키지 내의 임의의 애플릿 인스턴스에 의해 소유된 CLEAR_ON_DESELECT 타입의 일시 객체들은 상기 패키지의 애플릿 인스턴스들 중 임의의 애플릿이 현재 선택 애플릿일 때 액세스될 수 있다.

7. 트랜잭션 및 애터미시티

트랜잭션은 영구 데이터의 갱신 논리 집합이다. 예를 들어, 소정의 돈을 한 계좌로부터 다른 계좌로 이체하는 것이 은행 트랜잭션이다. 트랜잭션이 애터믹(atomic)하게 되는 것이 중요하다: 데이터 필드들 모두가 갱신되거나 또는 하나도 갱신되지 않는다. 트랜잭션이 정상적으로 완료되지 않는 경우 카드 데이터가 트랜잭션 전의 고유 상태로 복원되도록, JCRE는 애터믹 트랜잭션을 강력히 지원한다. 이 메카니즘은 트랜잭션 중에 전력이 손실되는 것과 같은 이벤트들, 및 트랜잭션이 정상적으로 완료되지 않는 경우 데이터 충돌을 야기할 수 있는 프로그램 에러들에 대한 프로텍션이다.

7.1 애터미시티

애터미시티는 단일 객체 또는 클래스 필드 또는 어레이 컴포넌트의 갱신 중의 정지, 실패, 또는 치명적인 예외 후에 카드가 영구 기억장치의 콘텐츠를 처리하는 방법을 정의한다. 전력이 갱신 중 손실되면, 애플릿 개발자는 전력이 복원될 때 필드 또는 어레이 컴포넌트가 포함하는 것에 의존할 수 있다.

자바 카드 플랫폼은 단일 영구 객체 또는 클래스 필드의 임의의 갱신이 애터믹함을 보장한다. 또한, 자바 카드 플랫폼은 영구 어레이들을 위한 단일 컴포넌트 레벨 애터미시티를 제공한다. 즉, CAD 세션 후에도 보존될 데이터 소자(객체/클래스의 필드 또는 어레이의 컴포넌트)의 갱신 중 스마트 카드가 전력을 손실하면, 데이터 소자는 이전 값으로 복원된다.

또한 몇몇 메소드들은 다수의 데이터 소자들의 블록 갱신들을 위한 애터미시티를 보장한다. 예를 들어, Util.arrayCopy 메소드의 애터미시티는 모든 바이트들이 정확하게 복사되거나 또는 행선 어레이가 이전 바이트 값들로 복원됨을 보장한다.

애플릿이 어레이 갱신을 위한 애터미시티를 요구하지 않을 수도 있다. 이를 위해 Util.arrayCopyNonAtomic 메소드가 제공된다. 진행중인 트랜잭션에 의해 호출되더라도 트랜잭션 커미트 버퍼를 사용하지 않는다.

7.2 트랜잭션

애플릿은 몇몇 상이한 객체들의 몇몇 상이한 필드들 또는 어레이 컴포넌트들을 애터믹하게 갱신할 필요가 있을 수 있다. 모든 갱신이 정확하고 일관되게 이루어지거나, 또는 모든 필드들/컴포넌트들이 이전 값들로 복원된다.

자바 카드 플랫폼은 애플릿이 JCSystem.beginTransaction 메소드에 대한 호출로 애터믹 집합의 갱신들의 초반부를 지정할 수 있는 트랜잭션 모델을 지원한다. 이후의 각각의 객체의 갱신은 조건적으로 이루어진다. 필드 또는 어레이 컴포넌트는 갱신될 것으로 보이지만 - 필드/어레이 컴포넌트를 판독하여 최종 조건부 값을 산출함 - 갱신은 아직 커미트되지 않았다.

애플릿이 JCSystem.commitTransaction을 호출할 때, 모든 조건부 갱신들이 영구 기억장치에 커미트된다. JCSystem.commitTransaction 완료 전에 전력이 손실되거나 몇몇 다른 시스템 실패가 발생하면, 모든 조건부 갱신 필드들 또는 어레이 컴포넌트들이 이전 값들로 복원된다. 애플릿이 내부 문제에 부닥치거나 트랜잭션을 취소하고자 결정하면, JCSystem.abortTransaction을 호출함으로써 조건부 갱신실행을 프로그램으로 취소할 수 있다.

7.3 트랜잭션 존속 기간

트랜잭션은 항상 애플릿의 select, deselect, process 또는 install 메소드들로부터의 복귀 시 JCRE가 프로그램 제어를 다시 획득할 때 종료한다. 애플릿의 commitTransaction 호출에 따라, 또는 트랜잭션 중지에 따라(애플릿에 의해 프로그램으로, 또는 JCRE에 의한 디폴트에 의해) 트랜잭션이 정상적으로 종료했는지의 여부가 true가 된다.

트랜잭션 존속 기간은 JCSystem.beginTransaction에 대한 호출과 commitTransaction에 대한 호출 또는 트랜잭션 중지 간의 트랜잭션의 수명이다.

7.4 중첩 트랜잭션

모델은 현재 중첩 트랜잭션이 가능하지 않다고 가정한다. 한번에 진행중인 트랜잭션은 오직 하나만이 존재할 수 있다. 트랜잭션이 이미 '진행중'일 때 JCSystem.beginTransaction이 호출되면, TransactionException이 던져진다.

JCSystem.transactionDepth 메소드가 트랜잭션이 진행중인지를 결정할 수 있도록 제공된다.

7.5 티어 또는 리셋 트랜잭션 실패

트랜잭션이 진행중인 동안 전력이 손실(티어)되거나 카드가 리셋되거나 또는 몇몇 다른 시스템 실패가 발생하면, JCRE는 JCSystem.beginTransaction에 대한 이전 호출 이래로 조건적으로 갱신된 모든 필드들 및 어레이 컴포넌트들을 이전 값들로 복원한다.

이 액션은 전력 손실, 리셋 또는 실패로부터 복구된 후에 카드를 다시 초기화할 때 JCRE에 의해 자동으로 실행된다. JCRE는 객체들(만약 있으면) 중 어떤 객체가 조건적으로 갱신되었는지를 결정하고 복원한다.

주지 사항 - 전력 손실 또는 카드 리셋으로 인해 실패한 트랜잭션 중에 생성된 인스턴스들에 의해 사용된 객체 공간은 JCRE에 의해 복구될 수 있다.

7.6 트랜잭션 중지

트랜잭션은 애플릿에 의해 또는 JCRE에 의해 중지될 수 있다.

7.6.1 프로그램에 의한 중지

애플릿이 내부 문제에 봉착하거나 트랜잭션을 취소하기로 결정하면, JCSystem.abortTransaction을 호출함으로써 조건부 갱신 실행을 프로그램에 의해 취소할 수 있다. 메소드가 호출되면, JCSystem.beginTransaction에 대한 이전 호출 이래로 조건적으로 갱신된 모든 필드들 및 어레이 컴포넌트들은 이전 값들로 복원되고, JCSystem.transactionDepth 값은 0으로 리셋된다.

7.6.2 JCRE에 의한 중지

트랜잭션이 진행중일 때 애플릿이 select, deselect, process 또는 install 메소드들로부터 리턴하면, JCRE는 자동으로 트랜잭션을 중지한다. 트랜잭션이 진행중일 때 select, deselect, process 또는 install 메소드들 중 임의의 메소드로부터의 리턴이 발생하면, JCRE는 예외가 던져진 것처럼 동작한다.

7.6.3 JCRE 클린업 책임

중지된 트랜잭션 중에 생성된 객체 인스턴스들은 상기 객체들에 대한 모든참조들이 로케이션되어 null로 변환될 수 있을 때만 삭제될 수 있다. JCRE는 중지된 트랜잭션 중에 생성된 객체들에 대한 참조들이 null 참조와 등가임을 보장한다.

7.7 일시 객체

영구 객체들에 대한 갱신들만이 트랜잭션에 참여한다. 일시 객체들에 대한 갱신들은 트랜잭션중이던 아니던 간에 결코 실행이 취소되지 않는다.

7.8 커미트 용량

플랫폼 리소스들이 제한적이기 때문에, 트랜잭션 중에 누적될 수 있는 조건부 갱신 데이터의 바이트들의 수는 제한된다. 자바 카드 기술은 구현에 있어서 유효한 커미트 용량의 양을 결정하는 메소드들을 제공한다. 커미트 용량은 유효한 조건 바이트 갱신들의 수에 대한 상한을 나타낸다. 유효한 조건부 바이트 갱신들의 실제 수는 관리 오버헤드로 인해 보다 적을 수도 있다.

커미트 용량이 트랜잭션 중에 초과되면, 예외가 던져진다.

8. API 토픽

본 장의 토픽은 자바 카드 2.1 API 드래프트 2 설명서에 규정된 요구 사항들을 보완한다. 제1 토픽은 APDU 클래스로 전체가 구현된 자바 카드 I/O 기능이다. 제2 토픽은 자바 카드 보안 및 암호문을 지원하는 API이다. JCSystem 클래스는 API 버젼 레벨을 요약한다.

API 내의 트랜잭션

자바 카드 2.1 API 설명서에서 특별히 지시되지 않는 한, API 클래스들의 구현은 개시되지 않거나 다른 경우 트랜잭션이 진행중이면 트랜잭션의 상태를 변경한다.

API 내의 리소스 사용

자바 카드 2.1 API 설명서에서 특별히 지시되지 않는 한, 객체 인스턴스의 소유자가 현재 선택 애플릿이 아니더라도, 구현은 API 인스턴스 메소드들의 호출을 지원한다. 다시 말해서, 특별히 지시되지 않는 한, 구현은 CLEAR_ON_DESELCT 타입의 일시 객체들과 같은 리소스들을 사용하지 않는다.

API 클래스들에 의해 던져진 예외들

API 구현에 의해 던져진 모든 예외 객체들은 임시 JCRE 엔트리 포인트 객체들이다. 임시 JCRE 엔트리 포인트 객체들은 클래스 변수, 인스턴스 변수 또는 어레이 컴포넌트로 기억될 수 없다.(6.2.1 참조)

8.1 APDU 클래스

APDU 클래스는 카드 시리얼 라인을 지나서 ISO 7816-4 기반 I/O에 대한 액세스를 요약한다. APDU 클래스는 기초 I/O 트랜스포트 프로토콜과 무관하도록 지정된다.

JCRE는 T = 0 또는 T = 1 트랜스포트 프로토코들을 지원할 수도 있다.

8.1.1 출력 데이터 전송을 위한 T = 0 명세

블록 체인 메카니즘들을 지원하지 않는 리거시(legacy) CAD/터미널들과의 호환을 위해 APDU 클래스는 setOutgoingNoChaining 메소드를 통해 모드 선택을 허용한다.

8.1.1.1 체이닝 없는 제약 전송

setOutgoingNoChaining 메소드를 호출함으로써 체이닝 없는 출력 전송 모드가 애플릿에 의해 요청될 때, 이하의 프로토콜 시퀀스가 수반된다.

주지 사항 - 체이닝 없는 모드가 사용될 때, waitExtension 메소드에 대한 호출은 ILLEGAL_USE 이유 코드로 APDUException을 던진다.

표기법

Le = CAD 예측 길이.

Lr = setOutgoingLength 메소드를 통해 설정된 애플릿 응답 길이.

<INS> = 모든 데이터 바이트들이 다음으로 전송될 것을 나타내는 입력 헤더 INS 바이트와 등가인 프로토콜 바이트.

<~INS> = 약 1개의 데이터 바이트가 다음으로 전송될 것을 나타내는 입력 헤더 INS 바이트의 보수인 프로토콜 바이트.

<SW1, SW2> = ISO7816-4에서의 응답 상태 바이트들.

ISO7816-4 케이스 2

Le == Lr

1. 카드는 표준 T = 0 <INS> 또는 <~INS> 프로시져 바이트 메카니즘을 사용해서 출력 데이터의 Lr 바이트들을 송신한다.

2. 카드는 Applet.process 메소드 완료시의 <SW1, SW2> 완료 상태를 송신한다.

Lr < Le

1. 카드는 <0x61,Lr> 완료 상태 바이트들을 송신한다.

2. CAD는 Le = Lr인 GET RESOPNSE 명령을 송신한다.

3. 카드는 표준 T = 0 <INS> 또는 <~INS> 프로시져 바이트 메카니즘을 사용해서 출력 데이터의 Lr 바이트들을 송신한다.

4. 카드는 Applet.process 메소드 완료시의 <SW1, SW2> 완료 상태를 송신한다.

Lr > Le

1. 카드는 표준 T = 0 <INS> 또는 <~INS> 프로시져 바이트 메카니즘을 사용해서 출력 데이터의 Le 바이트들을 송신한다.

2. 카드는 <0x61,(Lr-Le)> 완료 상태 바이트들을 송신한다.

3. CAD는 새로운 Le <= Lr인 GET RESOPNSE 명령을 송신한다.

4. 카드는 표준 T = 0 <INS> 또는 <~INS> 프로시져 바이트 메카니즘을 사용해서 출력 데이터의 (새로운) Le 바이트들을 송신한다.

5. 요구된 나머지 출력 데이터 바이트들(Lr)을 송신하기 위해 필요한 단계들(2-4)을 반복한다.

6. 카드는 Applet.process 메소드 완료시의 <SW1, SW2> 완료 상태를 송신한다.

ISO7816-4 케이스 4

케이스 4에서, Le는 이하의 초기 교환 후에 결정된다:

1. 카드는 <0x61,Lr 상태 바이트들>을 송신한다.

2. CAD는 Le <= Lr인 GET RESOPNSE 명령을 송신한다.

프로토콜 시퀀스의 나머지는 상술된 케이스 2와 동일하다.

애플릿이 초기에 중지하고 Le 바이트들 보다 적게 송신하면, CAD에 의해 예측된 전송 길이를 채우는 대신 0들이 송신될 수도 있다.

8.1.1.2 정규 출력 전송

체이닝 없는 출력 전송 모드가 애플릿에 의해 요청되지 않을 때(즉, setOutgoing 메소드가 사용됨), 이하의 프로토콜 시퀀스가 수반된다:

임의의 ISO-7816-3/4에 따른 프로토콜 전송 시퀀스가 사용될 수도 있다.

주지 사항 - sendBytes 또는 sendBytesLong 메소드들에 대한 성공적인 호출들 간에 waitExtension 메소드가 애플릿에 의해 호출될 수도 있다. waitExtension 메소드는 0x60 프로시져 바이트를 사용해서 추가 작업 대기 시간을 요청한다(ISO 7816-3).

8.1.1.3 추가 T = 0 요구 사항

임의의 시간에, T = 0 출력 전송 프로토콜이 사용중이고, APDU 클래스가 카드로부터의 응답 상태 <0x61, xx>에 대응해서 CAD로부터 GET RESPONSE 명령을 대기하고 있을 때, CAD가 상이한 명령을 송신하면, sendBytes 또는 sendBytesLong 메소드들은 이유 코드 NO_TO_GETRESPONSE로 APDUException을 던진다.

이때로부터 sendBytes 또는 sendBytesLong 메소드들에 대한 호출은 이유 코드 ILLEGAL_USE로 APDUException을 야기한다. NO_TO_GETRESPONSE 예외가 던져진 후에 애플릿에 의해 ISOException이 던져지면, JCRE는 이유 코드의 응답 상태를 폐기한다. JCRE는 새롭게 수신된 명령으로 APDU 프로세싱을 다시 개시하고 APDU 디스패칭을 재개한다.

8.1.2 출력 데이터 전송을 위한 T = 1 명세

8.1.2.1 체이닝 없는 제약 전송

setOutgoingNoChaining 메소드를 호출함으로써 체이닝 없는 출력 전송 모드가 애플릿에 의해 요청될 때, 이하의 프로토콜 시퀀스가 수반된다:

표기법

Le = CAD 예측 길이.

Lr = setOutgoingLength 메소드를 통해 설정된 애플릿 응답 길이.

전송 프로토콜 시퀀스는 블록 체이닝을 사용하지 않는다. 특히, M-비트(상위 데이터 비트)는 전송 중에 I-블록들의 PCB에서 설정되지 않는다(ISO 7816-3). 다시 말해서, 전체 출력 데이터(Lr 바이트들)는 하나의 I-블록으로 전송된다.

(애플릿이 초기에 중지하고 Le 바이트들 보다 적게 송신하면, 블록의 나머지길이를 채우는 대신 0들이 송신될 수도 있다.)

8.1.2.2 정규 출력 전송

체이닝 없는 출력 전송 모드가 애플릿에 의해 요청되지 않을 때, 즉, setOutgoing 메소드가 사용될 때, 이하의 프로토콜 시퀀스가 수반된다:

주지 사항 - sendBytes 또는 sendBytesLong 메소드들에 대한 성공적인 호출들 간에 waitExtension 메소드가 애플릿에 의해 호출될 수도 있다. waitExtension 메소드는 T = 0 모드의 1 추가 작업 대기 시간의 요청과 동일한 INF 유닛들의 WTX 요청에 따라 S-블록 명령을 송신한다.

8.2 보안 및 암호 패키지

이하의 클래스들의 getInstance 메소드는 요청된 알고리즘의 호출 애플릿의 콘텍스트의 구현 인스턴스를 리턴한다:

javacard.security.MessageDigest

javacard.security.Signature

javacard.security.RandomData

javacardx.crypto.Cipher.

JCRE의 구현은 API에 리스트된 0개 이상의 알고리즘들을 구현할 수도 있다. 구현되지 않은 알고리즘이 요청될 때, 본 메소드는 이유 코드 NO_SUCH_ALGORITHM으로 CryptoException을 던진다.

상술된 클래스들의 구현들은 대응 베이스 클래스를 확장하고 모든 추상 메소드들을 구현한다. 구현 인스턴스와 관련된 모든 데이터 할당은 요구된 리소스들의 임의의 결핍이 애플릿 인스톨레이션 중에 초기에 플래그화될 수 있음을 보장하기 위해 인스턴스 구성시 실행된다.

유사하게, javacard.security.keyBuilder 클래스의 buildkey 메소드는 요청된 키 타입의 구현 인스턴스를 리턴한다. JCRE는 0 개 이상의 타입의 키들을 구현할 수도 있다. 구현되지 않은 키 타입이 요청될 때, 본 메소드는 이유 코드 NO_SUCH_ALGORITHM으로 CryptoException을 던진다.

키 타입들의 구현들은 관련 인터페이스를 구현한다. 키 구현 인스턴스와 관련된 모든 데이터 할당은 요구된 리소스들의 임의의 결핍이 애플릿 인스톨레이션 중에 초기에 플래그화될 수 있음을 보장하기 위해 인스턴스 구성시 실행된다.

8.3 JCS 시스템 클래스

자바 카드 2.1에서, getVersion 메소드가 (짧은) 0x0201을 리턴한다.

9. 버츄얼 머신 토픽

본 장의 토픽은 버츄얼 머신 명세들을 상세히 설명한다.

9.1 리소스 실패

복구될 수 있는 (히프 공간과 같은) 리소스 부족 상태는 이유 코드 NO_RESOURCE로 SystemException을 야기한다. 일시적인 어레이들을 생성하는데 사용되는 JCSystem의 팩토리 메소드들은 일시 공간의 부족을 알리기 위해 이유 코드 NO_TRANSIENT_SPACE로 SystemException을 던진다.

스택 오버플로와 같은 모든 다른 (복구될 수 없는) 버츄얼 머신 에러들은 버츄얼 머신 에러를 야기한다. 이러한 상태는 버츄얼 머신이 멈추게 한다. 복구될 수 없는 버츄얼 머신 에러가 발생할 때, 구현은 선택적으로 카드가 차후 사용으로부터 뮤트되거나 차단될 것을 요구할 수 있다.

10. 애플릿 인스톨러

자바 카드 기술을 사용한 스마트 카드 상의 애플릿 인스톨레이션은 복합적인 토픽이다. 자바 카드 API 2.1은 JCRE 구현자들이 가능한한 자유롭게 구현할 수 있게 해주도록 의도된 것이다. 그러나, 특정 인스톨러가 구현 세부 사항을 모르더라도 자바 카드 애플릿들이 인스톨되게 하기 위해 몇몇 기본 공통 사양들이 필요하다.

본 설명서는 인스톨러 개념을 정의하고 광범위한 인스톨러 구현들에 대한 상호 작용을 달성하기 위해 최소 인스톨레이션 요구 사항들을 규정한다.

애플릿 인스톨러는 JCRE 2.1 설명서의 선택적인 파트이다. 즉, JCRE의 구현은 반드시 후-발행(post-issuance) 인스톨러를 포함할 필요가 없다. 그러나, 구현되면, 인스톨러가 섹션 9.1에 규정된 동작을 지원할 필요가 있다.

10.1 인스톨러

자바 카드 기술을 사용해서 스마트 카드에 애플릿을 설치하는데 필요한 메카니즘들은 인스톨러라고 하는 온-카드 컴포넌트에 내장된다.

CAD에게 인스톨러는 애플릿으로 보인다. 인스톨러는 AID를 갖고, AID가 SELECT 명령에 의해 성공적으로 프로세스될 때 현재 선택 애플릿이 된다. 일단 선택되면, 인스톨러는 임의의 다른 애플릿과 동일한 방법으로 동작한다:

ㆍ 임의의 다른 선택 애플릿과 같이 모든 APDU들을 수신한다.

ㆍ 설계 사양 다양한 선행 조건에서 명령들의 의미와 함께 수신할 것으로 예측한 APDU들의 다양한 종류들 및 형식들에 대해 기술한다.

ㆍ 수신한 모든 APDU들을 처리하고 응답한다. 부정확한 APDU들은 몇몇 종류의 에러 상태로 응답된다.

ㆍ 다른 애플릿이 선택될 때(또는 카드가 리셋되거나 전력이 카드로부터 제거될 때), 인스톨러는 선택 해제되고 이후에 선택될 때까지 중지 상태에 머물게 된다.

10.1.1 인스톨러 구현

인스톨러는 카드 상의 애플릿으로서 구현될 필요는 없다. 요구 사항은 단지 인스톨러 기능이 선택 가능하다는 점 뿐이다. 요구 사항으로 인해 인스톨러 애플릿이 선택되지 않았을 때나 어떠한 애플릿도 선택되지 않았을 때는 인스톨러 컴포넌트가 호출될 수 없다.

명백하게, JCRE 구현자는 인스톨러를 애플릿으로서 구현할 것을 선택할 수 있다. 그렇다면, 인스톨러는 Applet 클래스를 확장하고 select, process 및 deselect 메소드들의 호출에 응답하도록 코드화될 수 있다.

그러나, 또한 다시 말해서 외부에 선택 가능한 동작을 제공하는 한 JCRE 구현자는 인스톨러를 구현할 수 있다. 이러한 경우에, JCRE 구현자는 APDU들이 인스톨러 코드 모듈에 전달되는 몇몇 다른 메카니즘을 제공할 의무가 없다.

10.1.2 인스톨러 AID

인스톨러가 선택 가능하기 때문에, 인스톨러는 AID를 가진다. JCRE 구현자들은 인스톨러가 선택된 자신의 AID를 자유롭게 선택할 수 있다.

10.1.3 인스톨러 APDU

자바 카드 API 2.1은 인스톨러를 위한 임의의 APDU를 지정하지 않는다. JCRE 구현자들은 작업시 인스톨러를 관리하기 위해 자체 APDU 명령들을 전적으로 자유롭게 선택할 수 있다.

모델은 카드의 인스톨러가 CAD에서 실행되는 인스톨레이션 프로그램에 의해 구동된다는 것이다. 인스톨레이션이 성공적으로 달성되기 위해, CAD 인스톨레이션 프로그램은 이하의 사항들을 할 수 있다:

ㆍ 카드를 인식할 수 있다.

ㆍ 카드상의 인스톨러를 선택할 수 있다.

ㆍ 카드 인스톨러에게 적합한 APDU들을 송신함으로써 인스톨레이션 프로세스를 구동할 수 있다. APDU들은 다음을 포함한다:

▷ 인스톨레이션이 승인된 것임을 보장하기 위한 인증 정보.

▷ 카드 메모리에 로드될 애플릿 코드

▷ 애플릿 코드를 이미 카드에 있는 코드와 링크하기 위한 링크 정보.

▷ 애플릿의 install 메소드에 송신될 인스턴스 초기화 파라미터 데이터

자바 카드 API 2.1은 CAD 인스톨레이션 프로그램의 세부 사항을 규정하지도 않고 인스톨러와의 사이에 전달되는 APDU들을 규정하지도 않는다.

10.1.4 인스톨러 동작

JCRE 구현자들은 또한 다음을 포함하는 인스톨러의 다른 동작들을 정의한다:

ㆍ 인스톨레이션이 중지될 수 있는지의 여부 및 실행되는 방법.

ㆍ 인스톨레이션 중에 예외, 리셋, 또는 전력 실패가 발생하면 어떤 상황이 발생하는지.

ㆍ 인스톨러가 작업을 완료하기 전에 다른 애플릿이 선택되면 어떤 상황이 발생하는지.

JCRE는 다음과 같은 경우 애플릿이 성공적으로 인스톨되지 않았음을 보장한다:

ㆍ 애플릿의 install 메소드가 Applet.register 메소드로부터의 성공적인 리턴 전에 예외를 던지는 경우.(9.2절을 참조)

10.1.5 인스톨러 특권

인스톨러가 애플릿으로서 구현될 수 있더라도, 인스톨러는 전형적으로 "다른 애플릿들"에게 유효하지 않은 액세스 특징을 요구한다. 예를 들어, JCRE 구현자의 구현에 따라, 인스톨러는 다음을 필요로 한다:

ㆍ 메모리에 직접 판독 및 기록함으로써 객체 시스템 및/또는 표준 보안을 바이패스할 필요가 있다.

ㆍ 다른 애플릿들 또는 JCRE에 의해 소유된 객체들에 액세스할 필요가 있다.

ㆍ JCRE의 논-엔트리 포인트 메소드들(non-entry point methods)을 호출할 필요가 있다.

ㆍ 새롭게 설치된 애플릿의 install 메소드를 호출할 수 있을 필요가 있다.

다시 말해서, 인스톨러를 지원하기 위해 필요한 인스톨러 구현 결정 및 JCRE구현의 상기 특징들의 지원은 각각의 JCRE 구현자에 달려 있다.

10.2 새롭게 설치된 애플릿

인스톨러와 설치될 애플릿 간에 단일 인터페이스가 존재한다. 인스톨러가 실행을 위해 정확하게 애플릿을 준비한 후에(로딩 및 링킹과 같은 단계들을 실행한 후에), 인스톨러는 애플릿의 install 메소드를 호출한다. 본 메소드는 Applet 클래스에 정의된다.

애플릿의 install 메소드가 인스톨러로부터 호출되는 정확한 메카니즘은 JCRE 구현자-정의 구현 세부 사항(JCRE impementer-defined implementation detail)이다. 그러나, install 메소드에 의해 실행되는 임의의 콘텍스트-관련 오퍼레이션들(예를 들면, 새로운 객체 생성)이 새로운 애플릿의 콘텍스트에서 실행되지만 인스톨러의 콘텍스트에서는 실행되지 않도록 콘텍스트 스위칭이 존재한다. 인스톨러는 또한 애플릿 클래스 초기화(<clinit>) 메소드들 중에 생성된 어레이 객체들이 새로운 애플릿의 콘텍스트에 의해 소유됨을 보장한다.

모든 단계들이 Appelt.register 메소드 실행으로부터의 성공적인 리턴을 포함해서 실패 또는 던져진 예외 없이 완료되면 애플릿의 인스톨레이션은 완료된 것으로 간주된다. 이 때에, 설치 애플릿은 선택 가능하다.

10.2.1 인스톨레이션 파라미터

최대 사이즈의 32 바이트들 외에, 자바 카드 API 2.1은 인스톨레이션 파라미터 바이트 어레이 세그먼트의 콘텐츠에 대해 어떠한 것도 지정하지 않는다. 이는 애플릿 설계자에 의해 정의되고 임의의 희망 형식일 수 있다. 또한, 인스톨레이션파라미터들은 인스톨러에게 불명료하도록 의도된다.

JCRE 구현자들은 CAD에서 실행되는 인스톨레이션 프로그램들이 인스톨러에게 전달될 임의의 바이트 어레이를 규정할 수 있도록 인스톨러를 설계해야 한다. 인스톨러는 단지 bArray 파라미터로 타깃 애플릿의 install 메소드에게 바이트 어레이를 발송한다. 전형적인 구현은 동반 바이트 어레이의 콘텐츠를 전달하는 "애플릿 install 메소드 호출"을 의미하는 JCRE 구현자-속성 APDU 명령을 정의할 수도 있다.

11. API 상수

몇몇 API 클래스들은 자바 카드 API 2.1 참조질의 상수들을 위해 지정된 값을 갖지 않는다. 상수 값들이 JCRE 2.1 설명서의 구현자들에 의해 일관되게 지정되지 않으면, 산업계 전반의 상호 운용이 불가능하다. 본 장은 자바 카드 API 2.1 참조문에 지정되지 않은 상수들을 위해 필요한 값들을 제공한다.

용어 해설

AID는 ISO 7816-5에 정의된 애플리케이션 식별자(Applicatoin IDentifier)의 두문자어이다.

APDU는 애플리케이션 프로토콜 데이터 유닛(Applicatoin Protocol Data Unit)의 두문자어이다.

API는 애플리케이션 프로그래밍 인터페이스(Applicatoin Programming Interface)의 두문자어이다. API는 애플리케이션 프로그램이 오퍼레이팅 시스템 및 다른 서비스들에 액세스하는 호출 규정이다.

본 문서의 콘텍스트 내의애플릿은 자바 카드 기술의 선택, 콘텍스트, 기능, 및 보안의 기본 유닛인 자바 카드 애플릿을 의미한다.

애플릿 개발자는 자바 카드 기술 설명서들을 사용해서 자바 카드 애플릿을 생성하는 사람을 말한다.

애플릿 파이어월은 버츄얼 머신이 애플릿이 다른 애플릿 콘텍스트들 또는 JCRE 콘텍스트에 의해 소유된 객체들에 비승인 액세스를 하는 것을 방지하고, 위반을 보고하거나 처리하는 자바 카드 기술의 메카니즘이다.

애터믹 오퍼레이션은 전체가 완료되거나(오퍼레이션이 성공한 경우) 또는 전혀 완료되지 않은(오퍼레이션이 실패한 경우) 오퍼레이션이다.

애터미시티는 특정 오퍼레이션이 애터믹인지 아닌지의 여부와 관련되고 전력이 손실되거나 카드가 갑작스럽게 CAD로부터 제거되는 경우에 적합한 데이터 복구를 위해 필요하다.

ATR은 리셋에 대한 응답(Answer to Reset)의 두문자어이다. ATR은 리셋 상태 후에 자바 카드에 의해 송신된 바이트 스트링이다.CAD는 카드 수용 장치(Card Acceptance Device)의 두문자어이다. CAD는 카드가 삽입되는 장치이다.캐스트(cast)는 하나의 데이터 타입으로부터 다른 데이터 타입으로의 명시적 변환이다.cJCK는 자바 카드 기술 설명서의 구현의 컴플라이언스를 검증하는데 적합한 테스트이다. cJCK는 적합한 테스트를 실행하기 위해 자바 테스트 도구를 사용한다.

클래스는 객체 지향 언어의 객체를 위한 프로토타입이다. 클래스는 또한 공통 구조 및 동작을 공유하는 객체들의 집합이라고 생각될 수도 있다. 클래스의 구조는 클래스의 객체의 상태를 나타내는 클래스 변수들에 의해 결정되고 동작은 클래스와 연관된 메소드 집합에 의해 정해진다.

클래스들은 클래스 계층과 관련된다. 하나의 클래스는 다른 클래스(슈퍼클래스)의 특수 클래스(서브클래스)일 수도 있고, 다른 클래스들에 대한 참조를 가질 수도 있고, 클라이언트-서버 관계로 다른 클래스들을 사용할 수도 있다.

콘텍스트(애플릿 실행 콘텍스트를 참조하라.)

현재 능동 콘텍스트.JCRE는 현재 능동 자바 카드 애플릿 콘텍스트를 계속 추적한다. 가상 메소드가 객체 상에서 호출되고, 콘텍스트 스위칭이 요구되고 허용되면, 현재 능동 콘텍스트는 객체를 소유한 애플릿 콘텍스트에 대응하도록 변경된다. 메소드가 리턴할 때, 이전 콘텍스트가 복원된다. 정적 메소드들의 호출은 현재 능동 콘텍스트에 영향을 주지 않는다. 현재 능동 콘텍스트 및 객체 공유 상태는 함께 객체에 대한 액세스가 허용될 수 있는지를 결정한다.

현재 선택 애플릿.JCRE는 현재 선택 자바 카드 애플릿을 계속 추적한다. 애플릿의 AID와 함께 SELECT 명령을 수신하면, JCRE는 애플릿을 현재 선택 애플릿이 되게 한다. JCRE는 모든 APDU 명령들을 현재 선택 애플릿에게 송신한다.

EEPROM은 전기적 소거 가능 프로그래머블 ROM(Electrically Erasable, Programmable Read Only Memory)의 두문자어이다.

파이어월(애플릿 파이어월을 참조하라).

프레임워크는 API를 구현하는 클래스들의 집합이다. 이는 코어 및 확장 패키지를 포함한다. APDU 디스패칭, 애플릿 선택, 애터미시티 관리, 및 애플릿 설치의 책임이 있다.

쓰레기 수집(Garbage collection)은 동적 할당 기억 장치가 프로그램 실행 중에 자동으로 교정되는(reclaimed) 프로세스이다.

필드들로서 공지된인스턴스 변수들은 객체의 내부 상태의 일부분을 나타낸다. 각각의 객체는 자체 인스턴스 변수 집합을 갖는다. 동일한 클래스의 객체들은 동일한 인스턴스 변수들을 갖지만, 각각의 객체는 상이한 값들을 가질 수 있다.

객체 지향 프로그래밍에서인스턴시에이션(instantiation)은 클래스 템플릿으로부터 특정 객체를 생성하는 것을 의미한다. 이는 템플릿에 의해 규정된 타입들을 갖는 데이터 구조의 할당, 및 디폴트 값들 또는 클래스 구조물 함수에 의해 제공된 값들을 갖는 인스턴스 변수들의 초기화를 포함한다.

JAR는 자바 아카이브(Java Archive)의 두문자어이다. JAR는 다수의 파일들을 하나로 결합하는 플랫폼-독립 파일 형식이다.자바 카드 런타임 환경(JCRE; Java Card Runtime Environment)는 자바 카드 버츄얼 머신, 프레임워크, 및 관련 고유 메소드들로 구성된다.JC21RI는 자바 카드 2.1 참조 구현(Java Card 2.1 Reference Implementation)의 두문자어이다.JCRE 구현자는 자바 카드 API를 사용해서 벤더-특정 구현을 생성하는 사람을 말한다.

JCVM은 자바 카드 버츄얼 머신(Java Card Virtual Machine)의 두문자어이다. JCVM은 OP 카드 아키텍쳐의 기초이다. JCVM은 바이트 코드를 실행하고 클래스 및 객체를 관리한다. 애플리케이션들 간의 분리(파이어월)를 강화하고 안전한 데이터 공유를 가능케 한다.

JDK는 자바 개발 키트(Java Development Kit)의 두문자어이다. JDK는 자바의 프로그래밍을 위해 필요한 환경을 제공하는 선 마이크로시스템즈 주식회사 제품이다. JDK는 다양한 플랫폼들에 유용한데, 특히 Sun Solaris 및 마이크로소프트 윈도우즈^②에 유용하다.

메소드는 객체 지향 언어에서 하나 이상의 클래스들과 관련된 프로시져 또는 루틴에게 주어지는 명칭이다.

명칭 스페이스는 모든 명칭들이 유일한 명칭 집합이다.

객체 지향은 메소드라고 하는 루틴 집합으로 요약되는 데이터 구조이며 데이터에 대해 동작하는 객체라는 개념을 기반으로 한 프로그래밍 방법이다.

객체 지향 프로그래밍의객체들은 클래스에 의헤 제공된 템플릿에 따라 정의된 데이터 구조의 유일한 인스턴스들이다. 각각의 객체는 클래스에 속한 변수들에 대한 자체 값들을 갖고 클래스에 의해 정의된 메시지들(메소드들)에 응답할 수 있다.

패키지는 자바 프로그래밍 언어의 명칭 스페이스가고 클래스들 및 인터페이스들을 가질 수 있다. 패키지는 자바 프로그래밍 언어에서 가장 작은 단위이다.

영구 객체.영구 객체들 및 그 값들은 하나의 CAD 세션으로부터 다음 세션으로 무한정 지속된다. 객체들은 디폴트에 의해 영구적이다. 영구 객체 값들은 트랜잭션을 사용해서 자동으로 갱신된다. 영구라는 용어는 카드에 객체 지향 데이터베이스가 존재한다거나 객체들이 직렬화/비직렬화됨을 의미하는 것이 아니고, 단지 카드가 전력을 손실할 때 객체들이 손실됨을 의미한다.

공유 가능 인터페이스는 공유 인터페이스 메소드 집합을 정의한다. 인터페이스 메소드들은 상기 메소드들을 구현하는 객체가 다른 애플릿 콘텍스트에 의해 소유될 때 하나의 애플릿 콘텍스트으로부 호출될 수 있다.공유 가능 인터페이스 객체(SIO; Shareable Interface Object)는 공유 가능 인터페이스를 구현하는 객체이다.

트랜잭션은 개발자가 프로그램 코드에서 트랜잭션의 개시 및 종료를 나타냄으로써 오퍼레이션의 범위를 정의하는 애터믹 오퍼레이션이다.

일시 객체.일시 객체들의 값들은 하나의 CAD 세션으로부터 다음 세션으로 지속되지 않고, 특정 간격 마다 디폴트 상태로 리셋된다. 일시 객체들의 값들에 대한 갱신은 애터믹하지 않고 트랜잭션에 의해 영향을 받지 않는다.

1/5/99 12:49 PM Havnor: Stuff: JCRE D2 14DEC98: READ-ME-JCRE21-DF2.txt Page 1

날짜: 1998년 12월 16일

자바 카드 라인슨시(Java Card Licensee)에게,

JCRE21-DF2-14DEC98.zip은 라인슨시 리뷰 및 코멘트를 위해 1998년 12월 14일의 자바 카드 2.1 런타임 환경 설명서의 제2 드래프트를 포함한다. 우리가 수신한 리뷰 피드백을 기반으로 문서를 통합하고 명료화했다.

집 아카이브의 완전한 콘텐츠는 다음과 같다:

READ-ME-JCRE21-DF.txt - READ ME 텍스트 파일

JCRE21-DF2.pdf - PDF 형식의 "자바 카드 런타임 환경(JCRE) 2.1 설명서"

JCRE21-DF2-changebar.pdf - 리뷰 편의상 이전 버젼으로부터 체인지 바를 갖는 개정된 문서

변경 사항 요약:

1. 이는 새로운 드래프트 2 공개물이고 퍼블릭 웹 사이트에 간단하게 공개될 것이다.

2. 비승인 액세스를 제한하기 위해 임시 JCRE 엔트리 포인트 객체들에 대한 새로운 설명이 도입되었다.

3. 글로벌 어레이들이 임시 JCRE 엔트리 포인트 객체들과 유사한 보안 관련 제약들을 새롭게 추가했다. 파이어월 6.2.2 장.

4. 임시 JCRE 엔트리 포인트 객체 및 글로벌 어레이에 대한 제약들을 기억하는 것에 대한 바이트코드들의 상세한 설명이 추가되었다. 6.2.8 장.

5. 예외 객체들을 소유한 JCRE에 대한 일반적인 설명이 8장에 추가되었다.

6. 일시적인 팩토리 메소드들의 버츄얼 머신 리소스 실패에 대한 설명이 정정되었다. 9.1장

"자바 카드 런타임 환경 2.1 설명서"는 자바 카드 APT 2.1 및 자바 카드 2.1 버츄얼 머신 설명서 문서들에 의해 참조된 것처럼 자바 카드 2.1 구현을 완료하기 위한 최소 동작 및 런타임 환경을 규정한다. 본 설명서는 자바 카드 애플릿들의 호환 오퍼레이션을 보장하기 위해 필요하다. 본 설명서 문서의 목적은 JCRE 요소들이 함께 간결한 방식으로 자바 카드 2.1 설명서의 일부분이 되게 하는데 있다.

<javaoem-javacard@sun.com> 또는 이하의 주소로 리뷰 코멘트들을 송신해주기 바랍니다. 자바 카드 팀을 대표하여, 당신의 응답을 기다리겠습니다.

갓프리 디죠오지(Godfrey DiGiorgi)

godfrey.digiorgi@eng.sun.com

OEM Licensee Engineering

Sun Microsystems/Java Software

+1 408 343-1506 - FAX + 1 408 517-5460

Claims

소형 풋프린트 장치에 있어서,

적어도 하나의 프로세싱 소자,

메모리,

상기 메모리 및 상기 프로세싱 소자를 사용해서 프로그램 모듈들을 서로 아이솔레이트(isolate)하기 위한 콘텍스트 배리어(context barrier), 및

콘텍스트 배리어 제약 없이 모든 프로그램 모듈들로의 액세스를 갖는 하나의 콘텍스트

를 포함하는 것을 특징으로 하는 소형 풋프린트 장치.
제1항에 있어서,

상기 콘텍스트는 콘텍스트 배리어를 넘어서 적어도 하나의 프로그램 모듈을 액세스하기 위해 사용되는 것을 특징으로 하는 소형 풋프린트 장치.
제1항에 있어서,

상기 콘텍스트는 각각의 프로그램 모듈에 대해 별도의 명칭 스페이스를 할당하는 것을 특징으로 하는 소형 풋프린트 장치.
제3항에 있어서,

상기 콘텍스트는 상이한 명칭 스페이스에 위치되더라도 적어도 하나의 다른 프로그램을 액세스할 수 있는 것을 특징으로 하는 소형 풋프린트 장치.
제1항에 있어서,

상기 콘텍스트는 각각의 프로그램 모듈에 대해서 별도의 메모리 스페이스를 할당하는 것을 특징으로 하는 소형 풋프린트 장치.
제5항에 있어서,

상기 콘텍스트는 상이한 메모리 스페이스에 위치하더라도 적어도 하나의 프로그램 모듈을 액세스할 수 있는 것을 특징으로 하는 소형 풋프린트 장치.
제1항에 있어서,

상기 콘텍스트 배리어는 주체, 객체 및 액션들 중 적어도 하나에 보안 점검을 강요하는 것을 특징으로 하는 소형 풋프린트 장치.
제7항에 있어서,

적어도 하나의 보안 점검은 주체 및 객체간 부분 명칭 일치에 기초하는 것을 특징으로 하는 소형 풋프린트 장치.
제8항에 있어서,

상기 콘텍스트는 상기 적어도 하나의 보안 점검 없이도 적어도 하나의 다른 콘텍스트에 액세스할 수 있는 것을 특징으로 하는 소형 풋프린트 장치.
제7항에 있어서,

상기 적어도 하나의 보안 점검은 주체 및 객체간 메모리 스페이스에 기초하는 것을 특징으로 하는 소형 풋프린트 장치.
제10항에 있어서,

상기 콘텍스트는 상기 적어도 하나의 보안 점검 없이도 적어도 하나의 다른 콘텍스트에 액세스할 수 있는 것을 특징으로 하는 소형 풋프린트 장치.
소형 풋프린트 장치를 동작시키는 방법에 있어서,

콘텍스트 배리어를 사용해서 프로그램 모듈들을 분리하는 단계, 및

하나의 콘텍스트가 콘텍스트 배리어 제약없이 적어도 하나의 다른 콘텍스트를 액세스하는 것을 허용하는 단계

를 포함하는 것을 특징으로 하는 방법.
제12항에 있어서,

주체 및 객체 모두가 동일한 콘텍스트의 일부이거나 또는 주체가 상기 하나의 콘텍스트의 일부가 아니면, 주체가 객체에 대한 액션을 실행하는 것을 콘텍스트배리어가 허용하지 않는 것을 특징으로 하는 방법.
제1 프로그램 모듈로부터 콘텍스트 배리어에 의해 분리된 제2 프로그램 모듈로 소형 풋프린트 장치상의 정보를 액세스하는 것을 허용하는 방법에 있어서,

콘텍스트 배리어 제약없이 모든 프로그램 모듈에 대한 액세스를 갖는 콘텍스트를 생성하는 단계를 포함하는 것을 특징으로 하는 방법.
제14항에 있어서,

상기 콘텍스트는 슈퍼콘텍스트인 것을 특징으로 하는 방법.
소형 풋프린트 장치에서 프로그램 모듈들을 분리하는 콘텍스트 배리어를 넘어서 통신하는 방법에 있어서,

콘텍스트 배리어 제약이 없이 모든 프로그램 모듈에 액세스를 갖는 콘텍스트를 생성하는 단계, 및

상기 콘텍스트가 상기 콘텍스트 배리어를 넘어서 다른 프로그램 모듈의 정보를 액세스하는 것을 허용하는 단계

를 포함하는 것을 특징으로 하는 방법.
소형 풋프린트 장치에서 프로그램 모듈들을 분리하는 콘텍스트 배리어를 넘어서 통신하는 방법에 있어서,

콘텍스트 배리어 제약이 없이 모든 프로그램 모듈에 액세스를 갖는 콘텍스트를 생성하는 단계, 및

적어도 하나의 프로그램 모듈이 상기 콘텍스트를 사용해서 상기 콘텍스트 배리어를 넘어서 다른 프로그램 모듈의 정보를 액세스하는 것을 허용하는 단계

를 포함하는 것을 특징으로 하는 방법.
컴퓨터 프로그램 제품에 있어서,

메모리 매체, 및

소형 풋프린트 장치에 콘텍스트 배리어를 구현고, 콘텍스트 배리어 제약이 없이 모든 프로그램 모듈들에 하나의 콘텍스트 액세스를 부여하기 위한 명령을 포함하는 컴퓨터 제어 소자

를 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제18항에 있어서,

상기 매체는 캐리어 웨이브인 것을 특징으로 하는 컴퓨터 프로그램 제품.
컴퓨터 프로그램 제품에 있어서,

메모리 매체, 및

소형 풋프린트 장치에서 다수의 프로그램들을 각각의 콘텍스트로 동작시킴으로써 다수의 프로그램들을 분리하고, 콘텍스트 배리어 제약이 없이 하나의 콘텍스트가 모든 프로그램 모듈을 액세스하는 것을 허용하기 위한 명령을 포함하는 컴퓨터 제어 소자

를 포함하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제20항에 있어서,

상기 매체는 캐리어 웨이브인 것을 특징으로 하는 컴퓨터 프로그램 제품.
캐리어 웨이브에 있어서,

콘텍스트 배리어 제약이 없이 소형 풋프린트 장치의 모든 프로그램 모듈들에 대한 액세스를 갖는 콘텍스트를 구현하기 위한 명령들을 통신 링크를 통해 운송하는 것을 특징으로 하는 캐리어 웨이브.
캐리어 웨이브에 있어서,

소형 풋프린트 장치의 다수의 프로그램들을 각각의 콘텍스트로 실행함으로써 분리하기 위한 콘텍스트 배리어를 구현하고, 하나의 콘텍스트가 콘텍스트 배리어 제약이 없이 모든 프로그램을 액세스하는 것을 허용하기 위한 명령을 통신 링크를 통해 운송하는 것을 특징으로 하는 캐리어 웨이브.
네트워크를 통해 코드를 전송하는 방법에 있어서,

서버로부터 코드 블럭을 전송하는 단계를 포함하고, 상기 코드 블럭은 콘텍스트 배리어를 넘어서는 액세스를 제공하기 위해 모든 프로그램 모듈들에 대한 액세스를 갖는 콘텍스트를 구현하는 명령들을 포함하는 것을 특징으로 하는 방법.