KR20060045000A

KR20060045000A - 파일 락커 및 파일 락커를 제공하고 사용하기 위한메커니즘

Info

Publication number: KR20060045000A
Application number: KR1020050026468A
Authority: KR
Inventors: 브라이언 엠. 윌만
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-04-23
Filing date: 2005-03-30
Publication date: 2006-05-16
Also published as: US7330981B2; EP1594032A2; US20050257048A1; CN1690910A; EP1594032A3; JP2005310122A

Abstract

파일 락커는 소프트웨어 객체들에 대하여 보호된 데이터의 저장과 사용을 관리한다. 보호되는 환경은 신뢰된 에이전트에 의한 사용을 위해 데이터 항목들의 봉인을 지원하기 위한 암호적이고 고립적인 기반 구조를 유지한다. 파일 락커는 파일 락커의 배타적인 액세스를 위해 데이터 항목을 봉인하기 위한 보호되는 환경의 봉인 기능을 사용한다. 파일 락커는 소프트웨어 객체로부터 수신된 파일들을 자신에게로 봉인하고, 요청시에 그리고 요청자의 신뢰성, 확실성 및/또는 식별자에 대한 충분한 증거가 있을 때 그 파일들을 제공한다. 보호되는 환경에서 동작할 수 있고 봉인 기능을 직접 액세스할 수 있는 에이전트를 레거시 어플리케이션이 구현할 필요없이, 파일 락커는 보호되는 환경의 봉인 기능을 레거시 어플리케이션으로 확장하기 위하여 사용될 수 있다.

파일 락커, 봉인, 소프트웨어 객체, 에이전트

Description

파일 락커 및 파일 락커를 제공하고 사용하기 위한 메커니즘{FILE LOCKER AND MECHANISMS FOR PROVIDING AND USING SAME}

도 1은 본 발명의 양태들이 구현될 수 있는 컴퓨팅 환경의 예에 대한 블럭도.

도 2는 여러 엔터티들에 의해 사용 가능하고, 데이터를 엔터티에 봉인하기 위해 사용될 수 있는 저장 설비에 대한 블럭도.

도 3은 소프트웨어 객체를 대신하여 파일을 보호하기 위해 봉인된 저장소를 사용하는 파일 락커에 대한 블럭도.

도 4는 파일 락커가 파일을 보호하기 위해 동작할 수 있는 예시적인 시나리오에 대한 블럭도.

도 5는 본 발명의 특성에 따라 파일을 보호하는 예시적인 방법에 대한 흐름도.

<도면의 주요 부분에 대한 부호의 설명>

206: 보호되는 저장 설비

301: 데이터

302: 파일 락커

304: 식별자

306: 파일

310: 소프트웨어 객체

본 발명은 일반적으로 컴퓨팅 분야, 더 상세하게는 데이터의 저장과 검색을 위한 메커니즘에 관한 것이다.

컴퓨터 보안 시스템의 한 양상은 데이터의 비밀을 보호하는 능력이다. 데이터는 암호화에 의해 보호될 수 있고, 바르게 동작하고 있는 컴퓨터 보안 시스템은 데이터가 신뢰된 공간의 외부에서는 보통의(암호화되지 않은) 포맷으로 나타나지 않게 해야 한다.

이러한 형태의 데이터 보호를 구현하는 한가지 방법은 신뢰된 프로그램(또는 "에이전트")이 실행될 수 있는 신뢰된 운영환경(trusted operating environment)을 제공하고, 또한 데이터가 신뢰된 에이전트로 봉인되도록 허용하는 데이터 봉인 설비(data sealing facility)를 제공하는 것이다. 신뢰된 환경에서 동작하는 에이전트는 데이터를 그 자신에게 봉인할 수 있고, 신뢰된 환경은 데이터가 봉인된 에이전트 이외의 다른 누군가에 대해 데이터가 개봉(unseal)되는 것을 거부할 것이다. 부가적으로, 운영환경은 봉인의 회피에 저항하기 위하여 변경 저항(tamper-resistance)과 차단 메커니즘(isolation mechanism)을 사용할 수 있다. 따라서 (1) 봉인 설비를 제공하는 환경이 봉인이 붕괴되는 것을 방지한다고 신뢰될 수 있 고, (2) 데이터가 봉인된 에이전트는 데이터가 개봉될 때 오용되는 것을 방지한다고 신뢰될 수 있는 한, 봉인된 데이터는 보호된다.

상술된 봉인 메커니즘이 갖는 문제점은 봉인 설비가 신뢰된 에이전트에 의해서만 사용될 수 있다는 점이다. 따라서, 신뢰된 환경의 봉인 설비를 이용하여 데이터를 보호하고자 하는 임의의 소프트웨어 객체는, 신뢰된 환경에서 실행되고 파일의 저장과 봉인을 관리하는 봉인 설비와 상호작용할 수 있는 기능을 포함하는 신뢰된 에이전트를 가져야 한다. 이러한 사실은 특히 레거시 어플리케이션 프로그램(예를 들어, 종래의 비보안 운영 시스템 하에서 동작하도록 설계된 워드 프로세서나 스프레드시트)에 대해 문제를 발생시키는데, 이러한 프로그램들은 일반적으로 그것의 거동이 예측가능하고 신뢰할 수 있는 작은 프로그램들만을 실행시키는 신뢰된 환경에서 운영될 수 없기 때문이다. 비보안 어플리케이션 프로그램은 보안 관련 기능을 위해 협력할 특화된 신뢰된 에이전트(specialized trusted agent)를 가지도록 작성될 수 있다. 그러나, 레거시 어플리케이션 프로그램들, 특히 특정 보안 컴퓨팅 플랫폼보다 먼저 구현된 어플리케이션 프로그램들은 일반적으로 신뢰된 에이전트들을 가지지 않는다. 게다가, 신뢰된 컴퓨팅을 염두에 두고 설계된 어플리케이션 프로그램들에 있어서도, 그러한 어플리케이션 프로그램 각각이 봉인된 파일들을 관리하는 기능을 포함하는 것은 성가신 일이다. 신뢰된 환경의 봉인 기능을 사용하여 보호 및 관리를 행하는 일반적인 설비를 제공하고, 그 설비가 다양한 소프트웨어 객체(예를 들어, 레거시 어플리케이션 프로그램, 운영 시스템, 가상 기 계 등)에 의해 사용될 수 있도록 하는 것이 바람직할 것이다.

상술된 관점에서, 종래기술의 단점을 극복하는 메커니즘이 필요하다.

본 발명은 다른 엔터티들을 대표하여 파일들을 보호하기 위해 데이터 봉인 설비를 사용하는 파일 락커(file locker)를 제공한다. 파일을 보호하고자 하는 엔터티는 파일을 파일 락커에 제공한다. 그러면 파일 락커는 데이터 봉인 설비를 사용하여 그 파일을 자신에게로 봉인함으로써, 파일을 파일 락커의 "보관소(custody)"에 둔다. 파일 락커의 보관소에 있는 파일을 검색하고자 하는 엔터티는 파일 락커로부터 파일을 요청할 수 있다. 요청하는 엔터티의 요청된 파일에 대한 권리가 충분히 입증되면, 파일 락커는 파일을 개봉되도록 하여, 요청한 엔터티에게 제공한다.

본 발명의 바람직한 실시예에서, 파일 락커는 다양한 정도의 신뢰성(예를 들어, 자신의 거동에 대해 낮은 보장성을 제공하는 "열린(open)" 환경으로부터 높은 보장성을 제공하는 "신뢰된(trusted)" 환경까지)을 가지는 환경들의 동시 사용을 지원하는 플랫폼에서 운영된다. 그러한 플랫폼에서 데이터 봉인 설비는 신뢰된 환경의 기반시설의 일부일 수 있다. 즉, 신뢰된 환경은 그 환경에서 실행되는 프로그램 또는 "에이전트"들이 봉인 내에 지명된 에이전트에 의해서만 데이터가 검색될 수 있도록 데이터를 봉인하는 것을 허용할 수 있고, 봉인이 암호화, 메모리 차단, 변경 저항성 등과 같은 메커니즘을 갖도록 할 수 있다. 뿐만 아니라, 그러한 플랫폼에서, 파일 락커는 신뢰된 환경에서 동작하고 있는 에이전트일 수 있고, 파일들 을 받고 그 파일들을 자신에게로 봉인함으로써 다른 엔터티들(신뢰된 환경의 내부와 외부 모두)에게 파일 보호 서비스를 제공할 수 있다.

예를 들어, 파일 락커를 사용하는 엔터티들은 신뢰된 환경에서 실행되는 프로그램들, 다른(덜 신뢰된) 환경, 또는 기타 프로그램들이 실행되는 전체 환경에서 실행되는 프로그램일 수 있다. 파일을 보호하고자 하는 엔터티는 파일을 파일 락커에 제공하고, 파일 락커는 파일을 자신에게로 봉인한다. 엔터티는 파일을 요청할 수 있고, 이러한 경우에 엔터티가 파일을 수신하도록 허가되었다는 것을 파일 락커가 검증하며, 요청한 엔터티에 대한 임의의 기타 유효성 검사를 수행할 수도 있다. 파일 락커는 그 후, 요청한 엔터티에게 파일을 제공한다.

