1. 서론

인터넷의 급속한 발전과 더불어 1995년 5월에 발표된 Java는 기존의 컴퓨팅 환경인 메인프레임 및 클라이언트/서버 기반의 분산컴퓨팅 환경, 그리고 WWW(World Wide Web)들이 가지고 있는 많은 제약들에 대해 다양한 해결책을 제시하였다[1]. 특히 Java로 구현된 응용 프로그램은 기존의 컴퓨팅 플랫폼과 독립적으로 실행 가능하며, 이러한 패러다임을 썬 마이크로시스템즈(이하 썬)는 " Write Once, Run Anywhere^TM"라는 문장을 통해 Java의 핵심적인 특징을 표현하였다. 그림 1은 Java로 구현된 애플릿(Applet)이 아무런 수정없이 기존의 운영체제 플랫폼에서 동작되는 것을 보여준다.

그림1에서 보는 바와 같이 Java 애플릿과 같은 실행 가능한 응용(executable contents)은 네트워크를 통해 전송(download)되어 원격지에 있는 사용자의 컴퓨터에서 실행되어지는데 이와 같은 Java 기술은 네트워크를 기반으로 하는 컴퓨팅의 능력을 증대시킬 것은 틀림없지만 새로운 보안 문제를 발생시킨다.

그림1 "Write Once, Run Anywhere^TM"를 보여주는 Java 수행 모델

이에 본 고에서는 현재 Java에서 제공되고 있는 Security 기술, 그리고 향후 Java에서 제공하고자 하는 Security 기술에 대해 기술한다.

본 고의 구성은 다음과 같다. II장에서는 일반적인 Security 요구사항에 대한 내용을 기술하고, III장에서는 JDK1.0부터 제공하는Security 기법인 Sandbox를 분석하고, IV장에서는 JDK1.1에서 지원하는 확장된 Security 기법을 기술한다. V장에서는 향후 제공 예정인 Java Security기술을 살펴보고, 마지막으로 VI장에서 결론을 맺는다.

　

2. 네트워크 환경하에서의 Security 요구 사항 분석

그리고, 표2는 표1에서 살펴 본 컴퓨터 시스템 자원에 대한 위협 요소에 대해 Java 애플릿과 같은 실행 가능한 응용 프로그램이 접근할 수 있는 시스템의 자원 요소들을 보여준다.

Java에서는 이러한 위협 요소에 대한 기본적인 Security를 제공하고 있으며, 또한 Security 정책 수립자의 Security 방침 내용에 따라 수정 및 확장 가능케 하는 기술을 제공한다. 현재 시스템 자원들에 대한 접근 허용은 Java 어플리케이션(application) 및 애플릿 뷰어(viewer) , 그리고 네트워크에서 전송된 Java 애플릿을 수행할 수 있는 웹 브라우저(예: 넷스케이프사의 네비게이터, 마이크로소프트사의 인터넷 익스플로어) 등에 따라 다르다. 다음 표 3에서는 허용 가능한 시스템 자원 접근의 여부를 넷스케이프사의 웹 브라우저인 네비게이터 2.x 이상 버전 및 JDK내의 애플릿 뷰어, 그리고 Java 어플리케이션 별로 비교하여 제시하였다[3].

표 3에서 보는 바와 같이 NN인 경우에는 Security 정책이 매우 엄격하고, JS인 경우에는 기존의 응용 프로그램과 같이 대부분의 시스템 자원에 대한 접근이 가능하다. 즉, 네트워크를 통해 전송되어온 애플릿은 시스템 접근에 대한 많은 제약이 따르나, 로칼 파일 시스템에서 읽혀져 동작되는 Java 어플리케이션은 대부분의 시스템 자원에 접근이 가능하다.

한편, 표 3에서는 표 2에서 언급한 시스템 자원 중 메모리, 출력 장치, 입력 장치, 프로세스 제어, 시스템 커널 호출 등과 같은 부분의 내용이 빠져 있다. 이들 각각에 대해 살펴 보면 다음과 같다.

