3. 주요 기능 규격

이 장에서는 표준 플랫폼의 주요 기능 규격을 정의한다.

3.1. 다중 응용프로그램 수행

플랫폼은 여러 개의 응용프로그램이 메모리에 적재되어 동시에 수행 될 수 있는 환경 을 지원해야 한다. 또한, 플랫폼은 여러 개의 응용프로그램을 동시에 실행할 수 있어야 한다. 플랫폼은 여러 개의 응용프로그램 간 실행 우선 순위를 두고 매 순간 실행 가능 한 가장 높은 우선 순위의 응용프로그램을 실행해야 한다. 여러 응용프로그램을 수행 할 경우 각 응용프로그램은 독립적으로 수행 되어야 한다. 독립적인 응용프로그램간 통신을 지원하기 위하여 공유 메모리와 이벤트를 전달 할 수 있는 방법을 제공해야 한다. 플랫폼은 플랫폼이 지원하는 프로그래밍 언어로 작성된 응용프로그램의 생명주기를 관 리할 수 있어야 한다.

3.2. 지원 프로그래밍 언어

플랫폼은 응용 프로그램 개발자가 Java나 C 언어로 플랫폼의 필수 API를 사용하여 응 용 프로그램을 작성할 수 있도록 지원해야 한다.

3.2.1. C 언어 지원

플랫폼은 기본 API에 정의된 C 언어용 API와 ANSI C 언어 문맥을 지원해야 한다.

3.2.2. Java 언어 지원

플랫폼은 필수 API에 정의된 Java 언어용 API와 JAVA Programming Language 2nd edition 문맥을 지원해야 한다.

3.3. 플랫폼 보안

3.3.1. 보안의 정의

플랫폼에서의 보안은, 한 응용 프로그램 이 플랫폼의 자원(API 나 저장공간, 공유 메 모리 등등)를 통해서 다른 엔터티(다른 응용 프로그램 혹은 응용 프로그램 이 동작 하고 있는 플랫폼이나 플랫폼이 탑재된 단말기 혹은 다른 단말기 혹은 단말기가 연 동하고 있는 네트워크/서버 시스템 등등)의 동작에 영향을 끼치거나, 다른 엔터티가 소유하고 있는 정보에 접근하는 경우에 대한 정책적, 기술적 대책을 의미한다. 플랫 폼은 본 절의 보안 관련 규격에 따라 응용 프로그램 의 플랫폼 자원 에 대한 접근을 제어할 수 있어야 한다.

3.3.2. 보안 수준

플랫폼의 보안 기법은 기본적으로 플랫폼의 각 자원 별 정의된 보안 수준 별 접근 허용 여부와 응용 프로그램 의 보안 수준에 대한 정보를 바탕으로 수행되어야 한다. 플랫폼의 보안 수준의 종류 혹은 개수는 최소한 하나 이상 정의 되어야 하며, 그 내 용은 구현에 관한 사항이다. 단, WIPI 이전 버전 규격과 MIDP 2.0 규격과의 호환성 을 위해서 최소한 다음의 보안 수준을 지원할 것을 권장한다. ○ PUBLIC 플랫폼에 존재하는 보안 레벨 중 가장 신뢰할 수 없는 수준, 혹은 가장 제약 사항이 많은 수준을 뜻한다. 플랫폼은 PUBLIC 수준의 응용 프로그램 이 실행될 때, 단말기 시스템에 영향을 줄 수 있거나, 개인 정보에 접근하는 등, 보안 문제를 야기할 소지 가 있는 플랫폼 자원 에 대한 접근을 허용해서는 안 된다. ○ CP 플랫폼이 응용 프로그램 을 일정 수준 이상 혹은 전폭 신뢰가 가능하여 PUBLIC 수 준에서의 자원 에 대한 제약 사항을 일부 혹은 모두 해제한 수준을 의미한다. ○ SYSTEM System 보안 수준은 사실 CP 보안 수준의 부분 집합으로써 플랫폼이 응용 프로그 램 을 완전히 신뢰 가능한 것으로 간주하고 모든 자원 에 대한 접근을 자동 허용하 는 것을 말한다.

