Encrypted Data Vaults 0.1

digitalbazaar.github.io/encrypted-data-vaults/

Encrypted Data Vaults 0.1

 

요약

우리는 개인 식별 정보 (PII), 영업 비밀, 가족 사진 및 고객 정보와 같은 상당한 양의 민감한 데이터를 온라인에 저장합니다. 우리가 저장하는 데이터는 종종 적절한 방식으로 보호되지 않습니다. 이 사양은 스토리지 공급자에서 암호화 된 데이터를 저장, 인덱싱 및 검색하기위한 개인 정보 보호 메커니즘을 설명합니다. 개인이나 조직이 스토리지 공급자가 데이터를보고, 분석, 집계 또는 재판매 할 수없는 방식으로 데이터를 보호하려는 경우 종종 유용합니다. 이 접근 방식은 또한 애플리케이션 데이터가 이동 가능하고 스토리지 제공 업체 데이터 침해로부터 보호되도록 합니다.

 

 

1. 소개

이 섹션은 비표준입니다.

우리는 개인 식별 정보 (PII), 영업 비밀, 가족 사진 및 고객 정보와 같은 상당한 양의 민감한 데이터를 온라인에 저장합니다. 우리가 저장하는 데이터는 종종 적절한 방식으로 보호되지 않습니다.

일반 데이터 보호 규정 (GDPR)과 같은 입법은 주로 데이터 유출시 공급자가 책임을지게함으로써 개인의 프라이버시를 더 잘 보존하도록 서비스 공급자를 장려합니다. 이러한 책임 압력으로 인해 공급자는 종종 고객을 적절하게 보호 할 수있는 기술을 갖추고 있지 않은 기술적 격차가 드러났습니다. 암호화 된 데이터 볼트는이 격차를 메우고 다양한 다른 이점을 제공합니다.

이 사양은 스토리지 공급자에서 암호화 된 데이터를 저장, 인덱싱 및 검색하기위한 개인 정보 보호 메커니즘을 설명합니다. 개인이나 조직이 스토리지 공급자가 데이터를보고, 분석하고, 집계하거나, 재판매 할 수없는 방식으로 데이터를 보호하려는 경우 유용합니다. 이 접근 방식은 또한 애플리케이션 데이터가 이동 가능하고 스토리지 제공 업체 데이터 침해로부터 보호되도록합니다.

 

1.1 암호화 된 데이터 저장소가 필요한 이유는 무엇입니까?

이 섹션은 비표준입니다.

문제 1
개인 정보, 영업 비밀을 보호하고 데이터 이동성을 보장하려는 개인 및 조직이이 기술을 사용하여 혜택을받는 이유를 설명하십시오. 사용자 데이터 저장을위한 표준 API를 제공하여 사용자가 "자신의 저장소를 가져와"자신의 정보를 제어 할 수 있도록하는 방법을 설명합니다. 표준 API에 대해 작성된 애플리케이션을 설명하고 사용자가 자신의 스토리지를 가져올 것이라고 가정하면 애플리케이션의 기능에 관심을두고 집중할 수 있으므로 스토리지 인프라를 처리할 필요가 없습니다 (대신 전문 서비스 제공 업체에 맡기지 않고 사용자가 선택한).

사용자가 여러 장치에 데이터를 저장하고 다른 사용자와 데이터를 공유 할 수 있도록 하는 동시에 모든 데이터와 메타 데이터에 대해 클라이언트 측 (에지) 암호화를 요구하는 동시에 검색 또는 쿼리 가능한 데이터를 보유하는 것은 역사적으로 구현하기가 매우 어려웠습니다. 하나의 시스템. 유용성을 위해 프라이버시를 희생하는 트레이드 오프가 종종 이루어지며 그 반대의 경우도 마찬가지입니다.

다수의 성숙 된 기술과 표준으로 인해, 우리는 그러한 절충이 더 이상 필요하지 않으며, 실질적인 호소력이있는 암호화 된 분산 데이터 저장(Encrypted Distributed Data Storage)을 위한 개인 정보 보호 프로토콜을 설계 할 수 있기를 바랍니다.

 

 

1.2 Ecosystem Overview

 

이 섹션은 비표준입니다.

분산형 데이터 저장 문제는 다양한 각도에서 접근되어 왔으며, 분산 형 또는 기타 방식의 개인 데이터 저장소 (PDS)는 상업 및 학술 환경에서 오랜 역사를 가지고 있습니다. 다양한 접근 방식으로 인해 용어와 아키텍처가 다양해졌습니다. 아래 다이어그램은 새롭게 등장하는 구성 요소의 유형과 그 역할을 보여줍니다. 암호화된 데이터 볼트는 스토리지 역할을 수행합니다.

그림 1 역할 및 상호 작용