파일 락커의 사용은 파일을 파일 락커로부터 요청한 엔터티에게 투명할 수 있다. 예를 들어, 어플리케이션 프로그램이 파일을 오픈하기 위해 표준 어플리케이션 프로그램 인터페이스(Application Programming Interface : API) 또는 시스템 호출(system call)을 사용할 수 있고, API나 시스템 호출은 신뢰된 장소에 어떤 파일들이 저장되어 있고 어떤 파일들이 저장되어 있지 않은지를 이해하기 위해 갱신될 수 있다. 신뢰된 장소에 파일이 저장될 때 API는 파일을 검색하기 위해 파일 락커와 통신한다.

선택적으로, 파일 락커(혹은 협력 에이전트)는 파일을 요청한 엔터티로 파일이 체크아웃되는 동안 그 엔터티의 거동을 모니터할 수 있다. 예를 들어, 파일이 신뢰되지 않은 환경에서 어플리케이션 프로그램으로 체크아웃될 때, 파일 락커 혹은 협력 에이전트는 파일이 파일 락커의 보관소에 없는 동안 오용되지 않을 것을 보장하기 위하여 어플리케이션 프로그램을 관찰하고 제어할 수 있다.

본 발명의 다른 특성들이 이하 기술된다.

전술한 요약뿐만 아니라 후술될 본 발명의 바람직한 실시예의 상세한 설명은 첨부된 도면과 함께 읽혀질 때 더 잘 이해된다. 본 발명의 설명를 위해 본 발명의 예시적인 구조가 도면에 도시된다. 그러나 본 발명은 제시된 특정 방법 및 수단으로 한정되지 않는다.

예시적인 컴퓨팅 배치

도 1은 본 발명의 특성이 구현될 수 있는 예시적인 컴퓨팅 환경을 보여준다. 컴퓨팅 시스템 환경(100)은 적합한 컴퓨팅 환경의 하나의 예일 뿐이며, 본 발명의 사용이나 기능의 범위에 대해 어떠한 제한도 가하지 않는다. 컴퓨팅 환경(100)은 예시적인 운영 환경(100)에 도시된 컴포넌트들 중 어느 하나 혹은 조합에 관련하여 어떠한 의존성이나 요구사항도 가지는 것으로 해석되어서는 안 된다.

본 발명은 여러 다른 일반적인 목적이나 특정 목적을 갖는 컴퓨팅 시스템 환경 혹은 구조에서 동작 가능하다. 본 발명의 사용에 적합한 잘 알려진 컴퓨팅 시스템, 환경 및 구조의 예는 개인용 컴퓨터, 서버 컴퓨터, 포켓용 혹은 랩탑 장치, 멀티프로세서 시스템, 마이크로 프로세서 기반 시스템, 셋탑 박스, 프로그래밍 가능한 가전기기, 네트워크 PC, 미니 컴퓨터, 메인프레임 컴퓨터, 내장 시스템, 상술된 시스템이나 장치 등 중 임의의 것을 포함하는 분산 컴퓨팅 환경을 포함하며, 제한되지는 않는다.

본 발명은 프로그램 모듈과 같은 컴퓨터에 의해 실행될 컴퓨터 실행가능 명 령어의 일반적인 문맥으로 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크나 다른 데이터 전송 매체를 통해 연결된 원격 프로세싱 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈과 기타 데이터는 메모리 저장 장치를 포함하여 로컬과 원격 컴퓨터 저장 매체에 위치될 수 있다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태로 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 프로세싱 유닛(120), 시스템 메모리(130) 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트들을 프로세싱 유닛(120)으로 연결하는 시스템 버스(121)를 포함할 수 있지만, 그것으로 제한되지는 않는다. 프로세싱 유닛(120)은 멀티스레드 프로세서에서 지원되는 것과 같은 다수의 논리적 프로세싱 유닛들을 나타낼 수 있다. 시스템 버스(121)는 메모리 버스나 메모리 컨트롤러, 주변 버스 및 다양한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스를 포함하는 여러 형태의 버스 구조 중 어떤 것일 수 있다. 제한을 가하지 않는 예로서, 그러한 아키텍처는 산업 표준 구조(Industry Standard Architecture:ISA) 버스, 마이크로 채널 구조(Micro Channel Architecture:MCA) 버스, 강화된 ISA(EISA) 버스, 비디오 전자 표준 협회(Video Electronics Standards Association:VESA) 로컬 버스 및 주변 컴포넌트 인터커넥트(Peripheral Component Interconnect:PCI) 버스(Mezzanine 버스로도 알려짐)를 포 함하며, 이들로 제한되지는 않는다. 시스템 버스(121)는 또한 통신 장치들 사이에 점대점 연결, 스위칭 구조, pci-익스프레스 등으로 구현될 수도 있다.

컴퓨터(110)는 전형적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 가용 매체일 수 있고, 휘발성과 비휘발성 매체, 분리가능과 분리불가능 매체 모두 포함한다. 제한을 가하지 않는 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체와 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 방법 및 기술로 구현될 수 있는 휘발성과 비휘발성, 분리가능과 분리불가능 매체 모두 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CDROM, DVD 또는 기타 광학 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하기 위해 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 기타 매체를 포함하지만, 이들로 제한되지는 않는다. 통신 매체는 전형적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 반송파나 다른 전송 메커니즘과 같은 변조된 데이터 신호에서의 기타 데이터를 포함하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호에 있는 정보를 암호화하기 위한 방식으로 세팅 또는 변화시킨 하나 이상의 특성을 갖는 신호를 의미한다. 제한을 가하지 않는 예로서, 통신 매체는 유선 네트워크나 직접 유선연결된 연결과 같은 유선 매체와 음향, RF, 적외선 및 기타 무선 매체와 같은 무선 매체를 포함한다. 상기 임의의 것의 조합 또한 컴 퓨터 판독가능 매체의 범위에 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132)과 같은 휘발성 및/또는 비휘발성 메모리의 형태로 컴퓨터 저장 매체를 포함한다. 시작할 때 등에 컴퓨터(110) 내의 구성요소들 사이에 정보 교환을 돕는 기본적인 루틴들을 포함하는 기본적인 입력/출력 시스템(133)(BIOS)은 전형적으로 ROM(131)에 저장된다. RAM(132)은 전형적으로 직접 액세스 가능하고/하거나 현재 프로세싱 유닛(120)에 의해 실행되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 제한을 가하지 않는 예로서, 도 1은 운영 시스템(134), 어플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시한다.

컴퓨터(110)는 또한 다른 분리가능/분리불가능한 휘발성/비휘발성 컴퓨터 저장 매체를 포함한다. 단지 예로서, 도 1은 분리불가능한 비휘발성 자기 매체로 판독하거나 기록하는 하드 디스크 드라이브(140), 분리가능한 비휘발성 자기 디스크(152)로 판독하거나 기록하는 자기 디스크 드라이브(151), 그리고 CD ROM이나 기타 광학 매체와 같은 분리가능한 비휘발성 광학 디스크(156)로 판독하거나 기록하는 광학 디스크 드라이브(155)를 도시한다. 예시적인 운영 환경에서 사용될 수 있는 기타 분리가능/분리불가능한 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM 등을 포함하지만, 이들로 제한되지는 않는다. 하드 디스크 드라이브(141)는 전형적으로 인터페이스(140)와 같은 분리불가능한 메모리 인터페이스를 통해 시스템 버스(121)로 연결되고, 자기 디스크 드라이브(151)와 광학 디스크 드라이브 (155)는 전형적으로 인터페이스(150)와 같은 분리가능한 메모리 인터페이스에 의해 시스템 버스(121)로 연결된다.

상술되고 도 1에 도시된 드라이브들과 관련 컴퓨터 저장 매체는 컴퓨터(110)에 대해 컴퓨터 판독가능 명령어들, 데이터 구조, 프로그램 모듈, 기타 데이터의 저장을 제공한다. 예를 들어 도 1에서, 하드 디스크 드라이브(141)는 운영 시스템(144), 어플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이러한 컴포넌트들은 운영 시스템(134), 어플리케이션들 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 같을 수도 있고 다를 수도 있다는 점을 유의해야 한다. 운영 시스템(144), 어플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)는 여기서 최소한 그것들이 다른 것들이라는 것을 도시하기 위하여 다른 번호를 부여받는다. 사용자는 키보드(162)와 일반적으로 마우스, 트랙볼 또는 터치 패드로 언급되는 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)로 명령어와 정보를 입력할 수 있다. 기타 입력 장치들(도시되지 않음)은 마이크, 조이스틱, 게임 패드, 위성 디쉬, 스캐너 등을 포함할 수 있다. 이러한 기타 입력 장치들은 주로 시스템 버스로 연결되는 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)으로 연결되지만, 병렬 포트, 게임 포트 또는 USB와 같은 기타 인터페이스 및 버스 구조에 의해서도 연결될 수 있다. 모니터(191)나 다른 형태의 디스플레이 장치 또한 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)로 연결된다. 모니터 외에, 컴퓨터는 스피커(197)와 프린터(196) 같은 다른 주변 출력 장치들을 포 함할 수 있고, 그것은 출력 주변 인터페이스(195)를 통해 연결될 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터들로의 논리적 연결을 사용하는 네트워크 환경에서 동작할 수 있다. 도 1에서는 메모리 저장 장치(181)만이 도시되지만, 원격 컴퓨터(180)는 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 디바이스나 기타 공통 네트워크 노드일 수 있으며, 전형적으로 컴퓨터(110)와 관련되어 상술된 구성요소들 중 다수 혹은 모두를 포함한다. 도 1에 도시된 논리적 연결들은 근거리 통신망(LAN)(171)과 광역 통신망(WAN)(173)을 포함하지만, 다른 네트워크들도 포함할 수 있다. 그런 네트워킹 환경들은 사무실, 기업 규모 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스나 어댑터(170)를 통해 LAN(171)으로 연결된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 전형적으로 인터넷과 같은 WAN(173)을 거쳐 통신을 설정하기 위한 모뎀(172)이나 다른 수단을 포함한다. 내장되거나 외장일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160)나 다른 적합한 메커니즘을 통해 시스템 버스(121)로 연결될 수 있다. 네트워크 환경에서, 컴퓨터(110)와 관련되어 기술된 프로그램 모듈이나 그들의 일부는 원격 메모리 저장 장치에 저장될 수 있다. 제한을 가하지 않는 예로서, 도 1은 원격 어플리케이션 프로그램들을 메모리 장치(181)에 상주하는 것으로 도시한다. 도시된 네트워크 연결들은 예시이고, 컴퓨터들 사이에 통신 링크를 설정하기 위한 다른 수단들이 사용될 수 있다는 것을 잘 알 수 있을 것이다.