<표 3-4-1> WIPI 규격과 MIDP의 보안의 관계

WIPI 2. MIDP Public Un-Trusted CP Trusted System Trusted

3.3.3. 보안 정책의 대상 자원

보안 수준에 대한 자원의 종류에는 최소한 다음 그룹이 포함 되어 각 그룹별로 제어 가능해야 한다. Storage: Private directory / Application Shared Directory / System Shared Directory Network : Connection Oriented, Datagram, HTTP Secured Network connection : HTTPS Serial Device : RS-232C, USB Personal Information : 주소록, 촬영한 사진, 기타 개인 정보

3.3.4. 자원의 보안 수준 별 접근 허용 여부

플랫폼의 각 자원 별로 보안 수준에 따라 접근 허용 여부가 정의된 표가 존재해야 한다. 또한, 응용 프로그램 별로 보안 수준이 지정 되어야 한다. 자원 의 보안 수준 별 접근 인가 표는 단말 플랫폼에 존재할 수도 있고 응용 프로그램 을 공급하는 서 버에 존재할 수도 있다. 다음은 접근 인가 표의 예이다. <표 3-4-2>에서 자원 의 분 류나 보안 레벨의 분류는 모두 예제이며 그대로 따르지 않아도 좋다.

<표 3-4-2> 자원의 보안 수준 별 접근 인가 표

Graphic Sound Personal Info System Property Public Allow Allow Deny Deny CP Allow Allow User Deny System Allow Allow Allow Allow 플랫폼은 응용 프로그램 이 어떤 자원 를 접근하고자 할 경우 응용 프로그램 의 보 안 수준과 자원 의 보안 수준별 접근 인가 조건에 따라서 상기 표에 따라서 응용 프 로그램 의 자원 접근 시도에 대해서 다음과 같은 제어를 수행할 수 있어야 한다. ○ 허용 (Allow) 사용자의 개입 없이 자동으로 자원 에 대한 접근을 허용해야 한다. ○ 사용자의 허락에 의한 접근 허용 (User) 응용 프로그램 이 “사용자의 허락에 의한 허용”이라고 명시된 자원 를 접근하고자 할 경우 플랫폼은 이 사실을 사용자에게 응용 프로그램 이 하고자 하는 일을 정확하 게 알리고 사용자의 선택에 따라 행동해야 한다. 사용자의 선택에 대한 내정된 행동 또한 미리 정의 되어 있어야 한다. ○ 거부 (Deny) 사용자의 개입 없이 자동으로 자원 에 대한 접근을 거부해야 한다. ○ 사용자의 허락에 의한 접근 허용 “사용자의 허락에 의한 허용(User)” 대상인 자원 에 응용 프로그램 이 접근하고자 할 경우, 플랫폼은 사용자에게 이를 알려야 하며, 사용자는 다음 옵션 중 하나를 선택할 수 있다. 만약 플랫폼이 응용 프로그램 별로 자원에 대한 접근 인가 여부를 조회 및 변경할 수 있는 User Interface 를 제공할 경우, 사용자는 해당 사용자 인터페이스 를 통해서 응용 프로그램의 동작 여부와 상관 없이 접근 인가 여부를 변경할 수 있다. 변경된 사항은 각 조건별로 지속 시간 동안 계속 응용 프로그램 의 해당 자원 접근 시 유효해야 한다. ○ 계속 거부 응용 프로그램 이 uninstall 될 때까지 거부해야 한다. ○ 응용 프로그램 종료시까지 거부 응용 프로그램 의 실행이 종료될 때 까지 거부해야 한다. ○ 이번만 거부 응용 프로그램 은 이번 호출에 한해 자원 접근할 수 있어서는 안 되며, 다음 번에는 다시 사용자에게 문의해야 한다. ○ 이번만 허용 단 한번의 함수 호출만을 허용해야 하며, 다음 번에는 다시 사용자에게 문의해야 한 다. ○ 응용 프로그램 종료시까지 허용 응용 프로그램 의 실행이 종료될 때 까지 허용해야 한다. ○ 계속 허용 응용 프로그램 이 uninstall 될 때까지 허용해야 한다. 만약 플랫폼이 응용 프로그램 별 자원에 대한 보안 레벨을 조회 및 변경할 수 있는 사용자 인터페이스를 제공할 경우, 사용자는 계속 허용했던 자원 에 대한 정책을 변경할 수 있어야 한다.