먼저 메모리에 대한 보호는 Java 언어 명세에 의해 기본적으로 이루어진다. 이미 할당된 메모리에 대한 애플릿의 접근은 가능하지 않으나, 애플릿이 객체를 생성하여 현재의 이용 가능한 메모리를 과다하게 할당하는 위협 요소에 대한 보호 작용은 존재 하지 않는다. 그러나 이러한 애플릿의 과다한 메모리 할당 요구는 직접적인 위협을 제공하지 못한다. 일반적으로 웹 브라우저는 Java가 사용 가능한 메모리의 양을 제한하기 때문에 애플릿의 과다한 메모리 할당 요구는 치명적 위협 요소는 아니며, 또한 웹 브라우저는 네트워크를 통해 전송된 애플릿이 과도한 메모리 할당을 요구하는 경우, 애플릿을 종결 시키는 메쏘드(method)를 가지고 있기 때문에 애플릿의 과도한 메모리 할당 요구를 막을 수 있다.

구분:

1. NN: 네트워크을 통해 전송된 애플릿이 넷스케이프 네비게이터 2.x 이상 버전에서 실행되는 경우
2. NL: 로칼 파일 시스템에서 읽은 애플릿이 넷스케이프 네비게이터 2.x 이상 버전에서 실행되는 경우
3. AN: 네트워크을 통해 전송된 애플릿이 JDK 1.x에 있는 애플릿viewer에서 실행되는 경우
4. AL: 로칼 파일 시스템에서 읽은 애플릿이 JDK 1.x에 있는 애플릿viewer에서 실행되는 경우
5. JS: Java 어플리케이션이 실행되는 경우

한편, 애플릿은 직접적으로 출력장치에 접근할 수 없으며, 대신에 Java 라이브러리에서 제공하는 방법만을 사용함으로써 출력 장치에 접근할 수 있다. 그리고, 애플릿은 키보드 입력이나 마우스 장치를 통해서만 접근할 수 있으며, 입력에 대한 특별한 접근 제한은 없다.

애플릿의 쓰레드에 대한 접근은 매우 제한적이어서 애플릿은 쓰레드에 대한 제어 권한을 가지지 못한다. 또한, 애플릿의 시스텀 커널 호출 부분에 대한 접근도 매우 제한적이다.

이와 같이 애플릿은 매우 제한된 시스템 자원에 대한 접근 권한만을 가지고 실행됨으로써, Security에 대한 안전성을 제공한다.

1. Java Security 기본 기능

1. Java Security 모델의 단계별 발전 현황

1. SandBox 기술

1. SandBox 개요

Java가 제공하는 기본적인 Security 모델인 Sandbox는 미국의 가정집 뒤뜰에서 장난치는 어린이들의 물리적인 부상을 막기 위한 모래통(Sandbox)에서 의미를 가져왔다. 이와 같이 Java에서도 시스템 자원에 대한 접근 제한을 위해 JVM(Java Virtual Machine) 영역내에 Sandbox를 만들어 안전한 Security를 제공한다 [4][5][6]. JVM내의 Sandbox의 위치는 그림 2와 같다.

그림2 JVM내의 Sandbox의 위치

그림 2에서 보는 바와 같이 Java는 기본적으로 로칼(Local) 파일 시스템에서 실행되는 애플릿과 어플리케이션은 신뢰성이 있는 실행가능한 응용 프로그램으로 간주하여 시스템 자원에 대한 접근이 가능하지만, 네트워크를 통해 전송된 애플릿은 신뢰성이 없는 것으로 간주하여 반드시 Sandbox내에 있는 Security 정책에 따라 시스템 자원에 대한 접근을 제한한다. 즉, Sandbox에 의해 접근이 허용된 애플릿은 자신의 작업을 수행할 수 있지만, Sandbox에 의해 로칼 파일 시스템의 접근이 허용되지 않는 애플릿은 로칼 파일을 읽거나 변경할 수 없기 때문에 로칼 파일 시스템에 대한 손상을 입히지 않는다. Java에서는 Security 책임자들이 Sandbox를 시스템의 고유 특성에 적합한 Security 정책을 수용할 수 있는 플랫폼으로 전환할 수 있는 기술을 제공한다.

한편, 애플릿의 자원 접근에 대한 부분은 자동적으로 Sandbox를 통해 제한되어지므로 사용자는 시스템내의 보안을 고려할 필요가 없다. 따라서 앞서 살펴본 바와 같이 Java Security 보안 모델은 사용자가 직접 Security 정책을 고려해야 하는 기존의 Security 모델보다 사용자 편리성 측면에서 훨씬 우수함을 보여준다.

　

2. Sandbox의 구성