보호되는 저장

본 발명의 한 양상은 엔터티가 설비에 데이터를 맡기고 봉인할 수 있게 하는 보호되는 저장 설비를 사용한다는 것이다. 데이터가 봉인되면, 데이터는 그것이 봉인된 엔터티(또는 엔터티들) 이외의 어떠한 엔터티에 의해서도 액세스될 수 없다. 도 2는 그러한 보호되는 저장 설비(206)와 그것의 사용을 보여준다.

보호되는 저장 설비(206)는 하나 이상의 엔터티로부터 데이터를 수신할 수 있고, 해당 엔터티에 대해 수신된 데이터를 저장할 수 있다. 예를 들어, 엔터티들[202(1), 202(2), ..., 202(n)] 각각이 보호되는 저장 설비(206)에 데이터를 맡기기 위해, 보호되는 저장 설비(206)와 통신한다. 도 2의 예에서, 엔터티들[202(1), 202(2), ..., 202(n)]은 데이터[204(1), 204(2), ..., 204(n)]를 각각 보호되는 저장 설비(206)로 제공한다. 각 엔터티[202(1) 내지 202(n)]는 저장된 데이터를 자신에게로 봉인할 수 있고, 보호되는 저장 설비(206)는 그러한 봉인을 수행하기 위한 기능을 제공한다. 데이터를 엔터티로 "봉인"한다는 것은 데이터가 그 엔터티에게만 공개될 수 있는 방식으로 데이터를 저장한다는 것을 의미한다. 데이터의 봉인은 대개 암호화로 즉, 데이터를 복호하기 위해 필요한 키를 데이터가 봉인된 엔터티만이 이용할 수 있는 방식으로 데이터를 암호화함으로써 수행된다. 도 2에서 도시된 바와 같이, 각 데이터[204(1), 204(2), ..., 204(n)]는 엔터티[202(1), 202(2), ..., 202(n)]로 각각 봉인된다.

데이터가 보호되는 저장 설비(206)에 저장되고 봉인된 후에, 엔터티는 봉인된 데이터를 요청하는 엔터티로 다시 제공해줄 것을 보호되는 저장 설비(206)에게 요청할 수 있다. 데이터를 개봉하기 전에, 보호되는 저장 설비는 요청하는 엔터티 가 권리가 주어진 자인지를 결정하기 위하여 요청하는 엔터티에 대한 검증(210)을 수행하는 것이 바람직하다. 예를 들어, 데이터[204(1)]는 엔터티[202(1)]로 봉인되고, 따라서 엔터티[202(1)] 이외의 다른 어떠한 엔터티에게도 제공되어서는 안 된다. 따라서, 데이터[204(1)]에 대한 요청이 보호되는 저장 설비(206)로 들어오면, 보호되는 저장 설비는 요청하는 엔터티가 실제로 엔터티[202(1)]인지를 검증한다(예를 들어, 엔터티[202(1)]의 증명서를 검사하거나, 엔터티[202(1)]의 해시나 체크섬을 계산하거나, 또는 다른 형태의 테스트를 엔터티[202(1)]에 대해 수행하는 것에 의해). 한 예에서, 엔터티[202(1)]는 엔터티[202(1)]의 다양한 보안 특성을 지정하고 엔터티[202(1)]의 증명서나 디지털 서명을 포함할 수도 있는 증명 벡터(attestation vector, 208)와 결합된다. 이 증명 벡터는 엔터티(202)(1)가 실제로 자신이 주장하는 엔터티임을 검증하기 위해 사용될 수 있다. 그러한 증명 벡터, 서명, 증명서 등이 인증/식별 검사의 일부로서 검증될 수 있는 방식은 본 기술분야에서 숙련된 지식을 가진 자들에게 널리 알려져 있고, 따라서 여기에 기술되지 않는다.

일반적으로, 소정의 방식으로 식별될 수 있는 임의의 엔터티(예를 들어, 소프트웨어 객체, 사용자 등)는 데이터가 자신에게 봉인되도록 할 수 있다. 전형적으로, 데이터의 봉인된 저장을 요청하는 엔터티들은 소프트웨어 객체이다(예를 들어, 어플리케이션, 에이전트, 장치 드라이버 등).

도 2에 대하여, 한 엔터티에 데이터를 봉인하고, 데이터가 봉인된 그 엔터티 이외의 임의의 엔터티에 의해 요청될 때에는 봉인된 데이터로의 액세스를 거부할 수 있는 소정의 보호되는 저장 설비가 존재한다고 가정된다. 또한, 보호되는 저장 설비(206)는 엔터티로 봉인된 데이터가 그 엔터티에게만 액세스 가능하다는 특성을 강력히 시행하기 위하여 충분한 차단(isolation), 변경 저항성(tamper-resistance) 등의 특성을 가지거나 또는 그러한 특성을 가지는 환경에서 동작하는 것으로 가정된다. 그러한 보호되는 저장 설비를 구현하는 방식은 본 발명의 기술분야에서 숙련된 지식을 갖는 자에게 명백할 것이므로 여기에 상세히 기술되지 않는다. 한 예에서, 보호되는 저장 설비는 메모리 차단, 보안 부팅 및 플랫폼마다의 암호 키를 가지는 하드웨어적인 비밀 보장성을 제공하는 환경에서 동작할 수 있다.

봉인된 저장을 사용하는 엔터티로서의 파일 락커

봉인된 저장을 사용할 수 있는 엔터티의 한가지 형태는 파일 락커이다. 파일 락커는 소프트웨어로부터 파일을 수신하고 그 파일들을 자신에게로 봉인하기 위하여 보호되는 저장 설비를 사용한다. 그 후 파일 락커가 그 파일들에 대한 요청을 수신하고, 요청하는 소프트웨어 객체로 그러한 파일들이 제공될 수 있도록 하는 다양한 정책들을 관리한다. 예를 들어, 파일에 대한 요청이 수신되면, 파일 락커는 요청자가 요청된 파일을 액세스할 권리를 가지는지를 결정할 수 있고, 그러한 권리가 존재할 때에만 파일을 보호되는 저장으로부터 개봉되도록 할 수 있다. 또한, 만약 요청자가 그 파일을 액세스할 권리를 가진다면, 그 엔터티에 의한 파일의 오용을 예방하기 위하여 파일 락커는 파일이 "락커"의 외부에 있는 동안 요청하는 소프트웨어 객체의 동작이 감시되도록 요청할 수 있다.

도 3은 소프트웨어 객체로부터 파일들을 수신하고, 그 파일들을 자신에게로 봉인하기 위하여 보호되는 저장 설비를 사용하는 파일 락커(302)를 보여준다. 도 3의 예에서, 소프트웨어 객체(310)는 소정의 데이터(301)를 파일에 기입하고자 한다. 그러면, 데이터(301)는 파일(306)에 기입되고 그 파일은 보호되기 위하여 파일 락커(302)로 제공된다. 소프트웨어 객체(310)는 자신이 파일을 파일 락커(306)로 제공하고 있다는 것을 알 수도, 모를 수도 있다는 점을 유의해야 한다. 한 예에서, 소프트웨어 객체(310)가 파일을 보호하기 위하여 명시적이고 의도적으로 파일 락커(306)를 사용하고, 또다른 예에서는, 소프트웨어 객체(310)는 단지 표준 파일 작성 API(standard file-write API)를 사용하고, 작성된 파일을 파일 락커에 저장하기 위한 기능이 API에 갱신된다. 파일 락커의 사용이 발생할 수 있는 다양한 시나리오 예가 아래 "예시적인 시나리오" 섹션에서 기술된다.