이 섹션에서는이 사양이 유용 할 것으로 예상되는 생태계에서 핵심 행위자의 역할과 이들 간의 관계를 설명합니다. 역할은 다양한 방식으로 구현 될 수있는 추상화입니다. 역할 분리는 표준화를 위한 인터페이스와 프로토콜을 제안합니다. 이 사양에는 다음 역할이 도입되었습니다.

 

데이터 볼트 컨트롤러(data vault controller)
데이터 저장소를 생성, 관리 및 삭제하여 엔티티가 수행 할 수있는 역할입니다. 이 엔티티는 또한 자신이 제어하는 데이터 저장소에 대한 스토리지 에이전트에 대한 권한 부여 및 취소를 담당합니다.
스토리지 에이전트(storage agent)
데이터 저장소에서 데이터를 생성, 업데이트 및 삭제하여 엔터티가 수행 할 수있는 역할입니다. 이 엔티티는 일반적으로 데이터 저장소 컨트롤러가 데이터 저장소에 액세스 할 수있는 권한을 부여받습니다.
스토리지 제공자(storgae provider)
데이터 저장소 컨트롤러에 원시 데이터 저장 메커니즘을 제공하여 엔티티가 수행 할 수있는 역할입니다. 이 엔터티는 저장중인 데이터를 볼 수 없습니다. 모든 데이터가 저장 상태에서 암호화되고 저장소 공급자와주고받는 중이기 때문입니다.

1.3 사용 사례

이 섹션은 비표준입니다.

다음 네 가지 사용 사례는 일반적인 사용 패턴을 대표하는 것으로 확인되었습니다 (단, 유일한 사용 사례는 아닙니다).

1.3.1 데이터 저장 및 사용

내 데이터를 안전한 위치에 저장하고 싶습니다. 스토리지 제공 업체가 내가 저장 한 데이터를 볼 수 없도록하고 싶습니다. 이는 나만 데이터를보고 사용할 수 있음을 의미합니다.

1.3.2 검색 데이터

시간이 지남에 따라 많은 양의 데이터를 저장할 것입니다. 데이터를 검색하고 싶지만 서비스 제공 업체가 제가 무엇을 저장하거나 검색하는지 알기를 원하지 않습니다.

1.3.3 하나 이상의 엔터티와 데이터 공유

 

내 데이터를 다른 사람 및 서비스와 공유하고 싶습니다. 데이터를 처음 저장할 때 또는 이후 단계에서 다른 엔터티가 내 저장 영역의 데이터에 액세스하도록 할 수 있습니다. 저장소는 내가 각 항목에 대해 명시 적으로 동의 한 경우에만 다른 사람에게 액세스 권한을 부여해야합니다.

언제든지 다른 사람의 액세스 권한을 취소 할 수 있기를 원합니다. 데이터를 공유 할 때 제 3자가 내 데이터에 액세스 할 수있는 만료일을 포함 할 수 있습니다.

1.3.4 동일한 데이터를 여러 곳에 저장

하나가 실패 할 경우를 대비하여 여러 저장소 위치에 데이터를 백업하고 싶습니다. 이러한 위치는 서로 다른 저장소 공급자가 호스팅 할 수 있으며 서로 다른 프로토콜을 통해 액세스 할 수 있습니다. 한 위치는 내 휴대폰에서 로컬 일 수 있고 다른 위치는 클라우드 기반 일 수 있습니다. 위치는 서로 동기화 할 수 있어야 데이터를 생성하거나 업데이트하는 방법에 관계없이 두 위치 모두에서 데이터가 최신 상태 여야하며, 가능한 한 많은 도움없이 자동으로 수행되어야합니다.

 

1.3.5 배포 토폴로지

사용 사례를 기반으로 다음 배포 토폴로지를 고려합니다.

 

• 모바일 장치 전용 : 서버와 클라이언트가 동일한 장치에 있습니다. 볼트는 암호화 된 데이터베이스를 제공하기 위해 로컬 저장소를 사용하는 바이너리 API를 통해 기능을 제공하는 라이브러리입니다.
• 모바일 장치 플러스 클라우드 스토리지 : 모바일 장치는 클라이언트 역할을하고 서버는 네트워크 기반 API (예 : HTTPS를 통한 REST)를 통해 스토리지를 노출 한 원격 클라우드 기반 서비스 제공 업체입니다. 데이터는 모바일 장치에 저장되지 않습니다.
• 여러 장치 (단일 사용자) 및 클라우드 스토리지 : 단일 사용자가 관리하는 장치를 더 추가 할 때 볼트를 사용하여 장치간에 데이터를 동기화 할 수 있습니다.
• 여러 장치 (여러 사용자) 및 클라우드 스토리지 : 여러 사용자를 클라우드 스토리지와 페어링 할 때 볼트를 사용하여 복제 및 병합 전략을 통해 여러 사용자간에 데이터를 동기화 할 수 있습니다.

 

 