• 정확한 클래스가 로드 되었는지를 검사한다.
• 로드된 클래스가 정확한 바이트코드(bytecode) 포맷인지를 검증한다.
• 신뢰성이 없는 클래스가 위험한 메쏘드를 실행시켜 보호된 시스템 자원을 접근하지 못하도록 한다

이들 세가지 컴포넌트를 통해 네트워크에서 전송된 애플릿의 Security 처리 과정은 그림 3과 같다[8].

먼저, 클라이언트의 웹 브라우저는 네트워크에 연결되어 있는 서버로부터 전송된 애플릿을 자신의 웹 브라우저내에서 실행시키기 위한 첫번째 단계로 클래스 로더(Class Loader)를 호출하며 다음과 같은 기능 수행을 통하여 애플릿이 클래스를 언제 어떻게 로드할 수 있는가를 결정한다.

• 웹 브라우저내의 클래스 로더는 원격지의 서버로부터 애플릿을 가져온다.
• 웹 브라우저내의 클래스 로더는 전송된 애플릿이 실행 시에 시스템 자원에 접근하지 않도록 하기 위하여 애플릿에 대한 이름 공간(name space)을 생성하고 관리한다. 특히 애플릿이 자신에 대한 새로운 클래스 로더를 생성 못하게 한다.
• 웹 브라우저내의 클래스 로더는 전송된 애플릿이 시스템 클래스 로더내에 있는 메쏘드 호출을 못하게 한다.

클래스 로더는 그림 4와 같이 클래스가 발생한 위치를 기반으로 하여 이름 공간을 관리 및 이용하여 클래스가 로칼 클래스인가 혹은 네트워크를 통하여 온 클래스인가를 구분하고 클래스의 신뢰성 여부를 판단한다. 이렇게 함으로써 클래스 로더는 신뢰성이 없는 애플릿이 허가 받지 않은 시스템 자원(예: 로칼 파일)에 대한 접근을 못하게 한다.

한편, 바이트코드로 구성된 애플릿은 클래스 로더에 의해 실행되기 이전에 Bytecode Verifier에 의해 검증을 받는다.

Bytecode Verifier는 클래스 파일이 올바른 형태로 구성되어 있는지를 확인하여 Java 컴파일러의 적법한 사양에 따라 생성된 바이트코드인지를 검사한다. 이외에도 Bytecode Verifier는 전송되어온 바이트코드가 시스템내에서 스택 오버플로우, 혹은 언더플로우가 발생되는지를 검사하고, 명령어 및 파라미터가 올바른지를 확인하며, 부적절한 레지스터 접근 여부를 검사한다. Bytecode Verifier과정을 통해 1차적인 Security 처리 과정이 끝나면, 앞서 기술한 것처럼 클래스 로더에 의해 또 한번 Security 처리 과정을 거친다. 클래스 로더를 통한 두 번째 단계인 Security 처리 과정이 끝나면, 세 번째 단계인 Security Manager가 수행된다.

Security Manager는 애플릿 실행시 컴퓨터 시스템 자원에 대한 접근을 제어하며, 또한 위험스러운 메쏘드(dangerous method)에 대한 검증을 한다. 위험스러운 메쏘드란 파일 I/O, 네트워크 접근이 요구되는 메쏘드나 새로운 클래스 로더를 정의하고자 하는 메쏘드 등을 말한다. 어느 경우에나 Security Manager는 거부권을 행사하는데 예로써, 애플릿이 “read” 메쏘드를 호출하면, JVM은 Security Manager를 참조하여 그 애플릿이 신뢰성이 있다고 판단되면 “read” 메쏘드는 애플릿을 실행시키고, 그렇지 않은 경우에는 에러가 발생되어 실행을 중지 시킨다. 이러한 Security Manager를 통한 접근 제어는 기존의 Security 기능을 확장하거나 새로운 Security 기능으로 구현되어 처리될 수 있다. 만약 Security Manager가 구현되어 있지 않을 경우에는 애플릿은 Java 어플리케이션과 같은 접근 권한을 가질 수 있다. 표 3에서 보는 바와 같이 네비게이터와 같은 웹 브라우저가 애플릿을 실행할 경우 애플릿의 파일 시스템에 대한 접근을 허용하지 않는 것은 네비게이터 JVM내에 있는 Security Manager가 파일 시스템에 대한 접근을 허용하지 않기 때문이다. 이외에도 Security Manager에서는 소켓(socket) 작동 관리, 쓰레드(thread) 관리, Class Loader 관리 등과 같은 기능들을 수행한다.