파일 락커(302)가 파일(306)을 수신하면, 파일 락커(302)는 파일(306)을 보호되는 저장 설비(206)에 저장한다. 그 후 파일 락커(302)는 파일(306)을 자신에게로 봉인한다. 바람직한 실시예에서, 저장을 위해 파일 락커(302)로 전달되는 파일은 그 파일의 원래의 근원지가 아니라 파일 락커(302)에 봉인된다는 점에 유의해야 한다 - 예를 들어, 파일(306)은 소프트웨어 객체(310)가 아니라 파일 락커(302)에 봉인된다. 위에 언급된 바와 같이, 소프트웨어 객체(310)는 자신이 파일 락커(302)를 사용하고 있다는 것을 모를 수 있고, 봉인된 저장을 직접 사용할 수 없을 수도 있다. 따라서, 모든 파일들을 자신에게로 봉인함으로써, 파일 락커(302)는 봉인된 저장을 직접 사용할 수 없는 소프트웨어 객체들이 어떠한 봉인된 저장의 보호로부터 이득을 얻도록 허용한다.

파일 락커(302)는 보호되는 저장 설비(206)에 파일(306)을 저장한다. 보다 바람직하게, 파일 락커(302)는 식별자(304)를 파일(306)과 결합시킨다. 식별자는 보다 바람직하게 파일을 식별하고, 또한 궁극적으로 어떤 소프트웨어 객체가 그 파일에 액세스할 수 있는지를 나타낸다. 식별자(304)가 봉인된 저장에 필수적으로 저장되는 건 아니지만, 식별자(304)는 파일 락커(302)에 액세스할 수 있는 인덱스에 저장될 수 있다. 특히, 파일 락커(302)는 파일에 대한 요청이 들어올 때 어떤 파일이 봉인된 저장으로부터 검색될 필요가 있는지(그리고 개봉 전에 어떤 조건이 만족되어야 하는지)를 결정하기 위하여 봉인된 저장의 외부에서 식별자들에 액세스할 수 있어야 한다.

파일 락커(302)가 파일 락커(302)의 보관소에 있는 파일에 대한 요청을 수신하면, 파일 락커(302)는 검증(312)을 실시한다. 검증(312)은 어떠한 특정한 형태의 검증으로 제한되지 않는다. 한 예에서, 검증(312)은 요청자에 대해 수행된다. 예를 들어, 도 3에서 소프트웨어 객체(310)는 파일(예를 들어, 이전에 파일 락커(302)의 보관소로 전달되었던 동일한 파일(306))을 요청하고, 파일 락커(302)는 자신이 구현하는 보안의 일부로서 요청된 파일을 제공하기 위한 전제조건인 소정 형태의 검증(312)을 수행한다. 예들이 소프트웨어 객체(310)의 신분을 검사하는 검사(예를 들어, 소프트웨어 객체(301)의 증명서를 검사하거나 소프트웨어 객체(310)의 체크섬 혹은 해시를 계산하여 계산된 값을 저장된 값과 비교하는 것 등), 또는 소프트웨어 객체(310)(또는 소프트웨어 객체(310)의 호출 스택 등)의 진정성(authenticity)을 검사하는 검사들을 포함할 수 있지만, 본 발명은 어떠한 특정 형 태의 검증(312)으로 제한되지 않는다. 그러나, 많은 예에서, 요청자 자체에 대한 검증을 수행하는 것이 가능하지 않을 수 있으므로, 파일 락커(302)는 다른 형태의 검증을 수행할 수 있다. 예를 들어, 파일 락커(302)는 보안 입력/출력을 통해 사용자에게 자신이 특정 파일을 편집하고자 한다는 것을 확인하도록 요구함으로써, 또는 파일의 소유자로 등록된 사람이 현재 파일 락커로 또는 파일 락커가 동작하는 보안 환경으로 로그인했는지를 확실히 함으로써 검증을 수행할 수 있다. 파일 락커(302)는 요청하는 소프트웨어 객체에게 파일을 제공하기 전에 소정의 보안 파라미터들이 충족되기를 보증하도록 설계되지만, 본 발명은 어떤 특정한 보안 파라미터들의 세트 혹은 그러한 파라미터들이 충족되는지를 결정하기 위한 특정 메커니즘으로 제한되지 않는다.

검증(312)의 결과가 좋으면(즉, 만약 관련 보안 파라미터들이 충족된다면), 파일 락커(302)는 소프트웨어 객체(310)가 요청된 파일을 검색할 권리를 부여받았다고 결정한다. 그 후 파일 락커(302)는 파일(306)을 개봉하고 검색하기 위하여 보호되는 저장 설비(206)와 통신한다. 파일 락커(302)는 그 후 파일(306)을 소프트웨어 객체(310)로 다시 제공한다.

파일(306)에 대한 작업이 끝난 후 소프트웨어 객체(310)는 파일(소프트웨어 객체(310)가 행할 수 있는 어떠한 변형을 포함하여)을 파일 락커(302)의 보관소로 다시 전달함으로써 검색된 파일을 "체크인"할 수 있다.

소프트웨어 객체(310)가 특정 형태의 소프트웨어로 제한되지 않는다는 것에 유의해야 한다. 예로서, 소프트웨어 객체(310)는 어플리케이션 프로그램, 어플리 케이션 프로그램에 대한 서비스 에이전트, 다른 프로그램들이 실행되는 운영 환경, 운영 시스템이 동작할 수 있는 가상 기계 등일 수 있다.

파일 락커가 동작할 수 있는 예시적인 시나리오

파일 락커가 동작할 수 있는 예시적인 시나리오는 상이한 보안 혹은 보호 레벨을 갖는 다수의 환경이 동시에 동작할 수 있는 시스템에서이다. 도 4는 그러한 시나리오를 보여준다.

도 4에는 동시에 동작하는 다수의 환경들("환경 1", "환경 2", "환경 3" 및 "환경 4")이 존재한다. 이러한 환경들은 하나의 기계 혹은 기계들의 분산된 클러스터에서 동작할 수 있다. 각 환경들은 운영 시스템, 가상 기계 혹은 어떤 형태의 코드 실행이 발생할 수 있는 다른 형태의 환경일 수 있다. 상이한 환경들은 서로에 대해 소정 레벨의 차단을 유지해야 한다. 즉, 필수적이고 절대적으로 확실한 정도까지는 아니더라도 적어도 한 환경에서의 동작이 다른 환경으로부터의 간섭없이 이루어지게 되는 정도까지는 가능해야 한다. 상이한 환경들은 상이한 레벨의 보안을 제공할 수 있다. 예를 들어, 환경 1은 매우 한정된 세트의 프로그램만이 실행되도록 하고 상대적으로 적은 기능을 제공하지만, 그 환경에서 수행되는 기능들이 올바르게 그리고 다른 환경에서 발생하는 이벤트로부터의 침해 없이 수행될 것이라는 점에 대한 높은 보장성 또한 제공하는 높은 보안성 혹은 높은 보장성 환경일 수 있다. 이에 상반되게, 환경 4는 모든 코드가 실행될 수 있지만 다른 환경에서 발생하는 침해나 변경에 대한 낮은 보장성을 제공하는 완전 개방된 환경일 수 있다. 하이퍼바이저(hypervisor) 또는 가상 기계 모니터(virtual machine monitor)(404)(혹은 다른 유사한 컴포넌트)가 이러한 환경들의 동시 발생하는 동작을 관리할 수 있으며, 한 환경을 다른 환경으로부터 차단하기 위해 요구되는 서비스들 또한 제공할 수 있다.

환경 1이 높은 보안성 또는 높은 보장성 환경인 경우의 예에서, 파일 락커(302)는 그 환경에서 소프트웨어 객체로서 동작한다. 환경 1에서 동작하는 객체들에게 봉인된 저장을 제공하는 능력은 환경 1의 특성이다. 즉, 환경 1은 봉인된 저장 인터페이스(406)를 제공하는데, 이것은 환경 1에 있는 객체들이 봉인된 저장 설비(402)(이것은 도 2와 3에서 도시된 보호되는 저장 설비(206)의 일부이거나 동일함)에 데이터를 저장하기 위해, 그리고 그 데이터를 자신에게로 봉인하기 위해 사용할 수 있다. 봉인된 저장 설비(402)가 환경 1의 일부인 경우는 단지 하나의 예라는 것이 유의되어야 한다. 대안으로서, 봉인된 저장 설비가 가상 기계 모니터/하이퍼바이저(404) 혹은 충분한 보안 특성을 가진 다른 컴포넌트에 의해 제공될 수 있다.

다양한 상이한 형태의 소프트웨어 객체들이 파일들을 저장하기 위하여 파일 락커(302)를 사용할 수 있다. 예를 들어, 어플리케이션(412)(이 예에서, 환경 3에서 실행되고 있음)이 파일들을 파일 락커(302)에 저장할 수 있다. 또다른 예로서, 환경 3은 그 자체가 파일 락커(302)에 파일들을 저장할 수 있는 소프트웨어 객체일 수 있다. 예를 들어, 환경 3은 어플리케이션들로부터 저장을 위한 파일들을 수락하고 그 파일들을 파일 락커(302)에 저장함으로써, 파일 락커(302)의 존재를 환경 3에서 실행되는 어플리케이션들에게 투명하게 할 수 있다. 또다른 예로서, 에이전 트(410)(즉, 더 낮은 보장성을 갖는 환경에서 실행되고 있는 어플리케이션들에게 보안 서비스를 제공하기 위하여, 높은 보장성을 갖는 환경에서 실행되는 작은 어플리케이션)는 파일들을 저장하기 위하여 파일 락커(302)를 사용할 수 있다. 에이전트(410)는 자신을 위하여 봉인된 저장 인터페이스(406)를 사용할 수 있는 환경 1에서 동작하고 있지만, 에이전트(410)가 스스로 그러한 서비스들을 (중복적으로) 구현하는 것보다 파일 락커(302)에 의해 제공된 파일 락커(302)의 서비스들(예를 들어, 파일 관리 서비스 등)을 사용하는 것이 더 편리할 수 있다는 점이 유의되어야 한다.