1.4 요구 사항

 

이 섹션은 비표준입니다.

다음 섹션에서는 핵심 사용 사례에서 수집 한 요구 사항에 대해 자세히 설명합니다.

1.4.1 개인 정보 보호 및 다자간 암호화

이 시스템의 주요 목표 중 하나는 스토리지 제공 업체를 포함하여 권한이없는 당사자가 액세스 할 수 없도록 엔티티 데이터의 프라이버시를 보장하는 것입니다.

이를 위해서는 데이터가 전송되는 동안 (네트워크를 통해 전송되는 동안) 및 저장되는 동안 (스토리지 시스템에서) 데이터가 암호화되어야합니다.

데이터는 둘 이상의 엔터티와 공유 될 수 있으므로 암호화 메커니즘이 여러 당사자에 대한 데이터 암호화를 지원하는 것도 필요합니다.

1.4.2 공유 및 승인

하나 이상의 엔티티간에 암호화 된 정보의 승인 된 공유를 가능하게하는 메커니즘이 필요합니다.

시스템은 하나의 필수 권한 부여 체계를 지정하지만 다른 대체 권한 체계도 허용해야합니다. 인증 체계의 예로는 OAuth2, 웹 액세스 제어 및 [ZCAP] (인증 기능)가 있습니다.

1.4.3 식별자(Identifiers)

시스템은 식별자와 무관해야합니다. 일반적으로 URN 또는 URL 형식의 식별자가 선호됩니다. [DID-CORE] (분산 식별자, DID)는 시스템에서 몇 가지 중요한 방식으로 사용되는 것으로 추정되지만 구현을 DID에 하드 코딩하는 것은 안티 패턴이 될 것입니다.

 

1.4.4 버전 관리 및 복제

 

정보는 지속적으로 백업 될 것으로 예상됩니다. 이러한 이유로 시스템은 하나 이상의 필수 버전 관리 전략과 하나의 필수 복제 전략을 지원하지만 다른 대체 버전 관리 및 복제 전략도 허용해야합니다.

 

1.4.5 메타 데이터 및 검색

 

이 시스템을 사용하여 많은 양의 데이터가 저장 될 것으로 예상되며이를 효율적이고 선택적으로 검색해야합니다. 이를 위해 암호화 된 검색 메커니즘은 시스템의 필수 기능입니다.

클라이언트가 메타 데이터를 검색 할 수 있도록 데이터와 연관시킬 수 있어야합니다. 동시에 데이터와 메타 데이터의 개인 정보 보호가 핵심 요구 사항이므로 메타 데이터는 암호화 된 상태로 저장되어야하며 서비스 제공 업체는 이러한 검색을 불투명하고 개인 정보를 보호하는 방식으로 수행 할 수 있어야합니다. 메타 데이터를 참조하십시오.

 

1.4.6 프로토콜

이 시스템은 다양한 운영 환경에 상주 할 수 있기 때문에 최소한 하나의 프로토콜이 필수이지만 다른 프로토콜도 설계에 의해 허용되는 것이 중요합니다. 프로토콜의 예로는 HTTP, gRPC, Bluetooth 및 다양한 바이너리 온더 와이어 프로토콜이 있습니다. HTTPS API는 § 6. 데이터 볼트 HTTPS API에 정의되어 있습니다.

 

 

1.5 디자인 목표

 

 

이 섹션은 비표준입니다.

이 섹션에서는 암호화 된 데이터 저장소를 형성하는 여러 가지 기본 원칙 및 설계 목표에 대해 자세히 설명합니다.

1.5.1 계층화 및 모듈 식 아키텍처
계층화 된 아키텍처 접근 방식을 사용하여 시스템의 기반을 쉽게 구현하는 동시에 더 복잡한 기능을 하위 기반 위에 계층화 할 수 있습니다.

예를 들어, 레이어 1에는 가장 기본적인 시스템에 대한 필수 기능이 포함될 수 있고, 레이어 2에는 대부분의 배포에 유용한 기능이 포함될 수 있으며, 레이어 3에는 에코 시스템의 작은 하위 집합에 필요한 고급 기능이 포함될 수 있으며, 레이어 4에는 다음과 같은 매우 복잡한 기능이 포함될 수 있습니다. 생태계의 아주 작은 부분 집합이 필요합니다.

1.5.2 개인 정보 우선 순위 지정
이 시스템은 기업의 개인 정보를 보호하기위한 것입니다. 새로운 기능을 탐색 할 때 항상 "이가 개인 정보 보호에 어떤 영향을 미칠까요?"라고 질문하십시오. 개인 정보에 부정적인 영향을 미치는 새로운 기능은 절충 사항이 새로운 기능의 가치가 있는지 확인하기 위해 극도의 조사를 거쳐야합니다.