이러한 Security Manager를 구현하기 위해서는 JDK에서 제공하는 SecurityManager 클래스와 SecurityManager 클래스에서 제공되는 checkXXX() 메쏘드를 이용한다. Java에서는 파일 시스템, 소켓, 쓰레드, 클래스 로더등 시스템 자원의 종류에 따라 제공되는 checkXXX() 메쏘드의 종류가 다르다. 예로써, 파일 시스템 자원에 대한 접근 제어를 수행하는 checkXXX() 메쏘드 종류로는 checkWrite(), checkRead(), 그리고 checkDelete() 등이 있다. 이들 메쏘드의 기능을 살펴보면, checkWrite()는 네트워크를 통해 클라이언트에 전송된 애플릿이 클라이언트내의 로칼 파일 시스템에 접근하여 파일 생성에 대한 실행을 제어하고자 할 때 사용되어지며, checkRead()는 파일 읽기에 대한 실행을 제어하고, checkDelete()는 파일 삭제에 대한 실행을 제어하고자 할 때 수행되어진다.

앞서 설명한 checkXXX() 메쏘드와 SecurityManager 클래스를 이용하여Security Manager를 구현하는 절차는 다음과 같다. 먼저, Security 책임자는 새로운 Security 정책을 수립하고, 수립된 Security 정책의 실행을 담당하는 SecurityManager 클래스의 서브클래스(Subclass)를 생성한다. 그리고, 서브클래스가 생성된 후에 수립된 Security정책 내용을 만족시키기 위해 기존 checkXXX() 메쏘드들의 동작 내용들을 수정하고, 수정된 checkXXX() 메쏘드들을 서브클래스내에 포함시킨다. 마지막으로, 새로운 Security 정책을 수행하는 서브클래스를 포함하고 있는 SecurityManager 클래스를 설치하기 위해서 System클래스내의 setSecurityManager() 메쏘드를 이용하여 새로운 Security Manger를 JVM내에 설치함으로써, Security Manager의 구현이 완료된다. 이와 같이 Java에서는 Security Manager를 통해 매우 유연하면서도 투명성이 있는 Security를 제공해줄 수 있다.

한편, Bytecode Verifier, 클래스 로더, 그리고 Security Manger를 통한 Security 처리 과정이 끝나면, JVM은 운영체제와의 인터페이스를 통해 시스템내의 하드웨어 자원을 사용하면서 전송받은 실행 가능한 응용인 애플릿을 동작 시킨다.

1. Java 언어가 제공하는 Security 기능

C++와 마찬가지로 Java는 객체들의 변수와 메쏘드에 대해서 public, protected, private파라미터를 통해 접근 제어 능력을 가지고 있다. 이러한 접근 제어는 신뢰할 수 없는 클래스가 부적절하게 사용되지 않는다는 것을 보장해준다.

또한 접근 제어를 보장하는 다른 파라미터로는 final로 클래스나 메쏘드를 선언하는 것이다. 이것은 악의적인 프로그래머가 시스템의 자원을 위협하는 클래스를 기존의 자원 관련 핵심적인 라이브러리 클래스의 서브클래스로 사용하거나 한 클래스의 메쏘드를 오버라이딩하는 것을 막아준다. 그러므로, Java가 제공하는 final 파라미터는 클래스의 특정한 부분이 수정되지 않았음을 보장해준다.

또한 Java는 기존 C++에서 제공하는 포인터 기능을 제거하였다. 이는 실행 가능한 응용인 애플릿이 네트워크을 통해 원격지에 있는 컴퓨터 시스템에서 수행될 경우 메모리내에 존재하고 있는 기존의 다른 실행 프로그램들의 접근을 막기 위해서다.

이와 같이 Java는 Sandbox 기술뿐만 아니라 Java 언어 자체에 대한 Security를 제공하여 안전성을 한층 더 강화시켰다.

IV 확장된 Java Security 기능

본 장에서는 JDK1.1에서부터 제공하기 시작한 전자 서명 및 X.509기반의 인증서 등 JDK1.0에서 확장된 여러 Security 기술에 대해 기술한다.

1. Java Security API