파일 락커(302)로부터 파일이 해제될 때(또는 어플리케이션(402)에 의한 사용을 위해 환경 3으로 파일이 해제될 때), 엔젤(408)은 선택적으로 파일이 파일 락커(302)의 보관소 외부에 있는 동안 오용되지 않을 것을 보장하기 위하여 어플리케이션(402)(혹은 환경 3)의 동작을 감시할 수 있다. 엔젤(408)은 환경 1에서 동작하는 에이전트이고, 그것의 기능은 소프트웨어 객체들의 거동을 감시함으로써(그리고 가능하다면 제어함으로써) 더 낮은 보안성을 갖는 환경에서 실행되는 소프트웨어 객체들을 보다 안전하게 하는 것이다. 파일 락커(302)의 보관소 외부에 있는 동안 파일의 사용을 감시하는 것이 유용할 수 있지만, 모든 보안 모델이 그러한 감시를 요구하는 것은 아니다. 많은 보안 모델에 대하여, 일단 파일 락커(302)의 보관소로 다시 맡겨지면 그 파일은 손상, 오용 또는 간섭으로부터 자유롭다는 것이 보장될 수 있기만 하다면, 파일 락커(302)의 보관소 외부에 있는 파일은 변경, 오용 및 간섭에 종속되도록 하는 것이 용인된다.

파일 락커(302)가 사용될 수 있는 몇 가지 예시적인 시나리오들이 아래 기술된다.

파일 락커가 사용될 수 있는 예시적인 시나리오

다음은 파일 락커가 사용될 수 있는 예시적인 시나리오들이다.

1. 수동 잠금해제 . 허가된 사용자(표준 시스템 룰에 의해, 또는 파일 락커의 사용자 인터페이스로 직접 로그인한 것에 의해 결정됨)는 파일 락커에게 파일을 잠금해제해 줄 것을 요청한다. 파일 락커는 대개 사용자가 사용할 파일의 원본 파일을 보관한 채, 잠금해제된(암호화되지 않은) 복사본을 제공할 것이다. 대안적으로, 사용자는 소스 파일에 직접 액세스하도록 허용될 수 있다. 파일 락커는 사용자에게 키를 주지 않고, 단지 사용자가 보고, 편집하는 등의 작업을 하도록 파일의 플레인텍스트(plaintext)만을 제공한다.

파일이 잠금해제 되면, 사용자는 일반적인 툴/어플리케이션들을 사용하여 그것을 조작한다.

완료되면, 사용자는 변경된 파일을 파일 락커에게 제출한다. 그러면 파일 락커는 파일을 암호화하고 봉인한다.

선택적으로, 파일을 그것이 본래 있었던 파일 홀더(서버 등)에 다시 전송하기 전에, 사용자는 다운로드된 파일과 제출될 파일 사이의 파일 차이점 리스트를 보도록 요구받을 수 있다. 이 차이점 리스트는 더 바람직하게 보안 비디오(즉, 비디오 출력의 가로챔이 잠재적인 보안 결함을 나타내기 때문에, 파일 락커가 화면에 디스플레이되도록 하고 있는 차이점들이 실제로 사용자가 보게 되는 차이점들이라 는 것에 대한 높은 정도의 보장성이 존재하는 비디오)를 사용하여 디스플레이된다.

사용자는 파일을 파일 락커에게 다시 제출하기 전에 여러 번 파일을 편집할 수 있고 또는 전혀 하지 않을 수도 있다. 또는 사용자가 파일을 파일 락커에게 다시 제출하지 않는 경우도 있다.

이러한 모델에서, 파일 락커는 파일이 손상되거나 변경되지 않고서 사용자의 기계에 도달했다는 것을 보장할 수 있다. 또한, 파일 락커는 사용자가 파일의 사용을 명시적으로 요구할 때까지 파일이 읽혀지거나 변경되지 않을 것도 보장할 수 있다. 따라서, 파일에 대한 어떠한 침해나 그 내용에 대한 공격은, 파일이 "열린"(즉, 사용자의 입장에서, 그 파일이 파일 락커의 제어와 보관소 외부에 있다는 것이 알려진) 상태인 동안 발생해야 한다.

파일 락커는 적어도 몇 가지 파일 포맷을 사용자에게 디스플레이할 수 있는 능력을 가질 수 있고, 따라서 사용자는 이 파일들을 잠금 해제하기로(그리고 바이러스나 다른 보안 위험에 노출시키기로) 결정하기 전에 파일 락커에서 안전하게 파일들을 읽을 수 있다.

2. 프로젝티드 잠금해제 (Projected Unlock). 프로젝티드 잠금해제에서, 파일 락커는 승인된 리스트상에 있는 코드 ID를 갖는 특정 바이너리들에게만 파일을 노출한다. 보다 바람직하게, 파일이 바이너리와 사용자의 올바른 조합에 대해서만 해제되도록, 사용자는 또한 로그온하도록 요구받는다. 높은 보장성을 갖는 환경에서 실행되고 있지 않은 소프트웨어 객체들에 대한 코드 ID를 계산하기 위하여, 소정 형태의 "프로젝션"이 사용된다. 이 문맥에서 "프로젝션"은 높지 않은 보장성을 갖는 소프트웨어 객체의 거동에 대해 어느 정도의 보안을 제공하기 위하여, 높은 보장성을 갖는 환경에서 동작하고 있는 에이전트가 높지 않은 보장성을 제공하는 환경에서 동작하고 있는 소프트웨어 객체의 거동을 감시하고 영향을 미치는 경우를 일컫는다. 본 예에서, 파일 락커가 엔젤(즉, 특정한 높지 않은 보장성을 갖는 어플리케이션에 대해 상기 기술된 프로젝션을 수행하는 에이전트) 혹은 아마도 아크엔젤(ArchAngel)(즉, 특정한 어플리케이션이나 어플리케이션 세트에 대해서가 아니라, 일반적인 어플리케이션에 대하여 프로젝션을 수행하는 에이전트)에 대해서만 데이터를 개봉하고 노출하는 경우일 수 있다. 바람직한 실시예에서, 그 후 엔젤은 데이터를 직접 어플리케이션 어드레스 스페이스로 넣는다. 예를 들어, 높지 않은 보장성을 갖는 환경에서 실행되는 마이크로소프트 엑셀(MICROSOFT EXCEL) 스프레드 시트가, 그것의 버전과 코드 ID를 계산하고 그 후에 높은 보장성을 갖는 환경을 호출했던 라이브러리로 호출할 수 있다. 높은 보장성을 갖는 환경은 버전과 코드 ID의 유효성을 검사할 것이다. 높은 보장성을 갖는 환경은 높지 않은 보장성을 갖는 환경에(혹은, 적어도 엑셀 프로그램에) 프로젝션을 적용하고 있을 것이고, 그래서 코드 ID는 상당히 내구성을 가질 것이다(즉, 사람이 엑셀의 코드를 편집하는 것이 더 어려울 것이다). 그 후 엑셀은 파일 데이터를 읽기 위하여 다시 라이브러리를 호출할 것이고, 데이터는 엑셀의 어드레스 스페이스에 나타난다. 높지 않은 보장성을 갖는 환경으로부터의 약간의 도움으로, 엔젤은 페이지가 넘어가기 전에 엑셀의 스페이스에서 페이지를 암호화할 수 있다. 이것은 엑셀을 디버깅하기 위한 시도를 방해할 수도 있다.

따라서, 이러한 모델에서, 위탁자(로컬 및 원격)는 파일 락커와 승인된 버전의 엑셀(바이러스나 기타 승인되지 않은 동작으로부터 자유로운 것)만이 플레인텍스트를 보게 될 것이라는 것을 확신할 수 있다. 또한, 프로젝션의 성과로, 그 버전의 엑셀은 내구성이 있으며, 데이터는 디스크에 있는 플레인텍스트에 있지 않다.

본 시나리오는, 특정 어플리케이션의 실행(예를 들어, 엑셀)에 대한 불확실성이 감수될 수 있고 예방되어야 할 주요 위협이 다른 소프트웨어인 경우에 충분한 보안을 제공한다. 이것이 일반적인 위협 모델이다. 보안 비디오에 의해 디스플레이하고 다시 잠그기 전에 차이점의 비교를 허용한다고 하는 특성이 본 시나리오에서 사용될 수 있다.

3. 보틀링(bottling)과 조합된 파일 락커 . "보틀링"은 어플리케이션들의 세트가 거동 예측성과 다른 보틀로부터의 차단이 소정 수준으로 유지되는 컨테이너, 파티션 혹은 "보틀" 내에서 실행되는 경우를 일컫는다. 예를 들어, 보틀은 다소 제한된 운영 시스템(예를 들어, 윈도우즈 XP의 작은 구성) 혹은 소정의 운영 시스템을 실행시키는 게스트를 갖는 가상 기계이거나, 혹은 이들을 포함할 수 있다. 컨테이너, 컨테이너 운영 시스템 및 컨테이너에서 실행되고 있는 어플리케이션이나 어플리케이션들의 세트는 모두 "보틀"이다. 프로젝션이 보틀 내에 프로젝션을 적용하기 위하여 사용될 수 있다.