1.5.3 클라이언트에 구현 복잡성 푸시
이 시스템의 서버는 암호화 된 데이터의 저장 및 검색에 중점을 둔 기능을 제공 할 것으로 예상됩니다. 서버가 더 많이 알수록 데이터를 저장하는 주체의 개인 정보에 대한 위험이 커지고 서비스 공급자가 데이터를 호스팅하는 데 더 많은 책임이있을 수 있습니다. 또한 복잡성을 클라이언트로 밀어 붙이면 서비스 제공 업체는 안정적인 서버 측 구현을 제공 할 수 있으며 혁신은 클라이언트가 수행 할 수 있습니다.

 

1.6 적합성
비표준으로 표시된 섹션뿐만 아니라이 사양의 모든 작성 지침, 다이어그램, 예제 및 참고 사항은 비표준입니다. 이 사양의 다른 모든 내용은 표준입니다.

이 문서의 키워드 MAY 및 MUST는 BCP 14 [RFC2119] [RFC8174]에 설명 된대로 여기에 표시된대로 모두 대문자로 표시되는 경우에만 해석되어야합니다.

미정

 

 

2. 용어

이 섹션은 비표준입니다.

다음 용어는이 사양의 개념을 설명하는 데 사용됩니다.

entity
생태계에서 하나 이상의 역할을 수행하는 사람, 조직 또는 장치와 같이 고유하고 독립적 인 존재가있는 것.
user agent
이 사양에서 다양한 역할 간의 통신을 중재하는 브라우저 또는 기타 웹 클라이언트와 같은 프로그램.
URI
[RFC3986]에 정의 된 식별자입니다.

 

 

3. 핵심 개념

이 섹션은 비표준입니다.

다음 섹션에서는이 사양의 기반을 형성하는 암호화 된 저장소와 같은 핵심 개념에 대해 설명합니다.

 

3.1 암호화 된 저장소
암호화 된 데이터 저장소의 중요한 고려 사항은 아키텍처의 어떤 구성 요소가 (암호화되지 않은) 데이터에 액세스 할 수 있는지 또는 개인 키를 제어하는 ​​사람입니다. 대략 세 가지 접근 방식이 있습니다 : 스토리지 측 암호화, 클라이언트 측 (에지) 암호화 및 게이트웨이 측 암호화 (이전 두 가지의 하이브리드).

사용자가 임의의 데이터를 저장할 수있는 모든 데이터 스토리지 시스템은 또한 가장 기본적인 수준에서 클라이언트 측 암호화를 지원합니다. 즉, 사용자가 데이터를 직접 암호화 한 다음 저장할 수 있습니다. 그렇다고 이러한 시스템이 암호화 된 데이터에 최적화되어 있다는 의미는 아닙니다. 암호화 된 데이터에 대한 쿼리 및 액세스 제어가 어려울 수 있습니다.

스토리지 측 암호화는 일반적으로 전체 디스크 암호화 또는 파일 시스템 수준 암호화로 구현됩니다. 이것은 널리 지원되고 이해되며 모든 유형의 호스팅 된 클라우드 스토리지는 스토리지 측 암호화를 사용할 가능성이 높습니다. 이 시나리오에서 개인 키는 데이터를 저장하는 사용자와는 다른 엔티티 일 수있는 스토리지 서버의 서비스 제공자 또는 컨트롤러에 의해 관리됩니다. 디스크에 상주하는 동안 데이터를 암호화하는 것은 스토리지 하드웨어에 대한 물리적 액세스가 손상 될 경우 유용한 보안 조치이지만 데이터를 저장 한 원래 사용자 만 액세스 할 수 있다는 보장은 없습니다.

반대로, 클라이언트 측 암호화는 특히 메타 데이터도 암호화 할 수있는 경우 높은 수준의 보안 및 개인 정보 보호를 제공합니다. 암호화는 일반적으로 키 체인 또는 지갑 클라이언트에 의해 지원되는 개별 데이터 개체 수준에서 수행되므로 사용자는 개인 키에 직접 액세스 할 수 있습니다. 그러나 키 관리 및 복구의 중요한 책임이 최종 사용자에게 전가되기 때문에 비용이 발생합니다. 또한 데이터를 공유해야 할 때 키 관리 문제가 더욱 복잡해집니다.