JDK1.0에서의 Security 기술 외에 JDK1.1부터는 전자 서명, 메시지 다이제스트, X.509기반의 인증서 관리, 키 관리, 그리고 접근 제한 권한을 제공하는 Security API를 제공한다[10].

먼저 전자 서명에 대해 살펴 보면, 전자 서명은 애플릿 및 어플리케이션을 신뢰하는데 사용되어진다.

전자 서명을 구현하기 위해서는 공개키 암호화 방식을 이용하는데, 공개키 암호화 방식은 암호화 키와 복호화 키가 동일하여 교환되는 정보에 대한 인증을 제공하지 못하는 대칭형 암호화 기술과 달리 암호화에 사용되는 키와 복호화에 사용되는 키가 서로 다르다. 일반적으로 복호화 키는 공개를 하기 때문에 공개키로 정의되어지며, 암호화하는데 사용되는 키는 비밀로 간직하기 때문에 개인키로 정의되어진다. 공개키 암호화 방식은 암호화 알고리듬 특성상 개인키로 암호화된 정보는 개인키에 대응되는 공개키를 반드시 사용하여 복호화할 수 있다[11]. 공개키 암호화 방식의 절차는 그림 5와 같다.

그림5에서 보는 바와 같이 송신자 A는 개인키 KRa를 가지고 평문 M에 대한 암호문을 구성하고, 수신자 B는 A의 개인키로 암호화된 M`을 받고 암호화된 M`을 복호화하기 위해서 A의 공개키 KUa를 이용한다. 그림5와 같은 공개키 암호화 절차과정은 결과적으로는 송신자 A가 암호화하기 위한 평문 M에 자신의 개인키를 사용하여 전자 서명한 효과이다. 이와 같은 공개키 암호화의 특성때문에 정보 인증을 위해서는 공개키 암호화 방식을 근간으로 하는 전자 서명을 사용한다.

대표적인 공개키 암호화 알고리듬으로는 DSA(Digital Signature Algorithm)와 RSA(RSA 알고리듬을 만든 Ronald Rivest, Adir Shamir, Leonard Adleman에 의해 명명되어짐)가 있다. JDK1.1에서는 DSA만을 사용하고 있으며, 이는 RSA사가 현재 미국과 캐나다에서 RSA 암호화 알고리듬에 대해 특허를 소지하고 있기 때문이다. 그러나, 제3의 업체로부터 RSA를 제공하는 Java Security API를 사용하면, RSA 암호화 알고리듬을 Java에서도 사용할 수 있다.

한편, 메시지 다이제스트는 네트워크를 통해 전송되어온 애플릿의 내용이 변하지 않았음을 증명하는데 사용되어진다. 이 메시지 다이제스트 알고리듬은 정보 내용의 체크섬(CheckSum)을 구하듯이 정보를 해쉬(hash) 처리한 후 각 정보에 대응되는 일정 길이의 해쉬를 구하는 알고리듬이다. 메시지 다이제스트는 해당 정보와 일대일로 매핑되기 때문에 정보의 내용을 증명할 수 있는 코드로서 활용된다. 즉 어떤 정보를 해쉬함수를 통해 메시지 다이제스트를 구하면 해당 메시지 다이제스트를 이용해 자료의 수정, 순서 변경, 삭제, 첨가 등 정보의 통합성을 체크할 수 있다.

특히 메시지 다이제스트를 구하는 해쉬함수는 단방향 해쉬함수로서 생성된 메시지 다이제스트로부터 원래의 정보를 추론할 수 없는 해쉬를 사용하기 때문에 안전하다고 할 수 있다. 이 해쉬함수는 임의의 길이를 가지고 있는 정보를 입력 받아 일정한 길이의 결과로 전해주는 함수이다. 원래의 정보 X에 대하여 해쉬함수 f를 사용하여 나온 결과가 x'인 경우에 식으로 나타내면 f(X) = x' 이며, 안전한 해쉬 함수가 되기 위해서는 다음의 조건을 만족해야 한다.

조건 1: 임의의 길이의 정보를 입력으로 받을 수 있어야 한다.

조건 2: 고정된 길이의 출력을 만들어야 한다.

조건 3: 모든 X에 대해서, f(X)의 계산이 쉬워야 한다.

조건 4: 주어진 x'에 대해서 원래의 X를 구할 수 없어야 한다.