3.3.5. 보안 관련 실천 규칙

이렇게 정의된 플랫폼의 접근 인가 여부 표와 응용 프로그램 별로 설정된 보안 수준 을 통해서 보안 관련 동작을 수행해야 한다. 그 세부적인 규칙은 다음과 같다. ○ 응용 프로그램 별로 정의된 보안 관련 정보와 플랫폼의 자원 별로 정의된 보안 관련 접근 인가 조건에 따라 플랫폼은 응용 프로그램 의 자원 접근을 제어해야 한다. ○ 응용 프로그램 의 보안 관련 정보는 응용 프로그램 이 공급될 때 같이 공급 되어 야한다 ○ 응용 프로그램 의 보안 관련 정보는 인증 기술을 통해 인증할 수 있다. ○ 응용 프로그램 의 자원 접근이 보안 관련 문제로 거절 되었을 경우 응용 프로그 램 에게 이 사실을 통보해야 한다. Java 의 경우에는 보안 예외 상황을 발생 시켜야 하고, C 의 경우에는 오류를 반환해야 한다.

3.4. API 추가/갱신 지원

플랫폼은 API 를 무선망을 통해서 추가/갱신할 수 있으며, 추가/갱신은 DLL을 통해 이 루어져야 한다.

3.4.1. DLL(Dynamic Linking Library)

DLL은 플랫폼에서 새로운 API를 추가하거나, 기존 API를 갱신하는데 있어서 수단이 된다. [그림 3-5-1] DLL 서비스 및 사용 시나리오 DLL은 구현과 인터페이스로 분리되고, DLL 구현물의 관리를 위해 플랫폼은 API 추가/ 갱신에 따른 버전 관리 및 설치/삭제 기능을 가져야 한다. DLL사용자(응용 프로그램 개 발자)는 인터페이스를 통해 DLL의 특정 기능(라이브러리)을 사용 할 수 있다 플랫폼은 추가/갱신된 API에 대해서도 API 보안수준 정책을 동일하게 적용해야 한다. DLL/인터페이스는 단말기 기본 내장으로 탑재될 수도 있고, 어플리케이션 관리자나 사 용자의 지정에 의해 다운로드 될 수도 있다.

3.5. 메모리 관리

플랫폼은 응용프로그램이 사용하는 HEAP 메모리를 다음과 같이 관리해야 한다.

3.5.1. 자동 메모리 해제

하나의 응용프로그램이 종료되면, 해당 프로그램과 관련된 모든 메모리는 플랫폼에 반환해야 한다. 따라서, 이벤트 등 각종 동적으로 사용된 메모리는 자동으로 모두 반 환해야 한다.

3.5.2. 메모리 컴팩션(Compaction)

플랫폼에서 동적으로 사용하는 메모리를 할당/해제 할 때 메모리 단편화 (fragmentation)를 줄이기 위해 메모리 컴팩션을 할 수 있다.

3.5.3. Java 가비지 컬렉션(Garbage Collection)

플랫폼은 Java 언어 문맥에 따라 가비지 컬렉션을 지원해야 한다.

3.5.4. Java 스택(Stack)

플랫폼은 Java 응용프로그램 별로 스택을 할당/해제 할 수 있어야 하며, 각 응용프 로그램 별 스택의 크기를 동적으로 변화시킬 수 있다. Java 응용프로그램이 메모리 한계를 넘는 스택 할당 요청을 했을 경우 플랫폼은 예외 상황(exception)을 응용프로 그램에 전달 해야 하며, 예외상황 발생 후 플랫폼은 정상 동작해야 한다.