게이트웨이 측 암호화 시스템은 스토리지 측 및 클라이언트 측 암호화 아키텍처의 기술을 결합하는 접근 방식을 취합니다. 일반적으로 다중 서버 클러스터 또는 일부 "플랫폼으로서의 암호화"클라우드 서비스 공급자 사이에서 발생하는 이러한 스토리지 시스템은 일부 사용자 및 사용 사례에 대해 클라이언트 측 키 관리가 너무 어려울 수 있음을 인식하고 자체적으로 암호화 및 복호화를 수행 할 수 있습니다. 클라이언트 애플리케이션에 투명한 방식입니다. 동시에 개인 암호 해독 키에 액세스 할 수있는 구성 요소 (스토리지 서버)의 수를 최소화하는 것을 목표로합니다. 결과적으로 키는 일반적으로 데이터를 스토리지 서버로 전달하기 전에 암호화하는 "게이트웨이"서버에 상주합니다. 암호화 / 암호 해독은 클라이언트에 투명하고 데이터는 스토리지 서버에 대해 불투명하며 결과적으로 모듈 식 / 플러그 형이 될 수 있습니다. 게이트웨이 측 암호화는 스토리지 측 시스템에 비해 몇 가지 이점을 제공하지만 단점도 공유합니다. 게이트웨이 sysadmin이 사용자가 아닌 키를 제어합니다.

 

3.2 구조화 된 문서
데이터 저장소의 기본 저장 단위는 암호화 된 구조화 된 문서로, 복호화시 JSON 및 CBOR과 같은 인기있는 구문으로 표현할 수있는 데이터 구조를 제공합니다. 문서는 구조화 된 데이터와 구조화 된 데이터에 대한 메타 데이터를 저장할 수 있습니다. 구조화 된 문서 크기는 16MB로 제한됩니다.

3.3 스트림
16MB보다 큰 파일 또는 오디오, 비디오 및 사무실 생산성 파일과 같은 원시 이진 데이터 형식의 경우 데이터 저장소에서 데이터를 스트리밍 할 수있는 스트리밍 API가 제공됩니다. 스트림은 구조화 된 문서를 사용하여 설명되지만 데이터의 저장소는 암호화 된 콘텐츠에 대한 해시 링크를 사용하여 구조화 된 문서와 분리됩니다.

3.4 인덱싱
데이터 저장소는 다양한 종류의 문서를 매우 많이 저장할 것으로 예상됩니다. 즉, 문서를 적시에 검색 할 수 있어야하므로 콘텐츠가 암호화 될 때 스토리지 공급자에게 문제가됩니다. 이전에는이 ​​문제가 데이터 개체에 첨부 된 암호화되지 않은 일정량의 메타 데이터로 해결되었습니다. 또 다른 가능성은 필터링 된 데이터 하위 집합에 대한 포인터의 암호화되지 않은 목록입니다.

데이터 볼트의 경우, 데이터 볼트 클라이언트가 메타 데이터 인덱싱을 수행하면서 메타 데이터를 스토리지 공급자에게 유출하지 않도록하는 보안 데이터 볼트에 대해 암호화 된 검색 체계가 제공됩니다.

 

4. 아키텍쳐

이 섹션에서는 클라이언트-서버 관계의 형태로 암호화 된 데이터 저장소 프로토콜의 아키텍처를 설명합니다. 볼트는 서버로 간주되고 클라이언트는 볼트와 상호 작용하는 데 사용되는 인터페이스 역할을합니다.

이 아키텍처는 본질적으로 계층화되어 있으며, 기본 계층은 최소한의 기능이있는 운영 시스템으로 구성되고 고급 기능이 위에 계층화됩니다. 구현시 기본 계층 만 구현하거나 선택적으로 고급 사용 사례를 위해 더 풍부한 기능 세트로 구성된 추가 계층을 구현하도록 선택할 수 있습니다.

 

4.1 서버 및 클라이언트 책임
서버는 신뢰도가 낮은 것으로 간주되며 지속되는 데이터에 대한 가시성이 없어야합니다. 그러나 이 모델에서도 서버는 준수해야하는 최소한의 책임이 있습니다.

클라이언트는 구현에 필요한대로 각 관련 프로토콜 (HTTP, RPC 또는 이진 over-the-wire 프로토콜)에 대한 바인딩과 함께 서버에 인터페이스를 제공 할 책임이 있습니다.

데이터의 모든 암호화 및 암호 해독은 클라이언트 측의 에지에서 수행됩니다. 데이터 (메타 데이터 포함)는 서버에 대해 불투명해야하며 아키텍처는 서버가이를 해독 할 수 없도록 설계되었습니다.

4.2 레이어 1 (L1) 책임
계층 1은 전송 및 저장 데이터를 암호화 할 수있는 클라이언트-서버 시스템으로 구성됩니다.

4.2.1 서버 : 요청 유효성 검사 (L1)
볼트 클라이언트가 볼트의 데이터를 저장, 쿼리, 수정 또는 삭제하도록 요청하면 서버는 요청의 유효성을 검사합니다. 특정 요청의 실제 데이터와 메타 데이터가 암호화되기 때문에 이러한 유효성 검사는 반드시 제한되며 요청의 프로토콜과 의미에 크게 좌우됩니다.