보틀이 주어지면, 파일 락커는 파일들을 보틀이나 보틀 내의 특정 어플리케이션에 대해 해제하도록 세팅될 수 있고, 데이터를 보틀 내에서만 플레인텍스트 형태로 할 수 있다. (보틀은 전체로서 암호화되며, 따라서 데이터가 보틀 내에 있으 면 그것은 보틀 외부의 어떤 것으로부터도 안전하다.)

시나리오 #3은 본질적으로 #2의 보다 강력하게 차단된 버전이다. 그것은 동적 링크 라이브러리와 같은 트리를 갖는 어플리케이션의 세트(예를 들어, 마이크로 소프트 오피스 제품군의 어플리케이션들)에 잘 적용되며, 보틀링된 어플리케이션 하에 있는 운영 시스템에 대하여 비교적 강한 명령을 수행한다. (즉, 보틀 내에 있는 운영 시스템은 보다 바람직하게 제한되고 입증된 미니 운영 시스템이므로, 예를 들어 악한 드라이버들이 보틀 내에 허용되지 않기 때문에, 어떤 악한 드라이버가 운영 시스템의 최상위에서 실행되고 있는 어플리케이션으로부터 데이터를 훔치지 않는다고 강하게 믿을 수 있다.)

4. 파일 락커에게 파일을 제출하는 첫 번째 소프트웨어 객체는 로컬 혹은 원격일 수 있고, 파일을 암호화되거나 혹은 암호화되지 않은 형태로 제출할 수 있다(예를 들어, 서버는 암호화되기 전에 파일을 파일 락커에게 전송하거나, 혹은 파일 락커가 다시 암호화하지만, 전송을 위해 암호화된 형태로 전송할 수 있다). 파일을 사용하는 소프트웨어 객체나 객체들은 본래 파일 락커에 파일을 두었던 소프트웨어 객체와는 다를 수 있다. 즉, 파일은 한 객체로부터 파일 락커에 올 수 있고, 후에 다른 객체(들)에 의해 사용될 수 있다. 그 후 첫 번째 객체나 혹은 다른 객체에게 다시 전송될(혹은 전송되지 않을) 수 있다.

5. 파일을 파일 락커에 제출하는 (첫 번째) 소프트웨어 객체는 파일 락커가 파일에 강요할 로컬 룰을 지정할 수 있다. 그러한 룰은 다음과 같은 요구사항을 포함할 수 있다. (1) 모든 버전의 파일들이 로그되어야 하므로, 다른 환경(예를 들어, 신뢰되지 않는 환경)에 있는 다른 소프트웨어 객체에 의해 어떠한 변경이 행해지더라도, 그러한 변경들은 항상 원상태로 돌려질 수 있다. (2) 모든 변경들이 사용자(어떤 종류의 브라우저/차이점 뷰어를 통한 보안 입력 및 보안 출력)에 의해 재검토되고 사용자에 의해 "의도된 것"(혹은 의도된 것이 아님)으로 확인되며, 이러한 확인이 변경과 함께 저장되어야 한다. 이러한 기술은 그 파일을 다루는 두 번째 소프트웨어 객체가 불충분하게 제어되는 경우에 유용할 수 있다. 기본 아이디어는 파일 락커가 워드의 .doc 파일의 모든 버전을 저장하는 것이다. 파일이 어플리케이션(예를 들어, 워드)으로 편집되고 다시 파일 락커에 기록된 후에(아마도 투명하게), 파일 락커는 사용자에게 확인할 것을 요청한다. 사용자는 신뢰된 환경에서 실행될 수 있는 .doc 파일용의 단순한 "뷰어(viewer)"를 사용할 수 있고, 이러한 변경들이 사용자가 의도했던 것이라는 점을 보안 입력을 통하여 파일 락커에게 직접 알려줄 수 있다. 이러한 방식으로, 바이러스에 의하여, 기초를 이루는 어플리케이션(예를 들어, 워드)이 예상치 않은 방식으로 동작하게 되고 또한 파일을 예상치 않은 방식으로 편집하게 되더라도, 사용자는 파일 락커를 사용하여, 임의의 그러한 변경을 원상태로 돌리거나, 자신이 의도했던 변경만이 "로그인" 된다는 것을 보증할 수 있다.

6. 파일 락커는 첫 번째 소프트웨어 객체 혹은 로컬 사용자를 대신하여, 파일들에 다양한 일관성 검사를 적용할 수 있다. 예를 들어, 어플리케이션에 의해 작성된 파일에 대해 바이러스와 정확성 검사기를 실행시킬 수 있다. 기본 아이디어는, 파일 변경이 저장되지만 파일이 바이러스를 가지지 않는다는 것 혹은 손상되 지 않았다는 것 등으로 밝혀질 때까지 "공식적으로 로그"되지 않을 것이라는 점이다. 본 기술은 상기 #5에 설명된 기술과 결합될 수 있다.

7. 보안 입력을 사용하는 인간 사용자가 주어진 소프트웨어 객체가 액세스를 허가받았다고 말하는 한, 파일 락커는 그 객체가 파일에 액세스하도록 할 수 있다. 이것은 일반적인 원칙대로(예를 들어, 만약 사용자 "프레드"가 파일 락커로 로그인한다면 어떠한 툴도 프레드의 잠금된 파일들을 볼 수 있음) 행해질 수 있고, 혹은 특수한 원칙대로(예를 들어, 워드가 프레드의 파일 "2003년도 나의 세금"에 액세스하려고 할 때 파일 락커가 사용자에게 그래도 괜찮은지를 직접 질문함) 행해질 수도 있다. 또한, 사용자는 모든 혹은 특정한 파일들을 "미리 잠금해제"할 수 있다. (그리고, 사용자는 파일 락커에 가서 a.doc 및 b.doc 파일들을 사용하기를 원한다고 말함) 그 파일들이 액세스되도록 허용된다(증명 벡터 검사를 하거나 하지 않고). "액세스 허용"된 모든 비트들은 사용자가 로그오프하거나 아마도 소정 시간제한이 지나면 만료된다. 또한, 사용자는 파일을 판독하기 위해 혹은 판독 및 기입을 위해 파일을 잠금해제 할 수 있다. 사용자는 특정 세트의 변경이 로그되도록 혹은 버전별로 관리되도록 지정할 수 있다.

8. 파일 락커는 2개의 스테이크홀더(stakesholder)에 기초하여, 기록하거나 기록하지 않을 수 있고 또는 버전 히스토리를 간직하거나 간직하지 않을 수 있다. 사용자의 명령 시에(일정한 정책으로서 혹은 파일 생성시의 대화에 대한 응답으로) 그렇게 할 수 있고/있거나, 첫 번째 객체에 의해 생성될 때 파일과 함께 전송된 그렇게 하라는 명령에 응답하여 할 수 있다. (따라서 정보를 얻은 클라이언트는 파 일 생성 시에 "버전 보존, 변경 로그, 변경에 대한 증명 요구"를 설정할 수 있다.)

9. 파일이 오픈될 때, 파일 락커는 마지막으로 증명된 버전의 파일을 항상 투명하게 리턴할 수 있다.

10. 파일 락커는 파일의 이름, 작성자, 파일의 썸네일 등과 같은 공개적인 요약 정보를 파일과 함께 저장할 수 있다. 이러한 요약 정보 중 어떠한 것은 디폴트로 얻어질 수 있고(파일의 이름), 다른 요약 정보는 파일이 생성될 때 파일에 첨부될 수 있으며, 또다른 요약 정보는 파일 락커를 위해 파일을 검사했던 소정의 신뢰된 툴에 의해 계산될 것이다. 파일 락커는 그 후 덜 신뢰된 환경으로부터의 어떠한 서비스 호출이 요약 정보를 보도록 허용하는 반면, 다른 호출들은 파일이 잠금해제되지 않는 한 어떠한 것도 보지 못한다. 예를 들어, .tiff 파일이 파일 락커로 들어올 때, 파일 락커로 들어가게 하고 있는 소프트웨어 객체는 파일의 썸네일을 파일 락커에게 선언할 수 있다. 썸네일(아마도 상이한 관련된 파일에 있거나 혹은 스트림 등에 있음)은 요청시에 그것을 요구하는 두 번째 소프트웨어 객체로 제공된다. 이것은 보통의 신뢰되지 않는 가상 기계(또는 다른 환경)에서 실행되고 있는 파일 탐색기 어플리케이션이 썸네일, 파일 이름, 워드 .doc 요약 데이터 등을 보도록 허용할 것이다. 키워드 검색을 허용할 수도 있다. 그러나, 파일로부터 실제 데이터를 읽기 위해서는, 사용자가 파일들을 판독용 또는 판독/기입용으로 잠금해제하거나, 혹은 두 번째 소프트웨어 객체가 올바른 증명 벡터를 가질 필요가 있다.