조건 5: X,Y가 같지 않을 때, f(X), f(Y)는 같을 수 없다.

조건 6: f(X)=f(Y)인 X,Y를 구하기가 어려워야 한다.

이러한 암호화 해쉬 함수의 종류는 128 bit의 출력을 생성하는 MD5와 160 bit출력의 SHA(Secure Hash Algorithm)가 있다. JDK1.1에서는 MD5와 SHA를 지원하는 API를 제공하고 있다. 그림6은 메시지 다이제스트의 생성 과정을 보여준다.

한편, JDK1.1에서는 X.509v1기반의 인증서를 지원한다. X.509 기반의 인증서는 애플릿 혹은 어플리케이션에 공개키 암호화 알고리듬을 이용하여 전자 서명을 할 경우 사용되며 공개키의 신뢰성을 증명하는 인증서로 사용된다. 또한, JDK1.1에서 제공하는 키 관리 부분은 전자 서명 및 메시지 다이제스트를 사용하는데 필요한 개인키 및 공개키의 관리를 지원하기 위한 것이며 접근 제한 부분은 컴퓨터 시스템의 자원에 접근을 제한하는데 사용되어진다.

이외에도 Security와 관련되어 JDK1.1에서 제공하는 API외에 다른 업체에서 제공하는 SSP(Security Package Provider)에 포함되어 있는 API를 사용하여 Security 기능을 구현할 수 있다.

2. JAR 파일과 전자 서명

JAR방식은 여러 개의 파일로 되어 있는 애플릿을 하나의 통합된 파일로, 한번에 HTTP 프로토콜을 통해 전송하기 때문에 HTTP 프로토콜의 전송 효율을 개선시킬 수 있다.

이러한 JAR 파일 방식의 특성은 애플릿에 필요한 파일들을 함께 묶어 전송할 수 있기 때문에 애플릿을 구성하고 있는 각각의 파일에 대한 전자 서명을 할 필요없이 애플릿을 구성하고 있는 전체 파일인 JAR파일에 대한 전자 서명을 통해 애플릿의 전체 내용을 인증할 수 있다. 전자 서명은 파일의 압축 및 복원을 담당하는JAR 툴과 전자 서명에 필요한 키 생성을 담당하는 Javakey를 이용한다. 그리고, JDK1.1에서는 전자 서명을 위해 DSA와 MD5, 그리고 SHA 암호화 알고리듬과 X.509v1기반의 인증서를 사용한다.

여러 개의 파일 들로 구성되어 있는 애플릿은 JAR 툴과 Javakey를 이용하여 하나의 JAR파일로 묶여지며, JAR파일내에는 원래의 파일과 전자 서명을 통해 생성된 Manifest 파일 및Signature 파일, 그리고 전자 서명의 내용이 담겨져 있는 DSA파일이 생성된다. Manifest파일의 확장자는 .MF이며, Signature 파일의 확장자는 .SF이고, 마지막으로 DSA파일의 확장자는 .DSA가 된다. 그림7은 애플릿의 전자 서명 과정을 보여 준다.

그림7에서의 동작 과정을 살펴보면 송신자는 JAR 툴을 이용하여 여러 개의 파일로 구성된 파일을 하나로 묶어 JAR파일을 생성하고 생성된 JAR파일의 전자 서명을 초기화 한다. 초기화 하는 과정은 JAR 파일내에 포함되어 있는 각 클래스마다 별도로 수행되는데 먼저 클래스의 메시지 다이제스트를 구하여 .MF확장자를 가지는 파일을 생성하여 저장하고, .MF파일의 메시지 다이제스트를 구하여 .SF확장자를 가지는 파일을 생성하여 저장한다. 이와 같이 수행하는 이유는 .MF파일의 무결성을 보장하기 위해서 이다. 그리고 생성된 .MF파일은 X.509v1 인증서와 생성된 공개키 및 비밀키를 이용하여 전자 서명된 후에 .DSA확장자를 가지는 파일을 생성한다.

송신자는 생성된 .MF파일 및 .DSA파일, 그리고 .SF파일을 다시 묶어 전자 서명화된 새로운 JAR파일을 생성하여 수신자에게 전송한다. 수신자는 전자 서명화된 파일을 수신 받은 뒤 세 개의 .MF파일 및 .DSA파일, 그리고 .SF파일을 추출한 후, .MF파일의 메시지 다이제스트를 구하여 .SF파일과 비교하여 일치하면 .DSA파일을 복호화한다.