4.2.2 서버 : 데이터 유지 (L1)
서버가 로컬, 네트워크 또는 분산 파일 시스템의 스토리지와 같은 데이터를 유지하는 데 사용하는 메커니즘은 구현에 따라 결정됩니다. 지속성 메커니즘은 신뢰할 수있는 저장 및 데이터 검색과 같은 데이터 저장 공급자의 일반적인 기대를 준수 할 것으로 예상됩니다.

4.2.3 서버 : 전역 구성 유지 (L1)
볼트에는 다음 속성을 정의하는 전역 구성이 있습니다.

스트림 덩어리(chunk) 사이즈 
기타 구성 메타 데이터
구성을 통해 클라이언트는 서버에서 사용하는 권한 부여, 프로토콜 및 복제 메커니즘과 같은 기능 검색을 수행 할 수 있습니다.

4.2.4 서버 : 권한 부여 정책 시행 (L1)
클라이언트가 저장소에서 데이터를 저장, 쿼리, 수정 또는 삭제하도록 요청하면 서버는 요청과 관련된 모든 권한 부여 정책을 적용합니다.

4.2.5 클라이언트 : 암호화 된 데이터 청킹 (L1)
암호화 된 데이터 저장소는 구조화되지 않은 대규모 바이너리 데이터를 포함하여 다양한 유형의 데이터를 저장할 수 있습니다. 즉, 단일 레코드 크기에 제한이있는 시스템에서는 파일을 단일 항목으로 저장하는 것이 어려울 수 있습니다. 예를 들어, 일부 데이터베이스는 단일 레코드의 최대 크기를 16MB로 설정합니다. 따라서 대용량 데이터를 서버에서 쉽게 관리 할 수있는 크기로 청크해야합니다. 각 리소스의 청크 크기를 설정하고 대용량 데이터를 서버의 관리 가능한 청크로 설정하는 것은 클라이언트의 책임입니다. 처리 할 수 있는 더 큰 청크 저장 요청을 거부하는 것은 서버의 책임입니다.

각 청크는 인증 된 암호화를 사용하여 개별적으로 암호화됩니다. 이렇게하면 공격 서버가 큰 파일의 청크를 대체하고 파일이 손상되었는지 확인하기 전에 피해자가 전체 파일을 다운로드하고 해독해야하는 공격으로부터 보호 할 수 있습니다. 인증된 암호화로 각 청크를 암호화하면 클라이언트가 다음 청크로 진행하기 전에 유효한 청크가 있음을 알 수 있습니다. 다른 인증된 클라이언트는 청크에서 인증된 암호화를 수행하여 여전히 공격을 수행 할 수 있지만 서버는 동일한 공격을 시작할 수 없습니다.

 

4.2.6 클라이언트 : 리소스 구조 (L1)
암호화 된 데이터를 저장하는 프로세스는 다음과 같은 구조로 클라이언트가 리소스를 생성하는 것으로 시작됩니다.

자원:

아이디 (필수)
메타
meta.contentType MIME 유형
콘텐츠-전체 페이로드 또는 개별 청크에 대한 매니페스트와 유사한 해시 링크 목록
데이터가 청크 크기보다 작 으면 콘텐츠에 직접 포함됩니다.

그렇지 않으면 데이터가 클라이언트에 의해 청크로 분할되고 (다음 섹션 참조) 각 청크가 암호화되어 서버로 전송됩니다. 이 경우 콘텐츠에는 개별 청크에 대한 매니페스트와 유사한 URI 목록이 포함됩니다 ([HASHLINK]에 의해 무결성 보호됨).

4.2.7 클라이언트 : 암호화 된 리소스 구조 (L1)
암호화 된 리소스를 만드는 프로세스입니다. 데이터가 청크로 분할 된 경우 개별 청크가 서버에 기록 된 후에 수행됩니다.

• id
• index-클라이언트가 준비한 암호화 된 인덱스 태그 (암호화 된 리소스에 대한 개인 정보 보호 쿼리에 사용)
• 청크 크기 (글로벌 구성의 기본값과 다른 경우)
• 버전 관리 메타 데이터 (예 : 시퀀스 번호, Git 유사 해시 또는 기타 메커니즘)
• 암호화 된 리소스 페이로드-jwe [RFC7516], cwe [RFC8152] 또는 기타 적절한 메커니즘으로 인코딩 됨

4.3 레이어 2 (L2) 책임
레이어 2는 여러 엔티티간에 데이터를 공유하고 버전 관리 및 복제를 수행하고 효율적인 방식으로 개인 정보 보호 검색을 수행 할 수있는 시스템으로 구성됩니다.