11. 일 예에서, 공격의 한 형태는 어플리케이션(예를 들어, 워드)이 소정의 방식으로 변경되어, 파일에 불필요한 것을 쓰고 백업 버전을 삭제하는 것일 수 있다. 이러한 형태의 공격을 중단시키기 위하여, 파일 락커는 마지막 증명된 버전으로의 편집을 허용하기 전에, 파일에 대한 모든 증명된 변경이 원격 파일 저장소에 혹은 신뢰된 로컬 파일 저장소에 저장될 것을 확실히 할 수 있다. 따라서, 사용자가 변경들이 정당하다는 것을 증명하기 위하여 신뢰된 환경에서 실행되고 있는 프로그램을 사용할 때마다, 파일 락커는 그 파일의 암호화된/hmac된, 그리고 선택적으로 서명된 버전을 신뢰된 저장소나 원격 저장소로 전송한다. 그것이 성공한 것으로 보이면, 파일은 다시 편집될 수 있다. 이러한 환경에서, 클라이언트 컴퓨터에 있는 바이러스나 다른 공격자는 겨우 열린/증명되지 않은 편집을 삭제할 수 있을 뿐이며, 사용자가 원격/신뢰된 저장소로부터 파일의 마지막 검사된 버전을 요구하도록 할 수 있다. 파일 락커는, 파일을 암호화하고, 부과될 수 있는 모든 요구사항에 만족할 때까지 해제를 거부하는 능력을 가짐으로써, 그러한 룰을 적용할 수 있는 고유의 권력을 부여받는다.

파일 락커를 사용하는 예시적인 프로세스

도 5는 파일 락커가 파일을 저장하고 검색하는 데에 사용되게 하는 예시적인 프로세스를 도시한다. 처음에, 소프트웨어 객체는 파일 락커의 보관소에 파일을 위치시키기 위하여 파일을 파일 락커에 제공한다[단계(502)]. 그 후 파일 락커는 봉인된 저장 설비에서 파일을 자신에게로 봉인한다[단계(504)].

어느 정도의 시간이 흐른 후, 소프트웨어 객체는 파일 락커가 파일을 다시 소프트웨어 객체에게 제공하도록 요구할 수 있다[단계(506)]. 파일 락커는 소프트 웨어 객체에 대해 소정 형태의 검증을 수행한다[단계(508)]. 상기에 언급된 것과 같이, 검증은 요청하는 소프트웨어 객체의 신분, 진정성 등에 대한 검사를 포함할 수 있지만, 본 발명은 검증에 대한 어떠한 특정 형태로 제한되지 않는다.

만약 검증이 통과되는 경우[단계(510)], 요청된 파일이 소프트웨어 객체로 제공된다(514). 소프트웨어 객체가 상기 파일을 소유하고 있는 동안, 파일 락커(또는 파일 락커와 협동하는 어떤 컴포넌트)는 파일 락커로부터 파일이 검사되는 동안 파일이 오용되지 않도록 하기 위하여 선택적으로, 요청하는 소프트웨어 객체의 동작을 감시하고/감시하거나 제어할 수 있다[단계(516)]. 요청하는 소프트웨어 객체가 파일을 이용한 작업을 끝내면, 파일은 파일 락커의 보관소로 리턴된다[단계(518)].

단계(510)에서, 만약 검증이 통과되지 않는 경우, 파일 락커는 파일이 개봉되도록 하지 않을 것이며, 파일은 요청하는 엔터티에게 제공되지 않을 것이다[단계(512)].

단계(516)에서처럼, 파일이 파일 락커의 보관소 외부에 있는 동안 파일을 오용으로부터 보호하는 것은 필수적인 것이 아니라는 점이 유의되어야 한다. 파일 락커가 파일이 파일 락커의 보관소 외부에 있을 때 오용 방지를 시도하도록 구현될 수 있지만, 파일 락커가 파일이 파일 락커의 보관소에 있는 동안 함부로 변경되지 않을 것만을 보장하고, 파일 락커의 보관소 외부에 있는 파일에 무슨 일이 발생할 지에 대해서는 보장하지 않는 보안 모델 또한 허용가능하다. 또한, 인간 사용자 또는 승인된 인간 사용자가 그래야만 한다고 말할 때에만 파일이 보관소를 떠날 것 을 보장하는 보안 모델도 허용가능하다.

"신뢰된 저장소"를 갖지 않는 시스템에서, 공격자는 파일 락커의 보관소 내의 암호화된 파일을 삭제할 수 있어서, 파일들을 파괴하고 다른 곳에는 저장되지 않은 어떠한 작업을 잃게 할 수 있다. 그렇다고 하더라도 파일 락커는 그러한 환경에서 유용하다. 이것은 파일 락커가 (a) 그 파일들에 놀랄만한 변경이 행해지지 않았다는 것을 증명할 수 있고, 어떠한 변경도 수락되기 전에 안전하게 재검토되도록 실시할 수 있기 때문이며, 또한 (b) 파일이 실제로 사용중이지 않은 동안 어떠한 방식으로든 파일의 내용이 노출되지 않도록 할 수 있기 때문이다. "신뢰된 저장소"를 가진 시스템에서, 파일 락커는 신뢰된 저장소를 이용하여, 파일이 파일 락커의 보관소에 있는 동안 삭제될 수 없으며, 보관소 외부에 있을 때조차 파일로의 최근 변경만이 손실될 수 있도록 기록된 버전들을 보존할 수 있다는 것을 보장할 수 있다.

전술한 예들이 단지 설명을 위한 목적으로 제공되었고, 본 발명에 대한 제한으로 해석되어서는 안 된다는 점이 유의되어야 한다. 본 발명은 다양한 실시예들을 참조하여 기술되었지만, 본 발명에서 사용된 단어들은 한정의 단어가 아니라 설명과 예시를 위한 단어들로 이해되어야 한다. 또한, 본 발명은 특정 수단을 참조하여 기술되었지만, 여기 개시된 특정한 것들로 제한하고자 하는 것은 아니다. 오히려, 본 발명은 첨부되는 특허청구범위 내에서 기능적으로 균등한 모든 구조, 방법 및 사용으로 확장된다. 이러한 명세서의 교시에 대해 이점을 가지는 본 발명의 기술 분야에서 숙련된 기술을 지닌 자들은 그것들로의 수많은 변형을 초래할 수 있 으며, 변화는 본 발명의 범위와 취지를 벗어나지 않고 행해질 수 있다.

본 발명에 따르면, 신뢰된 환경의 봉인 기능을 사용하여 파일의 보호 및 관리를 행하는 일반적인 설비가 다양한 소프트웨어 객체에 의해 사용될 수 있다.

Claims

파일을 보호하기 위해 파일 관리 컴포넌트를 사용하는 방법으로서,

객체로부터 파일을 수신하는 단계,

데이터 저장 시스템을 사용하여, 상기 파일을 상기 파일 관리 컴포넌트에 봉인(seal)하는 단계 - 상기 데이터 저장 시스템은 상기 데이터가 봉인되지 않은 어떠한 컴포넌트에 의해서도 상기 데이터가 개봉(unseal)될 수 없도록, 지정된 카테고리의 컴포넌트들로부터 데이터를 수신하고 수신된 데이터를 상기 컴포넌트들 중 하나 이상의 컴포넌트에 봉인할 수 있고, 상기 파일 관리 컴포넌트는 상기 지정된 카테고리의 컴포넌트들 중 하나임 - , 및

상기 파일에 대한 요청을 발행한 객체가 상기 파일을 오픈하도록 허가받은 객체인지에 기초하여 상기 파일로의 액세스를 제한하는 단계 - 상기 요청을 발행한 객체가 허가받은 객체인지에 대한 결정은, 상기 요청을 발행한 객체가 상기 파일을 오픈하도록 허가받은 경우 상기 데이터 저장 시스템으로부터 상기 파일이 개봉되도록 하는 상기 파일 관리 컴포넌트에 의해 행해짐 -

를 포함하는 방법.
제1항에 있어서,

상기 파일이 상기 객체에 의해 사용 중인 동안 상기 객체의 거동을 감시 및/또는 제어하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 객체는 상기 객체를 식별하는 증명 벡터(attestation vector)와 연관되며,

상기 액세스를 제한하는 단계는 상기 객체의 연관된 증명 벡터에 대한 검사에 기초하는 방법.
제1항에 있어서,

상기 객체는 파일 오프닝 인터페이스 호출을 통해 상기 파일을 오픈하는 프로그램을 포함하고, 상기 파일 오프닝 인터페이스 호출은 상기 파일 관리 컴포넌트를 통해 상기 파일을 요청되도록 구성되며, 이러한 구성에 의해 상기 파일 관리 컴포넌트의 사용은 상기 객체에게 투명하게 되는 방법.
제1항에 있어서,

상기 객체는 프로그램이 실행될 수 있는 제1 운영 환경을 포함하는 방법.
제1항에 있어서,

상기 방법은 둘 이상의 운영 환경을 동시에 제공하는 컴퓨팅 배치에서 수행되며, 상기 환경들 중 제1 환경은, 상기 제1 환경이 상기 제1 환경에 기대되는 거동을 따를 것에 대한 제1 수준의 보장성(assurance)을 제공하는 높은 보장성 환경 이고, 상기 환경들 중 제2 환경은, 상기 제2 환경이 상기 제2 환경의 기대되는 거동을 따를 것에 대한 제2 수준의 보장성을 제공하는 상대적으로 낮은 보장성 환경이고, 상기 제2 수준의 보장성은 상기 제1 수준의 보장성보다 상대적으로 더 낮으며, 데이터 저장 설비에 데이터를 봉인하는 능력은 상기 첫 번째 환경의 특성이고, 상기 파일 관리 컴포넌트는 상기 첫 번째 환경에서 동작하고, 상기 객체는 상기 두 번째 환경에서 동작하는 방법.
제6항에 있어서,