.DSA파일이 복호화되면 .MF파일과의 내용과 비교하여 결과가 일치하면, JAR파일을 복원하여 JAR파일내에 포함되어 있는 클래스 파일들을 실행시킨다. 이러한 과정을 통해 신뢰성을 보장하는 전자 서명화된 애플릿을 실행시킬 수 있다.

한편, 전자 서명과 JAR 파일은 Java 어플리케이션에도 이용되어 질 수 있다. 물론 Java 어플리케이션은 대부분의 시스템 자원 접근에 대한 제한이 없기 때문에 애플릿의 전자 서명 효과와 조금 달라질 수 있으나, 전자 서명을 통해 컴퓨터 시스템내에 바이러스를 감염시킨 사용자에 대해 Java 어플리케이션 배포 유무의 책임을 판별할 수 있는 효과를 가져온다.

V. 향후 Java Security 기술

JDK1.2 및 향후 Java에서 제공하게 될 Security 구조는 Protected Domain에 대한 Security, 틀 기반의 Security 환경 설정, 유연한 접근 제한, X.509v3기반의 인증서, 다양한 암호화 알고리듬의 수용, 안전한 통신을 위한 SSL(Secure Socket Layer) 및 SKIP(Simple Key Management Internet Protocol) 지원, 향상된 감시 능력, 그리고 Domain IDs 등을 지원할 예정이다. 다음에 이들 각 기술에 대해 살펴본다.

1. Protected Domains

Protected Domains는 실행 가능한 응용인 애플릿 혹은 어플리케이션의 특징에 따라 시스템 자원에 접근할 수 있는 부분을 분리시켜 한 시스템 영역내에 가상적인 Protected Domains을 여러 개로 두는 기술이다. 예를 들어 전자 서명을 이용하여 신뢰성을 제공하는 애플릿 혹은 어플리케이션이 접근할 수 있는 시스템 자원 부분과 그렇지 않은 경우에 대한 부분을 Protected Domain 기술을 이용하여 차별화 시킬 수 있다. 이러한 기술은 기존의 방식에서 제공하는 Sandbox 기술의 기능 중 Fine-grained Control로 명명되어지는 시스템 자원에 대한 접근 제한 기술을 확장하여 응용 프로그램의 특성에 따라 다중 Security 정책을 세울 수 있음으로써 유연성 및 안정성을 강화시켰다.

Java에서 정의되고 있는 Protection Domain은 시스템 자원 부분과 응용 프로그램으로 나누어진다. 시스템 자원 부분으로는 파일 시스템, 네트워크, 모니터, 키보드 등이며, 응용 프로그램으로는 Java 애플릿 및 어플리케이션이 있다. Protected Domains 구조는 그림 8과 같다.

그림 8에서 보는 바와 같이 Protected Domain 구조는 한 System Domain 영역내에 다중 Protected Domain을 두어 해당되는 Protected Domain에 Domain ID(그림8 예: A, B)를 부여하여 구분하며 이러한 방식을 통해 기존의 Java에서 사용되는 단일 System Domain 기술에서 발생되어온 문제점인 하나의 에러가 전체적인 시스템 자원 관리 부분에 치명적인 위협이 되는 것을 해결할 수 있다.

그림 8 Protected Domains 구조
2. 기타 Security 기능들

이전에 Java에서 제공하는 Security 정책은 프로그래밍 수준에서 제공하여 일반 사용자들이 이용하기에는 매우 어려웠으나, 향후 나오게 될 JDK1.2 이후 버전에서는 간단하면서 사용하기 쉬운 툴을 제공할 계획이다.

한편, 송신자와 수신자간에 통신상에서 발생되는 주요한 정보의 유출을 방지하기 위한 암호화 기술의 상호 조정을 가능케 하는 SKIP을 제공하여 SSL과 더불어 통신상에서 발생되는 위협 요소들에 대한 Security를 강화 시킬 예정이다 [14].

감시 기능에서는 불법적으로 침입한 네트워크 사용자에 대한 감시 기능을 위해 사용자 기록(log)을 저장하고 검색할 수 있는 기능을 제공하며 X.509v3 기반의 인증서 및 온라인 인증 서버(Certificate Authority)를 구현하는데 필요한 API들도 제공할 예정이다.