4.3.1 클라이언트 : 암호화 된 검색 인덱스 (L2)
개인 정보 보호 쿼리 (검색 인덱스가 서버에 대해 불투명한 경우)를 사용하려면 클라이언트는 암호화 된 색인 태그 목록 (암호화 된 데이터 콘텐츠와 함께 암호화된 리소스에 저장됨)을 준비해야합니다.

 

4.3.2 클라이언트 : 버전 관리 및 복제 (L2)
서버는 하나 이상의 버전 관리 / 변경 제어 메커니즘을 지원해야합니다. 복제는 서버가 아니라 클라이언트에 의해 수행됩니다 (클라이언트가 키를 제어하고 복제할 다른 서버에 대해 알고 있기 때문에). 암호화 된 데이터 저장소 구현이 복제 기능을 제공하는 것을 목표로하는 경우 버전 관리 / 변경 제어 전략도 선택해야합니다 (복제에는 반드시 충돌 해결이 포함되므로). 일부 버전 관리 전략은 암시 적이지만 (예 : rsync 또는 파일 호스팅 서비스에 파일 업로드와 같은 "마지막 쓰기 승리") 복제 전략은 항상 일종의 충돌 해결 메커니즘이 포함되어야 함을 의미합니다.

4.3.3 클라이언트 : 다른 엔티티와 공유
개별 볼트의 권한 부여 메커니즘 선택에 따라 클라이언트가 다른 엔티티 (권한 부여 기능 링크 또는 유사한 메커니즘)와 리소스를 공유하는 방법이 결정됩니다.

 

4.4 레이어 3 (L3) 책임
4.4.1 서버 : 알림 (L3)
데이터 저장소 공급자가 영구 데이터가 변경 될 때 클라이언트에게 알릴 수 있으면 유용합니다. 서버는 클라이언트가 볼트의 변경 사항을 구독 할 수있는 메커니즘을 선택적으로 구현할 수 있습니다.

4.4.2 클라이언트 : 볼트 전체 무결성 보호 (L3)
문서를 이전 버전으로 되돌 리거나 삭제하는 경우와 같이 감지 할 수없는 방식으로 데이터가 수정되는 다양한 스토리지 공급자 공격을 방지하기 위해 Vault 전체의 무결성 보호가 제공됩니다. 이 보호를 위해서는 사용자에게 속한 모든 리소스 식별자의 글로벌 카탈로그와 최신 버전이 클라이언트에 의해 저장되고 최신 상태로 유지되어야합니다. 일부 클라이언트는이 카탈로그의 사본을 로컬에 저장할 수 있습니다 (서버의 간섭 또는 삭제를 방지하기 위해 [HASHLINK]와 같은 무결성 보호 메커니즘을 포함).

 

5. Data Model

다음 섹션에서는 데이터 저장소의 데이터 모델을 간략하게 설명합니다.

5.1 DataVaultConfiguration

데이터 볼트 구성은 특정 데이터 볼트가 가질 속성을 지정합니다.

특성	설명
sequence	클라이언트가 데이터 저장소에 올바르게 동기화되도록하기위한 데이터 저장소의 고유 카운터입니다. 값은 필수이며 부호없는 64 비트 숫자 여야합니다.
controller	데이터 저장소를 제어하는 엔티티 또는 암호화 키입니다. 값은 필수이며 URI 여야합니다.
invoker	데이터 저장소의 구성을 수정하거나 읽기 또는 쓰기를위한 권한 부여 기능을 호출(invoke) 할 권한이있는 루트 엔터티 또는 암호화 키입니다. 값은 선택 사항이지만 존재하는 경우 URI 또는 URI 배열이어야합니다. 이 값이 없으면 컨트롤러 속성의 값이 동일한 용도로 사용됩니다.
delegator	데이터 저장소의 구성을 수정하거나 읽기 또는 쓰기를 위해 권한 부여 기능을 위임(delegate) 할 권한이있는 루트 엔터티 또는 암호화 키입니다. 값은 선택 사항이지만 존재하는 경우 URI 또는 URI 배열이어야합니다. 이 값이 없으면 컨트롤러 속성의 값이 동일한 용도로 사용됩니다.
referenceId	애플리케이션 별 참조 식별자를 표현하는 데 사용됩니다. 값은 선택 사항이며 존재하는 경우 문자열이어야합니다.
keyAgreementKey.id	키 계약 키의 식별자입니다. 값은 필수이며 URI 여야합니다. 키 계약 키는 수신자를위한 키 암호화 키를 생성하는 데 사용되는 비밀을 파생하는 데 사용됩니다.
keyAgreementKey.type	키 계약 키의 유형입니다. 값은 필수이며 URI이거나 URI에 매핑되어야합니다.
hmac.id	HMAC 키의 id입니다. 값은 URI이거나 URI에 매핑되어야합니다.
hmac.type	HMAC 키의 타입입니다. 값은 필수이며 URI이거나 URI에 매핑되어야합니다.