상기 지정된 카테고리는 상기 첫 번째 환경에서 동작하는 컴포넌트들로 제한되는 방법.
제1항에 있어서,

상기 파일에 대한 요청을 발행한 객체는 상기 파일이 수신되게 한 객체와는 다르며, 상기 요청을 발행한 객체는 상기 파일을 오픈하도록 허가받는 방법.
제1항에 있어서,

상기 파일이 수신되게 한 객체는 상기 파일의 사용에 룰을 부과하는 방법.
제9항에 있어서,

상기 룰은,

상기 파일의 모든 이전 버전들이 로그되며, 파일 락커(file locker)에 저장된 파일들의 이전 버전들이 복구될 수 있게 하는 요구조건, 및

상기 파일 락커에 의한 상기 파일의 저장에 앞서 사용자가 상기 파일 락커와의 입력 세션에 관여하게 하는 요구조건 - 상기 세션은, 상기 사용자가 상기 파일을 저장할 의사를 확실하게 표현한 것을 확인하고, 상기 사용자가 보는 파일의 뷰가 상기 파일 및 상기 파일에 행해진 임의의 변경들을 정확하게 보여주는 상대적으로 높은 정도의 보장성을 제공하는 환경 하에서, 상기 사용자에게 상기 파일에 대한 임의의 변경을 볼 수 있는 기회를 제공함 -

중 적어도 하나인 방법.
제9항에 있어서,

상기 파일에 관한 요약 정보를 저장하는 단계 - 상기 파일 관리 컴포넌트는 상기 파일로의 액세스가 허용되지 않는 적어도 하나의 환경 하에서 상기 요약 정보로의 액세스를 허용함 -

를 더 포함하는 방법.
파일 락커로서,

파일을 수신하고, 상기 파일이 상기 파일 락커에 의해서만 개봉가능하도록 상기 파일 락커에 봉인되도록 하며, 상기 파일에 대한 요청을 객체로부터 수신하고, 상기 객체가 상기 파일을 수신하도록 권리를 부여받았는지를 검증하고, 상기 객체가 상기 파일을 수신하도록 권리를 부여받았는지에 따라 상기 객체로 상기 파일을 제공하거나 제공하지 않는 로직을 포함하는 파일 락커.
제12항에 있어서,

상기 파일 락커는 둘 이상의 운영 환경을 제공하는 컴퓨팅 배치에서 동작하며, 상기 파일 락커는 상기 환경들 중 제1 환경에서 동작하는 파일 락커.
제13항에 있어서,

상기 객체는 제2 환경인 파일 락커.
제13항에 있어서,

상기 객체는 상기 환경들 중 제2 환경에서 동작하는 파일 락커.
제15항에 있어서,

상기 제1 환경은 위협(threat)에 대하여 상기 제2 환경보다 상대적으로 더 높은 수준의 보호를 제공하는 파일 락커.
제16항에 있어서,

상기 파일이 상기 객체에 의해 사용중인 동안 상기 객체의 거동을 감시 및/또는 제어하는 컴포넌트가 상기 제1 환경에서 동작하는 파일 락커.
제16항에 있어서,

상기 파일을 개봉하기 위해 필요한 암호화 키가 존재하며, 상기 첫 번째 환경은 상기 암호화 키가 상기 첫 번째 환경 외부에서 사용될 수 없도록 하는 임의의 수준의 보장성을 제공하는 파일 락커.
제12항에 있어서,

상기 객체는 상기 객체를 식별하는 증명 벡터와 연관되고, 상기 로직은 상기 증명 벡터를 유효성 검사하여 상기 증명 벡터가 유효성 입증에 실패하면 상기 객체로의 액세스를 거부하는 파일 락커.
제12항에 있어서,

상기 요청이 수신되게 한 객체는 상기 파일이 수신되게 한 객체와 상이하고, 상기 요청이 수신되게 한 객체는 상기 파일을 수신하도록 권리를 부여받는 파일 락커.
제12항에 있어서,

상기 파일 락커는 상기 파일 락커에 의해 수신되거나 저장된 상기 파일의 모든 버전을 로그하는 파일 락커.
제12항에 있어서,

상기 파일 락커는 상기 파일이 수신되는 시점에 사용자와의 양방향 세션(interactive session)에 관여하고,

상기 세션은 사용자가 상기 파일의 현재 버전을 저장하고자 하는 의사를 확실히 밝히도록 요구하며, 상기 파일 락커와 상기 사용자 사이의 통신을 포함하며,

상기 파일 락커와 상기 사용자 사이의 통신은, 상기 통신이 손상되지 않을 것에 대해 상대적으로 높은 수준의 보장성을 제공하는 환경 하에서 발생되는 파일 락커.
컴퓨터 실행가능 명령어들로 암호화된 컴퓨터 판독가능 매체로서,

상기 컴퓨터 실행가능 명령어들은,

파일 관리 컴포넌트에서 파일을 수신하는 단계,

상기 파일 관리 컴포넌트에 상기 파일을 봉인하는 단계,

요청자로부터 상기 파일에 대한 요청을 수신하는 단계,

상기 요청자가 상기 파일을 수신하도록 권리를 부여받았는지를 검증하는 단계,

상기 요청자가 상기 파일을 수신하도록 권리를 부여받은 경우, 상기 파일을 개봉하여 상기 파일을 상기 요청자에게 제공하고, 그렇지 않은 경우, 상기 파일을 개봉하지 않고 상기 파일을 상기 요청자에게 제공하지 않는 단계

를 포함하는 방법을 수행하는 컴퓨터 판독가능 매체.
제23항에 있어서,

상기 방법은,

상기 요청자로부터 요청이 수신되고 상기 요청자가 상기 파일을 수신하도록 권리를 부여받은 것으로 검증된 때 이외에는, 상기 파일이 액세스되지 않도록 보호하는 단계를 더 포함하는 컴퓨터 판독가능 매체.
제23항에 있어서,

상기 파일이 상기 요청자로부터 상기 파일 관리 컴포넌트에서 수신되는 컴퓨터 판독가능 매체.
제23항에 있어서,

상기 요청자는 상기 파일을 생성하거나 조작하는 소프트웨어 객체인 컴퓨터 판독가능 매체.
제26항에 있어서,

상기 요청자는 상기 파일 관리 컴포넌트의 존재 혹은 사용을 상기 요청자에게 투명하게 하는 인터페이스를 통하여, 상기 파일을 상기 파일 관리 컴포넌트에게 제공하는 컴퓨터 판독가능 매체.
제26항에 있어서,

상기 파일 관리 컴포넌트는 제1 환경에서 동작하고, 상기 요청자는 제2 환경에서 동작하며, 상기 제1 환경은 정의된 일련의 위협에 대해 상기 제2 환경보다 상대적으로 더 높은 수준의 차단 혹은 보호를 제공하는 컴퓨터 판독가능 매체.
제28항에 있어서,

상기 파일 관리 컴포넌트는, 상기 첫 번째 환경에서 동작하는 엔터티들에게 이용가능하고 상기 제1 환경 이외의 임의의 환경에서 동작하는 엔터티들에게는 이용가능하지 않은 데이터 저장 설비를 사용하여, 상기 파일을 상기 파일 관리 컴포넌트에 봉인하는 컴퓨터 판독가능 매체.
제28항에 있어서, 상기 방법은,

상기 파일이 상기 요청자에 의해 사용 중인 동안 상기 요청자의 거동을 감시 및/또는 제어하기 위하여 상기 제1 환경에 있는 컴포넌트를 사용하고, 그에 의하여 상기 파일이 개봉된 동안 오용으로부터 보호되게 하는 단계를 더 포함하는 컴퓨터 판독가능 매체.
제23항에 있어서,

상기 방법은 상기 파일의 사용에 룰을 부과하는 단계를 더 포함하며,

상기 룰은,

상기 파일의 새로운 버전을 상기 파일 관리 컴포넌트에 저장하기에 앞서 상기 파일의 모든 버전이 로그되어, 상기 파일의 이전 버전이 검색될 수 있게 하는 요구조건, 및

상기 파일의 새로운 버전을 상기 파일 관리 컴포넌트에 저장하기에 앞서 상기 파일 관리 컴포넌트와 사용자가 통신에 관여하게 하는 요구조건 - 상기 통신은 상기 통신이 손상되지 않을 것에 대한 상대적으로 높은 정도의 보장성을 제공하는 환경 하에서 발생됨 -

중 적어도 하나인 컴퓨터 판독가능 매체.
제31항에 있어서,

상기 통신은 상기 파일 관리 컴포넌트에 저장될 상기 파일의 새로운 버전을 사용자에게 디스플레이하고, 상기 사용자에게 상기 새로운 버전이 용인될 수 있는지를 확인하도록 요구하는 것 포함하는 컴퓨터 판독가능 매체.
제23항에 있어서,

상기 방법은,

상기 파일을 상기 파일 관리 컴포넌트에 저장하기에 앞서, 상기 파일이 미리 정의된 표준을 따르는지를 검증하는 단계를 더 포함하는 컴퓨터 판독가능 매체.