VI. 결론

Java는 간결하고 객체지향적이며 플랫폼에 독립적으로 실행 가능한 프로그램밍 언어이다. 이러한 특징 중 가장 중요한 것은 네트워크를 통해 Java로 구현된 애플릿과 같은 실행 가능한 프로그램들이 운영체제 플랫폼에 관계없이 사용자의 컴퓨터에서 동적으로 전송되어 수행될 수 있다는 것이다. 이러한 Java 기술은 네트워크을 기반으로 하는 컴퓨팅 시스템의 능력을 증대시키며, 또한 네트워크 및 분산 컴퓨팅 환경에서 발생되는 응용 프로그램들의 보수 및 유지 문제에 대한 해결책을 제시할 수 있다.

그러나 네트워크 및 분산 컴퓨팅 환경에서는 서버에서 전송되어 온 Java 애플릿과 같은 실행 가능한 응용 프로그램이 클라이언트에서 실행되어 시스템 자원들을 파괴할 수 있는 새로운 Security 문제를 발생시킨다. 현재 Java Security에서는 JDK1.0에서의 Sandbox 기술, JDK1.1에서의 전자 서명을 사용한 애플릿 인증 기술, 그리고 JDK1.2에서 제공할 예정인 접근 제한 기술등과 같은 다양한 Security 기술을 제공하여 Security를 한층 더 강화 시키며, 사용자에게는 보다 나은 유연성을 지원한다.

따라서, Java를 네트워크 컴퓨팅 환경에 적용하려는 기업이나 기관, 혹은 개인 사용자는 Java에서 제공하는 다양한 Security기술을 효과적으로 이용함으로써, 네트워크 및 분산 컴퓨팅 환경에서의 Security 문제를 보다 효율적으로 해결할 수 있을 것이다.

• 약어 목록

JVM Java Virtual Machine

OLE Object Linking and Embedding

SHA Secure Hash Algorithm

SKIP Simple Key Management Internet Protocol

SSL Secure Socket Layer

SSP Security Package Provider

WWW World Wide Web

• 참고문헌

1. J.Steven Fritzinger, and Marianne Mueller, 'Java Security,' Sun Microsystems, Inc. 1997.

Available via http://java.sun.com/security

2. Joseph A. Bank, 'Java Security,' 1995.

Available via http://www-swiss.ai.mit.edu/~jbank/javapaper/javapaper.html

3. Sun Microsystems, 'Frequently Asked Questions - Java Security,' 1997.

Available via http://java.sun.com/sfaq

4. Sun Microsystems, 'Secure Computing With Java,' White Papers, 1997.

Available via http://java.sun.com/marketing/collateral/security.html

5. Li Gong, 'Java Security Present and near Future,' JavaOne Conference, April. 1997.

Available via http://java.sun.com/javaone

6. Li Gong, 'Java Security Present and near Future,' IEEE Micro, pp.14-19, May/JUNE. 1997.
7. Gary McGraw, and Edward Felten, 'Understanding the keys to Java security - the sandbox and authentication,' JavaWorld, May. 1997.

Available via http://www.javaworld.com/javaworld/jw-05-1997/jw-05-security.html

8. Sun Microsystems, 'HotJava™ : The security Story,' JavaWorld, May. 1995.

Available via http://java.sun.com/sfaq/may95/ security.html

9. T.Lindholm, and F.Yellin, "The Java Virtual Machine Specification," Addison-Wesly, 1997.
10. Sun Microsystems, 'Java Cryptography Architecture API Specification & Reference,' May. 1997.

Available via http://java.sun.com/product…ide/security/Cryptospec.html

11. William Stallings, Network And Internetwork Security Principle And Practice, Prentice Hall, Inc., 1995.
12. Sun Microsystems, 'Using Javakey,' 1997.

Available via http://java.sun.com/security/UsingJavakey.html

13. Sun Microsystems, 'Manifest Format,' 1997.

Available via http://java.sun.com/products/jdk/1.1/docs/guide/jar/manifest.html

14. T J Hudson, and E A Young, 'SSLeay and SSLapps FAQ,' April. 1997.

Available via http://psych.psy.uq.oz.au/~ftp/Crypto.html

15. Merlin Hughes, 'JavaBeans and ActiveX go head to head,' JavaWorld, March. 1997.