{
  "sequence": 0,
  "controller": "did:example:123456789",
  "referenceId": "my-primary-data-vault",
  "keyAgreementKey": {
    "id": "https://example.com/kms/12345",
    "type": "X25519KeyAgreementKey2019"
  },
  "hmac": {
    "id": "https://example.com/kms/67891",
    "type": "Sha256HmacKey2019"
  }
}

 

5.2.1 스트림
스트림은 이미지, 비디오, 백업 파일 및 임의 길이의 기타 이진 데이터를 저장하는 데 사용할 수 있습니다. 이는 스트림 속성과 저장되는 스트림의 유형을 추가로 식별하는 추가 메타 데이터를 사용하여 수행됩니다. 아래 표는 StructuredDocument에 지정된 값 외에 저장할 메타 데이터를 제공합니다.

속성	설명
meta.chunks	스트림의 청크 수를 지정합니다.
stream.id	스트림의 식별자입니다. 스트림 식별자는 동일한 데이터 저장소의 스트림을 참조하는 URI 여야합니다. 스트림이 데이터 저장소에 기록되면 콘텐츠 식별자는 유효한 해시 링크가되도록 업데이트해야합니다. 스트리밍 암호화를 허용하기 위해 스트림에 대한 다이제스트 값은 스트림이 기록 될 때까지 알 수없는 것으로 간주됩니다. 해시 링크는 데이터 저장소에 기록 된 스트림에 대한 콘텐츠 해시로 존재해야합니다.

{
  "id": "urn:uuid:41289468-c42c-4b28-adb0-bf76044aec77",
  "meta": {
    "created": "2019-06-19",
    "contentType": "video/mpeg",
    "chunks": 16
  },
  "stream": {
    "id": "https://example.com/encrypted-data-vaults/zMbxmSDn2Xzz?hl=zb47JhaKJ3hJ5Jkw8oan35jK23289Hp"
  }
}

 

5.3 EncryptedDocument

암호화 된 문서는 데이터 컨트롤러의 동의 없이는 어떤 엔티티도 정보를 읽을 수 없도록 구조화 된 문서를 저장하는 데 사용됩니다.

문제 6
아래 표는 EncryptedDocument의 간단한 버전이지만 EncryptedDocument에있는 경우 색인 된 속성과 하위 속성을 설명하는 다른 테이블은 없습니다.

문제 7
JWE 수신자 필드에서 Diffie-Hellman 키를 식별 할 수 있음을 보여주는 또 다른 예를 추가해야합니다. 이 유형의 키는 키 래핑 키에 대한 키 계약에 사용할 수 있습니다.

특성	설명
id	암호화 된 문서의 식별자입니다. 이 값은 필수이며 Base58로 인코딩 된 128 비트 임의 값이어야합니다.
sequence	클라이언트가 데이터 저장소에 올바르게 동기화되도록하기위한 데이터 저장소의 고유 카운터입니다. 값은 필수이며 부호없는 64 비트 숫자 여야합니다.
jwe 또는 cwe	디코딩된 경우 해당 StructuredDocument를 생성하는 JSON 웹 암호화 또는 COSE 암호화 값입니다.

문제 8 
다른 섹션에서는 EncryptedDocument를 요청하는 엔터티가 필드 또는 해당 값을 볼 수있는 권한이 있는지 여부에 따라 데이터 볼트 서버가 특정 필드 또는받는 사람 필드와 같은 특정 필드의 특정 값을 생략 할 수 있음을 자세히 설명해야합니다. 이는 권한 부여 기능을 사용하여 세밀하게 제어 할 수 있습니다.

 

{
  "id":"z19x9iFMnfo4YLsShKAvnJk4L",
  "sequence":0,
  "indexed":[
    {
      "hmac":{
        "id":"did:ex:12345#key1",
        "type":"Sha256HmacKey2019"
      },
      "sequence":0,
      "attributes":[
      ]
    }
  ],
  "jwe":{
    "protected":"eyJlbmMiOiJDMjBQIn0",
    "recipients":[
      {
        "header":{
          "kid":"urn:123",
          "alg":"ECDH-ES+A256KW",
          "epk":{
            "kty":"OKP",
            "crv":"X25519",
            "x":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs"
          },
          "apu":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs",
          "apv":"dXJuOjEyMw"
        },
        "encrypted_key":"4PQsjDGs8IE3YqgcoGfwPTuVG25MKjojx4HSZqcjfkhr0qhwqkpUUw"
      }
    ],
    "iv":"FoJ5uPIR6HDPFCtD",
    "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE",
    "tag":"TMRcEPc74knOIbXhLDJA_w"
  }
}