3.5.5. 공유 메모리 지원

응용프로그램들이 사용하는 메모리는 서로 독립적이어야 하고, 플랫폼은 응용프로그 램 간에 공유할 수 있는 메모리를 지원해야 한다. 플랫폼은 공유하는 모든 응용프로 그램이 종료될 경우 자동으로 공유 메모리를 해제 해야 한다

3.6. 응용 프로그램 관리

플랫폼은 다음의 기능을 제공해야 한다

3.6.1. 관리 기능

응용프로그램 수행 시 날짜 제한, 회수 제한 설정에 따라 기동 여부를 판단해야 한 다. 응용프로그램 설치/삭제 기능을 제공해야 한다. 응용프로그램 정지 기능을 제공 할 수 있다. 정지 기능은 실행 프로그램만 삭제하고 관련 데이터 파일을 남겨 두어 추 후 다시 프로그램을 설치하면 이전 데이터를 활용 할 수 있도록 하는 기능이다. API 추가/갱신 기능을 제공해야 한다. 응용프로그램 강제 종료 기능을 제공해야 한다.

3.6.2. 응용프로그램 다운로드 기능

플랫폼은 응용프로그램을 다운로드 받는 기능을 지원 하고, 다운로드 중 오류가 발 생할 경우 초기 상태로 복구해야 한다. 시리얼 인터페이스를 통한 다운로드 기능은 선택 사항이다.

3.7. 다국어 지원

3.7.1. 유니코드 지원

플랫폼은 Java 응용프로그램을 위해 유니코드를 지원해야 하며 입출력 시 문자열은 지역 특성에 맞게 해당되는 문자 코드로 변환해야 한다. 한국의 경우는 유니코드 문 자열과 EUC_KR 문자셋(Character Set) 문자열로 상호 변환해야 한다.

3.7.2. 로케일 지원

플랫폼은 C 응용프로그램에 대해 지역 정보에 따라 참조하여 지원하는 문자셋으로 인식해야 한다. 한국의 경우는 EUC_KR 문자셋을 이용해야 한다.

3.7.3. 확장 유니코드

EUC_KR 문자셋에는 유니코드에 대응되지 않는 그래픽 문자가 있으며, 이를 지원하 기 위해서 유니코드 사양에서 Private Use(0xE000-0xF8FFF)영역을 사용하는 확장된 유니코드를 사용 할 수 있다.

3.8. CLDC/MIDP 지원

WIPI 2.0 규격에서는 CLDC/MIDP를 필수 규격으로 채택하였으며 아래 소절을 준수해 야 한다.

3.8.1. CLDC 지원

CLDC 규격은 Sun Microsystems사의 CLDC 규격 1.1 (http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html)을 기준으로 해야 하며, 플랫폼은 바이너리 코드의 실행을 기반으로 하고 있으므로, CLDC 규격에서 정 의하는 버추얼머신의 기능은 플랫폼 엔진에서 수용해야 한다. 단, CLDC 규격에서 바 이트코드와 코드 검증 처리는 플랫폼의 의미를 AOTC를 포함하는 것으로 해석하여 처리하기로 규정한다. (이와 관련하여 CLDC 규격서 5.2.1.1 Verification process의 Phase 2: In-device verification에서 “In-device”의 정의를 플랫폼과 AOTC를 포함하는 것으로 한다.) CLDC를 지원할 경우 규격서 “제4편 2.1 CLDC 클래스”를 CLDC Core API와 호환되도록 대체한다.

3.8.2. MIDP 지원

MIDP 규격은 Sun Microsystems사의 규격 2.0 (http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html)을 기준으로 해야 한다.

3.8.3. 필수 API와의 상호운용성

CLDC/MIDP는 필수 Java API와 상호 보완적으로 사용되어야 한다. 같은 기능을 하 는 API를 혼용하지 말아야 하며, 한 편에서만 지원되는 API는 보완적으로 서로 사용 할 수 있다.