KR20220137788A - 암호화된 사용자 데이터 송신 및 저장 - Google Patents

암호화된 사용자 데이터 송신 및 저장 Download PDF

Info

Publication number
KR20220137788A
KR20220137788A KR1020227033687A KR20227033687A KR20220137788A KR 20220137788 A KR20220137788 A KR 20220137788A KR 1020227033687 A KR1020227033687 A KR 1020227033687A KR 20227033687 A KR20227033687 A KR 20227033687A KR 20220137788 A KR20220137788 A KR 20220137788A
Authority
KR
South Korea
Prior art keywords
data
key
keys
input
lock
Prior art date
Application number
KR1020227033687A
Other languages
English (en)
Other versions
KR102649209B1 (ko
Inventor
어윤호
Original Assignee
너츠 홀딩스 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 너츠 홀딩스 엘엘씨 filed Critical 너츠 홀딩스 엘엘씨
Priority to KR1020247008644A priority Critical patent/KR20240038828A/ko
Publication of KR20220137788A publication Critical patent/KR20220137788A/ko
Application granted granted Critical
Publication of KR102649209B1 publication Critical patent/KR102649209B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Power Engineering (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Seeds, Soups, And Other Foods (AREA)
  • Footwear And Its Accessory, Manufacturing Method And Apparatuses (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Input From Keyboards Or The Like (AREA)

Abstract

데이터를 처리하는 방법은 적어도 하나의 프로세서가 데이터 저장 유닛을 평가하는 단계를 포함하며, 상기 데이터 저장 유닛은 적어도 하나의 입력 데이터 객체 및 상기 적어도 하나의 입력 데이터 객체에 대해 수행될 적어도 하나의 변환 명령을 제공한다. 상기 적어도 하나의 변환 명령은 상기 데이터 저장 유닛에 저장될 적어도 하나의 출력 데이터 객체를 생성하기 위해 상기 적어도 하나의 입력 데이터 객체에 대해 포워드 모드로 동작한다.

Description

암호화된 사용자 데이터 송신 및 저장 {Encrypted userdata transit and storage}
본 출원은 2016년 9월 15일자로 출원된 미국 가출원 제62/395,084호에 기초하여 우선권을 주장하며, 상기 가출원의 전체 내용은 본 명세서에 참고로 포함된다.
컴퓨터 소프트웨어 디자인의 데이터 중심 모델은 사용자 데이터가 응용 프로그램들 보다 우선화될 수 있는 곳이다. 데이터 중심 소프트웨어 설계는 데이터가 저장 지점에 안전하게 보관될 수 있게 할 수 있다. 데이터의 컨테이너화는 데이터 중심 설계의 일 실시예일 수 있다. 이 개시서 내에서 다양한 개념들이 구현될 수 있는 방법을 보여주기 위해, 서로 다른 관점의 일련의 도면들은 탐구되는 특정 개념들을 강조 표시하고 그리고 통합 도면들은 이러한 프로세서들 및 구조들 중 몇 가지가 함께 작동하는 방법을 보여준다.
데이터의 컨테이너화는 계층화 접근법(layered approach)으로 제공될 수 있으며, 선호되는 경우, 각각의 계층은 부분적으로 또는 전체가 이전 계층에 구축되거나 또는 이전 계층과 함께 작동할 수 있다. 제1 계층에 대해 본원에 설명된 개념들, 방법들, 장치들, 실시예들 및/또는 스펙들(specifications)은 총괄적으로 Structured Data Folding with Transmutations 또는 SDFT(Structured Data Folding with Transmutations)라 불릴 수 있다. 제1 계층을 포함할 수 있는 제2 계층에 대해 본원에 설명된 개념들, 방법들, 장치들, 실시예들 및/또는 상술들은 총괄적으로 eNcrypted User data Transit & Storage 또는 NUTS(eNcrypted User data Transit & Storage)라 불릴 수 있다. 각 계층의 임의의 조합은 부분적으로 또는 전체적으로 이용되어 Nut(Nut)라고 하는 데이터용 컨테이너를 구성할 수 있으며, 그리고 각 계층은 부분적으로 또는 전체적으로 격리되어 이용될 수 있다. 이러한 두 개의 계층들의 상호작용(interplay) 및/또는 인터위빙(interweaving)은 중요하고 그리고/또는 복잡할 수 있으며, 이러한 계층들의 명확한 구분(demarcation)에 대해 어려움을 제기할 수 있다. 따라서, 이러한 계층들은 본 명세서에서 함께 제시된다. 그 다음, Nut 컨테이너는 그 안에 포함된 데이터에 대한 논리 연산들을 허용할 수 있는 다양한 데이터 중심 특성들이 주입될 수 있다. Nut(Nut)라 불리는 저장 유닛에, 사용자의 프라이버시, 보안, 편의 및/또는 기능들을 제공하기 위해 어떤 데이터 지향 논리 연산들이 어떻게 재-정의되고 재구성될 수 있는지를 보여주기 위해 다양한 실시예들이 설명될 수 있다.
본 발명은 암호화된 사용자 데이터 송신 및 저장을 위한 방안을 제공하려고 한다.
본 발명은 암호화된 사용자 데이터 송신 및 저장을 위한 방안을 제공하려고 한다.
다양한 실시예들이 다음의 상세한 설명 및 첨부 도면들에 개시될 수 있다.
도 1은 상이한 암호 키(cipher key) 유형들을 나타내기 위해 사용되는 기호들의 표를 도시한다.
도 2는 상이한 암호 방법들에 의해 전형적으로 수행될 수 있는 데이터 입력, 데이터 출력 및 논리 연산을 도시하는 단순화된 흐름도를 도시한다.
도 3은 본 개시서의 실시예들이 기능할 수 있는 일반적인 네트워크 레이아웃의 예를 도시한다.
도 4는 본 개시서의 실시예들이 기능할 수 있는 컴퓨팅 기기의 예를 도시한다.
도 5는 포워드 모드 또는 정상 동작에서의 변환(transmutation)의 예를 도시한다.
도 6은 공통 데이터 연산들 및 이들의 변환 분류들(transmutation classifications)의 표를 도시한다.
도 7은 리버스 모드에서의 변환의 예시를 도시한다.
도 8은 비가역적 변환의 예를 도시한다.
도 9는 조건부 가역 변환의 예를 도시한다.
도 10은 변환 유형에 의해 그룹화된 일반적인 데이터 연산들 및 함수들의 표를 나타낸다.
도 11은 Python v3에서 정의된 코덱들의 표를 도시한다.
도 12는 추가적인 변환 정의들을 나열하는 표를 도시한다.
도 13은 변환 가역성 매트릭스(transmutation reversibility matrix)를 도시한다.
도 14는 변환 모달 동작 매트릭스(transmutation modal action matrix)를 도시한다.
도 15는 직렬화 변환(serialize transmutation)의 상세한 예를 도시한다.
도 16은 다이제스트 변환(digest transmutation)의 상세한 예를 도시한다.
도 17은 검증(verification)으로서 알려진 리버스 모드의 다이제스트 변환의 상세한 예를 도시한다.
도 18은 암호 변환의 설명을 도시한다.
도 19는 salsa20 (scipher) 변환의 예를 도시한다.
도 20은 salsa20 (scipher) 변환의 상세한 예를 도시한다.
도 21은 변환들을 직렬화하고 압축하기 위한 명령 스펙들의 표, 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트를 도시한다.
도 22는 인코드 변환을 위한 명령 스펙들의 표, 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트를 도시한다.
도 23은 다이제스트 변환을 위한 명령 스펙들의 표, 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트 도시한다.
도 24는 acipher 및 dign 변환들을 위한 명령 스펙들의 표, 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트 도시한다.
도 25는 derive 변환을 위한 명령 스펙들의 표, 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트 도시한다.
도 26은 scipher 변환을 위한 명령 스펙들의 표(2602), 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트(2604)를 도시한다.
도 27은 두 단계들의 시퀀스에서의 scipher 출력 스트링에 대한 출력 구조 포맷을 도시하며, 단계 1은 입력 포맷을 나타내고 단계 2는 출력 포맷을 나타낸다. "헤더"는 출력 메시지에 대한 scipher 변환의 가변 길이 키-값 utf8로 인코딩된 파라미터 스트링이다.
도 28은 scipher 변환의 출력 구조 포맷에서의 헤더 스트링에 대한 파라미터 키워드들 및 스펙들의 표를 도시한다.
도 29는 AEAD 모드 scipher 변환을 위한 반복적인 임베디드된 메시지 캡슐화의 예를 도시한다.
도 30은 lock 변환을 위한 명령 스펙들의 표(3002), 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트(3010)를 도시한다.
도 31은 다양한 변환 구조들의 스펙들을 표 형식으로 도시한다.
도 32는 mobius 변환을 위한 명령 스펙들의 표를 도시한다. 그것의 사용법이 도시되며, 그리고 그래픽은 다양한 구조들에 적용할 수 있는 구조적 변화를 보여준다. 매트릭스는 mobius 변환이 작동할 수 있는 구조 유형/모드 유효 동작들을 도시한다.
도 33은 press, clean 및 key 변환들에 대한 명령 스펙들의 표(3302, 3304), 그리고 그것의 사용법을 나타내는 예시적 변환 명령들의 세트를 도시한다.
도 34는 Key Interchange Specification Structure 또는 KISS(Key Interchange Specification Structure)에 대한 표를 도시한다.
도 35는 KISS 동작 모드들에 대한 표(3502), 키 유형들/필드 생성 매핑들을 나타내는 매트릭스(3504), 그리고 키 유형 정의들을 나타내는 표(3506)를 도시한다.
도 36은 TAR의 구조 및 TAR 정의들의 예들을 도시한다.
도 37은 변환 관련 속성들이 지속되는 곳을 도시하는 블록도들, 그리고 속성들의 유형 및 위치들을 열거하는 표를 도시한다.
도 38은 SDFT 동작 라벨(ravel) 및 언라벨(unravel)(또는 라벨의 리버스)의 블록도들을 도시한다.
도 39는 SDFT 라벨 동작의 흐름도를 도시한다.
도 40은 SDFT 언라벨 동작의 흐름도를 도시한다.
도 41은 일반적인 TAR에 대해 TAR 리버스가 수행되는 방법을 도시한다.
도 42는 TAR 리버스들의 예들을 도시한다.
도 43은 TAR 프로세싱 동안 생성 또는 요구할 수 있는 키 유형 템플릿에 매핑되는 변환들의 표를 도시한다.
도 44는 TAR 예들 그리고 각각으로부터 생성된 키 템플릿들을 도시한다.
도 45는 TAR 예들 그리고 각각으로부터 생성된 키 템플릿들, 그리고 입력(put)되거나 또는 생성(gen)될 KISS 구조들의 예상 목록을 도시한다. KISS들의 목록은 키 스택(keystack)이라고도 한다.
도 46은 SDFT TAR 프로세싱 내의 3 가지 키 스택 동작 모드들을 도시한다 : 생성(gen), 입력(put) 및 주입(mixed).
도 47은 데이터 및 그것의 TAR의 라이프 사이클에서 키 스택들이 어떻게 생성되고 사용될 수 있는지를 도시한다.
도 48은 NSstr 구조에 저장된 데이터에서 발생할 수 있는 동작들의 예를 도시한다.
도 49는 데이터를 반복적으로 폴딩하기 위한 SDFT 사용의 흐름도를 도시한다.
도 50은 데이터를 반복적으로 언-폴딩(unfolding)하기 위한 SDFT 사용의 흐름도를 도시한다.
도 51은 SDFT API/라이브러리 및 그것이 액세스할 수 있는 다양한 유형의 TAR 정의 파일들의 예를 도시한다.
도 52는 수동 데이터 폴딩을 수행하기 위한 예시적인 Python 스크립트를 도시한다.
도 53은 TAR 정의의 SDFT 예 그리고 그 사용예를 Python 스크립트로 도시한다.
도 54는 단일 통신 세션 내의 동적 TAR 스위칭의 블록도들을 도시한다.
도 55는 Nut ID를 생성하기 위한 예시적인 프로세스의 흐름도를 도시한다.
도 56은 Nut ID들 및 Lock ID들이 Nut 내에서 사용될 수 있는 곳을 도시하는 블록도들이다.
도 57은 Nut ID들, 경로 이름들 및 페이로드 데이터 간의 예시적 관계들을 도시한다.
도 58은 논리 섹션들(Nut Lock 및 Nut Parts)을 포함하는 Nut 또는 Lock 그래프의 일 실시예의 블록도를 도시한다.
도 59는 3 개의 키홀(Keyhole) Lock 노드들을 포함하는 Nut의 Nut Lock의 대안 실시예의 블록도를 도시한다.
도 60은 Lock Node의 내부 데이터 구조들의 블록도를 도시한다.
도 61은 도 60에 도시된 Lock Node의 입력 섹션의 내부 데이터 구조들의 블록도를 도시한다.
도 62는 유효한 기본 키(Primary Key)가 키홀에 삽입될 수 있을 때 도 61에 도시된 입력 섹션의 기본 키홀의 내부 데이터 구조들의 관계를 도시하는 데이터 흐름도를 도시한다.
도 63은 임의의 Lock Node 및 임의의 암호 키에 대한 키 삽입 프로세스의 흐름도를 도시한다.
도 64는 3 개의 기본 키들이 기본 키홀에 삽입될 수 있는 예를 도시한다.
도 65는 도 64에 도시된 예에서부터 계속되는 Variable Lock 해독 동작의 데이터 흐름도를 도시한다.
도 66은 도 64에 도시된 예에서부터 계속되는 Variable Lock 암호화 동작의 데이터 흐름도를 도시한다.
도 67은 임의의 Lock Node에서 이용 가능한 Variable Lock 유형들 및 그들의 특성들의 표를 도시한다.
도 68은 ORLOCK 해독 동작의 데이터 흐름도를 도시한다.
도 69는 Nut 소유자에 의한 ORLOCK 암호화 동작의 데이터 흐름도를 도시한다.
도 70은 MATLOCK 해독 동작의 데이터 흐름도를 도시한다.
도 71은 Nut 소유자에 의한 MATLOCK 암호화 동작의 데이터 흐름도를 도시한다.
도 72는 XORLOCK 해독 동작의 데이터 흐름도를 도시한다.
도 73은 Nut 소유자에 의한 XORLOCK 암호화 동작의 데이터 흐름도를 도시한다.
도 74는 HASHLOCK 해독 동작의 데이터 흐름도를 도시한다.
도 75는 Nut 소유자에 의한 HASHLOCK 암호화 동작의 데이터 흐름도를 도시한다.
도 76은 SSLOCK 복호화 동작의 데이터 흐름도를 도시한다.
도 77은 Nut 소유자에 의한 SSLOCK 암호화 동작의 데이터 흐름도를 도시한다.
도 78은 Nut 강조 Stratum Key들의 블록도를 도시한다.
도 79는 Stratum Key가 Nut 내에 어떻게 삽입될 수 있는지에 대한 흐름도를 도시한다.
도 80은 2개의 역할 그리고 4 명의 역할 플레이어들에 대한 키-기반 승인(Key Based Permissions)의 테이블을 도시한다.
도 81은 각각의 부분이 Lock Node에 의해 표현될 수 있는 예시적 Nut의 다양한 Nut 부분들을 열거한 표를 도시한다.
도 82는 일반적인 Nut에 대해 정의된 키 기반 승인 액세스 역할들을 나열하는 표를 도시한다.
도 83은 AAKSUK(Access Attribute Key Set Unlock Keys)라고 불리는 Nut 액세스 제어 액세스 키들의 초기 세트가 각각의 유효한 기본 키에 대한 액세스 키홀에 삽입될 수 있는 방법의 블록도를 도시한다.
도 84는 외부 Lock 노드들로부터 내부 Lock 노드들로의 NAC 액세스 속성들의 전파의 블록도를 도시한다.
도 85는 외부 Lock 노드들로부터 내부 Lcok 노드들로의 NAC 액세스 속성들의 전파, 그리고 링크된 Lock 노드의 기본 키홀로의 출력 링크 키의 삽입의 블록도를 도시한다.
도 86은 액세스 키홀에 키들을 삽입하기 위한 흐름도를 도시한다.
도 87은 대안 실시예에 대한 키 기반 승인들의 표를 도시한다.
도 88은 Lock 노드의 내부 해독 데이터 흐름의 데이터 흐름도를 도시한다.
도 89는 Nut를 잠금해제하기 위한 흐름도를 도시한다.
도 90은 NUTS 기반 시스템의 실시예의 블록도, 그리고 Nut에 저장된 문서가 어떻게 잠금 해제될 수 있는지를 도시한다.
도 91은 Nut의 페이로드를 보유하고 있는 Nut의 Nut ID에 의해 Nut의 페이로드를 참조하기 위한 NUTS 용어(parlance)의 일반적인 사용예를 도시한다. 여기서, 암호 키는 그것을 보유하고 있는 Nut의 Nut ID에 의해 참조될 수 있다.
도 92는 수신자 잠금 모델(recipient locking model)의 리스트의 단순화된 실시예를 도시한다.
도 93은 순서화된 로킹 모델(ordered locking model)의 단순화된 실시예를 도시한다.
도 94는 마스터 키를 갖는 순서화된 잠금 모델의 단순화된 실시예를 도시한다.
도 95는 마스터 키를 갖는 잠금 모델의 단순화된 실시예를 도시한다.
도 96은 마스터 키를 갖는 잠금 모델의 단순화된 실시예를 도시한다.
도 97은 대여금고(safe deposit box) 잠금 모델의 단순화된 실시예를 도시한다.
도 98은 마스터 키를 갖는 비밀 공유 잠금 모델의 단순화된 실시예를 도시한다.
도 99는 "PrivaTegrity" 유형 잠금 모델의 단순화된 실시예를 도시한다.
도 100은 다수의 페이로드들이 단일 Nut 내에 저장될 수 있는 다중 Nut 구성의 단순화된 실시예를 도시한다.
도 101은 다수의 페이로드들이 단일 Nut 내에 저장될 수 있는 다중 Nut 구성의 단순화된 실시예를 도시한다.
도 102는 다중 페이로드들을 갖는 직접 잠금 모델의 단순화된 실시예를 도시한다.
도 103은 공모 방지 설계(collusion resistant design)를 나타내는 순서화된 메시지 전달의 단순화된 실시예를 도시한다.
도 104는 모듈러 I/O의 전형적인 구성요소들의 블록도를 도시한다.
도 105는 MIOR을 이용한 간단한 읽기 및 쓰기 동작의 예를 도시한다.
도 106은 전형적인 MIO 파일 판독 동작에 포함될 수 있는 데이터 변환 및 전송을 도시한다.
도 107은 모듈러 I/O를 사용하여 파일 포맷들의 하위 호환성(backward compatibility)을 용이하게 할 수 있는 방법을 도시한다.
도 108은 모듈형 I/O를 사용하여 파일 포맷들의 상위 호환성(forward compatibility)을 용이하게 할 수 있는 방법을 도시한다.
도 109는 모듈러 I/O를 사용하여 모듈러 디스플레이를 용이하게 할 수 있는 방법을 도시한다.
도 110은 모듈러 I/O를 사용하여 모듈러 애플리케이션을 용이하게 할 수 있는 방법을 도시한다.
도 111은 2번의 편집(edit)에 걸친 그리고 3 개의 시점에서의 Nut 히스토리에 대한 점진적인 변화를 도시한다.
도 112는 도 111로부터의 이벤트 과정 동안 Nut Log에 대한 점진적인 변화를 도시한다.
도 113은 관계 기반 키들이 Alice와 Bob의 연락처 카드(contact card)들에 어떻게 표현될 수 있는지를 도시한다.
도 114는 잘 알려진 이메일 주소들 및/또는 RBK들을 사용하여 SPAM이 검출될 수 있는 방법의 흐름도를 도시한다.
도 115는 익명 이메일 주소들 및/또는 RBK들을 사용하여 SPAM이 검출될 수 있는 방법의 흐름도를 도시한다.
도 116은 Alice-Bob RBK 통신 채널의 결정론적 문맥 기반 상태 매트릭스(Deterministic Context Based Status Matrix)를 도시한다.
도 117은 Alice-판매자(vendor) RBK 통신 채널의 결정성 문맥 기반 상태 매트릭스(Deterministic Context Based Status Matrix)를 도시한다.
도 118은 판매자-Alice RBK 통신 채널의 결정성 문맥 기반 상태 매트릭스(Deterministic Context Based Status Matrix)를 도시한다.
도 119는 Bob에 대한 손상된 시스템에서의 RBK 관계의 격리(isolation)를 도시한다.
도 120은 사전-패키징된 데이터 Nut들의 블록도를 도시한다.
도 121은 RBK들을 사용하는 자동화된 등록 프로세스에서의 이벤트들의 시퀀스를 차트로 나타낸 것이다.
도 122는 RBK들 및 익명의 이메일 주소들을 사용하는 자동 등록 프로세스의 이벤트들의 순서를 차트로 나타낸 것이다.
도 123은 NUTS 코어 애플리케이션들 및 그것들의 설명들(description)을 나열하는 표를 도시한다.
도 124는 컴퓨터 기기에서 실행중인 NUTS 코어 애플리케이션들의 블록도를 도시한다.
도 125는 사용자 기기에서 실행중인 NUTserver의 블록도를 도시한다.
도 126은 NUT서버를 포함하는 내부 구성요소들 및 사용자 기기의 환경에 대한 그들의 기능적 연결들의 블록도를 도시한다.
도 127은 NoSQL 데이터베이스를 캐싱 메커니즘(caching mechanism)으로 사용하는 도 126에 도시된 NUTserver의 다른 실시예를 도시한다.
도 128은 MIOR 서버 네트워크 레이아웃의 블록도를 도시한다.
도 129는 MIOR 서버 애플리케이션 레이아웃의 블록도를 도시한다.
도 130은 MIOR 서버로부터 MIO 모듈들을 가져오기 위한 흐름도를 도시한다.
도 131은 MIOR 캐시의 구성을 나타내는 블록도를 도시한다.
도 132는 사용자 기기 환경에서의 NUTbrowser 애플리케이션의 블록도를 도시한다.
도 133은 사용자 기기 환경에서의 NUTbook 애플리케이션의 블록도를 도시한다.
도 134는 사용자 기기 환경에서의 Nut 프로세싱 애플리케이션 프레임워크의 블록도를 도시한다.
도 135는 NUTbook을 포함하는 내부 컴포넌트들을 도시하는 블록도를 도시한다.
도 136은 도 135의 NUTbook 카탈로그 캐시의 내부 구성을 나타내는 블록도를 도시한다.
도 137은 계층적 패스워드들의 구성을 도시하는 다이어그램을 도시한다.
도 138은 도 137의 계층적 패스워드에 따라 메인 패스워드가 개인 문서를 여는 방법을 도시한다.
도 139는 도 137의 계층적 패스워드 및 도 138의 문서에 따라 마스터 패스워드가 개인 문서를 여는 방법을 도시한다.
도 140은 도 137의 계층적 패스워드에 따라 메인 및 업무 패스워드들이 업무 문서를 여는 방법을 도시한다.
도 141은 도 137의 계층적 패스워드 및 도 140의 문서에 따라 마스터 패스워드가 업무 문서를 여는 방법을 도시한다.
도 142는 도 135의 NUTbook 키 캐시의 내부 구성을 나타내는 블록도를 도시한다.
도 143은 NUTbook이 카드 카탈로그를 볼 수 있는 방법에 대한 흐름도를 도시한다.
도 144는 NUTS 기반 서비스들의 표를 도시한다.
도 145는 NUTS 기반 서비스들의 네트워크 레이아웃을 도시한다.
도 146은 NUTmail 서버의 네트워크 레이아웃을 도시한다.
도 147은 RBK들을 사용하는 NUTmail과 같은 익명의 이메일 서비스에 대한 자동화된 등록 프로세스의 이벤트 순서를 차트화한다.
도 148은 NUTmail 서버에서 통신 채널을 추가할 때 이벤트들의 시퀀스를 차트화한다.
도 149는 Alice와 Bob이 NUTmail을 통해 서로 이메일을 전송할 때 이벤트들의 시퀀스를 차트화한다.
도 150은 NUTchat 서버의 네트워크 레이아웃을 도시한다.
도 151은 NUTchat 서버에 의해 호스팅되는 3 개의 채팅 세션들의 데이터 흐름도를 도시한다.
도 152는 NUT서버들을 통한 채팅 히스토리 지속성 및 복제의 데이터 흐름도를 도시한다.
도 153은 상이한 채팅 ID들 또는 채팅 서비스들을 사용하는 3 개의 개별 채팅 세션들에 대한 데이터 흐름도를 도시한다.
도 154는 도 153의 3 개의 상이한 채팅 경로들을 사용하여 NUTchat 클라이언트에 의해 관리되는 경로에 관계없는(path agnostic) 대화에 대한 데이터 흐름도를 도시한다.
도 155는 NUTcloud 서버의 네트워크 레이아웃을 도시한다.
도 156은 NUTnet 서버의 네트워크 레이아웃을 도시한다.
도 157은 NUTS의 인터넷(Internet of NUTS; IoN)을 위한 NUThub 서버의 네트워크 레이아웃을 도시한다.
도 158은 직접 IoN 네트워크 토폴로지를 도시한다.
도 159는 간접 IoN 네트워크 토폴로지를 도시한다.
도 160은 NUT서버 허브, 그리고 도 159의 NUThub와 IoN 기기들에 대한 NUT 서버 허브의 연결들을 도시한다.
도 161은 도 160의 NUT 서버 허브 내의 NUThub/IoN 인터페이스의 블록도를 도시한다.
도 162는 도 160의 IoN 기기의 NUThub/IoT 인터페이스의 블록도를 도시한다.
도 163은 IoN/IoT 기기들에 대한 등록 및 구성 프로세스의 흐름도를 도시한다.
도 164는 도 161 및 도 162의 원격 제어 인터페이스가 명령(Command) Nut들을 처리하는 방법에 대한 흐름도를 도시한다.
도 165는 NUTS 인증 서버의 네트워크 레이아웃을 도시한다.
도 166은 도 165의 NUTS 인증 서버의 기능들을 강조하는 블록도를 도시한다.
도 167은 NUTS 기반 WiFi/이더넷 라우터의 네트워크 레이아웃을 도시한다.
도 168은 도 167의 NUTS 기반 WiFi/이더넷 라우터에서 메시지들이 처리될 수 있는 방법에 대한 흐름도를 도시한다.
도 169는 NUTS 기반 WiFi/이더넷 라우터에 대한 기기 카테고리들의 표를 도시한다.
도 170은 NUTS 기반 WiFi/이더넷 라우터상의 예시적인 기기 카테고리 속성들의 표를 도시한다.
도 171은 애플리케이션 래핑(Application Wrapping)이 자동화된 방식으로 기기 백업 및 복제를 가능하게 하는 방법의 블록도를 도시한다.
도 172는 2 개의 기기들에서의 이벤트 처리 서비스(Event Processing Service; EPS)의 블록도를 도시한다.
도 173은 빅 데이터 서버들 상에 저장된 추적 쿠키들(tracking cookies) 및 세션 히스토리들을 사용할 수 있는 전형적인 판매자 네트워크 설정의 블록도를 도시한다.
도 174는 도 173의 빅 데이터 서버들에 저장되는 것뿐만 아니라 국부적으로 세션 히스토리들의 사본을 기록하기 위해 애플리케이션 Nut들을 사용할 수 있는 판매자 네트워크 설정의 블록도를 도시한다.
도 175는 도 173 및 도 174로부터의 애플리케이션 Nut들을 국부적으로 이용하여 수행될 수 있는 상황인식 컴퓨팅(Contextual Computing)의 블록도를 도시한다.
도 176은 IoT 기기들 및 서비스 제공자들을 포함하는 개인 홈 네트워크 토폴로지를 도시한다.
도 177은 판매자들로 나가는 데이터의 흐름을 제어하기 위해 간접 IoN 네트워크 토폴로지에서 2 개의 IoN 기기들 및 그것들의 각각의 서비스 제공자들을 포함하는 개인 홈 네트워크를 도시한다.
도 178은 상황인식 분석 애플리케이션(Contextual Analysis Apps)이 도 177의 NUT서버에서 사용자의 프라이버시를 보호하기 위해 출력되는 IoN 메시지들을 자동으로 필터링할 수 있는 방법의 블록도를 보여준다.
목차
● 기호 & 약어 (Symbols & Abbreviations)
● 암호 & 일방향 해시 (Ciphers & One Way Hashes)
● 네트워크 다이어그램 (Network Diagram)
● 기기 다이어그램 (Device Diagram)
● 변환 (Transmutations)
● 변환 유형 (Transmutation Types)
● 변환 구조 (Transmutation Structures)
● 변환 감사 기록 (Transmutation Audit Records; TAR)
● 변환을 통한 구조화된 데이터 폴딩 (Structured Data Folding with Transmutations; SDFT)
● Nut ID
● Lock 그래프 및 Lock 노드 (Lock Graphs and Lock Nodes)
○ 키홀 (Keyholes)
○ 가변 Lock (Variable Locks)
○ Stratum
○ Nut 액세스 제어 (Nut Access Control; NAC)
○ Lock 노드 순회 (Lock Node Traversal)
● 모듈형 I/O (Modular I/O)
○ 읽기와 쓰기 (Reading and Writing)
○ 하위 호환성 (Backward Compatibility)
○ 상위 호환성 (Forward Compatibility)
○ 디스플레이 (Display)
○ 애플리케이션 (Application)
● Nut 히스토리
● Nut Log
● 관계 기반 키들 (Relationship Based Keys; RBK)
● 익명 관계 (Anonymous Relationships)
● NUTS 코어 애플리케이션 (NUTS Core Applications)
○ Nutserver
○ MIOR 서버 (MIOR Server)
○ NUTbrowser/NUTshell
○ NUTbook
● NUTS 기반 서비스 (NUTS Based Services)
○ NUTmail
○ NUTchat
○ NUTcloud
○ NUTnet
○ NUThub
○ NUTS CertificationServer
● NUTS 기반 Wifi/Ethernet 라우터 (NUTS Based Wifi/Ethernet Router)
● 애플리케이션 래핑 (Application Wrapping)
● 이벤트 처리 서비스 (Event Processing Service)
● 상황인식 컴퓨팅 (Contextual Computing)
● 결론 및 철학 (Conclusion and Philosophy)
기호 & 약어 (Symbols & Abbreviations)
다음의 기호들 및 약어들이 설명 및 도면 전체에서 사용될 수 있다. (*)로 표시된 기호들 및 약어들은 NUTS에만 적용될 수 있다 :
● AAKS *Access Attribute Key Set
● AAKSUK *Access Attribute Key Set Unlock Key
● AAPK *Access Attribute Propagation Key
● acipher Asymmetric Cipher
● AEAD Authenticated Encryption with Associated Data
● AES Advanced Encryption Standard; also Rijndael
● API Application Programming Interface
● AKS *Access Key Set
● ARK *Access Role Key
● BIOS Basic Input/Output System
● bz2 bzip2, Burrows-Wheeler compression algorithm
● CA Certificate Authority
● CAC Cryptographic Access Control
● ChaCha20 symmetric key based stream cipher by Bernstein
● CLI Command Line Interface
● CMAC Cipher-based Message Authentication Code
● CODEC COder/DECoder; encoding scheme for character data
● COM Component Object Model
● COR *Class of Readers; or Reader
● CORBA Common Object Request Broker Architecture
● COW *Class or Writers; or Writer
● CPU Central Processing Unit
● CRC Cyclic Redundancy Check
● dign *(명사) a digital signature generated using an asymmetric private key
● dign *(동사) to create a digital signature using an asymmetric private key
● DK *Derived Key
● DRM Digital Rights Management
● DVD Digital Video Disk
● DSA Digital Signature Algorithm
● ECC Elliptic Curve Cryptography
● eDK *encrypted Derived Key
● EPS *Event Processing Service
● FIPS Federal Information Processing Standards
● HMAC Hash based Message Authentication Code
● GPS Global Positioning System
● GPU GraphicsProcessing Unit
● GUI Graphical User Interface
● GUID Globally Unique Identifier
● gzip GNU zip compression
● HKDF HMAC based Key Derivation Function
● ikm Initial key material
● IMEI International Mobile station Equipment Identity
● IoN *Internet of Nuts
● IoT Internet of Things
● IPC Inter Process Communication
● IPv4 Internet Protocol version 4
● IPv6 Internet Protocol version 6
● I/O Input/Output
● ima *KISS field name short for "I am a" or "I'm a": determines KISS mode
● iv Initialization Vector: random number for cryptographic use
● JSON JavaScript Object Notation
● KBP *Key Based Permissions
● Keccak SHA3 hash family
● KISS *Key Interchange Specification Structure
● LAN Local Area Network
● lock *Implementation of Variable Locks as a class of transmutations
● lzma Lempel-Ziv-Markov chain Algorithm
● MAC Media Access Control (w.r.t. Ethernet)
● MAC Message Authentication Code
● MD5 Message Digest #5 by Rivest
● MIO *Modular I/O
● MIOR *Modular I/O Repository
● MMS Multimedia Messaging Service
● NAC *Nut Access Control
● NCS *NUTS Certification Server
● NFC Near Field Communication
● NIST National Institute of Standards and Technology
● NoSQL Non Standard Query Language also non-relational Standard Query Language
● nonce Number only used ONCE: random number for cryptographic use
● NTFS New Technology File System (Microsoft)
● NUTS *eNcrypted Userdata Transit & Storage
● OAEP Optimal Asymmetric Encryption Padding by Bellare and Rogaway
● OS OperatingSystem
● PBKDF2 Password Based Key Derivation Function #2 by RSA (PKCS)
● PGP Pretty Good Privacy
● PIM Personal Information Manager
● PKCS Public Key Cryptography Standards by RSA Laboratories
● PKCS1_V1.5 Version 1.5 of PKCS #1
● PKI Public Key Infrastructure
● PSS Probabilistic Signature Scheme
● PUID Practically Unique ID
● QA Quality Assurance
● QUOPRI Quoted-Printable or QP encoding
● RAM Random Access Memory
● RAT *Root Access Tier, owner/creator of Nut also RAT Writer, owner
● RBAC Role Based Access Control
● RBCAC Role Based Cryptographic Access Control
*● RBK *Relationship Based Keys
● ROM Read Only Memory
● RSA Rivest-Shamir-Adleman public key cryptosystem
● SAC *Stratum Access Control
● Salsa20 symmetric key based stream cipher by Bernstein
● salt random number for cryptographic use
● scipher Symmetric Cipher
● SCP *Structured Cryptographic Programming
● SCRYPT a password based key derivation function by Percival
● SDF *Structured Data Folding
● SDFT *Structured Data Folding with Transmutations
● SHA Secure Hash Algorithm Keccak hash variant
● Shake Keccak hash variant
● SMS Short Message Service
● SOAP Simple Object Access Protocol
● SPAM unsolicited bulk email; also junk email
● SSD Solid State Drive
● SSID Service Set IDentifier
● SSO Single Sign On
● tar Tape Archive : Unix command to store data onto tape or disk
● TAR *Transmutation Audit Record
● TOP *Transmutations Organizing Principle
● tine *Shamir's Secret Sharing share, like tines on a fork
● TMX *Transmutation
● TOP *Transmutations Organizing Principle
● URL Uniform Resource Locator
● UTF Unicode Transformation Format
● UTI Uniform Type Identifier
● UUID Universally Unique Identifier
● VPN Virtual Private Network
● WAN Wide Area Network
● WiFi WLAN protocol
● WLAN Wireless LAN
● XML eXensible Markup Language
● Zlib zlib compression algorithm
도 1은 본 발명의 설명 및 도면 전체에 걸쳐 사용될 수 있는 암호 키 유형들 및 그 각각의 기호들의 표를 도시한다. 가변 길이 텍스트 기반 패스워드 또는 패스프레이즈는 기호(102)에 의해 표현될 수 있다. 기호(104)는 AES-256 또는 대체 암호를 포함하는 대칭 암호에 대한 키를 나타낸다. 기호(106)는 RSA-2048 또는 대체 암호를 포함하는 비대칭 암호에 대한 키 쌍을 나타낸다. 비대칭 키 쌍(106)의 공개 부분은 기호(10)로 도시될 수 있고, 그리고 개인 부분은 기호(110)로 도시될 수 있다. 당해 기술 분야의 통상의 지식을 가진 자는 이러한 암호들이 잘 알려져 있고 잘 테스트된 알고리즘들일 수 있으며, 그리고 표준이 변경되거나 대안이 요구될 수 있을 때 이러한 방법들이 본 개시서에서 특정될 수 있는 경우 다른 적절한 방법들이 대체될 수 있다는 것을 쉽게 인식할 수 있다.
암호 & 일방향 해시 (Ciphers & One Way Hashes)
도 2는 다양한 유형의 암호들에 의해 수행될 수 있는 기본 동작들을 나타낸다. 암호화 모드의 대칭 암호(208)는 대칭 키(202) 및 데이터(204)를 수용하여 암호화된 데이터(206) 또는 암호문을 생성할 수 있다. 해독 모드의 대칭 암호(208)는 동일한 대칭 키(202) 및 암호문(206)을 수용하여 원래의 데이터(204)를 생성할 수 있다. 대칭 암호의 구현에서, 암호화 및 해독 방법들은 두 개의 개별적으로 명명된 함수 호출일 수 있으며, 또는 입력들의 일부로서 모드 매개변수를 갖는 단일 호출일 수 있다. 대칭 암호의 특성은 암호화 및 복호 프로세스들 모두가 동일한 비밀 키(202)를 이용할 수 있다는 것이다.
암호화 모드의 비대칭 암호(214)는 비대칭 키 쌍(210) 및 데이터(204)의 공개 부분(public portion)을 수용하여 암호화된 데이터(212) 또는 암호문을 생성할 수 있다. 해독 모드의 비대칭 암호(214)는 비대칭 키 쌍(216) 및 암호문(212)의 개인적인(private) 부분을 수용하여 원래의 데이터(204)를 생성할 수 있다. 비대칭 암호의 구현들에서, 암호 및 해독 방법들은 두 개의 개별적으로 명명된 함수 호출일 수 있거나 또는 입력들의 일부로서 모드 파라미터를 갖는 단일 호출일 수 있다. 비대칭 암호의 특성은 암호화 및 해독 프로세스들이 키 쌍의 상이한 부분들을 활용할 수 있다는 것이다. RSA-2048과 같은 구현에서, 공개 키는 수학적 관계를 사용하여 개인 키에서 파생될 수 있으므로, RSA-2048 개인 키는 키 쌍과 동의어가 될 수 있으며, 공개 키는 그로부터 추출될 수 있다.
서명 모드의 디지털 서명 방법(222)은 디지털 서명(220)을 생성하기 위해 비대칭 키 쌍(216) 및 암호문(218)의 개인적인 부분을 수용할 수 있다. 인증 모드에서 디지털 서명 방법(222)은 비대칭 키 쌍(210), 디지털 서명(220) 및 암호문(218)의 공개 부분을 수용하여 디지털 서명이 상기 암호문(218)과 비대칭 키 쌍의 개인적인 부분(216)을 사용하여 생성되었는지 여부를 인증할 수 있다. 디지털 서명 방법의 구현들에서, 서명 및 인증 방법들은 두 개의 개별적으로 명명된 함수 호출들일 수 있으며, 또는 입력들의 일부로서 모드 파라미터들이 있는 단일 호출일 수 있다. 디지털 서명 방법의 특성은 서명 및 인증 프로세스들이 키 쌍의 서로 다른 부분들을 활용할 수 있다는 것이다. RSA-2048 키 쌍들을 기반으로 하는 디지털 서명 방법과 같은 구현에서, 공개 키는 수학적 관계를 사용하는 개인 키로부터 파생될 수 있으므로, RSA-2048 개인 키는 키 쌍과 동의어가 될 수 있으며, 그리고 공개 키는 그로부터 추출될 수 있다. 간결성과 간명함을 위해, 이 문서는 디지털 서명을 dign으로 상호 교환적으로 언급할 수 있으며, 데이터의 일부를 디지털 방식으로 서명하는 행위는 digning으로 상호 교환적으로 언급될 수 있으며, 데이터의 일부를 디지털 방식으로 서명한 것은 digned으로 상호 교환적으로 언급될 수 있다.
디지털 서명 방법은 메시지 인증 코드 또는 MAC 유형일 수 있다. MAC들은 데이터에 일방향 해시 알고리즘들을 사용하여 생성될 수 있다. SHA-512와 같은 해시 방법은 최대 512 비트 기리일 수 있는 메시지 다이제스트를 생성하기 위해 데이터 콘텐츠를 수용할 수 있다. SHA-512와 같은 방법들을 사용하는 MAC의 인증은 상기 데이터 조각에 대해 MAC을 재계산하고 동일성에 대해 제공된 MAC과 계산된 MAC을 비교하는 것을 수반한다. 키 해시 메시지 인증 코드 또는 HMAC(hash message authentication code)로 알려진 기술은 데이터 콘텐츠와 함께 암호화 키의 추가 입력을 받아 HMAC 값을 생성할 수 있다.
디지털 서명 방법들 및/또는 해싱 방법들은 각각의 데이터를 나타낼 수 있는 메시지 다이제스트들을 생성하기 위해 본 개시 내용의 다양한 부분들에서 사용될 수 있다.
네트워크 다이어그램(network diagram)
도 3은 본 개시서의 다양한 실시예들이 부분적으로 또는 전체적으로 적용될 수 있는 단순화된 네트워크 다이어그램을 나타낸다. 광역 네트워크(WAN)(302)는 사용자 또는 회사에 단순화된 네트워크 클라우드 뷰를 제공하기 위해 함께 동작하는 다양한 원격 통신 센터들에 다수의 서버들, 라우터들 및 스위칭 시스템들을 포함할 수 있는 네트워크 클라우드로서 표현될 수 있다. 클라우드 서비스들(304)은 또한 클라우드 스토리지 및 클라우드 프로세싱과 같은 네트워크 서비스들을 제공할 수 있는 다양한 상업 시스템을 나타내는 클라우드로서 그림으로 단순화될 수 있다; 이러한 서비스들은 자체 사양으로 구현될 수 있지만, 서버 팜, 스토리지 배열 및 라우터의 많은 인스턴스들을 포함할 수 있다. 개인 라우터(306)는 WAN(302)에 접속될 수 있으며, 개별 사용자들에게, 사용자가 가질 수 있는 다수의 네트워크 접속 가능 기기들(308-318) 사이에 네트워크에 대한 액세스를 제공할 수 있다. 사용자는 다이어그램에 묘사된 기기들에 국한되지 않고, 동일한 네트워크 또는 인터넷을 통해 다른 기기들에 액세스하기 위해 라우터를 이용할 수 있는 임의의 기기를 사용할 수 있다. 라우터(306)는 인터넷 서비스 제공자에 대한 전용 라우팅 기기일 수 있으며, 또는 라우팅 및/또는 LAN 및/또는 WLAN 성능을 제공하는 조합 기기(combination device)일 수 있으며, 게이트웨이로 지칭될 수 있다. 기업 라우터(corporate router)(320)는 WAN(302)에 접속될 수 있으며, 기관 사용자들(institutional user)에게, 회사가 가질 수 있는 다수의 네트워크 접속 가능 기기들(302-330) 사이에 인터넷에 대한 액세스를 제공할 수 있다. 회사는 다이어그램에 묘사된 기기들에 국한되지 않고, 동일한 네트워크 또는 인터넷을 통해 다른 기기들에 액세스하기 위해 라우터를 이용할 수 있는 임의의 기기를 사용할 수 있다. 라우터(320)는 인터넷 서비스 제공자에 대한 전용 라우팅 기기일 수 있으며, 또는 라우팅 및/또는 LAN 및/또는 WLAN 성능을 제공하는 상호 연결된 관리형 라우터들의 세트일 수 있으며, 게이트웨이 및/또는 인트라넷으로 지칭될 수 있다. 본원에서 다양한 실시예들에서 설명된 시스템 및 방법은 이 네트워크 다이어그램의 일부 또는 전부에 사용되어 적용될 수 있다.
기기 다이어그램(Device Diagram)
일반적인 컴퓨팅 기기(400)가 도 4에 도시되어 있다. 프로세싱 유닛(404)은 시스템 버스(402)에 접속될 수 있으며, 시스템 버스(402)는 기기 내의 일부 또는 모든 내부 통신 및 데이터 전달을 용이하게 할 수 있다. 이용 가능한 여러 종류의 시스템 버스들이 존재할 수 있지만, 간략화를 위해 시스템 버스(402)라고 총괄적으로 지칭될 수 있다. 프로세싱 유닛은 단일 또는 멀티 코어 프로세서뿐만 아니라 GPU 보드 및 블레이드 서버와 같은 다양한 특수 프로세싱 보드에 있는 것과 같은 프로세서들의 어레이들을 나타낼 수 있다. 시스템 버스에 의해 서비스되는 다른 컴포넌트들은 네트워크 어댑터들(412); I/O 인터페이스들(410); 디스플레이 인터페이스들(414); BIOS 프로그램(408)을 저장할 수 있는 ROM(Read Only Memory)(406); 실행 중인 운영체제(418), 실행 중인 애플리케이션(420) 및/또는 애플리케이션 데이터(422)를 임시로(ephemerally) 저장할 수 있는 비휘발성 메모리 RAM(416); 및 설치된 운영체제(428), 애플리케이션(430) 및/또는 데이터 파일들(432)을 집합적으로 지속적으로 저장할 수 있는 하드드라이브, SSD 및 플래시 드라이브(426) 같은 비-휘발성 메모리(424)를 포함할 수 있다.
본 개시서의 일부 또는 모든 실시예들이 적용 가능하고 기능적이기 위해 도시된 컴퓨팅 기기의 모든 컴포넌트들이 필요하지 않을 수 있다. 예를 들어, 기기들은 일부 IoT 기기들에서 발견되는 것들과 같은 물리적 디스플레이나 I/O 인터페이스들을 가지지 않을 수 있으며, 라우터들 및 게이트웨이들은 물리적 하드디스크를 거의 활용하지 못할 수 있다. NUTS 지원 및 호환성에 필요한 요구사항은 처리 유닛, 일부 형식의 저장소 및 시스템 버스를 포함할 수 있는 NUTS 호환 소프트웨어를 실행할 수 있는 능력일 수 있다.
변환(Transmutations)
변환은 컴퓨터 프로그래밍에서 발견되는 많은 알려진 데이터 조작 작업을 구성하는데 선호되는 방법일 수 있다. NUTS는 이를 TOP(Transmutations Organizing Principle)로 지정할 수 있다. 뿐만 아니라, 어떠한 체계적인 데이터 조작 작업도 TOP를 사용하여 분석될 수 있으며, 변환 유형으로 분류될 수 있다. 그런 다음, 변환은 SDFT(Structured Data Folding with Transmutations)라 불릴 수 있는 TOP의 프레임 워크 내에서 협력하여 작업하도록 카테고리화, 정규화, 구조화, 통합 및/또는 적용될 수 있다. TOP의 통찰력 있는 관점 그리고/또는 SDFT를 사용한 데이터에 대한 조작은 더 나은 그리고/또는 복잡한 데이터 설계들이 개념적으로 더 단순하고 그리고/또는 프로그래밍 방식으로 효율적인 방식으로 구현될 수 있게 한다. TOP 및 SDFT는 NUTS 컴포넌트들에 대한 바람직한 하위 레벨 구현 메커니즘(preferred lower level implementation mechanism)일 수 있다.
데이터의 변형에 기반한 분석, 방법 및/또는 구조는 그러한 개념들을 계층화하고 관련 방법들을 설계하는 것이, 모듈식, 휴대용, 저장 가능 및/또는 자체 설명 방식으로 데이터의 간편하고 체계적인 변환들을 허용할 수 있는 통합 데이터 구조들 및 알고리즘 방법들의 구현 가능한 세트를 정의하는 방법을 보여줄 수 있다. 그러한 분석들의 계층적이고 밀접하게 관련된 본질로 인해, 변환에 대한 기술은 전방 참조(forward reference) 및 후방 참조(backward reference)를 가질 수 있으며, 특정 특성들에 대한 더 나은 이해를 얻기 위해 판독자(reader)가 다른 섹션들을 참조하도록 요구할 수 있다. SDFT(Structured Data Folding with Transmutations)는 데이터 구조 및 방법론을 사용하는 변환을 기반으로 하며, 변환된 데이터의 저장성(storability), 전달성(transmissibility), 모듈성(modularity), 이동성(portability), 캡슐화가능성(encapsulability), 그리고/또는 시간 호환성을 지원할 수 있다.
NUTS 설계 내에서, SDFT는 낮은 수준의 작업들의 세트이며, 그리고 Nut를 보다 쉽게 구성하기 위한 기본 빌딩 블록으로 간주될 수 있다. 그러나, SDFT는 애플리케이션 내에서 어떤 장황한(tedious) 그리고/또는 반복적인 데이터 변환들을 단순화하기 위해, 부분적으로 또는 전체적으로, 독립적으로 사용될 수 있다. SDFT는 컴퓨터 통신 프로토콜들로 하여금 두 개의 상이한 애플리케이션들 사이에서 동일한 세션 내에서 변환 시퀀스들 및/또는 변환 파라메트릭 변화(transmutation parametric variance)를 동적으로 스위칭할 수 있게 할 수 있다. 현재, 이러한 단일 세션 동적 스위칭은 중요하지 않은 프로그래밍 방식의 연습(programmatic exercise)일 수 있다. Nut를 구축하기 위해 SDFT를 사용하는 것이 필수 요건이 아니지만 그것의 기능들은 Nut를 보다 편리하고 명확하며 유연하게 구축하는 데 도움이 될 수 있다. SDFT는 상태 전이 시퀀스들의 가역성에 대한 잘-정의된 동작들을 갖는 전이 이벤트들의 무한 변형을 가능하게 하는 데이터 상태 전이 방법론으로 더 설명될 수 있으며, 그리고 반복적인 캡슐화 기술을 제공하여 필요한 속성들 및 데이터를 단순한 문맥 의존(context sensitive) 방식으로 유지할 수 있게 한다. SDFT는 일상적인 프로그래밍 문제의 복잡성(messiness)을 수용하여 채택하며, 그리고 이론적 근거가 경험적 증거에 종속적일 수 있는 조직화 원리(organizing principle)들의 실용적인 세트를 제시할 수 있다.
도 5는 변환 조직화 원리(Transmutations Organizing Principle; TOP)가 임의의 데이터 동작을 데이터 변환(510)으로서 어떻게 볼 수 있는지를 나타내며, 여기서, 데이터 변환(510)은 입력 데이터 소스(502) 및 속성들(504)을 필요로 할 수 있고 그리고 변환된 데이터(512) 및 연관된 속성들(514)을 출력할 수 있다. 데이터의 잘-정의된 조작, 동작, 변환 및/또는 변형은 일종의 변환(transmutation)(510)으로 분류될 수 있다. TOP는 모듈 방식으로, 이동(portable) 방식으로, 자체-기술(self-describing) 방식으로 데이터를 변환하는 방법들의 일관된 세트를 체계적으로 구성할 수 있게 할 수 있다.
도 6의 표는 공통 데이터 연산들의 샘플 세트를 나타내며, 그리고 이들이 TOP를 사용하여 어떻게 분류될 수 있는지를 나타낸다. 변환들은 전통적으로 인식에서 그리고 실제로 구분되었을 수 있는 일종의 기본 데이터 연산들을 포함할 수 있다. 프로그래머가 암호 및 데이터 압축에 대해 토론할 때 이러한 경우가 있을 수 있지만, 이러한 두 개의 클래스의 데이터 작업들은 대개 데이터에 대해 매우 다른 두 개의 별개의 작업들로 간주될 수 있다. 각 연산의 알고리즘상의 차이점을 넘어, TOP의 관점에서, 이러한 연산들은 암호화 변환 및 압축 변환의 한 유형으로 간주될 수 있다. 표에서, 'JSON 직렬화(serialization)'는 'json' 연산을 사용하는 '직렬' 변환으로 분류될 수 있으며, 따라서 실행 가능한 변환 명령은 'serialize json'으로 명시될 수 있다. 데이터 조각에 대한 AES 대칭 암호 암호화 호출(AES symmetric cipher encryption call)은 'aes' 연산을 사용하는 'scipher'변환으로 분류될 수 있으며, 따라서 실행 가능한 명령은 'scipher aes'로 명시될 수 있다. 당업자는 표에 열거된 다른 모든 유형의 데이터 연산들을 용이하게 인식할 수 있으며, 변환 분류 및 연산 카테고리화의 조직화 패턴을 따를 수 있다.
도 7은 리버스 모드 또는 리버스 연산에서의 변환의 다이어그램을 도시한다. 이 도면은 반대 방향으로 흐르는 데이터 흐름 화살표를 제외하고는 도 5와 동일하다. 변환(510)은 블록(710)에 의해 예시된 바와 같이 잘-정의된 가역 알고리즘을 가질 수 있다. 가역적 변환(710)은 입력으로서 변환된 데이터 소스(712) 및 속성들(714)을 요구할 수 있고, 그리고 원본 데이터(702) 및 연관된 속성들(704)을 출력할 수 있다. 가역적 변환과 유사한 개념을 나타낼 수 있는 리버스 컴퓨팅(Reversible Computing)이라 불리는 컴퓨팅 분야가 존재할 수 있다. 각각의 조직화 원리의 목표들에는 약간의 차이가 있을 수 있다. 리버스 컴퓨팅은 일반적인 연산들의 가능한 에너지 효율을 위해 실리콘 계층들까지 연산들이 구현될 수 있는 일반적인 가역 컴퓨팅 언어의 존재를 이론화할 수 있다. 가역적 변환은 작성된 코드 최소화, 프로그래밍 오류 최소화, 편리한 키 관리, 키 생성 단순화, 휴대용 자체-기술(self-describing) 데이터 구조화, 데이터 조작 개념 정규화(normalizing), 프로그래밍 언어에 독립적인 변환 수행 방법 도입, 그리고/또는 복잡한 암호 데이터 구조의 구축을 단순화하는 것과 같은(그러나 이에 제한되지 않음) 이점들을 위해 TOP를 구체적으로 구현하는 것을 목표로 할 수 있다.
도 8은 비가역적 변환의 도식적 표현을 도시한다. 포워드 모드의 변환(810)은 변환된 데이터(812) 및 속성들(814)을 생성할 수 있는 데이터(802) 및 속성들(804)에 대한 변환을 수행할 수 있지만, 이러한 출력들은 변환이 입력들에 대해 수행할 수 있는 조작들의 유형과 함께 비가역적 성질을 가질 수 있다. 이러한 비가역적 변환들은 해시들, MAC들, 손실 데이터 압축들, 그리고 기타 일방향 함수들 또는 데이터 조작들에 의해 예시될 수 있다. TOP는 그러한 비가역적 변환들의 특성들을 지엽적으로 보완할 수 있는 분석 기법들을 도입할 수 있고, 그리고 그것들의 리버스 변환 특성들을 정의할 수 있는 연산들을 생성할 수 있다.
도 9는 조건부 가역 변환의 블록도를 도시한다. 이러한 변환(910)은 잘-정의된 가역 알고리즘을 가질 수 있지만, 리버스 연산이 성공하기 위한 추가 입력들 및/또는 속성들(914)을 요구할 수 있다. 조건부 가역 변환(910)은 입력으로서 변환된 데이터 소스(912) 및/또는 속성들(14)을 요구할 수 있고, 그리고 필수 조건들(916)이 만족되는 경우에 원본 데이터(902) 및/또는 관련된 속성들((04)을 출력할 수 있고, 그렇지 않다면 오류 조건(condition)(920)으로 실패할 수 있다. 올바른 키(속성)가 없으면 암호문의 해독을 방해할 수 있기 때문에, 키들을 필요로 하는 암호들은 조건부 가역 변환들로 분류될 수 있다.
도 10은 일반적인 데이터 연산들 및 함수들 그리고 이들 각각의 변환 분류들을 열거한 표이다. 당업자는 표에 열거된 데이터 연산들 및/또는 기능들의 일부 또는 전부를 인식할 수 있다. 예를 들어, 이 문서에 제시된 자료는 Python 버전 3.6이라는 프로그래밍 언어와 그것의 구문, 개념, 기능 및/또는 방법들을 참조할 수 있다. 이 개시서에 언급된 많은 암호화 함수들은 Python 표준, pyCryptodome, secretsharing 및/또는 pyCrypto 라이브러리에서 찾을 수 있다. 당업자는 대부분의 현대의 프로그래밍 언어들 및 그 각각의 라이브러리들에서 동등한 구문, 개념, 기능 및/또는 방법들을 찾을 수 있다. 'dign'은 디지털 서명들을 위한 변환이며, 다른 기억술(mnemonics)은 이 문서의 SYMBOLS & ABBREVIATIONS 섹션에 나열될 수 있다는 것을 유의한다. 각 변환의 더 상세한 설명은 도 12의 표에서 발견될 수 있다.
도 11은 Pyhon v3.6에 정의된 코덱들의 표이다. 수많은 코덱들이 존재하고 새로운 코덱들이 급증하고, 그리고/또는 Python v3.6에 정의된 코덱들의 제한사항으로 인해, 이 목록은 완전하지 않을 수 있다. '코덱'은 코드/디코드의 약자로, 컴퓨팅에서 문자 세트에 대한 매핑이다. 문자에는 단일 코덱 내에서 임의의 그러나 고유한 이진 값이 할당된다. 따라서, 완전한 문자 세트는 단일 코덱을 정의할 수 있다. 주어진 코덱 내의 모든 문자들이 사람이 읽을 수 있거나 인쇄 가능한 것은 아닐 수 있다. 코덱의 일반적인 사용법은 다른 언어의 다른 문자 집합을 적절히 표현하는 것이다. '인코딩' 변환은 주어진 데이터 문자열에 대해 이러한 코덱 인코딩 작업들을 수행할 수 있다. 'utf_'로 시작하는 이름들을 가진 코덱들은 많은 인터넷 기반 표준들에 대한 국제 문자 세트들의 조직화 원리일 수 있는 유니코드 변환 형식(unicode transformation format; UTF)을 준수하는 코덱들을 지정할 수 있다.
도 12는 상세한 설명과 함께 지금까지 논의된 변환들을 나열하는 표이다. key, clean, TAR 그룹, press, lock 및 mobius와 같은 표의 마지막 6 개의 변환들에 의해 보여지는 것처럼 TOP를 사용하여 프레임워크 내에서 추가적인 변환들이 정의될 수 있다. 이러한 추가 변환들 중 일부는 SDFT(Structural Data Folding with Transmutations) 라이브러리에 특정적일 수 있으며, 일부는 언어 특정적일 수 있으며, 그리고/또는 일부는 NUTS와 관련된 작업들일 수 있다. 이는 새로운 변환 유형들을 정의하고 분류하여 그것의 레퍼토리를 확장함으로써 TOP의 유연한 본질을 설명할 수 있다. 이 유연한 확장 기능은 SDFT 라이브러리가 향후 새로운 변환 연산들을 수용할 수 있도록 설계된 것이다. 확장 기능은 또한 이번 버전과의 호환을 위해, 이전 버전의 변환 연산들이 소급하여 추가될 수 있게 할 수도 있다. 이러한 유연성의 이점은 SDFT 처리된 데이터가 더 나은 시간 호환성의 특성을 획득할 수 있는 능력일 수 있다. 데이터의 시간 호환성은 저장된 데이터가 미래의 특정 시점에서 동일하거나 상이한 애플리케이션에 의해 쉽게 처리될 수 있도록 하는 특성으로 정의될 수 있다. 시간 불일치는 응용 프로그램 파일 형식 버전 차이, 서로 다른 문자 인코딩, 오래된 응용 프로그램 파일 형식, 데이터 작업 방법 차이, 데이터 작업 순서 차이 그리고/또는 데이터 작업 관련 파라미터 차이로 인해 발생할 수 있지만 이에 제한되는 것은 아니다.
도 13은 변환 가역성 매트릭스를 도시한다. 각각의 변환은 가역성, 비가역성 및/또는 조건부 가역성으로 지정될 수 있다. 그러한 지정을 하기 위한 기준은 실제로 구현된 그리고/또는 이론적인 결함들보다는 변환의 이상적인 의도에 근거할 수 있다. 다른 경우, 지정은 임의적일 수 있다. 이는 소스 데이터의 128 비트 길이 해시들을 생성할 수 있는 MD4라는 다이제스트 작업으로 설명될 수 있다. MD4 해시는 해싱 알고리즘에서 바람직하지 않은 특성일 수 있는, 충돌 가능성에 기인한 512 비트 SHA2와 같은 해시 연산에 비해 심각하게 약한 해싱 알고리즘으로 간주될 수 있다. TOP 관점은 MD4의 원래 의도 중 하나를 비가역적인 고유한 해시로 인식하고 이를 그런 방식으로 분류하는 것일 수 있다. 이러한 카테고리화는 이러한 유형의 변환이 추가 TOP 분석을 통해 잘 정의되고 설계된 가역 특성을 얻는 것을 배제하지 않을 수 있다. 이는 이후 섹션에서 보여질 것이다. 압축 변환은 수행되는 특정 압축 동작에 기초하여 가역적 및 비가역적 지정들 하에 있을 수 있다. 많은 이미지 및/또는 오디오 압축 기술은 샘플링 특성으로 인해 비가역성을 나타낼 수 있다. 12 MB 디지털 이미지는 채팅 응용 프로그램을 통한 효율적인 전송을 위해 36 KB까지 압축될 수 있지만, 인간의 시각적 인식의 특성으로 인해, 이미지의 일반적인 인상은 영구적인 데이터 손실에도 불구하고 적절히 전달될 수 있다. 이러한 압축된 이미지는 변환 중에 폐기되었을 수 있는 엄청난 양의 원본 데이터로 인해 비가역적으로 수정될 수 있다.
가역 압축 변환은 gzip 압축에 의해 예시될 수 있다. 그것은 2진 데이터 내에서 반복적인 비트 패턴들을 식별하고 감소시키는 원칙에 따라 작동하지만, 프로세스를 리버스시키고 원본 데이터 전체를 재생산하기에 충분한 정보를 유지할 수 있다. 조건부 가역 변환은 AES 대칭 암호에 의해 예시될 수 있다. 그것은 평문(cleartext)과 대칭키를 가져와서 암호문을 생성하는 원칙에 따라 작동할 수 있다. 복호화 프로세스는 원래 평문을 생성하기 위해 키와 암호문을 취할 수 있다. 이에 따라, 암호문에 대한 정확한 대칭 키의 표현은 암호문을 해독하고 암호화 과정을 리버스하기 위해 만족되어야하는 필수 조건일 수 있다.
TOP는 주어진 변환 연산의 방향을 순방향으로 또는 역방향으로 나타낼 수 있는 변환 모드를 정의할 수 있다. 변환의 순방향 모드는 그것의 정상적인 처리 및/또는 그것의 설계된 순방향 처리를 수행할 수 있다. 변환의 리버스 모드는 고유의 역방향 처리 및/또는 설계된 역방향 처리(engineered reverse process)를 수행할 수 있다. 도 14의 표는 변환이 그 변환 모드에 기초하여 내부적으로 수행할 수 있는 동작 유형을 나타내는 매트릭스를 도시한다. 참고로, 이 표는 "직렬화" 및 "역직렬화(deserialize)", 또는 "암호화" 및 "해독"과 같이 일반적으로 알려진 연산들의 이름을 나열한다. digest 및 dign의 설계된 역방향 처리를 유의한다 : '다이제스트(digest)' 및 '검증(verification)', 'sign' 및 '인증'. 변환 데이터 구조와 관련된 다양한 내부 데이터를 삭제할 수 있는 'clean' 변환에 대해, 삭제된 임시 데이터를 재생산하기 위해 적절한 추가 데이터 및/또는 원래의 데이터에 대한 순방향 변환 처리의 재실행 없이 그러한 삭제된 데이터를 복원하는 것은 불가능할 수 있다. 'key' 변환은 변환을 수행하는 것과 관련된 키 생성 및/또는 관리 작업들을 수행할 수 있다. 이와 같이, 키 생성의 고유한 랜덤 특성으로 인해, 유한 시간에 결정론적인 방식으로 이론적으로 그리고/또는 알고리즘적으로 그러한 프로세스를 리버스시키는 것은 불가능할 수 있다. 'key' 변환의 키 관리 측면은 SDF(Structured Data Folding)의 맥락에서 변환이 어떻게 작동하는지를 다룰 때 이후 섹션에서 자세히 논의될 것이다. key 변환의 키 관리 측면은 SDF 맥락에서 성공적인 처리를 위한 적절한 키 구조들을 설정하는 특성 때문에 가역적 대응물을 설계하는 것이 어려울 수 있다.
도 15는 일련의 3 개의 다이어그램들을 도시하며, 각각은 가역적인 변환으로 지정될 수 있는 직렬화 변환(1504) 예를 더 상세히 설명한다. 컴퓨터 프로그래밍에서, 직렬화 및/또는 마샬링(marshalling) 기술은 복잡한 언어 특정 내부 데이터 구조를 취할 수 있고, 그리고 등가의 데이터 스트링 또는 데이터 스트링의 세트(이하, 데이터 스트링이라 칭함)를 생성하기 위해 그 내용을 선형 방식으로 체계적으로 해체 및/또는 조직화할 수 있다. 데이터 스트링 형태는 영구 저장, 데이터 전송 및/또는 추가의 변환에 보다 적합할 수 있다. 정의에 의한 직렬화는 원본 언어 또는 그것의 등가물의 원본 내용을 재구성하기 위해 논리적인 방식으로 완전히 가역적일 것을 요구할 수 있다. Python 구조(1512)는 JSON 동작(1514)을 사용하여 변환되어 등가의 JSON 스트링(1516)을 생성할 수 있고, 그리고 양방향 프로세스 흐름 화살표에 의해 도시된 바와 같이 역방향 처리가 가능할 수 있다. 복잡한 Python 데이터 구조를 예시할 수 있는 참조번호 1522에 간단한 트리 데이터 구조가 도시되어 있다. 직렬화 변환(1524)은 1522로부터 등가의 스트링(1526)을 생성할 수 있다. 이제 이 출력 스트링(1526)은 프로그램이 진행됨에 따라 저장되고, 전송되고, 그리고/또는 변환될 수 있다.
도 16은 일련의 3 개의 다이어그램들을 도시하며, 각각은 비가역적 변환으로 지정될 수 있는 다이제스트 변환(1606)의 예를 더 상세히 설명한다. 이 예는 입력 데이터(1612) 및 다이제스트 길이(1614)를 속성(1604)으로서 요구할 수 있는 다이제스트 변환(1616)으로서 SHA2 해시 작업을 도시한다. SHA2 해시 다이제스트 변환(1616)은 지정된 길이(1618)의 해시를 생성할 수 있다. 256 비트의 Python 데이터 스트링(1622) 및 원하는 다이제스트 길이(1624)는 256 비트 길이의 해시 스트링(1628)을 생성하기 위한 SHA2 해시 변환(1626)에 대한 입력들일 수 있다.
도 17은 검증으로서 알려진 리버스 모드의 다이제스트 변환의 상세한 예를 도시한다. TOP에서, 이는 변환의 설계된 리버스라고 지칭될 수 있다. 다이제스트 변환(1710)은 다이제스트 스트링 DG1(1712)을 출력(1708)으로서 생성할 수 있는 포워드 모드 다이제스트 변환(1710)을 수행하기 위해 입력 데이터 D1(1702) 및 속성들 A1(1704)을 입력들로서 받아들일 수 있다. 이러한 변환(1720)의 리버스 모드는 다이제스트 스트링 DG1(1728)이 검증되었는지(1732) 또는 검증 실패되었는지(1734) 여부를 나타내는 플래그 및/또는 값을 출력(1738)으로서 생성할 수 있는 리버스 모드 다이제스트 변환(1720)을 수행하기 위해 데이터 D1(1722), 속성들 A1(1724) 및 다이제스트 스트링 DG1(1728)을 입력들(1736)로서 받아들일 수 있다. 검증(1740)의 프로세스는 입력들 D1 (1722) 및 A1 (1724)에 대해 포워드 모드 다이제스트 변환(1720)을 수행함으로써 다이제스트 스트링 DG2 (1722)를 생성할 수 있다. 그 다음, 출력 다이제스트 스트링 DG2(1722)는 등식(1730)에 대해 입력 다이제스트 스트링 DG1(1728)과 비교될 수 있다. 비교 결과(1738)는 리버스 다이제스트 변환이 성공했는지의 여부를 나타내는 어떤 형태로 제공될 수 있다. 이런 방식으로, 다이제스트 리버스의 엔지니어링은 변환의 순방향 모드가 재-처리될 것을 요구할 수 있고, 그리고 어렵고, 시간이 많이 걸릴 수 있고 그리고/또는 달성 불가능할 수 있는 그러한 연산들의 논리적 가역성을 찾기 위한 어떠한 해결 수단에 의존하지 않고 출력들을 비교하는 것을 요구할 수 있다.
도 18, 도 19 및 도 20은 대칭 암호로도 알려진 포워드 및 리버스 모드의 scipher 변환의 상세한 예를 도시한다. 포워드 모드(1806)의 scipher 변환은 입력으로서 평문(cleartext)(1802) 및 속성들(1804)을 수용하여 출력으로서 암호문(1810) 및/또는 속성들(1812)을 생성할 수 있다. 리버스 모드(1826)의 scipher 변환은 입력으로서 암호문(1830) 및 속성들(1832)을 수용하여 출력으로서 평문(1822) 및/또는 속성들(1824)을 생성할 수 있다. 도 19는 salsa20 대칭 암호가 scipher 변환으로 동작할 수 있는 방법을 도시한다. 포워드 모드(1906)의 scipher salsa20 변환은 입력으로서 평문(1902) 및 속성들(1904)을 수용하여 출력으로서 암호문(1910)을 생성할 수 있다. 포워드 모드에서의 이러한 특정 암호에 대한 속성들은 이진 대칭 키, 키의 길이 및/또는 salt 값을 포함할 수 있다. 이러한 salsa20 포워드(암호화) 구현은 스트리밍 암호일 수 있으며, 함수가 자체 출력 스트링에 포함할 수 있는 숨겨진 속성 이외에 암호화 프로세스 동안 추가 출력 속성들을 생성할 수 없다. 리버스 모드(1926)의 scipher salsa20 변환은 입력으로서 평문(1930) 및 속성들(1932)을 수용하여 출력으로서 평문(1922)을 생성할 수 있다. 리버스 모드에서의 이러한 특정 암호에 대한 속성들은 이진 대칭 키, 키의 길이 및/또는 salt 값을 포함할 수 있다. 이러한 salsa20 리버스 구현(해독)은 스트리밍 암호일 수 있으며, 해독 프로세스 중에 추가 출력 속성들이 생성될 수 없다. 도 20은 salsa20 대칭 암호가 Python v3.6 및 PyCryptodome 라이브러리 함수 내에서 표현될 수 있는 바와 같이 샘플 데이터에 대한 변환으로서 동작할 수 있는 방법을 도시한다. 포워드 모드(2006)의 scipher salsa20 변환은 출력으로서 암호문(2010)을 생성하기 위해, 입력으로서 데이터 스트링(2002), 그리고 256 비트의 대칭 비밀 키 및 (salt 로서) nonce를 포함하는 속성들(2004)을 수용할 수 있다. Python에서, 대칭 키는 'bytes' 데이터 유형 스트링으로 표현될 수 있으며, 이에 따라 키 길이 속성은 키 바이트 스트링에 대한 len() 함수에 의해 쉽게 유도될 수 있다. 리버스 모드(2026)의 scipher salsa20 변환은 출력으로서 암호문(2022)을 생성하기 위해, 입력으로서 암호문(2030), 그리고 256 비트 대칭 비밀 키 및 nonce를 포함하는 속성들(2032)을 수용할 수 있다. Python에서, 대칭 키는 'bytes' 데이터 유형 스트링으로 표현될 수 있으며, 이에 따라 키 길이 속성은 키 바이트 스트링에 대한 len() 함수에 의해 쉽게 유도될 수 있다. 속성들(2032)은 이 조건부 가역 변환이 리버스 모드(해독)에서 암호문(2030)을 적절히 처리하여 원래의 평문(2002)을 복구하기 위해서는 속성들(2004)과 동등할 필요가 있을 수 있다.
변환 유형
도 21 내지 도 35에 제시된 다음의 표들 및 예들에서, 각 변환은 이 표에 명시된 작업들로 제한되지 않을 수 있으며; 임의의 적절한 작업은 TOP를 통해 분석될 수 있으며, 그 다음 특정 변환의 연산 기능들을 확장하기 위해 프레임워크에 통합될 수 있다. Python v3.6 구문(syntax) 및 구성체들(constructs)은 예들을 보다 자세하게 설명하기 위해 사용될 수 있다. 등가의 데이터 유형들, 구조들, 구문 및/또는 방법들이 발견될 수 있고, 당업자에 의해 다른 프로그래밍 언어로 대체될 수 있다. 몇몇 경우에, 키/값 옵션은 특정 언어 또는 라이브러리와 관련이 없을 수 있으며, 그리고 처리가 동등한 결과들을 생성할 수 있는 한 필요에 따라 무시되거나 수정될 수 있다.
직렬화/압축 변환
도 21은 직렬 변환 및 압축 변환에 대한 명령 스펙들의 표(2102) 그리고 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(2104)를 도시한다. 표(2102)는 각 변환에 대한 변환 명칭 및 수용 가능한 연산 유형들을 열거한다. 뒤에 '='를 갖는 임의의 열 헤더는 그것 아래에 표현된 값이 명령 구문 작성시 키/값 형식으로 표현될 수 있다는 것을 나타낸다. "입력" 및 "출력" 열들은 Python v3.6의 컨텍스트에서 변환/연산을 위한 예상 데이터 유형/구조들을 지정할 수 있다. 예를 들어, 명령 'serialize json sortkeys=t'는 다음과 같은 데이터 조작 시퀀스들을 수행할 수 있다; 임의의 Python 데이터 구조를 입력받고, True로 설정된 'sort_keys' 플래그로 그것에 대하여 json.dumps()를 수행한 다음, 직렬화된 버전의 데이터로 Python 스트링을 출력한다. 이 명령의 리버스 모드는 JSON 형식의 Python 스트링을 입력으로 기대할 수 있고, 그것에 대해 json.loads()를 수행한 다음, Python 데이터 구조를 출력할 수 있다. 'sort_keys' 플래그는 Python 사전 구조의 키들을 오름차순으로 처리하도록 json.dumps() 함수에 알린다. Python v3.6은 키에 의해 처리될 때 사전 구조에 대한 일관된 처리를 보장하지 않을 수 있으며, 이에 따라 결과물인 JSON 스트링들은 동일한 데이터 구조에 대한 이 변환의 여러 실행들 간에 일치하지 않을 수 있다. 직렬화 변환 내에서 특정 순서로 키들을 정렬하는 것은 처리 시퀀스의 일관성을 제공하여 동일한 데이터 구조에 대한 여러 실행들 간의 출력과 동일한 JSON 스트링들을 야기할 수 있다. 이는 두 개의 JSON 스트링이 동등한지를 결정할 목적을 위해 매우 중요하게 될 수 있으며, 이와 같이 2 개의 동등한 사전-직렬화 데이터 구조들을 나타낼 수 있다.
표(2102)에서 압축 변환은 여러 상이한 무손실 압축 연산들 또는 가역적 압축들을 나타낸다. 비가역적 또는 손실 압축 연산들은 압축 변환 레퍼토리를 확장할 수 있지만, 가역적인 변환을 논의할 목적으로, 데이터 크기 축소를 크게 벗어나 암호화 목적을 제공할 수 없는 일방향 함수를 논의하는 것은 흥미롭지도 건설적이지도 않을 수 있다. TOP 관점에서, 손실 압축들은 이후 섹션에서 논의될 다이제스트 변환과 동일한 방식으로 분석되고 처리될 수 있다. 2104의 예에서, 명령 'compress bz2'은 2진 스트링 입력에 대해 bz2 압축을 수행할 수 있으며, 그리고 입력 스트링보다 크기가 작거나 작지 않을 수 있는 2진 스트링 출력을 생성할 수 있다. 일부 데이터는 더 이상 특정 압축 기법을 사용하여 압축될 수 없으며, 이 예는 bz2 압축된 스트링이 다시 처리될 수 있고 더 이상의 데이터 크기 감소가 달성될 수 없는 경우일 수 있다.
인코딩 변환
도 22는 인코딩 변환에 대한 명령 스펙들의 표(2202) 그리고 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(2204)를 도시한다. 컴퓨터 과학에는 많은 인코딩 기법들이 존재할 수 있으며, 이 테이블의 참조들은 알려진 모든 인코딩 기법들을 나타내지는 않는다. "encoding = " 열에 나열된 인코딩 기법들은 Python v3.6 및 관련 표준 라이브러리에서 찾을 수 있다. 당업자는 데이터를 조작할 수 있는 애플리케이션과 관련된 문제를 해결하기 위해 이러한 모든 유형의 인코딩들에 대한 액세스를 갖는 유틸리티를 인식할 수 있다. 'Codecs(98)'은 이 문서에서와 같이 그리고 도 11의 표에 이전에 나열된 바와 같이 Python v3.6에서 지원되는 코덱들의 목록을 지칭한다. 변환 명령 'encode stribin utf_8'은 Python 스트링을 입력으로 받아, 그에 대해 uft_8 유니코드 인코딩을 수행하며, 그리고 Python 바이트 스트링으로 결과들을 출력할 수 있다. 변환 명령 'encode utf utf_16'은 Python 스트링을 입력으로 받아, 그에 대해 utf_16 유니코드 인코딩을 수행하며, Python 스트링으로 결과들을 출력할 수 있다. 변환 명령 'encode binascii hex'은 Python 바이트 스트링을 입력으로 받아, 그에 대해 16진수 인코딩(hexadecimal encoding)을 수행하고, Python 스트링으로 결과들을 출력할 수 있다. 변환 명령 'encode base 64'은 Python 바이트 스트링을 입력으로 받아, 그에 대해 base64 바이너리 인코딩을 수행하고, Python 스트링으로 결과들을 출력할 수 있다. 변환 명령 'encode utf_8'은 'encode utf utf_8'와 등가이다. 이러한 설명들은 인코드 변환 명령 구문에서 허용되는 순열들의 유형들과 일관성을 설명할 수 있다.
다이제스트 변환
도 23은 다이제스트 변환에 대한 명령 스펙들의 표(2302) 그리고 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(2304)를 도시한다. 표(2302)에 도시된 다이제스트 변환은 세 가지 유형의 연산들 hash, hmac, 및/또는 cmac을 정의하지만, 그것들에 제한되지 않는다. 변환 명령 'digest hash md5 128'은 소스 데이터 스트링을 입력으로 받아, 그에 대해 MD5 해시 함수를 수행하고, 128 비트 길이인 출력 다이제스트 바이트 스트링을 생성한다. 입력 소스 데이터 스트링은 다이제스트 변환 호출 동안 수정되거나 덮어씌어지지 않을 수 있으며, 출력 다이제스트 바이트 스트링은 다이제스트 변환 호출로부터 생성된 추가 데이터일 수 있으며, 그리고 개별 메모리 공간을 제공받을 수 있다는 것을 유의한다. 변환 명령 'digest hash sha2 512'은 소스 데이터 스트링을 입력으로 받아, 그에 대해 SHA2 해시 함수를 수행하며, 512 비트 길이인 출력 다이제스트 바이트 스트링을 생성한다. 변환 명령 'digest hash shake256 digestlen=332'은 소스 데이터 스트링을 입력으로 받아, 그에 대해 SHAKE256 해시 함수를 수행하고, 332 비트 길이인 출력 다이제스트 바이트 스트링을 생성할 수 있다. 변환 명령 'digest hmac sha2 256'은 소스 데이터 스트링을 입력으로 받아, SHA2 해시를 사용하여 그에 대해 HMAC 함수를 수행하고, 256 비트 길이인 출력 다이제스트 바이트 스트링을 생성할 수 있다. 변환 명령 'digest cmac aes 256'은 소스 데이터 스트링 및 256 비트 대칭 키를 입력으로 받아, AES256 암호를 사용하여 그에 대해 CMAC 함수를 수행하며, 그리고 128 비트 길이인 출력 다이제스트 바이트 스트링을 생성할 수 있다. 이러한 모든 다이제스트 변환의 예시적 연산들 및 유형들은 표준 Python 라이브러리 및/또는 PyCryptodome 라이브러리에서 찾을 수 있으며, 그리고 이러한 샘플 라이브러리들 이외의 이론적 및/또는 구현된 의미로 존재할 수 있는 모든 다양한 연산들, 유형들, 다이제스트 길이들, 키 길이들 및/또는 다른 파라미터들을 나타낼 수 없다. 추가적인 변형들은 TOP를 통해 적절히 분석되고 변환 형식으로 통합될 수 있다. 임의의 변환 형태에 대한 그러한 통합들은 존재하는 변환 연산들의 리팩토링(refactoring) 및 리테스팅(retesting)을 요구할 수 있다.
Acipher/Dign 변환들
도 24는 acipher 및 dign 변환들에 대한 명령 스펙들의 표(2402, 2404, 2406) 및 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(2410)를 도시한다. 변환 명령 'acipher pkcs1_oaep 2048'은 바이트 스트링 및 2048 비트 길이 RSA 비대칭 공개키를 입력으로 받아들여, 512 비트 SHA2 해시를 이용하여 그에 대해 RSA PKCS#1 OAEP 암호 연산을 수행할 수 있으며, 그리고 2048 비트 길이인 암호화된 바이트 스트링을 출력으로 생성할 수 있다. 변환 명령 'acipher pkcs1_v1_5 3072'은 바이트 스트링 및 3072 비트 길이 RSA 비대칭 공개키를 입력으로 받아들여, 그에 대해 RSA PKCS#1 v1.5 암호 연산을 수행할 수 있으며, 그리고 3072 비트 길이인 암호화된 바이트 스트링을 출력으로 생성할 수 있다. 이러한 acipher 변환들의 리버스 모드는 원본의 평문을 생성하기 위해 바이트 스트링으로서의 암호문, 그리고 적절한 RSA 키의 개인 부분을 입력으로 요구할 수 있다.
변환 명령 'dign pkcs1_v1_5 2048'은 바이트 소스 스트링 및 2048 비트 길이의 RSA 비대칭 개인키를 입력으로 받아들이고, 512 비트 SHA2 해시를 사용하여 그에 대해 RSA PKCS#1 v1.5 디지털 서명 연산을 수행할 수 있고, 그리고 2048 비트 길이인 다이제스트 바이트 스트링을 출력으로 생성할 수 있다. '다이제스트 바이트 스트링(digesst bytes string)'이란 용어는 '디지털 서명 바이트 스트링(digital signature bytes string)'과 같은 의미로 사용될 수 있다. 왜냐하면 TOP는 이러한 출력들을 유사한 기능을 제공하는 것으로 볼 수 있기 때문에, '다이제스트(digest)' 변수 이름이 가리키는 이러한 바이트 스트링을 저장할 수 있기 때문이다. 변환 명령 'dign dss 1024 hashtyp=sha2'은 바이트 소스 스트링 및 1024 비트 길이 DSA 비대칭 개인키를 입력으로 받아들이고, 512 비트 SHA2 해시를 사용하여 FIPS-186-3 모드에서 그에 대해 DSS 디지털 서명 연산을 수행할 수 있고, 그리고 1024 비트 길이인 디지털 바이트 스트링을 출력으로 생성할 수 있다. 변환 명령 'dign dss 256'은 바이트 소스 스트링 및 256 비트 길이의 ECC 비대칭 개인키를 입력으로 받아들이고, 512 비트 SHA2 해시를 이용하여 FIPS-186-3 모드에서 그에 대해 DSS 디지털 서명 연산을 수행할 수 있고, 그리고 256 비트 길이인 다이제스트 바이트 스트링을 출력으로 생성할 수 있다. 이러한 dign 변환들의 리버스 모드는 다이제스트 바이트 스트링(디지털 서명), 소스 바이트 스트링 및 적절한 비대칭 키의 공개 부분을 입력으로 요구하여 이를 인증할 수 있다.
Derive 변환
도 25는 derive 변환들에 대한 명령 스펙들의 표(2502, 2504, 2506) 및 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(2510)를 도시한다. 샘플 연산들 pbkdf2, hkdf 및 scrypt 또한 키 유도 함수(key derivation function) 및/또는 키 스트레칭 함수로도 알려져있을 수 있다. 유도 변환의 기본 기능은 사용자에게 알려질 수 있는 이진 또는 문자 데이터 스트링으로부터 원하는 길이의 대칭 키 또는 키들을 유도하는 것일 수 있다. 키 유도 함수의 일반적인 사용법은 패스워드 또는 패스프레이즈로부터 적절하게 형성된 대칭 암호화 키(들)를 유도하는 것일 수 있다. 변환 명령 'derive pbkdf2 keylen=256 iterations=100000'은 문자 데이터 스트링(패스워드 또는 패스프레이즈)을 입력으로 받아들여, SHA2 512 비트 해시 함수, salt로서 랜덤으로 생성된 512 비트 초기화 벡터, 그리고 100,000로 설정된 반복 카운트 파라미터(iteration count parameter)를 사용하여 그에 대해 PBKDF2 연산을 수행할 수 있고, 그리고 256 비트 길이 바이트 데이터 스트링인 대응 대칭키를 생성할 수 있다. 변환 명령 'derive hkdf keylen=256 numkeys=4'은 바이트 데이터 스트링을 입력으로 받아들여, SHA2 512 비트 해시 함수, salt 로서 랜덤으로 생성된 512 비트 초기화 벡터를 사용하여 그에 대해 HKDF 연산을 수행하고, 그리고 각각 256 비트 길이의 바이트 데이터 스트링인 4개의 관련 대칭 키들의 대응하는 세트를 생성할 수 있다. 변환 명령 'derive scrypt keylen=128 mode=login'은 데이터 스트링을 입력으로 받아들이고, salt로서 랜덤으로 생성된 512 비트 초기화 벡터를 사용하여 그에 대해 로그인(login) 모드 SCRYPT 연산을 수행할 수 있고, 그리고 256 비트 길이 바이트 데이터 스트링일 수 있는 대응 대칭키를 생성할 수 있다. derive scrypt 변환의 로그인 모드는 표(2506)에 표시된 값들에 세 개의 파라미터들 n, r 및 p을 설정하기 위한 단축형(shorthand)일 수 있다. 이러한 파라미터 값들은 SCRYPT 알고리즘 작성자의 제안된 설정일 수 있다.
변환을 유도하는 TOP 접근법은 이중 모드 연산을 제안할 수 있다. 데이터 모드 : 변환이 키스택(keystack)(이후 섹션에서 상세히 설명됨)과 연관되지 않고 오직 일부 유형의 데이터 소스 스트링과만 연관될 수 있다면, 이 입력 데이터 소스 스트링을 변환하여 이를 대칭 키(들)의 형태일 수 있는 변환의 출력으로 대체할 수 있다. 키 모드 : 변환이 키 스택과 일부 유형의 데이터 소스와 연관될 수 있다면, 키스택에 존재하는 대응 키 소스 재료(material)를 변환할 수 있고, 키 소스 재료를 대체함으로써 암호식으로(cryptographically) 이용 가능한 대칭 키(들)를 도출하여 이를 키스택에 배치할 수 있다. 이러한 진술은 키스택 및 키 관리가 TAR(Transmutation Audit Record) 및 종속 변환들의 맥락에서 논의될 때 이후 섹션에서 더 명확하게 설명될 수 있다.
Scipher 변환
TOP를 사용하여, 대칭 암호 연산들은 scipher 변환들로 분류될 수 있고, 그리고 그룹으로서, 이러한 변환들은 수 및/또는 다양성 모두에서 확장될 수 있는 관련 속성 세트를 나타낼 수 있다. 다음 3개의 그림들은 TOP가 모든 속성들을 갖는 각각의 scipher 변환을 시스템적으로 정규화하고 동일한 출력 스트링으로 캡슐화하는 방법을 도시한다. 이 유형의 속성 임베딩 기술들은 다양한 유형들의 연산들을 위한 다양한 함수들 및 라이브러리들에서 찾을 수 있다. 그러나, 이러한 임베딩 기술들에 대해 널리 인정된 표준들은 거의 없을 수 있다. TOP는 SDFT(또는 Structured Data Folding with Transmutations)라 불리는 기능을 지원하기 위한 뚜렷한 목적으로 모든 scipher 변환들에 적용될 수 있는 일관된 방법론을 제안할 수 있다. 이러한 방법론이 널리 사용되는 표준이 될 수 있는지 여부는 이 문서의 범위를 벗어날 수 있지만, 판독자는 특히 TAR 및 SDFT 구성들 및 방법들에 대해 나중에 토론할 때 TOP 프레임워크 내에서 그 사용법의 가능한 이점들을 인식할 수 있다.
도 26은 scipher 변환들에 대한 명령 스펙들의 표(2602) 및 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(2604)를 도시한다. 표는 세 개의 유형의 scipher 연산들 aes, chacha20 및 salsa20을 도시한다. 이것은 알려진 대칭 암호들의 완전한 목록은 아니지만, TOP가 어떻게 그것들을 체계화하고 그것들의 사용법을 제안할 수 있는지 설명하기 위해 그것들의 관련 다양성을 제시할 수 있다. 대칭 암호들은 그것들과 연관된 다음의 속성들을 다소 가질 수 있다 : 키 길이 (keylen), 연산 모드(mode), salt 유형 (salttyp), salt 길이 (saltlen), 블록 사이즈 (Block), 암호 연산 유형 (type), 및/또는 패딩 (pad). 키 길이는 평문으로부터 암호문을 생성하기 위해 암호에서 사용될 수 있는 비밀 대칭 키의 길이를 명시할 수 있다. AES 암호의 경우, 표에 도시된 것과 같이 적어도 10 개의 서로 다른 연산 모드들을 가질 수 있다. 대부분의 대칭 암호들은 그 사용이 보다 나은 의미론적 안정성(semantic security)을 촉진할 수 있는 특정 유형(iv 또는 nonce) 및 특정 salt 길이의 salt (랜덤값)의 입력을 요구할 수 있다. 대칭 암호는 적어도 세 개의 상이한 연산 유형들을 제공할 수 있다 : block, stream 및/또는 AEAD 암호들. 최신 모드들이 제안될 수 있으며, 이들은 TOP를 추가 변환 변종(variant)으로 사용하여 통합될 수 있다. 블록 모드 암호들은 패딩 방법론(padding methodology), 패드 포지셔닝(pad positioning), 패드 유형 및/또는 패드 길이를 포함하는 추가 속성들을 필요로 할 수 있다.
섹션(2604)의 예들에서, 변환 명령 'scipher aes 256 mode=ofb' 은 바이트 데이터 스트링 및 256 비트 대칭 키를 입력으로 받아들여, 제시된 키 및 랜덤으로 생성된 128 비트 초기화 벡터를 갖는 AES-256 OFB 모드 스트리밍 암호를 사용하여 입력 데이터 스트링을 암호화하며, 그리고 도 27에 특정된 바와 같이(이후 섹션에서 논의됨) 일관된 키/값 형식으로 포맷팅된 출력 바이트 스트링의 헤더에 임베디드된 프로세스에 관련된 암호문 및 모든 관련 속성들로 구성될 수 있는 출력 스트링을 생성할 수 있다. 변환 명령 'scipher aes 128 mode=gcm'은 바이트 데이터 스트링 및 128 비트 대칭 키를 입력으로 받아들여, 제시된 키 및 128 비트의 nonce를 갖는 AES-256 GCM 모드 AEAD 스트리밍 암호를 사용하여 입력 스트링을 암호화하며, 그리고 도 27에 특정된 바와 같이 일관된 키/값 형식으로 포맷팅된 출력 스트링의 헤더에 임베디드된 프로세스에 관련된 암호문 및 모든 관련 속성들로 구성될 수 있는 출력 바이트 스트링을 생성할 수 있다. AEAD는 Authenticated Encryption with Associated Data의 두문자어이며, AEAD는 단일 함수 호출 내에서 대칭형 암호의 암호화 기능과 함께 인증 기능을 임베딩하는 표준화된 방법 또는 잘-알려진 방법일 수 있다. 변환 명령 'scipher chacha20 256'은 바이트 데이터 스트링 및 256 비트 대칭 키를 입력으로 받아들이고, 제시된 키 및 64 비트 nonce를 갖는 CHACHA20 스트리밍 암호를 사용하여 입력 스트링을 암호화하고, 그리고 도 27에 명시된 일관된 키/값 포맷으로 포맷팅된 출력 스트링의 헤더에 임베디드된 프로세스에 관련된 암호문 및 모든 관련 속성들로 구성될 수 있는 출력 스트링을 생성할 수 있다. 변환 명령 'scipher salsa20 128'은 바이트 데이터 스트링 및 128 비트 대칭키를 입력으로 받아들이고, 제시된 키 및 64 비트 nonce를 갖는 SALSA20 스트리밍 암호를 사용하여 입력 스트링을 암호화하고, 그리고 도 27에 명시된 일관된 키/값 포맷으로 포맷팅된 출력 바이트 스트링의 헤더에 임베디드된 프로세스에 관련된 암호문 및 모든 관련 속성들로 구성될 수 있는 출력 스트링을 생성할 수 있다.
도 27은 단계 1이 입력 포맷을 나타내고 단계 2가 출력 포맷을 나타내는 두 단계들의 시퀀스에서의 scipher 출력 스트링에 대한 출력 구조 포맷을 도시한다. "헤더"는 출력 메시지의 scipher 변환의 가변 길이 key-value utf8 인코딩된 파라미터 스트링이다. 단계 1에서, scipher는 필요에 따라 보통 메시지의 끝에 배치된 패드 길이의 선택적 패딩을 갖는 가변 길이의 메시지 바이트 스트링 '메시지'를 입력으로 받아들일 수 있다. 선택된 암호에 의해 추천될 수 있는 바와 같이, 메시지의 앞에 salt 값이 추가되었을 수 있다. 패딩은 블록 모드 대칭 암호의 필수 요구사항일 수 있다. 프로그래머가 지정한 특정 패딩 방법이 없는 경우, 디폴트 패딩 방법이 사용되어 메시지 끝에 부가될 수 있다. 이 메시지와 패딩은 일반 텍스트(plaintext)로 지칭될 수 있다. 이제 선택된 암호는 입력 일반 텍스트를 처리하고 그리고 단계 2에서 도시된 바와 같이 암호화된 메시지라 불리는 것을 생성하고 출력할 수 있다. 선택된 암호 변환은 이제 키들이 파라미터 유형을 나타낼 수 있고 값들이 각각의 설정들을 나타내는 문자 스트링 형식의 인쇄 가능한 키/값 쌍들로 임베디드된 헤더를 준비할 수 있다. 키/값의 세부사항들은 다음 섹션에서 논의될 것이다. 헤더 스트링이 생성될 수 있으면, 변환은 헤더 크기라고 하는 헤더 스트링의 길이를 계산할 수 있으며, 그리고 2 바이트 길이의 부호 없는 빅 엔디언 정수(big-endian integer)로 포맷팅될 수 있다. 2 바이트들은 0에서 216(65,536) 값을 가질 수 있으며, 그리고 이러한 특정 형식에서 가까운 미래의 임의의 대칭 암호들에 대한 모든 속성들을 설명하기에 충분할 수 있다. 그런 다음, 단계 2는 헤더 크기, 헤더 및 암호화된 메시지를 포함하는 패킹된 메시지(packed message)를 생성하도록 진행할 수 있다. 이러한 패킹된 메시지는 scipher 변환으로부터의 실제 출력 스트링일 수 있으며, 이에 따라, 변환된 데이터와 관련된 모든 속성들을 성공적으로 캡슐화하고 임베디드한 것으로 간주될 수 있다. 리버스 scipher 변환의 데이터 흐름은 이 프로세스를 역으로 따를 수 있다 : 변환 명령은 수행할 정확한 scipher 변환을 특정할 수 있고, 매칭하는 대칭 키와 패킹된 메시지가 입력으로서 제공될 수 있다. 그 다음, scipher 변환은 패킹된 메시지를 언패킹하고, 헤더에서 발견된 모든 속성들을 읽고 저장한 다음, 암호화된 메시지를 해독할 준비를 할 수 있다. 대칭 암호에는 성공적인 암호 해독을 운반하는 결정론적 방법이 없을 수 있다. 검증 방법은 그러한 결과들을 결정하기 위해 중첩 방식(overlaid manner)으로 사용될 수 있다. 가장 기본적인 방법의 예는 해독된 메시지에서 앞에 추가된(prepended) salt 값을 추출하고, 그것을 헤더로부터의 상기 저장된 salt 값들과 비교한다. 매칭하는 salt 값들은 성공적인 해독을 나타낼 수 있지만 이를 보장하지는 못할 수 있다. AEAD 모드 대칭 암호들은 암호화된 메시지 내에 (암호화 전 또는 후) 데이터 스트링의 MAC(CMAC, HASH 또는 HMAC)을 임데디드하고 비교를 수행함으로써 이 문제를 어느 정도 해결할 수 있다. 좀 더 정교한 방법들은 상이한 키들을 사용하는 메시지의 일부 형식의 디지털 서명된 해시들의 인증을 요구할 수 있다. 이후 섹션에서 도시될 수 있는 바와 같이, SDFT 및 TAR들의 사용은 절차적으로 단순하고 논리적인 방식으로 그러한 정교함을 허용할 수 있다. 이러한 모든 해시 기반 방법론들에서, 보편적으로 데이터를 고유하게 식별하기 위해 해싱 기법에 내재된 약점으로 인해 해독 시도의 상태를 완전히 진술하는 것은 결정적으로 불가능할 수 있다. 결정적 방법 중 하나는 암호 해독된 메시지를 원본 메시지와 비교하여 동등한지 비교하는 것일 수 있지만, 긴 메시지들을 위해 효율성에 대한 절충안(trade-off)이 있을 수 있다.
도 28은 암호 변환의 출력 구조 포맷에서 헤더 스트링에 대한 파라미터 키워드 및 스펙들의 표를 도시한다. 이 속성 테이블을 위해 선택된 키워드는 당업자에게 충분히 설명될 수 있거나 그리고/또는 자명할 수 있다. 속성 값들의 예들은 오른쪽 열에 도시된다. 나열된 첫 번째 속성인 Header Size는 16 비트 2진 부호 없는 빅 엔디언 정수(big-endian integer) 값으로 표시될 수 있는 유일한 속성일 수 있으며, 그리고 헤더에 있는 첫 번째 필드일 수 있다. 이 헤더 크기는 이 특정 암호 변환의 속성들을 인쇄 가능한 형식으로 설명할 수 있는 바이트 수를 나타낼 수 있다. 속성 값 범위와 길이의 가변성을 허용하기 위해 속성 형식이 인쇄 가능하도록 선택되었을 수 있다. sal 값들(salt_val)과 MAC 스트링들(mac_val)을 포함하는, 실행중인 프로그램에서 자연스럽게 2진 스트링으로 존재할 수 있는 모든 속성값들은 인쇄 가능한 문자들의 기본설정(preference)을 만족시키기 위해 base64로 인코딩될 수 있다.
이러한 방식으로, 암호 변환의 출력 스트링은 선택된 scipher의 세부사항들에 의존하는 속성들의 하나 이상의 캡슐화 계층들을 포함할 수 있다. 도 29는 AEAD 모드 scipher 변환을 위한 반복적인 임베디드된 메시지 캡슐화의 예를 도시한다. AEAD 모드 AES 암호는 내부 레이어에서 외부 레이어로 나열된 다음 레이어들을 출력할 수 있다. 메시지 준비 계층(2910)은 적절한 salt 값(2912)과 결합된 암호화될 평문 메시지(2914)를 포함할 수 있다. 이러한 준비된 메시지(2910)는 선택된 AEAD 암호로 암호화될 수 있으며, 이 선택된 AEAD 암호는 암호화 프로세스의 일부로서 MAC 값 및 추가 데이터(2922)를 추가로 생성할 수 있으며, 이 결합된 메시지를 AEAD 암호 출력(2920)으로 지칭할 수 있다. 이 AEAD 암호 출력(2920)은 또한 암호화된 메시지(2934)로 지칭될 수 있다. 암호화된 메시지(2934)는 헤더(2932)를 생성하기 위해 도 28의 키워드/값 헤더 방법을 사용하여 파라미터화될 수 있는 scipher 프로세스로부터의 관련 속성들을 가질 수 있고, 이 조합은 scipher 패킹된 메시지(2930)로 지칭될 수 있다. 이러한 scipher 패킹된 메시지(2930)는 암호 변환을 호출한 TAR과 관련될 수 있는 NSstr 구조체(2940)의 obj 포인터 또는 변수(2944)에 저장될 수 있는 선택된 scipher 변환의 출력일 수 있다. NSstr의 구조는 이후 섹션에서 더 자세히 논의될 것이다. 또한, 다른 속성들(2942)은 TAR, 키스택, 다이제스트 및/또는 상태 플래그들을 포함하는 NSstr 구조체라 불리는 이 데이터 저장 유닛에 저장될 수 있다. NSstr 구조(2940) 내의 obj 포인터 또는 변수(2944)는 평문 메시지(2914)의 시작점이었을 수 있으며, 이에 따라, 반복 경로(2950)가 가능할 수 있고, 그리고 반복 경로(2950)는 그 자체가 NSstr 구조(2940)의 속성들(2942)에 저장될 수 있는, 그것이 처리 중일 수 있는 TAR에 의해 요구되는 만큼 많은 중첩된 캡슐화(nested encapsulation)를 위해 객체(2944)에 대해 존재할 수 있다.
scipher 패킹된 메시지(2930)의 헤더(2932)에서, 사용된 대칭 암호, 그것의 모드 및 속성 값들의 설명을 포함하는 파라미터들은 도 28에 열겨된 키워드들에 의해 완전하고 정확하게 기술될 수 있다. 이와 관련하여, TOP 접근법은 데이터를 보호하기 위한 비-암호화 프로세스들 및 절차들의 난독화 및 숨기기에 의존하지 않고, 오히려 변환으로 사용되는 암호의 이론적이고 구현된 보안에만 의존할 수 있다. 이것은 초기 관찰에서 중요하게 보일 수는 없겠지만, 변환 자체의 출력에 임베디드된 데이터 변환들의 관련 세부사항들의 이러한 명료성이 결국에는 그것을 적절히 처리하기 위해 하드와이어드된 프로그램들보다 자체 기술(self-describing) 데이터에 더 의존할 수 있는 새로운 방법론 및 디자인에 적합할 수 있다는 것이 나중에 보여질 수 있다. 이러한 접근법은 데이터 저장소 과학의 가장 낮은 계층들의 일부 데이터에서 작동하는 데이터 중심 디자인 및 데이터 중심 모델의 기본 요소 중 하나를 공식화하는데 도움이 될 수 있다. NUTS는 이후 섹션에서 도시될 수 있는 바와 같이 데이터 중심 설계와 모델들에 크게 의존할 수 있다.
도 30은 lock 변환에 대한 명령 스펙들의 표(3002) 및 그것의 사용법을 보여주는 샘플 변환 명령들의 세트(3010)를 도시한다. lock 변환은 도 12의 표에 나열된 추가 변환들 중 하나이며, 그리고 이는 도 65 내지 도 77에서 상세히 설명되는 바와 같이 NUTS로부터의 Variable Lock의 일 실시예일 수 있다. Variable Lock들은 sslock, orlock, matlock, xorlock 및 hashlock를 포함하는 비밀 메시지를 암호로 잠그는 여러 가지 서로 다른 방법들을 제시할 수 있다. Variable Lock들의 특징은 정규화되고 체계적이고 질서 있는 방식으로 비밀 메시지를 암호화하는 과정에서 여러 암호 키들을 입력하고 사용할 수 있는 기능이다. TOP 접근법은 간단하고 편리한 방식으로 그러한 잠금 기술을 구현하는 간결한 방법을 허용할 수 있다. 섹션(3010)의 예들에서, 변환 명령 'lock orlock 128 numkeys=10 scipherkeylen=128'은 바이트 데이터 스트링과 최대 10 개의 128 bit 동일한 대칭키들을 입력으로 사용할 수 있으며, 'scipher aes 128 mode=eax' 변환 명령을 사용하여 입력 스트링을 암호화할 수 있고, 그리고 암호문과 연관 임베디드된 속성들을 포함하는 출력 스트링을 생성할 수 있다. 변환 명령 'lock matlock 256 numkeys=5'은 바이트 데이터 스트링과 5개의 256 비트 대칭 키들을 입력으로 취하고, 각 키에 대해 'scipher aes 256 mode=eax' 변환 명령을 사용하여 입력 스트링을 반복적으로 암호화하고, 그리고 암호문과 관련 임베디드된 속성들을 포함하는 출력 스트링을 생성할 수 있다. 변환 명령 'lock sslock 256 numkeys=4 threshold='은 바이트 데이터 스트링과 적어도 두 개의 256 비트 ines256 비밀 공유 키들을 입력으로 받아들이며, 공급된 비밀 공유(secret share)들을 사용하여 Shamir의 Secret Sharing 방법의 구현을 사용하여 입력 스트링을 암호화할 수 있으며, 그리고 암호문과 관련 임베디드된 속성들을 포함하는 출력 스트링을 생성할 수 있다. 변환 명령 'lock sslock_b 256 numkeys=6 threshold=3'은 바이트 데이터 스트링과 적어도 3 개의 256 비트 tinesidx128 비밀 공유 키들을 입력으로 받아들이고, 공급된 비밀 공유들로 Shamir의 Secret Sharing 방법의 구현을 사용하여 입력 스트링을 암호화할 수 있으며, 그리고 암호문과 관련 임베비드된 속성들을 포함하는 출력 스트링을 생성할 수 있다. 변환 명령 'lock xorlock 128 numkeys=6'은 바이트 데이터 스트링과 6 개의 128 비트 대칭 키들을 입력으로 받아들이고, 공급된 키들에 대한 XOPR 연산들을 반복적으로 수행함으로써 계산된 키를 도출할 수 있으며, 그리고 암호문과 관련 임베디드된 속성들을 포함하는 출력 스트링을 생성할 수 있다. 변환 명령 'lock hashlock 192 numkeys=7'은 바이트 데이터 스트링과 7 개의 192 비트 대칭 키들을 입력으로 받아들이고, 공급된 키들의 순서화된 연결(ordered concatenation)에 대해 해시를 수행함으로써 계산된 키를 도출할 수 있으며, 'scipher aes 192 mode=eax' 변환 명령을 사용하여 입력 스트링을 암호화할 수 있고, 그리고 암호문과 관련 임베디드된 속성들을 포함하는 출력 스트링을 생성할 수 있다.
각각의 Variable Lock 유형 설명 및 작동 모드는 도 60부터 변화riable Lock에 대한 이후 섹션들에서 볼 수 있다. TOP 분석 및 방법들은 잠재적으로 복수의 암호 키들을 이용하여 간결한 논리적 방식으로 행해지는 복잡한 반복적인 잠금 변형들을 허용할 수 있으며, 그리고 장래에 다양한 유형의 잠금 알고리즘들을 쉽게 확장할 수 있다. 그리고, SDFT의 핵심 관리 측면은 프로그래머가 그러한 복수의 암호 키들을 비교적 편리하게 생성하고 비교적 쉽게 관리할 수 있게 한다는 것을 나중에 보여줄 수 있다.
도 12, 도 13 및 도 14에 제시된 바와 같이, TOP 분석 및 방법들은 당업자가 주어진 데이터 조작 함수를 취하여, 변환 작업 및 유형으로 표준화하기 위해 그 적합성을 결정할 수 있게 할 수 있다. 도 12의 표는 매우 잘 알려진 데이터 조작의 샘플링을 보여줄 수 있으며, 그리고 광범위한 개발자들에 의해 사용하기에 적절하다고 매우 잘 고려될 수 있다. 그러나, 이 표에서 데이터 조작 기능이 발견될 수 없는 경우, TOP 방법들을 사용하여 SDFT 프레임워크와 함께 작동하는 함수를 분석하고 조정할 수 있다; 비가역압축(lossy compression), 비트 스캐터링(bit scattering), 메시지 분산(message dispersals), 이레이져 코딩(erasure coding; ECC) 및 메시지 레벨 RAID 인코딩 및 구조화와 같은 기능을 포함하지만 이에 한정되지 않는 기능들. 그러한 변환 확장들의 대부분의 경우, 실제 데이터 조작 기능을 다시 코딩하거나 다시 쓸 필요가 없을 수 있다. 실제로, 그것은 대부분의 상황에서 그렇게 하기에는 비생산적이며 절차적으로 약할 수 있다. 데이터 조작 함수를 포함하는 라이브러리는 변환 라이브러리에 의해 액세스될 수 있으며, 그리고 TOP 방법은 개발자가 SDFT 프레임워크와 잘 작동하도록 특정 데이터 조작 함수를 중심으로 정규화 래퍼 함수(normalizing wrapper function)를 제공할 수 있게 한다.
변환 구조들, TAR(Transmutation Audit Records) 및 SDFT(Structured Data Folding with Transmutations)
도 31은 다양한 변환 구조들의 스펙들을 표 형식으로 나타낸 것이다. 구조적 정의는 Javascript 내에서 구조들이 정의되는 방식과 유사한 중첩된 키 기반 접근법에 의존한다. 이는 의도적인 디자인 선택일 수 있으므로, 그 표현이 다양한 프로그래밍 언어들로 쉽게 복제될 수 있고, 특정 언어의 특성들에 의존하지 않을 수 있다. 예를 들어, Python v3.6에서는 클래스들을 정의할 수 있지만, Javascript와 같은 일부 언어들은 정의할 수 없으므로, 변환 데이터 구조들은 적용 범위를 넓히기 위해 클래스들을 정의하기 위해 클래스들에 의존하지 않을 수 있다. 변환 구조는 잘 정의된 작업 메모리 영역을 제공하여, 변환의 입력들 및 출력들이 준비되고, 처리되고, 그리고/또는 저장될 수 있다. 전체는 아닐지라도 대부분의 변환 연산들에서 사용될 수 있는 주 데이터 저장 유닛 또는 구조는 NSstr 구조(3108)로 불린다. 변환 호출과 관련된 NSstr의 적어도 하나의 인스턴스가 존재할 수 있다. 모든 변환 구조들은 그것이 명시하는 구조가 무엇인지를 나타내는 'typ' 또는 구조 유형을 가질 수 있다. NSstr 구조는 구조 및/또는 그 데이터의 상태를 명시하는 '상태(state)' 필드를 더 정의할 수 있다. 'obj' 또는 객체 필드는 단일 값을 포함하거나 또는 메모리의 다른 영역을 참조하는 포인터일 수 있다. obj 필드는 대부분의 변환들에 대한 입력 데이터가 발견될 수 있는 곳일 수 있다. 또한 obj 필드는 대부분의 변환들의 출력 데이터가 발견될 수 있는 곳일 수 있다. '다이제스트(digest)' 필드가 존재한다면, '다이제스트' 필드는 obj 필드에 의해 저장되거나 참조되는 데이터의 다이제스트를 저장할 수 있다. 다이제스트가 생성되었을 수 있는 방식은 특정 dign 또는 다이제스트 변환 그리고 변환 명령에 공급된 파라미터들 및/또는 속성들에 의존할 수 있다. '키스택(keystack)'이 존재한다면, '키스택(keystack)'은 KISS(Key Interchange Specification Structure(이후 섹션에서 논의됨)) 구조의 단일 인스턴스일 수 있으며, 또는 그것의 운영 TAR에 상응하는 미리 결정된 순서의 KISS 구조들의 리스트일 수 있다. 키스택은 기본적으로 특정 변환들에 필요할 수 있는 다양한 유형이 비밀 키(들)를 보유한다. 'tar' 필드는 NStar 구조(3106)의 인스턴스를 가리킬 수 있다.
NStar 구조(3106)는 NSstr 구조의 obj 필드에 저장된 입력 데이터에 적용될 수 있는 특정 TAR(Transmutation Audit Record)를 명시할 수 있다. TAR은 NSstr 데이터의 단일 '폴딩(folding)'을 생성하기 위해 질서있게 그리고 잘-작동하는 방식으로 NSstr에서 데이터를 처리하기 위해 숙련된 순서로 정렬되었을 수 있는(knowledgeably sequenced) 논리적 순서의 변환 명령들의 모음일 수 있다. NSstr 데이터 구조에서 TAR을 'ravel' 함수 호출로서 수행하는 프로세스를 참조할 수 있다. 반대로, 'unravel' 함수 호출은 가역적인 변환들의 고유한 특성들에 의존하는 동일한 TAR을 사용하여 NSstr 구조 내에서 폴딩된 데이터의 조각을 '언폴딩'할 수 있다. 따라서, 변환의 가역성은 SDFT(Structured Data Folding with Transmutations)에서 핵심적인 특징이 될 수 있다. SDFT 방법은 NSstr 구조들에서 TAR들을 사용하여 데이터에 대한 어셈블리 라인 작업과 같이 객체를 반복적으로 변환할 수 있다. 분석이 TAR에서 각 변환 명령의 가역적인 동작에 대해 수행되었을 수 있으므로, 임의의 TAR는 리버스 모드에서 또는 unravel 함수 호출시 호출될 수 있다. 이러한 조작들을 가능하게 할 수 있는 추가로 필요한 구성 요소들이 다음 절에서 제시될 수 있으므로 이 주제는 보다 심도있게 논의될 수 있다.
NSbin 구조(3102)는 Python v3.6에만 관련이 있을 수도 있고 그렇지 않을 수도 있는 특정 함수를 제공할 수 있다. Python v3.6에서, 데이터 스트링이 내부적으로 저장될 수 있는 방식으로 구별이 이루어질 수 있다. 그것은 '바이트' 스트링 또는 문자 스트링으로 저장될 수 있다. 바이트 스트링 데이터 유형은 변수 내에 보유된 정보가 일련의 2진 바이트 데이터일 수 있음을 나타낼 수 있다. 문자 스트링은 변수 내에 보유되는 정보가 어떤 유형의 인코딩 기법에서 인코딩된 문자들을 나타내는 일련의 비트일 수 있음을 나타낼 수 있다. Python v3.6은 정교한 내부 관리 체계를 사용하여 특정 문자 스트링을 저장하는 방법을 가장 잘 결정할 수 있다. 왜냐하면, 서로 다른 인코딩들은 '문자'마다 다른 저장 요구사항들이 필요로할 수 있기 때문이다. 예를 들어, UTF-8은 각 문자를 나타내는데 8 비트 길이의 코드 단위를 사용할 수 있지만, UTF-16은 16 비트 길이의 코드 유닛들을 사용하여 각 문자를 나타낼 수 있다. 이러한 변형들은, 언어의 문자 수가 영어 알파벳과 상당히 다를 수 있고 8 비트 데이터의 순열에 맞지 않을 수 있는 상이한 국제 문자 세트를 전달하는데 필요할 수 있다. 변환들, TAR들 및 SDFT의 바람직한 내부 직렬화 방법은 JSON일 수 있으며, JSON은 Python의 '바이트' 데이터 유형을 고유한 것으로 매핑하기 위한 기본 지원(native support)이 없을 수 있다. 변환이 시도된다면, 특정 데이터 유형이 지원되지 않을 수 있다는 일부 표시와 함께 JSON 함수 호출이 갑자기 실패할 수 있다. NSbin 구조는 이러한 유형의 상황을 위해 특별히 설계될 수 있으며, 그리고 '바이트' 데이터 스트링으로 대체될 수 있으므로, Pyhon 변수 JSON를 호환 가능하게 할 수 있다. '바이트' 스트링은 base64 문자 스트링으로 인코딩될 수 있으며 NSbin 구조의 'b64' 필드에 저장될 수 있다. 이제 바이트 스트링 변수는 이 NSbin 구조를 가리키고, 원본 바이트 데이터를 덮어쓰게될 수 있다. 이것들은 동등한 데이터를 나타낼 수 있지만, 다른 인코딩들과 구조들을 가질 수 있다. 그러나, 최종 결과는 NSbin 구조가 완전히 JSON과 호환될 수 있으며, 그리고 이제 호환되지 않은 데이터 유형으로 인해 오류 없이 JSON 함수들을 사용하여 안전하게 직렬화될 수 있다는 것일 수 있다.
TOP 접근법에서, NSbin 구조 변환 및 대체에 대한 이러한 '바이트' 데이터는 도 12 및 도 33으로부터의 '프레스' 변환으로 지칭될 수 있다. Python v3.6에서, 표 3302에 나열된 press 변환은 유효한 Python 구조 또는 변수를 취할 수 있으며, 그리고 임의의 바이트 데이터 유형이 없는 Python 구조를 초래할 수 있는 동등한 NSbin 구조로 모든 바이트 스트링을 반복적으로 변환할 수 있다. 당업자는 그러한 데이터 직렬화 에러들의 소스들을 제거하기 위해 Python v3.6 이외의 언어에 대한 적절한 press 변환 및 그것의 JSON 함수 호출을 커스터마이즈할 수 있다. 'press'의 리버스 모드는 'depress'라고 지칭될 수 있으며, 원래 데이터 유형을 포함하는 데이터 구조가 복원될 수 있도록 반복적으로 변환 및 대체를 원상태로 돌릴 수 있다(undoing).
NSjson 구조(3104)는 완전히 JSON과 호환될 수 있는 데이터만을 보유하는 특유의 유용한 기능을 제공할 수 있다. Nsstr에 대해 정의된 필드들(3108)을 간략히 살펴보면, Python v3.6에서 다이제스트 필드가 소스 obj의 다이제스트 값을 이진 스트링 형식 또는 바이트 데이터 스트링 형식으로 잠재적으로 보유하기 때문에, 구조가 JSON 직렬화에 대해 직접 제출(submitted)된 경우 잠재적인 문제가 발생할 수 있음을 경고할 수 있다. 도 12를 다시 참조하고, 이러한 특정 문제에 대한 'mobius' 변환을 다시 도입한다. 이 설명에서 이 시점 이전의 mobius 변환에 대한 합리적인 정의는 변환의 얽힘(interwining) 특성과 TOP 접근법으로 인해 판독자에게 완전히 명확하지 않을 수도 있음에 유의한다. 도 32에서의 mobius 변환은 주어진 구조를 하나의 형태에서 다른 형태로 원형 방식으로, 그러나 뫼비우스 띠에서와 같이 약간의 꼬임을 가지면서 변환할 수 있다. mobius 변환은 NSstr 구조를 NSjson과 같은 JSON 직렬 가능한 구조로 체계적으로 변환함으로써 SDFT(Structured Data Folding with Transmutations)의 중요한 원동력이 될 수 있다. 변환 프로세스는 변환된 데이터와 함께 NSstr에 대한 동작 TAR을 전체적으로 임베딩할 수 있고, 이에 의해 결과적인 저장 가능한 객체에 자체-기술 특성을 부여할 수 있다. mobius 변환은 SDFT 라이브러리에서 구조화된 데이터 폴딩의 본질(essence)을 편리한 방식으로 수행하는 실시예일 수 있다. 개발자는 mobius 명령을 제외한 변환 명령들의 논리적 조합을 사용하여 SDF를 수동으로 수행하도록 선택할 수 있지만, mobius 명령은 개발자가 SDFT 라이브러리 외부에서 해당 단계를 수행해야할 것을 요구할 수 있는 적어도 하나의 추가 논리 단계를 추가한다 : 그것이 동작하고 잇는 NSstr 데이터 구조를 NSstr와 같은 다른 구조로 직렬화하는 기능. mobius 변환은 TAR에서의 마지막 변환 명령일 수 있다. 그 기능으로 인해, 이것은 mobius 변환이 배치될 수 있는 유일한 논리적 장소일 수 있다. mobius 변환이 처리될 때, 그것이 작동할 수 있는 NSstr 구조를 가져올 수 있고, 그리고 그것을 NSjson 구조로 변환할 수 있다. NSstr 구조에 내장된 TAR은 더 이상 유용하거나 액세스 가능한 형태로 존재할 수 없으며, 이에 따라, mobius 변환은 처리될 주어진 TAR의 마지막 변환 명령일 수 있다. 간단히 말해서, mobius 변환은 NSstr 구조를 누를 수 있고, JSON은 이를 직렬화한 다음, 그것을 저장되거나, 전송되거나, JSON 직렬화되거나, 폴딩되거나, 또는 그러한 구조들 상에서 수행될 수 있는 다른 유효한 데이터 연산이될 수 있는 NSjson 구조로 저장할 수 있다. mobius 변환에 대한 리버스 모드가 존재할 수 있지만, 이 변환을 보는 또 다른 방법은 그것이 원형 변환이라고 선언하는 것일 수 있다 : 포워드 또는 리버스 모드에 관계없이, 입력 데이터 구조 유형에 따라 특정 데이터 변환을 수행한다. 표(3204)는 NSjson이 변형일 수 있는 NSx 구조를 나타낸다. 미래에 도 31에 정의된 것 이외의 추가적인 변환 구조들이 필요하고 그리고 그것들이 mobius 변환에 수용될 필요가 있을 수 있다면, 이 표는 NSstr 이외의 임의의 변환 구조에 대해 mobius 변환이 어떻게 작용할 수 있는지를 예시한다. 실제로 SDFT로 프로그래밍하지 않으면 완전히 명확하지 않을 수도 있지만, mobius 변환은 복원된 NSjson 구조로부터 가능한 TAR 처리가 존재하지 않을 수 있다는 것을 논리적으로 암시할 수 있다. 단, mobius 변환이 그것을 폴딩했을 수 있는 TAR을 보유할 수 있는 원래의 NSstr 구조로 그것을 변환하기 위해 그것 상에서 동작될 수 없는 경우에 그러하다. NSjson 구조로 이 mobius 스핀 사이클을 개시하기 위해, mobius (리버스)는 SDFT 라이브러리로부터의 mobius 함수 호출로 킥스타트(kickstart)되어, NSstr 구조를 생성하고, 임베디드된 TAR에 액세스하고, 그리고 임베디드된 TAR을 역순으로 처리할 수 있다. 이것은 정의에 의해 리버스 모드에서 처리될 첫 번째 명령이 될 TAR에서의 mobius 변환 명령이 킥스타트 함수 호출에 의해 이미 수행되었을 수도 있기 때문에 처리 중에 안전하게 무시될 수 있으며, 이에 따라 그러한 리버스 동안 한 번 이상 mobius 기능을 수행하지 못할 수도 있다는 것을 더 의미할 수 있다. 이 시퀀스에서, 리버스 모드에서의 mobius 변환을 무시하지 못하면 NSstr을 NSjson으로 그리고 다시 NSjson을 NSstr로 연속적으로 변환하는 mobius 호출의 무한한 발진이 잠재적으로 생성될 수 있다. 그것은 그러한 동작들을 표현하는 순환적인 방식으로 보일 수 있지만, 상당히 압축된 양방향 TAR들을 생성할 수 있으며, 이는 출력 변환 데이터에 체계적으로 임베디드되어, 폴딩된 데이터에 자체-기술 특성들을 부여할 수 있다. 이 특성은 SDFT 라이브러리의 구현을 지원할 수 있는 임의의 언어 및/또는 운영 체제들에서 일관된 재생산 가능한 방식으로 데이터에 대한 작업들을 수행하기 위해 포워드 또는 리버스 모드 모두에서 해석되는 스크립트들과 비슷하게 작용할 수 있다는 점에서 새로운 점일 수 있다.
도 33은 press, clean 및 key 변환들(3302, 3304)에 대한 명령 스펙들의 표 그리고 그것의 사용법을 도시하는 샘플 변환 명령들의 세트(3310)를 도시한다. clean 변환은 NSstr 구조 내에서 일시적(transitory) 또는 임시적(temporary) 필드들을 삭제하는 하우스키핑 함수일 수 있다. 특정 변환들은 처리 중에 추가 임시 필드들이 필요할 수 있으며, NSstr 구조 내에 추가 필드를 생성하여 그것들을 저장하고 액세스할 수 있다. NSstr 내의 그러한 임시 필드들의 생성 및 사용은 TOP 접근법 내에서의 공존을 분석하고 임의의 다른 변환들의 적절한 기능과의 간섭을 최소화한 후에 신중한 방법으로 수행될 수 있다. 그것의 기능으로 인해 clean 변환에 대한 리버스 모드가 없을 수 있으므로, 안전하게 무시될 수 있다. NSstr 구조 내에 새로운 임시 필드를 제안할 때 이러한 리버스 의미가 고려될 수 있지만, 필드가 변환의 리버스 모드 처리에 존재하지 않을 수 있으므로, 리버스의 변환은 그것이 제대로 기능하기 위해 그 존재에 의존할 수 없다. clean 변환의 중요한 기능은 TAR의 처리에 사용되는 전체 키스택의 내부 복사본을 삭제하는 것이다. 또는, 키스택 내의 비밀 키들만을 삭제하고 KISS 구조를 키홀로 변환할 수 있다. 이것은 SDFT TAR 처리에서 가장 중요한 변환들 중 하나일 수 있다. 왜냐하면, 저장을 위해 NSstr을 준비하기 전에 NSstr을 적절하게 클리닝하지 못하면, 특정 TAR 처리에 사용되었을 수 있는 임의의 그리고 모든 암호화 키들을 저장할 수 있고, 그리고 그것이 부주의하게 평문에 폴딩된 데이터와 함께 저장될 수 있기 때문이다. 이 상황은 비밀 키들을 공개하고 폴딩된 데이터 내의 일부 또는 모든 암호화된 데이터를 손상시킬 수 있다. 이는 데이터 암호화의 의도된 목적이 아닐 수 있다.
표(3304)에서, 키 변환이 그것의 몇가지 연산들과 함께 도시된다. 이 변환은 SDFT의 키 관리 기능의 일부일 수 있으며, 그리고 주로 NSstr 구조의 타르 필드를 참조하여 키스택 필드에서 작동할 수 있다. 키 체크 변환은 저장된 TAR을 검사할 수 있으며, 그리고 키 템플릿의 목록을 생성할 수 있다. 키스택이 입력된 경우, 이것은 그러한 키 템플릿(template)들과 비교되어, 적절한 순서의 올바른 키 유형들이 입력 키스택에 제공되었는지 판단될 수 있다. 예를 들어, TAR이 키들을 요구할 수 있는 두 개의 키 변환들을 위해 두 개의 서로 다른 256 비트 대칭 키들을 필요로 한다면, 그러한 키들이 존재할 수 있다면 TAR이 그러한 키들을 포함하기 위해 키스택을 기대한다는 것을 나타내는 목록에서 'symmetric 256'이라는 두 개의 키 템플릿들을 생성할 수 있다. 표(3504)는 다양한 키 유형들 중 일부를 나열한다. 빈 키스택 또는 부분적으로 채워진 입력 키스택 또한 적절하게 처리될 수 있다. TAR가 몇 개의 키들을 필요로 하는 경우에 키스택이 입력되지 않으면, '키 생성' 변환을 나타낼 수 있다. SDFT는 키 생성 모드에 관여할 수 있으며, 이러한 키 생성 모드에 의해, 적절한 유형들의 키들은 파생된 키 템플릿들에 따라 생성되고, obj 필드에 저장된 데이터에 대한 TAR 처리 전에 작업 중인 NSstr 구조에 제출하기 위해 키스택으로 구성될 수 있다. 일부 '키 생성' 모드는 부분적으로 채워진 키스택이 입력될 수 있을 때 관여될 수 있다. 키 확인 및 생성 변환들은 키스택의 부분적으로 공급된 키들이 적절한 유형 및 적절한 순서로 존재할 수 있는지 여부를 협력적으로 결정할 수 있다. 그런 다음, 누락된 키들에 대한 적절한 키들을 생성하도록 진행할 수 있다. 이러한 프로세스는 SDFT 키스택 관리의 'missing teeth' 시나리오라고 지칭될 수 있다. 키 변환 명령들을 가진 TAR의 예들은 거의 없을 수 있다. 왜냐하면 이것은 TAR을 사용하는 NSstr 구조에서 SDFT 라이브러리의 적절한 작업에 매우 기본적이라고 간주될 수 있기 때문에, 프로그래머가 그것을 모든 TAR에 배치하도록 하기보다는 그것이 ravel/unravel 작업들에 대한 모든 호출에서 디폴트로 암시적으로 수행될 수 있기 때문이다. 암호화 키를 필요로할 수 있는 TAR를 처리할 가능성이 있음으로써, 일관성있게, 암시적으로, 그리고/또는 자동으로 적절한 키스택 관리에 대한 검사를 암시적으로 수행하는데 충분한 이유가 될 수 있다. TAR 리버스 프로세스는 적절하게 역순으로 키스택을 처리할 수 있다. 키스택 모드에서 derive 변환의 특이점들로 인해 문제들이 발생할 수 있는데, 이는 SDFT가 종속 변환들에 대한 TAR 그룹화라고 하는 이러한 상황들을 어떻게 처리하는지에 대한 이후 섹션에서 논의될 것이다.
도 34는 KISS(또는 Key Interchange Specification Structure)에 대한 표를 도시한다. 이 구조는 적어도 두 가지 작동 모드들을 가질 수 있다 : 키 또는 키홀. 키의 속성들은 표에 정의된 일부 또는 모든 필드들로 지정될 수 있으며, 그리고 필요에 따라 다른 키 속성들을 지원하도록 구조를 확장하기 위해 추가 필드들이 추가될 수 있다. 암호 연산들에 대한 TOP 접근법은 해당 변환에 필요한 정확한 키 유형을 지정하는 매칭 키홀을 요구하도록 각 암호 변환에 대한 관점(view)을 주장하는 것일 수 있다. 속성들은 키 자체에 대한 실제적으로 고유한 ID, 패스프레이즈 또는 패스워드에 대한 질문 또는 힌트, 키에 대한 설명 등을 포함할 수 있지만 이에 국한되지는 않는다. 키 값이 KISS 구조에 존재할 수 있다면, 이는 단지 키로 지칭될 수 있다. 키 값이 KISS 구조에서 누락된 경우, 키홀이라고 지칭될 수 있다. 이는 'ima' 필드의 값으로 표시될 수 있다. 필드 이름은 "I'm a" 키/키홀의 축약형일 수 있으며, 그리고 명확성을 위해 그런 식으로 읽힐 수 있다. 'In' 이란 열은 빈(blank) KISS 구조를 형성하고, 그리고 NSstr 구조의 입력 키스택에 그것을 배치하기 위해 키를 그곳에 삽입하기 위해 필요한 값들을 나타낼 수 있다. 'Gen'이란 열은 SDFT 라이브러리에서의 키 생성 변환 동안 자동으로 생성되고 채워질 수 있는 필드들을 나타낼 수 있다. TAR을 포함하는 SDFT 논의를 통해, 모든 키 참조들은 적절한 유형의 KISS 구조들과 동의어일 수 있다. 키스택이 처리되는 TAR의 특성들과 근접하게 일치할 수 있고, 그리고 변환 명령들을 적층하고 필요한 암호 키들을 특정 형식 및 시퀀스로 적층하는 이 방법이, 임의의 입력 데이터가 무한한 수의 변환 변이들, 변환들의 파라메트릭 변화 및/또는 연속적인 데이터 폴딩들을 통해 반복적으로 처리되도록 허용할 수 있다는 것이 명백할 수 있다. TOP의 설명의 이 시점에서, SDFT의 다양한 컴포넌트들의 서로 얽혀있는 성질을 이해하기시작할 수 있으며, 그리고 특정 부분에 대한 완전한 이해는 완전히 선형적인 방식으로 드러나지 않을 수도 있다.
도 35는 KISS 동작 모드(3502)에 대한 표, 키 유형/필드 생성 맵핑을 도시하는 매트릭스(3504), 그리고 키 유형 정의들(3506)을 도시한다. 표(3506)는 SDFT에 의해 인식되는 몇 가지 유형의 키들을 나열하지만, 필요에 따라 새로운 키 유형들이 추가되고 통합될 수 있으므로 이러한 유형들에만 국한되지는 않는다. 최소한 세 가지 키 유형들은 잘 알려진 기본 키 유형들을 사용하여 SDFT 라이브러리에 맞게 특별히 구성될 수 있으므로 설명이 필요하다. 키 유형 'symmetriclist'는 대칭 키들의 배열 또는 목록일 수 있으며, 단일 KISS 구조 내에서 키 값으로 저장될 수 있다. 이러한 키 유형은 lock 및 derive 같은 변환들을 지원할 수 있지만 이에 제한되지는 않는다. sslock 및 sslock_b라고하는 비밀 공유 lock 변환들은 각각 Shamir의 비밀 공유 알고리즘의 서로 다른 두 개의 구현들을 나타낼 수 있다. 잠금 sslock 변환은 256 비트 길이 키의 키 공유(key share) 및 내부 인덱스 번호를 포함하는 특정 형식의 비밀 공유들(secret shares)을 기대할 수 있다. 이것은 SDFT 라이브러리 내에서 'tines256' 키 유형으로 지칭될 수 있다. 잠금 sslock_b 변환은 256 비트 길이 키의 키 공유 및 내부 인덱스 번호를 포함하는 특정 형식의 비밀 공유들을 기대할 수 있다. 이는 SDFT 라이브러리 내에서 'tinesidx256' 키 유형으로 지칭될 수 있다.
표(3502)는 그것이 존재할 수 있는 두 가지 모드들, 즉 키(또는 변환) 또는 키홀에서 KISS 구조에 적용될 수 있는 특성들을 보여주는 매트릭스이다. 변환 (키) 모드에서, KISS 구조는 keyed digest들 및/또는 dign들을 포함할 수 있는 몇몇 버전의 암호문을 생성하기 위해 실제 암호 키를 저장할 것으로 예상될 수 있다. 따라서, 저장소는 정보적으로(informationally) 사용될 수 있지만, 그것을 안전한 방식으로 지속적으로 저장하기 위해 암호화 기능을 추가로 사용하여 임베디드되어야 한다. 키홀 모드에서, KISS 구조는 keyed digest들, dign들 및/또는 유도된 키들을 포함할 수 있는 몇몇 버전의 암호문을 생성하기 위해 적절한 암호 키를 그 값으로 받아들이기에 충분한 세부사항을 가질 것으로 예상될 수 있다. 따라서, 저장소가 필수적일 수 있으며, 키 값을 키홀로 포함할 수 없기 때문에 저장소는 임의의 임베딩 방법론에 의해 더 안전하게 보호될 필요가 없을 수 있다.
표(3504)는 어느 필드들이 키 유형에 의해 생성되고, 입력되고, 관련되고, 그리고/또는 필수적일 수 있는지를 나타내는 매트릭스이다. 표를 검토할 때, KISS 구조가 다양한 암호 연산들과 관련된 salt들을 보유할 수 있음이 명백할 수 있다. 이것은 scipher 임베디드된 헤더들에 대한 논의에 비추어볼 때 불필요할 수 있지만, salt에 대한 논의는 salt에 대한 전체 그림을 나타내지 않을 수 있다. 도 37에 도시된 바와 같이, 변환과 연관된 속성들(3704, 3714)의 지속성은 여러 데이터 저장소 영역들(3732, 3734, 3736 및 3738) 사이에 분산될 수 있다. TOP 접근법은 생성된 암호문에 대한 추가 정보가 나타나지 않을 수 있으므로, salt들이 결과적인 출력 데이터와 함께 특정 암호화 연산들에 임베디드될 수 있음을 보여주었다. 그러나, 키스택 모드에서 처리되는 키 유도 변환들을 검사할 때, KISS 구조에 관련 salt 값을 저장하는 것이 편리하고 논리적일 수 있음을 알 수 있다. 키 유도 함수를 사용하는 일반적인 방법은 패스프레이즈를 입력으로 받아들이고, 그것을 salt 값과 결합하여, 대칭 키와 같은(그러나 이에 한정되지 않음) 적절히 형성된 암호화 키를 생성하는 것일 수 있다. 이 경우 salt의 사용은 의미론적 안정성(semantic security)을 위한 것일 수 있다. 따라서, 동일한 패스프레이즈를 허용할 수 있는 모든 키홀은 결과적인 비밀 암호 키가 어떤 합리적인 이유에서든지 서로 다를 수 있도록 서로 다른 salt를 가질 수 있다는 것은 전적으로 가능할 수 있다. 이러한 유도된 키는 임시 방식으로 사용될 수 있으며, 사용 후에 버려져서, 키홀을 그 존재의 증거로 남겨둘 수 있다. 키 유도의 생성물이 비밀 키로 사용될 수 있어서 일반적으로 영구적으로 저장되지 않을 수 있기 때문에, 이러한 질문을 할 수 있다 : 우리는 그것을 어디에 저장할 수 있을까? TOP는 그것을 대응하는 키홀에 저장할 수 있으며, 그리고 SDFT가 폴딩된 데이터와 함께 이 키홀을 저장함으로써, 동일한 패스프레이즈를 수용할 수 있는 각 키홀이 salt 값의 자체 인스턴스에 대해 적절한 저장소를 가질 수 있는 것을 선호할 수 있다. 프로그래머는 KISS 키홀들을 완전히 다른 방식으로 외부 방식으로 저장할 수 있다. 도 5의 것과 동일한 도 37의 상부에 있는 단순화된 변환 다이어그램은 TOP와 SDFT의 다양한 컴포넌트들이 도입될 때 도 37의 하부에 있는 다이어그램과 유사해진다. 표(3720)는 속성들의 배치를 요약한다.
TOP 및 SDFT를 통해 분석되고 사용 가능한 변환 명령들의 구문 및 다양성과 관련하여 이전에 많은 부분이 설명되었지만, 실제로 TAR은 어떻게 생겼을까? 도 36은 TAR의 구조를 도시하고, TAR들의 몇 가지 예들을 나열한다. 섹션(3602)은 TAR(또는 Transmutation Audit Record)의 일반적인 구조를 규정한다. 'tar label01' 선언은 바로 아래에 정의되는 TAR의 이름 또는 레이블을 나타낸다. 모든 TAR 명령들은 TAR 라벨 선언을 따르며, 빈 라인은 현재 TAR 정의의 끝을 나타낸다. 따라서, 많은 TAR들이 하나의 텍스트 파일에 선언될 수 있다. TAR 정의 섹션은 자체적으로 또는 변환 명령으로 라인에 TAR 레이블들을 포함할 수 있다. 이것은 프로그래밍 언어 컴파일러의 매크로 기능들과 유사할 수 있다; TAR 자체에 정의를 실제로 복사할 필요 없이 잘 알려진 TAR 구문들을 새로운 TAR과 결합하는 편리한 기능으로 사용될 수 있다. 변환 명령들은 특정 순서로 삽입되어 원하는 방식으로 타겟 NSstr 구조를 처리할 수 있다. TAR 'test_a01'은 단지 Python 데이터 객체를 임의의 Python 바이트 데이터 유형이 없는 동등한 구조로 밀어넣을 수 있다; 다른 언어의 경우, 'press'는 언어 및/또는 환경에 따라 다를 수 있으므로 동일한 기능을 수행할 수도 있고 수행하지 않을 수도 있다. TAR 'test_a02'는 press 변환을 두 번 연속 수행한다. 두 번째 press 변환은 데이터에 아무런 기능적 변경을 수행하지 않을 수 있다. 이것은 작업시 TAR 확장을 보여준다. TAR 'test_a07'은 데이터를 press하여 JSON 스트링으로 직렬화한 다음, uft_32 인코딩을 사용하여 바이트 유형의 이진 스트링으로 변환할 수 있다. TAR 'test_a17'은 종료되는 mobius 변환이 어떻게 보일 수 있는지 보여준다. TAR 'test_a20'은 데이터를 press하여 JSON 스트링으로 직렬화한 다음, utf_8 인코딩된 이진 스트링으로 변환하고, 256 비트의 대칭 키로 chacha20을 사용하여 그것을 암호화한다음, 결과물인 이진 암호문 스트링을 base64 인코딩된 문자 스트링으로 변환한다. scipher 변환에 대한 대칭 키는 256 비트 대칭 키 값을 보유하는 단일 KISS 구조를 포함할 수 있는 NSstr의 키스택에서 예상될 수 있다. 대안으로, 키스택이 제공되지 않을 수 있고, ravel 함수는 적절하게 생성된 랜덤 256 비트의 대칭 키를 사용하여 유효한 키스택을 생성하도록 진행하고, 이를 사용하여 scipher 변환을 수행하고, 그리고 완료시 프로그래머가 키스택의 복사본(이에 따라 그 내부에 있는 키)을 가져올 수 있게 할 수 있다. TAR 'test_a42'은 TAR 그룹들 및 종속 변환들의 예를 보여준다 : 이것은 데이터를 press하여 JSON 스트링으로 직렬화하고, 그것을 utf_8로 인코딩된 이진 스트링으로 변환하고, 키스택에 공급된 패스프레이즈로부터 256 비트 대칭 키를 도출한 다음, 상기 도출된 대칭 키를 사용하여 데이터에 대해 chacha20 암호화를 수행할 것이다. 마지막 두 변환들은 암호가 상기 도출된 키에 의존하므로 영구적인 종속성을 가질 수 있다. 따라서, 이러한 종속성은 선행 <tags>이 이와 같이 마킹된 TAR 내에 그룹화될 수 있다. 포워드 모드에서, 시각적인 방법으로 그러한 의존성들을 강조하는 것을 제외하고는 TAR 정의 내에서 TAR 그룹화들의 명백한 영향이 없을 수 있다. 그러나, TAR 그룹들은 TAR 리버스와 관련하여 중요한 역할을 할 수 있다. TAR이 TAR 리버스 프로세스를 위해 준비중일 때, TAR 그룹들은 하나의 단위로 손상되지 않고 유지될 수 있으며 그 구성물들은 리버스되지 않을 수 있다. 도 41 및 도 42는 TAR 리버스들의 여러 예들을 도시한다. TAR 'test_a64'는 5회의 scipher 변환들과 DSS dign 변환을 수행할 수 있다. 이러한 TAR은 특정 순서로 다양한 유형들과 길이들의 6 개의 키들로 채워진 키스택을 기대할 수 있다. 섹션(3610)에 예시된 것은 TAR 'test_a64'에 대응할 수 있는 키 템플릿의 단순화된 표현일 수 있다. 이 키 템플릿은 암시적 키 확인에 의해 사용될 수 있으며, 그리고/또는 임의의 입력 키스텍들을 검증하기 위해 변환들을 생성할 수 있으며, 그리고/또는 TAR의 적절한 처리를 위해 유효한 키스택을 생성할 수 있다.
도 38은 SDFT 동작 ravel 및 unravel(또는 ravel의 리버스)의 블록도들을 도시한다. SDFT에서의 두 가지 중심 연산들은 'ravel'과 그것의 인버스인 'unravel'일 수 있다. ravel 연산은 다음의 항목들 중 일부 또는 전부를 포함할 수 있는 주어진 NSstr을 처리할 수 있다 : 데이터, TAR, 키스택 및/또는 다른 속성들. ravel 연산은 3802 내의 TAR에 열거된 변환들의 시퀀스에 따라 3802 내의 소스 데이터를 'ravel' 또는 폴딩(folding)(3810)할 수 있으며, 결국 NSstr 구조(3804) 또는 NSjson 구조(3806) 내의 컴포넌트로서 출력을 생성할 수 있다. unravel 연산은 임베디드된 TAR에 나열된 변환들의 리버스 시퀀스에 따라 소스 NSstr(3804) 또는 NSjson(3806) 구조를 'unravel' 또는 언폴딩(3820)할 수 있으며, 결국 NSstr 구조(3802)로서 출력을 생성할 수 있다. 도시될 바와 같이, ravel/unravel의 대칭은 이러한 설계의 흥미로운 측면일 수 있다. TOP 전체에서 사용될 수 있는 용어와 관점들의 일관성에 유의한다. 리버스의 ravel 작업은 unravel과 동일할 수 있다. 이러한 가역성 원칙은 그러한 기능의 분석을 단순화할뿐만 아니라, 모듈형 조직화 방법을 퍼뜨려서 데이터의 변환에 관련된 고차원 개념으로 이끌 수 있다.
도 39는 SDFT ravel 작업의 흐름도를 도시한다. NSx 구조가 주어지면, ravel 함수 또는 메소드 호출은 호출과 함께 제공되는 파라미터들 및/또는 NSx(이 경우 'x'는 임의의 변환 구조를 나타냄) 내에 임베디드된 TAR을 이용하여 포함된 데이터에 대해 다음 작업을 수행할 수 있다. 키 확인/생성 변환들과 유사하게, mobius 변환은 이 알고리즘에서 매우 기본적인 것으로 간주되어, 조건이 충족되면(3906) 임의의 입력 데이터 구조에 대해 암시적으로 수행될 수 있다. Ravel은 NSstr 구조에 대해 핵심 연산들(core operations)만 적절하게 수행할 수 있으므로, NSstr 구조가 아닌 NSx 구조가 통과될 수 있다면, NSx 구조는 NSstr 구조로의 변환을 시도할 수 있다(3918). 유효한 NSstr을 생성하지 못하면(3924), 적절한 오류 코드가 발생하고(3978), 갑자기 프로세스가 종료될 수 있다(3984). 내부 데이터가 ravel되거나 폴딩될 수 있는 적어도 세 가지 방법들이 존재할 수 있다: 첫 번째로, 유효한 NSstr 내에서, NSstr 구조 내의 데이터에 대해 수행할 변환 순서들을 나타내는 포함된 TAR이 존재할 수 있다; 두 번째로, TAR 레이블의 이름은 파라미터로서 ravel 호출에 전달될 수 있으며, 이에 의해, NSstr 구조 내의 데이터에 대해 수행할 변환들의 선호되는 세트를 나타낼 수 있다; 세 번째로, 커스터마이징된 TAR 리스트는 ravel 호출 내의 주어진 이름과 함께 파라미터로서 전달될 수 있고, 이에 의해, NSstr 구조 내의 데이터에 대해 수행할 변환들의 선호되는 세트를 나타낼 수 있다. TAR(3912)의 준비는 다른 TAR 레이블 참조들을 확장하는 것 그리고/또는 포워드 또는 리버스일 수 있는 순회(traversal) 모드를 위해 이를 적절히 순서화(ordering)하는 것을 포함할 수 있다. 도 41 및 도 42는 TAR 리버스들의 몇 가지 예들을 도시한다. 그 다음, 키 확인 변환은 TAR 및 NSstr 구조에서 효과적으로 수행될 수 있다. 키 확인 변환의 컴포넌트는 TAR(3930)을 검사함으로써 키 템플릿들의 리스트를 유도하는 것일 수 있다. TAR, (비어있거나 또는 부분적으로 채워질 수 있는) 입력 키스택 및/또는 키 템플릿들을 사용하여, 프로세스는 TAR 3936의 적절한 순회(traversal)를 위해 키스택을 구성할 수 있다. 이는 올바른 유형의 누락 키들을 생성, 올바른 순서로 키들을 차례로 배열, 그리고/또는 입력 키들을 적절한 구조 및 유형에 대해 검사를 포함할 수 있다. 입력 키 유형들 및 대응하는 유도 키 템플릿들의 임의의 불일치는 오류 조건(3942)을 생성하여 적절한 오류 코드(3978)를 발생시키고, 프로세스를 갑자기 종료시킬 수 있다(3984). 프로세스는 이제 적절한 시퀀스의 TAR의 각각의 변환 명령들에 대해 반복하고(3948), 그리고 NSstr 내에 포함된 데이터에 대해 지정된 변환을 수행(3954)할 수 있다. 변환 명령 실행 동안 마주칠 수 있는 임의의 오류는 적절한 오류 코드를 발생시킬 수 있고(3978), 그리고 프로세스(3984)를 갑자기 종료시킬 수 있다. TAR 시퀀스의 끝이 에러 없이 도달되면(3948), ravel 작업은 성공으로 간주될 수 있고(3966), 프로세스는 정상적으로 종료될 수 있다(3972).
도 40은 SDFT unravel 작업의 흐름도를 도시한다. unravel 프로세스를 상세히 기술하기보다는, 도 39와 도 40의 흐름도를 비교함으로써 변환들의 가역성의 대칭성을 설명할 수 있다. 두 흐름도들 간의 유일한 차이점은 TAR 준비 단계들(3912 및 4012)일 수 있다. 모든 변환이 양방향으로 잘 작동하는 방식으로 수행하기 위해 TOP를 사용하여 분석되고 구조화되었을 수 있으므로, TAR이 제시될 수 있는 방법을 제외하고는 unravel 프로세스들이 ravel 프로세스와 크게 다를 필요가 없을 수 있다. 동일한 코드로 구현될 수 있지만, 리버스 플래그가 표시될 때 약간의 편차를 가질 수 있으며, 그리고 발생시(encountered) TAR의 적절한 리버스 시퀀싱을 수행할 수 있다. Python v3.6에서 이러한 호출은 'obj.ravel(…, reverse=True)' 형식을 취할 수 있다. 대칭은 실제 구현된 코드를 훨씬 더 작게 만들 수 있으며, 그리고/또는 프로그래밍 오류에 대한 기회가 적을 수 있다. 개념적 이점은 특정 목적을 위해 새로운 TAR들을 구성할 때 명확하고 단순한 사고방식일 수 있다 : 프로그래머는 제한 조건 내에서 완전히 가역적일 수 있는 적절한 TAR 시퀀스에 의존할 수 있으며, 애플리케이션의 해당 부분을 많이 고려하지 않아도 된다. 프로그래머가 더 이상 이러한 데이터 조작들의 리버스 코드를 생성할 필요가 없기 때문에, 특정 데이터 변환 세트를 작성하기 위한 프로그래머의 작업 부하가 효과적으로 감소할 수 있다는 이점이 있을 수 있다. 복잡한 암호화 및 잠금 메커니즘들을 구축하려면 많은 수의 암호화 키들을 사용하는 엄청난 수의 데이터 조작들이 필요할 수 있다. TOP(Transmutation Organizing Principle) 방법들은 오류가 발생하지 않는 별개의 방식으로 이러한 복잡성에 접근하는 보다 밀접하고 통합된 방법들을 달성하는데 도움이 될 수 있다. 따라서, 보다 일관성 있고, 신뢰성 있고, 안전하고, 이식 가능하고(portable), 이해할 수 있고, 포괄적이고, 융통성 있고, 확장 가능하며, 그리고/또는 복잡한 코드 및/또는 데이터를 허용할 수 있지만, 이에 국한되지는 않는다.
도 43은 TAR 프로세싱 동안 생성 또는 요구할 수 있는 키 유형 템플릿에 매핑된 변환들의 표를 도시한다. 키 관리에 대한 논의로 돌아가서, 키 관리의 주요 동작들 중 하나는 주어진 TAR을 분석하고 주어진 TAR의 성공적인 처리에 필요할 수 있는 각 키의 유형 및 스펙들을 상세하게 설명할 수 있는 키 유형 템플릿들의 대응 목록을 생성하는 것이다. 표(3506)는 SDFT에서 정의된 적어도 9가지 유형의 키 유형들을 나열한다. 표(4300)는 각 변환 동작의 매핑을 보여주며, 이는 ravel/unravel 프로세스에서 요구할 수 있는 키 및 대응 키 유형 또는 'keytyp'을 필요로 할 수 있다. 키 템플릿은 키 길이 또는 'keylen'과 같은(그러나 이에 국한되지 않음) 각각의 키 유형과 연관된 여러 속성들을 가질 수 있다. 간결함과 단순화된 설명을 위해, 우리는 256 비트 길이의 대칭 키가 'symmetric keylen=256' 또는 'symmetric 256'으로 표현될 수 있는 키 템플릿을 갖는 것으로 나타낼 수 있지만, 실제 구현들에서는, 조직적인 방식으로 그러한 값들을 저장하기 위해 프로그래밍 언어에서 사용 가능한 데이터 구조 메커니즘들을 활용할 수 있다. Python v3.6에서, 키 템플릿에 대한 가능한 구조는 어레이의 각 사전 항목(dictionary entry)이 사전 키에 대응하는 각 속성과 해당 키와 연관된 값에 대응하는 속성 값을 갖는 단일 키 템플릿을 사전에 저장하는 사전들의 배열로 표현될 수 있다. SDFT 내에서, 모든 키 템플릿들은 임시 구조들일 수 있으며, 그리고 키 확인 변환을 통해 반복적인 재생성을 받을 수 있으며, 그리고 그러한 키 템플릿들을 영구적으로 저장할 필요가 없을 수 있다. 이러한 방식으로, SDFT는 키 유형/구조 비호환성으로 인해 암호화 변환이 완전히 실패하도록 하기 전에 처리를 위해 키 스택에 삽입된 키들을 적절히 분석할 수 있다. TOP 및 SDFT의 보편적인 주제는 데이터 조작 시퀀스들의 난독화(obfuscation)가 민감한 페이로드들을 안전하게 유지하는데 신뢰할 수 있는 컴포넌트일 수 있는게 아니라 오히려 선택된 암호의 강도 및 작동 속성들 및/또는 특성들로 귀속(relegate)될 수 있다는 견해일 수 있다.
도 44는 TAR 예들 그리고 각각으로부터 생성된 키 템플릿들을 도시한다. 표(4402)의 왼쪽 열은 TAR 예 'A'를 나열한다. 오른쪽 열은 속성 입력으로 암호 키를 필요로 할 수 있는 각 변환 명령에 대해 생성된 키 유형 템플릿들을 나타낸다. 이 예에서, TAR 'A'는 표시된 순서로 두 개의 암호화 키들을 요구할 수 있다. 표(4404)의 왼쪽 열은 TAR 예 'B'를 나열한다. 오른쪽 열은 입력으로 암호 키를 필요로 할 수 있는 각 변환 명령에 대해 생성된 키 유형 템플릿들을 나타낸다. 이 예에서, TAR 'B'는 표시된 순서로 4 개의 암호화 키들을 요구할 수 있다. 이 프로세스는 TAR로부터의 키 템플릿 생성이라고 할 수 있다.
도 45는 TAR 예들 및 각각으로부터 생성된 키 템플릿들 그리고 입력(put) 또는 생성(gen)될 KISS 구조들의 예상 목록을 도시한다. KISS들의 목록은 키스택이라고도 한다. 우리는 도 44에서 두 가지 예를 들 수 있으며, ravel/unravel/ 호출의 키 관리 측면에서 다음 단계를 보여줄 수 있다. 키 스택은 4510에 의해 도시된 바와 같이 각각의 키 유형 템플릿에 대응하는 KISS 구조들의 목록의 형태로 예상되거나 생성될 수 있다. TAR 'A' 처리가 'scipher salsa20 256' 변환 명령에 도달하면, 이 처리는 KISS A1에 의해 표시된 바와 같이 키 스택에 입력된 256 비트 길이의 대칭 키를 찾을 것으로 예상할 수 있다. TAR 'A' 처리가 'dign dss 1024 digestlen=512' 변환 명령에 도달하면, 처리는 KISS A2에 의해 표시된 바와 같이 키 스택에 입력된 1024 비트의 dsa 키를 찾을 것으로 예상할 수 있다. TAR 'B'에 대한 KISS 목록은 유사한 방식으로 읽히고 이해될 수 있다. 그러한 예상 키가 키 스택에서 발견되지 않으면, TAR 처리는 생성된 키가 대신 발견될 것으로 기대할 수 있다. 이러한 암시된 키 생성은 프로그래머에서 유익할 수 있다. 주어진 keyed 변환에 대해 임의의 유형의 허용 가능한 키를 생성하기 위한 유일한 요구사항은 TAR 내에서 그것을 선언할 수 있어야한다는 것이기 때문이다. 특정 암호화 기능을 위한 특정 키를 생성하는데 필요한 추가 단계들이 없을 수 있다. 비어있는 키 스택이 있는 ravel을 호출하면 적절하게 생성된 키들을 갖는 완전히 호환되는 키스택을 보유하여 TAR과 매칭하고 내부 데이터를 폴딩할 수 있는 출력 NSstr 구조가 야기될 수 있다. KISS 구조들로 구성된 이러한 키스택이 폴딩된 데이터와는 별도로 안전한 방법으로 저장될 수 있는 것이 좋으며, 그리고/또는 어떤 방식으로든 더 수정될 수 있으며 그리고 다시 폴딩되고 암호화 변환을 가져서 그것을 추가 암호화하는 TAR을 사용하여 보호(secured)될 수 있는 것이 좋다. 키스택들의 반복 암호화 및 캡슐화는 관리 및 보호를 위해 많은 암호화 키들을 다룰 때 유용할 수 있다. TAR 'B'는 4개의 KISS들의 키스택을 생성할 수 있으며, 그리고 전체 키스택을 키 저장소에 안전하게 저장하는 것이 편리할 수 있다. 그러나, 프로그래머는 편리성을 위해 단일 키를 사용하여 4 개의 키들의 키스택을 암호화하길 원할 수 있다. 이는 새로운 NSstr을 생성하고, 4 개의 키들의 키스택을 데이터 obj 필드에 삽입하고, 적절한 암호화 TAR을 선택하고(picking), 그리고 NSstr 구조에서 ravel 호출을 수행함으로써 달성될 수 있다. 이러한 일련의 단계들은 4 개의 키들의 키스택을 보유하는 폴딩된 NSstr 구조에 대한 잠금 키를 포함하는 단일 KISS 구조를 갖는 키스택을 생성할 수 있다.
도 46은 SDFT TAR 처리 내의 3 가지 키스택 동작 모드들을 도시한다 : 생성(gen), 입력(put) 및 주입(mixed). 섹션(4600)은 TAR 예 'B'의 처리에서 키스택(4602)이 비어있을 때 발생할 수 있는 것을 설명한다. ravel 프로세스는 TAR 'B'에 대한 키 유형 템플릿(4508)을 취할 수 있고, 그리고 4604에서 도시된 바와 같이 키 유형 템플릿에서 발견되는 것과 동일한 순서 및 동일한 유형의 무작위로 생성된 적절한 수의 암호화 키들을 생성할 수 있다(4606). 섹션(4610)은 키스택(4612)이 TAR 예 'B'의 처리에 입력(put)될 때(4616) 발생할 수 있는 것을 설명한다. ravel 프로세스는 TAR 'B'에 대한 키 유형 템플릿(4508)을 취할 수 있고, 그리고 제공된 키스택(4612)에 대해 이를 검사하여, 키의 수, 유형 및 순서를 검증한 다음, 4614에 도시된 바와 같이 TAR 'B'의 처리 동안 그것을 사용할 수 있게 할 수 있다. 섹션(4620)은 오직 하나의 키 KISS B3(또는 부분적으로 채워진 키스택 또는 'missing teeth' 시나리오라고도 지칭됨)이 제공되는 TAR 예 'B'의 처리에 키스택(4622)이 제시될 때 발생할 수 있는 것을 설명한다. ravel 프로세스는 TAR 'B'에 대한 키 유형 템플릿(4508)을 취할 수 있고, 제공된 키스택(4622)에 대해 이를 검사하여, 키들의 수, 유형 및 순서를 검증할 수 있다. 키스택 엔트리에 대한 각각의 키 유형 템플릿의 반복적인 검증 동안, 임의의 비어있는 KISS 구조는 특별한 유형의 검증 실패로 간주될 수 있고, 그 키 유형 템플릿에 대한 암시적인 키 생성 변환으로 더 해석될 수 있다. 그 다음, ravel 프로세스는 적절한 유형의 새로 생성된 키를 키스택의 빈 위치에 삽입하고(4626), 그리고 키 유효성 검증 반복을 계속할 수 있다. 이 단계를 완료하면, 4624에 도시된 바와 같이 TAR 'B'의 처리 중에 혼합된 키스택(입력 및 생성된 키들, missing teeth 시나리오, 또는 키 주입의 혼합으로 지칭될 수 있음)이 제시되고 사용될 수 있다.
도 47은 데이터 및 그것의 TAR의 라이프 사이클에서 키 스택들이 어떻게 생성되고 사용될 수 있는지를 도시한다. 데이터(4700)에 대한 SDFT의 사용은 그것이 특정 TAR(4702)에 의해 정의된 바와 같은 변환들의 가변적인 세트에 따라 규칙적인 방식으로 반복적으로 변환되도록 허용할 수 있다. TAR은 암호 키 유형 분석을 허용하고 이에 따라 TAR에 필요한 키의 수와 유형을 자세히 설명하는 키 템플릿들을 생성하는 방식으로 구조화될 수 있다. 그 다음, 키 템플릿은 입력 키 스택의 구성(4704)에서 모든 필수 키들이 존재할 수 있는지, 일부 필수 키들이 존재할 수 있는지, 또는 필수 키들이 없을 수도 있는지 여부에 관계없이 참조될 수 있다. 필요한 암호화 키가 누락될 수 있을 때, 구성 프로세스(composition precess)는 사용하기 위해 새로운 키를 생성할 수 있다. 그 다음, TAR, 데이터 및 키스택은 TAR에 따라 구조화된 데이터의 폴딩을 수행하기 위해 ravel 호출(4706)에 전달될 수 있다. 그 다음, 폴딩된 데이터는 임의의 수단에 의해 저장될 수 있다(4708). 키스택의 키들은 별도의 안전한 위치에 저장될 수 있다(4710). 폴딩된 데이터가 참조될 필요가 있을 때, 애플리케이션은 자신의 저장소에서 그것을 검색할 수 있고(4712), 그 보안 저장소(4714)에서 키 또는 키스택을 검색할 수 있고, 폴딩된 데이터 및 키스택을 unravel 호출에 전달할 수 있고(4716), 그리고 unravel 출력 구조로부터 원래 형태의 데이터에 액세스할 수 있다(4702). 이는 SDFT(Structured Data Folding with Transmutations)의 완전한 한주기를 나타낼 수 있다. 임의의 데이터 구조가 변환되고 폴딩될 수 있는 다른 많은 경로들이 있을 수 있지만, 본질적으로 SDFT 내에서 원래 데이터를 완전히 검색하려면 이 주기의 일부 형태를 완료해야할 수 있다.
키들 또는 키스택의 저장(4710)은 보다 적은 키들, 단지 하나의 키 및/또는 상이한 키들로 그것을 보호하기 위해 암호화 TAR을 이용하는 키스택의 폴딩을 수반할 수 있다. 폴딩된 키스택 데이터는 결국 자체적으로 폴딩될 수 있는 다른 구조의 일부가 될 수 있다. 데이터가 캐스케이딩(cascading) 방식으로 반복적으로 폴딩되어, 정밀한 부분적(piecemeal) 폴딩이 정밀한 부분적(piecemeal) 암호화들로 이어질 수 있는 내부 데이터 구조들을 구축할 수 있다. 복잡한 암호화 데이터 변환들을 정확하고, 조직적이고 및/또는 체계적인 방식으로 유도할 수 있는 이러한 능력은 보다 정교한 변환 방식들을 사용하여 민감한 데이터를 보호하기 위한 보다 우수하고 그리고/또는 간단한 설계로 이어질 수 있다. TAR 구문의 단순성과 명료성으로 인해 타인이 타겟 데이터에 수행하는 작업들을 더 잘 이해할 수 있다.
SDFT의 중요한 이점은 4704 및 4714에서와 같이 주어진 데이터 조각에 대한 다양한 암호화 연산들을 결합하는 맥락에서 키 관리를 체계적으로 처리하는 것일 수 있다. 프로그래머는 각각의 키를 생성하고, 그러한 프로세스들 동안 저장 및/또는 시퀀싱을 수동으로 조작하는 사소한 일에서 다소 벗어날 수 있다. 암호화 함수들을 적용할 때, 이러한 사소한 일들은 빠르게 추가되어, 애플리케이션(이에 따라 프로그래머)이 추적, 분석, 저장 및/또는 사용해야하는 대량의 작은 세부사항들이나 속성들이 될 수 있다. SDFT 방법들은 주어진 애플리케이션이 암호화 함수들의 더 적은 개별 특성을 추적, 분석, 저장 및/또는 사용하도록 허용할 수 있다. 왜냐하면, 이는 이러한 속성들이, 그것이 작동되고 출력으로 생성되는 데이터 및/또는 키스택의 컨텍스트(context) 내에 임베딩되도록 허용할 수 있어서, 폴딩된 데이터를, 그것을 폴딩했을 수 있는 변환들과 함께 쌍으로 결합할 수 있기 때문이다. 애플리케이션에서 데이터로 데이터 조작 지침들(data manipulation instruction)을 이식하면 보다 단순한 애플리케이션들 및/또는 암호화 함수들을 보다 정교하게 사용하는 애플리케이션들을 사용할 수 있다. SDFT는 NUTS 섹션에서 논의되는 것처럼 SCP(Structured Cryptographic Programming)를 표현하는 더 나은 대안을 가능하게 할 수 있다.
도 48은 NSstr 구조에 저장된 데이터에서 발생할 수 있는 작업들을 도시한다. 포인터에 의해 참조되고 그리고/또는 변수에 저장되는 임의의 데이터(4802)는 인스턴스화 방법을 사용하여 그리고/또는 방법/함수 호출을 사용하여(4804) NSstr 구조에 직접 캡슐화될 수 있다(4812). 그 다음 ,NSstr 구조(4810)는 TAR(4814), 그리고 필요하다면 그것의 속성들(4816)을 캡슐화할 수 있다. 속성들은 키스택, 다이제스트, 변환 파라미터들 및/또는 임시 변수들을 포함할 수 있다. 이는 제공될 수 있었던 속성들을 사용하여 내부에 포함된 데이터에 대해 TAR을 수행하기 위해 SDFT ravel/unravel 연산을 통해 NSstr(4810)을 처리하는데 필요한 최소한의 완전한 정보 집합을 제공할 수 있다. TOP 용어로는, 데이터 폴딩이라고 할 수 있다. SDFT의 출력은 동일한 NSstr 구조체(4810) 또는 NSjson과 같은 NSx 구조체로 반환될 수 있다. 그 다음, 이 출력은 일부 영구적이고 액세스 가능한 방식으로 저장될 수 있으며(4820), IPT 방법을 사용하여 다른 컴퓨팅 기기에 전송될 수 있고(4840), 그리고/또는 다른 내부 데이터 구조에 저장될 수 있다(4830). 애플리케이션의 나중 시점에 저장된 데이터(4820 및 4830)에 대하여 사이클이 새로 시작할 수 있다. 송신된 데이터(4840)에 대해, 사이클은 그러한 데이터 패킷들(4800)의 수신에 의해 개시될 수 있다.
도 49는 데이터를 반복적으로 폴딩하기 위해 SDFT 사용의 흐름도를 도시한다. 일련의 단순화된 다이어그램은 N 개의 연속적인 데이터 폴딩에 대한 SDFT ravel 호출들을 사용하여 데이터를 체계적으로 폴딩하는 것을 보여준다. 적어도 데이터(4902) 및 TAR(4904)를 포함하는 NSstr 구조(4900)는 ravel(4906)을 호출함으로써 폴딩되어 출력 데이터(4908)를 생성할 수 있으며, 출력 데이터(4908)는 적어도 데이터(4922) 및 TAR(4924)를 포함하는 NSstr 구조(4920)로 변형되고 그리고/또는 캡슐화될 수 있으며, NSstr(4920)는 ravel(4926)을 호출함으로써 폴딩되어 출력 데이터(4928)를 생성할 수 있으며, 출력 데이터(4928)는 적어도 데이터(4942) 및 TAR(4944)를 포함하는 NSstr 구조(4940)로 변형되고 그리고/또는 캡슐화될 수 있으며, NSstr 구조(4940)는 ravel(4946)을 호출함으로써 폴딩되어 출력 데이터(4948)를 생성할 수 있으며, 출력 데이터(4948)는 변형되거나 추가로 캡슐화될 수 있다... 이러한 프로세스는 필요에 따라 반복될 수 있다(4950). 이 복잡한 일련의 구조화된 데이터 폴딩에서, 임의의 단계의 임의의 TAR은 일부 텍스트 파일 또는 이와 동등한 파일에 저장된 TAR 명령들을 단순히 수정함으로써 애플리케이션 코드와 별도로 수정할 수 있다. 각 단계에 대한 변환 시퀀스 및/또는 파라메트릭 변화(parametric variance)의 가능성을 갖는 이러한 반복적인 캡슐화의 SDFT 없는 동등한 프로그래밍 방식의 표현은 비교적 길고, 오류가 발생하기 쉽고, 그리고/또는 이해하기 어려울 수 있다.
도 50은 데이터를 반복적으로 언폴딩(unfolding)하기 위한 SDFT 사용의 흐름도를 도시한다. 일련의 단순화된 다이어그램은 N 개의 연속적인 데이터 언폴딩을 위해 SDFT unravel 호출을 사용하여 데이터를 체계적으로 언폴딩하는 것을 보여준다. 이것은 도 49의 흐름의 정확한 역순으로 이루어지므로, 이와 같이 이해될 수 있다. 도 39 및 도 40에서 이전에 도시된 바와 같이, TAR의 준비 및 그것에 공급되는 데이터의 상태를 제외하고, unravel 호출은 ravel 호출과 동일할 수 있다. 이 복잡한 일련의 구조화된 데이터 언폴딩에서, 언폴딩을 달성하기 위해 추가의 리버스 TAR들이 필요하지 않을 수 있다. 각각의 폴딩된 데이터를 unravel하기 위해 필요한 모든 TAR들은 폴딩된 구조 내에 임베디드된 것으로 발견될 수 있다. NStar 구조(3106)의 더 정밀한 검사는 'List of TAR commands-expanded form'으로 정의된 'expd' 필드를 나타낸다. 이것은 SDFT에서 가역성의 중요한 특징일 수 있다 : TAR 준비 단계들(3912 및 4012)의 출력은 라벨 참조들 및 임의의 다른 외부 참조들이 없는 동작 가능한 변환 명령들의 전체 세트를 생성할 수 있으며, 그리고 변환된 데이터가 받게될 수도 있는 변환들의 완전한 설명으로 간주될 수 있다. 이는 폴딩된 데이터에 대한 TAR 세트의 정적 스냅샷으로 볼 수 있으며, 이에 의해, 외부 위치에서의 TAR 정의들에 대한 변경에 관계없이 폴딩된 데이터에 대해 적절한 언폴딩이 수행될 수 있도록 보장한다. TAR 정의 파일들은 수많은 TAR 정의들을 가지며 시간에 따라 커질 수 있음을 암시할 수 있지만, 운영 TAR 정의의 저장는 그러한 외부 정의 파일들에 대한 변경과 관계없이 가역성을 유지하는 방식으로 SDFT 프로세스에 의해 저장될 수 있다(권장 관행이 아닐 수 있음). 이러한 설계는 더 나은 방법으로 저장된 데이터의 시간 호환성을 해결할 수 있는 체계적인 방법을 촉진할 수 있다.
도 51은 SDFT API/라이브러리 및 그것이 액세스할 수 있는 다양한 유형의 TAR 정의 파일들을 도시한다. TAR 정의는 텍스트 파일, Nut, 암호화된 파일, 데이터베이스, 서버 프로세스 및/또는 실행중인 메모리와 같은 다양한 형태로 존재할 수 있다. TAR은 프로그래머에 의해 언제든지 ravel 호출의 커스터마이징된 TAR 정의로서 정의될 수 있으며, 이에 따라 일시적인 TAR일 수 있다. 지속적으로 저장될 수 있는 TAR 정의들에 대해, 다이어그램(5100)은 이들의 다양한 형태를 예시할 수 있지만, 도시된 것들에 의해 제한되지 않을 수 있다. 표준 TAR들(5102)은 임의의 OS/언어 쌍을 위한 SDFT 라이브러리 설치와 함께 패키지로서 제공될 수 있는 TAR 정의들일 수 있다. 숨겨진 TAR들(5104)은 액세스 제한 위치들에만 존재할 수 있고 그리고/또는 표현된 허가에 의해서만 액세스될 수 있는 커스터마이즈된 TAR 정의들일 수 있는 TAR 정의들일 수 있다. 이들은 사설 네트워크 또는 커스텀 애플리케이션 설치에서 TAR 정의들의 바람직한 방법일 수 있다. 숨겨진 TAR들의 사용은 ravel의 출력 내에서도 숨겨져 있을 수 있으며, 그러한 폴딩된 데이터에 임베디드된 확장된 형식의 TAR이 발견되지 않을 수 있지만, TAR 레이블(label)에 의한 그것에 대한 참조만 임베디드되어 있을 수 있다. 숨겨진 TAR들을 유지해야하는 의무는 그러한 그룹들의 관리자들에게 있을 수 있다. 숨겨진 TAR들로 폴딩된 데이터에는 그것을 언폴딩하기 위해 필요한 변환 세트가 반드시 포함되어 있지 않을 수도 있기 때문이다. 숨겨진 TAR들은 프로그램 내에서 데이터 조작 시퀀스를 난독화하는 것과 동일한 방법으로 익숙해보일 수 있다. 로컬 사용자 TAR들(5106)은 사용자 또는 프로그래머의 계정 권한 하에서만 액세스될 수 있는 커스터마이징된 TAR 정의들일 수 있는 TAR 정의들일 수 있다. 이것들은 프로그래머가 나중에 TAR 정의 저장 양식들 중 하나에 영구적으로 추가하기 위해 공식화(formulating)할 수 있는 임시 또는 개발 TAR들일 수 있다. 원격 TAR들(5108)은 원격 서버 또는 저장 사이트로부터의 허가 액세스를 갖거나 또는 갖지 않고 액세스될 수 있는 TAR 정의들일 수 있다. 이러한 토폴로지는 제한된 로컬 저장소로 인해 또는 핵심(key) TAR 정의들을 중앙 관리 영역으로 중앙 집중화하는 정책으로 인해 필요할 수 있다. 이것은 또한 표준 TAR 정의들이 가장 최신 버전일 수 있는지 지속적으로 확인하는 방법일 수 있다. 보호된 TAR들(5110)은 임의의 적절한 액세스 가능한 장소에 위치할 수 있지만 인증된 액세스만을 위해 암호화될 수 있는 TAR 정의일 수 있다. 보호된 TAR들에 대한 액세스를 얻기 위해 별도의 인증 및/또는 허가 프로세스가 성공적으로 통과될 필요가 있을 수 있다. 보호된 TAR의 다른 형태는 Nut 컨테이너 내에 저장될 수 있으며, 이 컨테이너에는 그것에 대한 액세스를 얻기 위해 적절한 키(들)가 필요할 수 있다. 임베디드된 폴딩된 TAR들(5112)은 ravel 호출로부터 폴딩된 데이터와 함께 보존되는 확장된 TAR 정의들일 수 있다.
도 52는 수동 데이터 폴딩을 수행하기 위한 예시적인 Python 스크립트를 도시한다. 도 53은 TAR 정의의 SDFT 예 그리고 그 사용법을 Python 스크립트로 나타낸 것이다. 도 52 및 도 53은 SDFT가 Python v3.6을 사용하는 보다 직접적인 프로그래밍 방식과 어떻게 다른지 함께 보여주는 예이다. 이러한 예시적 Python 스크립트들은 각 방법론을 사용하는 당면한 각 작업의 기본 호출 시퀀스들의 주요 차이점을 보여준다. 우리는 샘플 데이터 세트(5210)부터 시작할 수 있다. 데이터에 대해 수행하는 연산들은 라인 02-06에 도시된 바와 같이 평이한 언어로 표현된 태스크들(5220)에서 특정될 수 있다. 일반적으로, 이들은 가독성을 위해 주석 라인들로서 프로그램 자체에 입력될 수 있다. 섹션(5250)은 태스크를 수행하기 위한 실제 Python 코드를 보여주고, 섹션(5260)은 원본 데이터(5210)를 복구하는 태스크들의 역처리를 보여준다.
SDFT를 사용하면, 데이터 세트(5310)는 5210과 동일하다. 섹션(5320)은 태스크(5220)를 'test_a70'로 라벨링된 TAR 정의로 표현한다. 섹션(5350)은 데이터를 ravel하고, 폴딩된 데이터를 파일에 기록한다. 섹션(5360)은 파일에서 폴딩된 데이터를 읽고 이를 unravel한다.
도 52에는 18 줄들의 Python 코드가 있고, 도 53에는 8 줄들의 코드만이 있다. 데이터 변환들의 유형 및 수의 임의의 변화가 섹션(5250) 및 섹션(5260) 모두에 영향을 줄 수 있음은 자명할 수 있다. 도 52의 방법은 프로그래머가 여러 변수들, 태스크들의 시퀀스 및/또는 각 함수 또는 방법의 적절한 호출을 유지할 것을 요구한다. 5260에서의 리버스 프로세스는 프로그래머가 모든 작업들이 올바른 역순으로 호출되고 각 함수 또는 메소드 호출에 대해 파라미터들이 올바른 방식으로 공급되게 할 것을 요구한다. 5220에서 작업들을 변경하면 섹션들(5250 및 5260)에 대한 프로그래밍 변경을 야기할 수 있다. 5220에서의 임의의 추가 작업들로 인해, 섹션들(5250 및 5260)에 추가적인 프로그램 라인들이 생길 수 있다. 작업들에 대한 이러한 추가 또는 변경을 위해 필요한 경우 더 많은 임시 변수들이 생성되고 사용될 수 있다.
도 53의 SDFT 방법에서, 작업들의 임의의 변경은 TAR(5320)에 직접 반영될 수 있다. 이에 따라, 추가적인 변환 변경들은 오직 이 섹션의 길이만을 변화시킬 수 있다. ravel 및 unravel 호출 라인들(10 및 14)은 변경되지 않는다. TAR(5320)의 5360에서의 리버스 프로세스는 5320의 원래의 TAR 정의를 넘어서서 지정될 필요는 없다. 실제로, 섹션들(5350 및 5360)은 TAR 정의 레이블이 ravel 메소드 호출에 지정되는 10행을 제외하고 선택된 모든 TAR 정의에 대해 방해받지 않고 머물러있을 수 있다.
수행되는 작업들의 가독성 및 이해도 측면에서, 판독자는 섹션들(5250 및 5260)에서의 실제 프로그램 코드보다 TAR(5320)을 더 선호할 수 있다. 5220에서 지정된 작업들은 코드가 아니며, 대게 Python 코드 내에서 주석으로 표현될 수 있다. 섹션들(5250 및 5260)의 프로그램 코드에 대한 변경 사항은 프로그래머에 의한 주석들로 수동으로 조정되어야 한다. 그렇지 않으면, 다른 프로그래머가 부정확한 주석들로 코드를 이해하려고 시도하는 경우 혼란이 발생할 수 있으며, 그 반대의 경우도 마찬가지이다. TAR(5320)은 명확하고 간결한 방식으로 자체 설명하는 것으로 간주될 수 있다.
섹션(5250)의 행 15-16에 의해 저장된 데이터는 그것이 어떻게 변환되었을 수 있는지를 설명하는 임베디드된 메타 데이터가 없다. 변환 방법론은 실제 코드로서 섹션들(5250 및 5260)에 하드와이어되어 있다. 이러한 방식으로 작성된 이러한 데이터는 해당 검색 및 복구를 위해 동일하거나 유사한 코드의 존재에 전적으로 의존할 수 있다. 이러한 코드 섹션들 또는 등가물들은 변환된 데이터가 항상 복구 가능하도록 항상 유지되어야 한다. 이것은 숨겨진 TAR 방법과 동일할 수 있다.
섹션(5350)에서 라인(11)에 의해 저장되는 데이터는 폴딩된 데이터를 변환할 수 있는 임베디드된 확장된 TAR 정의를 포함할 수 있다. 변환 방법론은 폴딩된 데이터와 쌍을 이루어 전송 가능하게 만들 수 있다. 폴딩된 데이터의 복구 가능성은 그것을 형성한 코드(5350 및 5360)와 독립적으로 간주될 수 있다. 폴딩된 데이터에서 임베디드된 TAR 정의를 적절히 처리할 수 있는 임의의 코드는 원래의 데이터를 복구할 수 있다. 이러한 유형의 기능은 오래된 폴딩된 데이터가 자체 기술할 수 있고 이에 따라 그것이 복구될 수 있는 방법을 자체-규정(self-prescribing)할 수 있기 때문에 시간이 지남에 따라 변화하는 변환 시퀀스들에 대해 더 나은 시간 호환성을 허용할 수 있다.
도 54는 단일 통신 세션 내의 동적 TAR 스위칭의 블록도들을 도시한다. TOP 접근법에서, 더 높은 레벨의 통신 프로토콜은 하나의 컴퓨팅 프로세스에서 다른 컴퓨팅 프로세스로의 변환된 데이터의 전달로 간주될 수 있다. 변환들은 가장 자주 사용되는 암호화 함수들을 허용할 수 있기 때문에, IPC에 대한 보안 메시지들을 작성하는데 사용될 수 있다. 이론적으로, 각 메시지는 상이한 TAR을 사용하여 변환되고 폴딩될 수 있다. 각각의 상이한 TAR 정의는 프로토콜 정의들의 현대 표준에 따라 자체 프로토콜로 간주될 수 있다. SDFT를 사용하여, TAR들은 도 54에 도시된 바와 같이 2 개의 애플리케이션들 사이에서 폴딩된 메시지 단위로 동적으로 스위칭될 수 있다. 도 51에 도시되고 기술된 바와 같이 TAR 소스들의 임의의 혼합은 각각의 애플리케이션이 이러한 TAR 정의 소스들에 액세스할 수 있는 한 사용될 수 있다. 임베디드 암호화 변환에 필요한 각각의 키의 정확한 키 식별자를 지정하는 키홀들로서의 KISS 구조들과 같은(그러나 이에 국한되지 않음) 임베디드되고 폴딩된 메타데이터의 풍부한 세트는 SDFT 기반의 통신 프로토콜들이 보다 정교하고 잠재적으로 보다 안전한 수준에서 보안을 제공할 수 있게 할 수 있다.
SDFT라는 프레임워크를 초래할 수 있는 TOP 분석 및 방법들은 저장된 데이터가 이를 생성할 수 있는 자체 이식 가능한 명령어 세트(own portable instruction set)를 포함할 수 있게 할 수 있다. 이러한 프레임워크는 데이터 폴딩을 정의할 수 있고, 그리고 조직화된 방식으로 상기 저장된 데이터 내에 임베디드될 수 있는 TAR(Transmutation Audit Record)로 표현 가능한, 개념적으로 그리고 논리적으로 일관된 가역적인 변환 처리 방법을 사용하여, 데이터를 폴딩하는 방법론들 및/또는 실시예들을 제공할 수 있다. 그 다음, 결과로 얻은 폴딩된 데이터는 어떤 식으로든 수정될수 있으며, 그리고 원하는 애플리케이션 또는 데이터 형식 결과를 얻기 위해 필요에 따라 반복적으로 폴딩될 수 있다. TAR을 프로그래밍 언어로 기술하는 것 외에, 이는 주어진 TAR 및/또는 속성들 내에서 변환 시퀀스들의 무한 변형들 및/또는 변형 속성들의 무한 변형들을 허용할 수 있는 간결한 형태의 협력 데이터 조작(cooperative data manipulations) 세트를 나타낸다. SDFT는 프로그래밍 언어들이 범위 지정(scoping) 개념들과 기법들을 사용하여 로컬 변수들을 분리하는 방식과 유사한 방식으로 데이터 세트에 대해 가변 범위 지정을 허용할 수 있다. TOP를 통해, 프로토콜 변화(protocol variance)는, 자체-기술적일 수 있고 가능하다면 그들의 프로그래밍 환경에 적합한 이용 가능한 SDFT 라이브러리를 통해 방법들에 액세스할 수 있는 다양한 애플리케이션들에서 액세스할 수 있고 판독 가능할 수 있는 데이터로 이어질 수 있는 더 높은 개념 구조에서 볼 수 있다. 뿐만 아니라, 폴딩된 데이터에 주입될 수 있는 이러한 특성들은 단일 통신 세션 또는 단일 저장된 데이터 객체 내에서 프로토콜들의 동적 스위칭을 허용할 수 있다. TOP 접근법은 NUT 생태계(ecosystem)에 대해 그리고 Nut 구성에서 기본적인 빌딩 블록으로 활용될 수 있다. NUTS는 SDFT와 별도로 완전히 구현될 수 있지만, 이는 바람직하지 않을 수 있다.
NUT ID
NUTS 설계는 위치에 관계없이 데이터의 식별 가능성을 가능하게 할 수 있다. 이는 범용 고유 ID(UUID)를 필요로 할 수 있지만, 이는 어떤 형태의 중앙 집중화(centralization) 없이는 보장된 방식으로 달성할 수 없기 때문에, 우리는 ID 충돌 가능성을 낮추기 위해 충분한 길이와 엔트로피 특성을 갖는 실제적으로 고유한 ID의 개념에 정착할 수 있다. 도 55는 Nut ID(5500)를 생성하는 처리 예의 흐름도이다. 여기서, 로컬 기기(5502)는 사용자 속성들(5504), 환경 속성들(5506) 및/또는 랜덤 속성들(5508)과 같은(그러나 이에 국한되지는 않음) 데이터 조각들로부터 실제적으로 고유한 ID를 생성하는 함수를 호출할 수 있는 애플리케이션을 실행 중일 수 있다. 사용자 속성들(5504)은 사용자 로그인 정보, 그룹 ID, 회사 ID, 사용자 ID 및/또는 사용자 패스워드 해시와 같은 데이터 항목들을 포함할 수 있지만, 이에 국한되는 것은 아니다. 환경 속성들(5506)은 MAC 어드레스, IP 어드레스, 기기 정보, 시스템 시간, OS 정보, 디렉토리 경로 및/또는 파일, 원자 시계 동기화된 시간 값, GPS 동기화된 시간 값, 선언된 환경 변수, 스레드 ID, CPU 런타임, IMEI 번호, 전화번호, 애플리케이션 이름 및/또는 프로세스 ID와 같은 데이터 항목들을 포함할 수 있지만, 이에 국한되는 것은 아니다. 랜덤 속성들(5508)은 세션 카운터, UUID, 클럭 사이클 카운트, 랜덤하게 생성된 번호, 마우스 움직임, 키보드 활동, 파일 시스템 상태, 부분 또는 전체 화면 영역 해시, 프로세스 업타임, OS 업타임 및/또는 세션 기간과 같은 데이터 항목들을 포함할 수 있지만, 이에 국한되는 것은 아니다. 이러한 데이터 조각들은 수집되어 ID 구조(5510)에 저장될 수 있으며, 그 다음 JSON 또는 대안 마샬링(marshalling) 기법들을 사용하여 직렬화될 수 있다. 그 다음, 결과물인 이진 스트링은 ID 충돌의 확률을 낮추기 위해 512 비트의 제안된 최소 길이로 실용적인 고유성을 생성할 수 있는 (2001년 NIST에 의해 FIPS PUB 180-2에 공개된 해시 알고리즘들의 SHA-2 패밀리로부터의) SHA-512와 같은 해싱 알고리즘 또는 대안적인 해싱 방법을 사용하여 해싱될 수 있다(5520). 이진 해시는 이식성 및 가독성을 위해 base64(또는 대안 인코딩 기법) 텍스트 스트링으로 인코딩될 수 있으며, 이는 86 문자 이상의 텍스트 스트링을 생성할 수 있다. 인코딩 기법은 인쇄 가능하고 사람이 읽을 수 있는 형태를 야기할 수 있고 그리고 텍스트 스트링으로서 다수의 프로그래밍 언어 및 소프트웨어 시스템에 의해 수용될 수 있는 임의의 방법을 포함할 수 있다. 함수가 호출되었을 수 있는 방식에 따라, 결과물인 인코딩된 해시 스트링은 액세스 가능한 Nut ID 캐시(5516)에 대한 복제에 대해 검사될 수 있다. ID 값들의 충돌이 존재한다면, 프로세스는 비-충돌 ID가 생성될 때까지 새로운 랜덤 속성들(5508)로 반복될 수 있다; 충돌들이 드물게 발생할 것으로 예상될 수 있다. 이러한 논리 연산의 출력 스트링은 Nut ID(5518)이라고 불릴 수 있다.
이러한 프로세스는 실행중인 프로그램 내에서 국부적으로 호출되거나, 또는 새로운 Nut ID들에 대한 클라이언트 애플리케이션 요청들을 서빙하는 로컬 또는 원격으로 존재하는 서버 애플리케이션 내에서 구현될 수 있다. 서버 모델 구현의 가능한 이점은 검사할 기존 너트 ID의 더 큰 캐시에 액세스할 수 있다는 것이며, 그리고 충돌 확률이 낮은 Nut ID를 생성할 수 있다. ID 구조(5510) 내의 해시 길이 및 적절하게 수집된 데이터 컴포넌트들이 충분한 엔트로피를 제공할 수 있기 때문에, Nut ID 중복 검사는 필수적이지 않다. IPv4/IPv6 주소, 도메인, 디렉토리 계층 및 액세스 제어 그룹들이 있는 인터넷과 같은 일부 또는 모든 디지털 인프라 전반에 걸쳐 구획화에 대한 일반적인 개념이 있을 수 있다. 유사한 방식으로, Nut ID는 실제적으로 고유할 수 있지만 외부 시스템이나 관계로 구성된 구획의 컨텍스트(context) 내에서 사용될 수 있으며, 따라서, 충돌 가능성은 Nut ID의 주어진 길이의 비트들의 순열에 의해 제공되는 수학적 확률보다 몇 자리수 더 작을 수 있다. 상이한 길이가 요구될 수 있는 경우에, 이는 당해 기술분야에서 통상의 지식을 가지 자에 의해 SHA-512 해시를 모듈형 매개변수화된 방식의 대안적 해시 알고리즘으로 대체하여 달성될 수 있다.
실제적으로 고유한 ID가 Nut ID의 형태로 생성될 수 있는 프로세스가 주어지면, 그 ID로 식별될 수 있는 것은 무엇인가? NUTS 용어로, 이는 Nut ID 스탬핑이라고도 할 수 있다. NUTS 내에 Nut ID들로 지속적으로 스탬핑될 수 있는 적어도 두 개의 구조들이 존재할 수 있다 : Lock Node들 및 Nut들. Lock Node에 할당되는 Nut ID는 Lock ID라고 할 수 있다. Nut에 할당된 Nut ID는 Nut ID라고 할 수 있다. Lock Node는 Nut의 내부 빌딩 블록(internal building block)일 수 있다. Lock Node는 가방(Bag)으로 알려진 페이로드를 보호할 수 있는 자체-포함된 독립형 잠금 메커니즘일 수 있다. Nut는 하나 이상의 잠금 노드들로 구성된 데이터 구조일 수 있다. 따라서, Nut는 데이터의 임의의 파슬(parcel) 또는 파슬들을 전체적으로 또는 부분적으로 저장할 수 있다. Nuts들은 실질적으로 고유한 방식으로 바이너리 형태로 표현된 일부 또는 모든 관련 소프트웨어, 데이터 및/또는 하드웨어를 식별하기 위해 NUTS 환경 전반에 걸쳐 사용될 수 있다. Nut ID 스탬핑의 결과는 모든 Nut가 고유하게 식별될 수 있다는 것일 수 있으며, 이는 Nut 내에 저장된 모든 데이터 파슬(parcel)이 Nut가 물리적으로 위치할 수 있는 곳과 관계없이 해당 Nut ID에 의해 고유하게 식별될 수 있음을 의미한다.
도 56은 Nut 데이터 구조의 단순화된 개략도를 도시한다. 이 다이어그램은 Nut 데이터 구조 내의 Lock ID들 및 Nut ID들의 사용법 및 상대적 위치들을 강조 표시할 수 있다. 특정 Lock ID들(5614-5622)은 이 Nut에 할당될 수 있으며, 그리고 서로 다른 값일 수 있다. Lock Node들(5604-5612)은 각각 Lock ID들(5614-5622)에 의해 식별될 수 있다. 이 예와 같은 전형적인 Nut 데이터 구조 형성에서, Nut(5602)는 잠금 그래프라 불리는 데이터 구조와 같은 그래프로 조직화된 Lock Node들의 그룹일 수 있다. 특정 Nut(5602)는 자신의 Nut ID(5634)에 의해 식별될 수 있으며, 그 Nut ID(5634)는 Lock Node(5606)의 Bag(5626)에 저장될 수 있으며, Nut ID는 다른 Lock Node Bag들 중 하나 이상에 저장될 수 있는 Nut의 페이로드와 상이할 수 있는 이 Lock Node의 페이로드로 간주될 수 있다. 모든 Lock Node(5604-5612) 구조는 Bag(5624-5632)라고 하는 페이로드 영역을 포함할 수 있다. 이것은 Nut와 Nut ID 간의 관계와, 일반적인 Nut 컨테이너에 저장되는 이러한 항목들을 찾을 수 있는 위치를 보여준다.
도 57은 Nut ID들, 경로 이름들 및/또는 페이로드 데이터 간의 관계들의 예들을 도시한다. Nut의 메타데이터, Nut 페이로드에 대한 메타데이터 및/또는 Nut 페이로드를 저장하는데 사용될 수 있는 Nut 내의 여러 Lock Node들이 존재할 수 있다. 메타데이터 부분들은 Nut의 다양한 Lock Node들의 Bag들에 저장될 수 있다. 5702는 각각 Nut ID들(A3 및 B1)에 의해 식별되는 별개의 Nut들에 각각 저장되는 두 개의 별개의 Nut 페이로드들(D1 및 D2)이 존재할 수 있는 시나리오를 도시한다. 최대 86 문자 길이의 텍스트 스트링을 생성할 수 있는 512 비트 해시의 base64 인코딩일 수 있다는 것을 이전에 지정했을지라도, 설명을 위해 두 개의 문자의 Nut ID들이 사용된다. Nut들(A3 및 B1)은 또한 NTFS 파일 시스템에서 별개의 경로 이름을 갖는다. 5705는 동일한 파일 이름을 갖지만 상이한 경로 이름을 갖는 두 개의 별개 Nut들을 보여준다. 5706은 상이한 디렉토리에 동일한 파일 이름을 가진 동일한 Nut의 두 사본들을 보여준다. 5708은 동일한 디렉토리에 위치한 상이한 파일 이름을 가진 Nut의 두 사본들을 보여준다. 이것은 이러한 속성들의 일부 또는 모든 순열들의 전체 목록은 아닐 수 있지만, Nut ID와 같은 각 페이로드와 영구적으로 연관된 메타데이터 항목을 가질 수 있는 유연성을 나타낼 수 있다.
연관된 Nut ID에 의해 식별될 수 있는 Nut 파일 내에 임베디드된 데이터는 이 방법론의 새로운 특징을 야기할 수 있다 : 메타데이터의 매개변수화된 규칙들을 기반으로 동적 파일 이름들을 자동으로 생성하는 기능. 파일 이름은 파일에 대한 일반적인 식별 스트링뿐만 아니라 수정 날짜 및 시간 및/또는 당일의 쓰기 수(number of writes for the day)와 같은(그러나 이에 국한되지 않음) 다른 속성들의 공식화된 요약을 나타낼 수 있다. 이렇게 하면, 디렉토리 브라우징 애플리케이션에서 파일 속성들을 살펴보는 것과 같이 일반적으로 숨겨진 속성들을 철저하게 조사(delving)하지 않고도 파일 및 그것의 상태를 보다 정확하고 편리하게 식별할 수 있다. 또한, 파일 시스템마다 다를 수 있는 파일 시스템의 속성 캡처 기능들에 의존하기보다는, 파일을 보유하는 컨테이너에 파일 및 데이터 속성들을 임베디드할 수도 있다. 예: 사용자는 텍스트 문서를 저장할 수 있는 Nut ID #234를 갖는 Nut를 생성할 수 있으며, 텍스트 문서는 항상 Nut ID #234로 식별될 수 있지만, 사용자는 "diary_20151115_1.txt"와 같이 기본 이름 + 마지막 수정 날짜 + 당일의 쓰기 횟수를 포함하는 동적 파일 이름을 설정할 수 있다. 같은 날, 약간 수정한 후 디스크에 저장하면, 파일 이름은 "diary_20151115_2.txt"로 나타날 수 있으며, 이전 파일 이름은 더 이상 디렉토리에 존재하지 않을 수 있다. 이 방법론은 저장된 데이터의 일부 상태 정보를 나타낼 수 있는 새 파일 이름을 자동으로 생성할 수 있다. 실제적으로 고유할 수 있고 경로 이름 + 파일 이름 지정과 구분될 수 있는 Nut ID의 속성들은 이러한 기능이 외부 참조 없이 구현될 수 있게 할 수 있다. 이러한 기능의 이점들 중 하나는 날짜 스탬프를 이용하여 작업 문서의 이전 상태들을 복사하고 보관하는데 종종 사용되는 방법일 수 있다. 저자는 매일 자신의 문서에서 작업한 파일이 담긴 디렉토리를 찾을 수 있다. 동적 파일 이름 방법을 사용하면, 저자는 디렉토리에 그가 마지막으로 기록한 날짜 스탬프가 있는 Nut 파일 하나만 가질 수 있다. 수동 방법의 히스토리 (상태) 저장 측면은 추후 섹션에서 제시되는 Nut 히스토리 기능을 사용하여 Nut 자체 내에 보존될 수 있다. 콘텐츠의 주요 식별인 Nut ID의 이러한 개념은 나중에 NUT 서버가 분산된 Nut들에 대한 복제 및 동기화 작업들을 수행하는데 사용될 수 있다.
잠금 그래프 & 잠금 노드
NUTS 기술은 SCP(Structured Cryptographic Programming)로 정의될 수 있는 계층적, 통합적, 모듈식 및/또는 반복적 접근법으로 데이터의 저장, 보호 및 액세스 제어를 처리할 수 있다. Nut 내부의 전반적인 설계가 설명되고 정의될 수 있으며, 그 다음 각각의 정의된 구조는 나중에 자세히 설명될 수 있다. 일부 기능들은 계층화된 방식으로 설명될 수 있으며, 그 다음 통합 설명은 개별 기능들이 함께 작동할 수 있는 방법을 보여주기 위해 제공될 수 있다. SDFT는 복합 암호화 구조들의 구성과 각각의 폴딩된 데이터 구조와 연관된 속성들의 체계적인 임베딩을 향상시키기 위해 NUTS 설계를 통해 활용될 수 있다. SDFT가 SCP 설계가 동등한 수동 방법들과 비교하여 상대적으로 용이하게 구현될 수 있게 하는 방법을 다양한 실시예들로 나타낼 수 있다.
Nut의 액세스를 제어할 수 있는 네 개의 상이한 방법들이 존재할 수 있다 : 키홀, Variable Lock, SAC(Stratum Access Control) 및/또는 NAC(Nut Access Control). 이러한 방법론들의 일부 또는 모두는 부분적으로 또는 전체적으로 내부화된 방식으로 그리고/또는 독립적인 방식으로 참조 모니터링 시스템의 전체 기능을 제공할 수 있는 Nut 내에 새로운 방식으로 함께 적층(layered) 및/또는 통합될 수 있다. 이러한 4 개의 계층들은 모듈형으로, 고립형(insular)으로 그리고/또는 링크 가능하도록 설계될 수 있는 Lock Node라고하는 복잡한 데이터 구조로 구현될 수 있다.
키홀은 각각 연관된 암호화된 키 맵을 가질 수 있는 임의의 수의 암호화 키들을 수용할 수 있는 데이터 구조일 수 있다. 이 실시예는 현재 인식할 수 있고 허용할 수 있는 암호 키 유형들에 제한되지 않는다 : 패스프레이즈, 대칭키 및 비대칭 키 쌍. 비트 시퀀스를 비밀 키로 지정할 수 있는 단순하거나 복잡한 방법, 또는 임의의 프로세스는 키홀에 통합될 수 있다. 암호화된 키 맵은 여러 키 세트를 포함할 수 있으며, 그 중 하나의 키 세트는 Nut 내의 액세스 제어의 각 계층에 대한 것이다 : Variable Lock, SAC(Stratum Access Control) 및/또는 NAC(Nut Access Control).
Variable Lock은 Lock Node 내의 데이터를 보호할 수 있는 정규화된 구조에서 상이한 유형들의 잠금 메커니즘들을 제공할 수 있다. 이러한 Variable Lock들은 ORLOCK, MATLOCK, SSLOCK, XORLOCK 및 HASHLOCK을 포함할 수 있다. 본 개시서는 이러한 사전 정의된 잠금 유형들에 국한되지 않고, 구조로 정규화될 수 있는 임의의 적절한 잠금 기법을 수용하도록 확장되거나 축소될 수 있다.
Stratum Access Control은 잠금 그래프에서 개별 Lock Node들로의 침투 액세스(penetration access)를 규제할 수 있다. 이 기능을 사용하면, 적절한 액세스 속성들이 주어질 때 Nut가 다양한 수준의 메타 데이터를 볼 수 있게 하는 능력일 수 있는 Gradient Opacity라는 Nuts 내의 속성이 생길 수 있다.
NUT 액세스 제어 또는 NAC는 역할 기반 암호화 액세스 제어(Role Based Cryptographic Access Control; RBCAC) 기술들을 사용하여 너트 내부의 수정 및 인증을 미세하게 제어할 수 있다.
구조화된 암호화 프로그래밍은 다양한 액세스 모델들을 표현하기 위해 상이한 방법론들 간에 쉽고 유연한 상호 작용들을 허용할 수 있는 데이터 구조의 설계일 수 있다. 보안 메커니즘은 전체적으로 암호화된 데이터 및 관련 암호들로 구현될 수 있으며, 이에 따라, 참조 모니터(reference monitor)와 같은 Nut의 액세스 제어에 대한 외부 애플리케이션 종속성들이 없을 수 있다. 일부 실시예들에서, Lock Node는 페이로드의 임의의 부분에서 필드 레벨 데이터를 보호하기 위해 개별적으로 사용될 수 있다. Nut 컨테이너의 내부는 특정 보안 모델을 구현하기 위해 다수의 암호화 키들을 잠재적으로 사용할 수 있다.
Nut는 Lock Node라고 하는 노드들로 구성된 잠금 그래프라고 하는 방향 그래프(directed graph) 데이터 구조일 수 있다. 각각의 Lock Node는 Nut ID를 생성하기 위해 동일한 기능에 의해 생성될 수 있는 Lock ID에 의해 식별될 수 있으므로, 모두 동일한 특성들을 가질 수 있다. Lock Node들은 그것들의 Lock ID들에 의해 참조될 수 있는 해시된 배열에 저장될 수 있다. 각각의 Lock Node는 다른 Lock ID들 또는 null 포인터에 링크하는 포인터들을 가질 수 있다. 잘 설정된 프로그래밍 방식의 그래프 추출 및 순회(traversal) 기법들을 사용하면, 잠금 그래프는 Lock Node들의 해시된 배열로부터 도출될 수 있다. 그것을 가리키는 다른 Lock Node들이 없는 Lock Node는 키홀 Lock Node(엔트리 또는 외부 Lock Node)일 수 있다. null 포인터를 가질 수 있는 Lock Node는 잠금 그래프의 터미널(terminal) Lock Node일 수 있으며, Nut의 페이로드 또는 페이로드에 대한 참조를 저장할 수 있다. Lock Node는 그것을 연결하는 여러 Lock Node들을 가질 수 있다. 대부분의 경우, Lock Node는 잠금 그래프 또는 그 자체의 이전 Lock Node에 다시 링크하지 않는다. 원형 링크 참조는 일반적이지 않지만 그러한 구조가 보증되는 경우 맞춤(custom) Nut들에 대한 커스터마이징된 프로그래밍을 통해 수용될 수 있다.
Nut의 기능들을 지원하기 위해 본원에 설명된 모든 데이터 구조는 아니더라도 일부 데이터 구조는 선택된 프로그래밍 언어 내의 복잡한 데이터 구조를 사용하여 구현될 수 있다. 선택된 프로그래밍 언어에 대해 SDFT 기능 라이브러리를 사용할 수 있다면, 데이터 조작 코드를 최소화하고, 데이터 조작 방법들을 명확히하며, 코딩 오류의 가능성을 줄이고, 그리고 모든 폴딩된 데이터 구조에 임베디드된 함축된 SDFT 기능들을 활용할 수 있도록 임의의 그리고 모든 적용 가능한 복잡한 데이터 구조들 또는 그것들의 하위부분들을 폴딩하고 캡슐화하는 것이 용이하게 적용될 수 있다.
본 개시서의 데이터 중심 특성으로 인해, 대부분의 흐름도 유형 다이어그램들은 데이터 흐름 다이어그램 또는 데이터 흐름도라고 지칭될 수 있는 데이터 컴포넌트들과 혼합된 기존의 흐름도 요소들의 혼합일 수 있다는 것을 유의한다. 또한, Lock Node 설계 계층들의 얽힌 특성은 포워드 참조문을 작성하지 않고도 완전히 선형 방식으로 컴포넌트들의 논리적 작업들을 노출하는 것을 어렵게 만들 수 있으며, 이에 따라 일부는 판독자의 입장에서 다시 읽어야할 수도 있다.
도 58은 모듈형 Lock Node들의 다목적 양상들을 사용하는 2 개의 논리 섹션들을 포함하는 Nut 또는 잠금 그래프(5800)의 실시예이다: Nut Lock(5802) 및 Nut parts(5804). 잠금 그래프의 Nut Lock(5802) 섹션은 하나 이상의 Lock Node들을 사용하여 주어진 Nut에 대해 복잡하게 암호로 링크된 잠금들이 구성될 수 있게 할 수 있다. 언급된 5가지 유형의 Variable Lock들에 대응하는 본 개시서에 정의된 5 가지 유형의 Lock Node들이 현재 존재한다 : ORLOCK, MATLOCK, SSLOCK, XORLOCK 및 HASHLOCK. 각각의 Lock Node 유형은 저장 영역 및 다른 Lock Node 메타데이터 및 파라미터들에 대한 암호화 키들을 보호하기 위해 특정 Lock Node의 한가운데서 이용될 수 있는 Variable Lock 내부 잠금 메커니즘의 유형을 나타낼 수 있다. 도 30에 개시된 잠금 변환들은 Variable Lock들의 실시예일 수 있고, 그리고 Lock Node의 구축에 사용될 수 있다. 잠금 그래프의 Nut Lock(5802) 부분을 성공적으로 잠금해제하고 순회하면 잠금 그래프(5800)의 Nut parts(5804) 섹션으로 이어질 수 있다. Nut parts(5804)를 포함하는 여러 Lock Node들이 존재할 수 있다 : hair(5820), tick(5822), seal(5824), vita(5826), bale(5828) 및/또는 tale(5830). Nut Parts(5804)는 Nut 페이로드(5830) 및/또는 메타데이터(5820-5828)를 포함할 수 있다. 잠금 그래프에 대한 Nut parts의 개수 및 유형은 Nut가 저장할 수 있는 데이터 유형 및/또는 일부 원하는 동작들 및 특성들에 대한 Nut의 설계에 따라 달라질 수 있다. 이 예에서, 키홀 Lock Node(5806)(5816)을 잠금 해제하면 링크된(5818) Lock Node(5820)의 기본 키홀에 삽입될 수 있는 적절한 암호 키들이 생길 수 있다. Lock Node(5820)를 잠금 해제하면 링크된 Lock Node(5822)의 기본 키홀에 삽입될 수 있는 적절한 암호 키들이 생길 수 있다. Lock Node(5822)를 잠금 해제하면 링크된 Lock Node(5824)의 기본 키홀에 삽입될 수 있는 적절한 암호 키들이 생길 수 있다. Lock Node(5824)를 잠금 해제하면 링크된 Lock Node(5826)의 기본 키홀에 삽입될 수 있는 적절한 암호 키들이 생길 수 있다. Lock Node(5826)를 잠금 해제하면 링크된 Lock Node(5828)의 기본 키홀에 삽입될 수 있는 적절한 암호 키들이 생길 수 있다. Lock Node(5828)를 잠금 해제하면 링크된 Lock Node(5830)의 기본 키홀에 삽입될 수 있는 적절한 암호 키들이 생길 수 있다. Lock Node(5830)는 null 포인터에 링크될 수 있으므로, 이는 터미널 Lock Node 또는 이 잠금 그래프 또는 Nut의 최내층(innermost layer)일 수 있다. Lock Node의 잠금 해제는 SDFT 방법들(언폴딩)을 사용하여 Lock Node를 나타내는 폴딩된 데이터 구조의 unravel을 포함할 수 있다. 각각의 Lock Node는 Lock Node를 잠금 해제하는 동작이 적용 가능한 데이터 구조들의 언폴딩과 동등할 수 있는 다수의 폴딩된 데이터 구조들을 포함할 수 있다.
도 59는 논리 섹션들 Nut Lock(5902) 및 Nut parts(5904)를 포함하는 잠금 그래프 실시예의 단순화된 Nut 구조도(5900)를 도시한다. 이 예는 네 개의 Lock Node들(5908, 5910, 5912 및 5916)을 포함하는 Nut Lock(5902)을 탐색한다. Lock Node들(5908-5912)은 이 Nut의 키홀 Lock Node들(5906)일 수 있다. 왜냐하면, 그것들 중 일부 또는 전부가 외부 대면 노드들(external facing nodes)일 수 있으며, 그리고 기본 키(primary key)들이라고 하는 외부 암호 키들을 허용할 수 있기 때문이다. 사용자는 이러한 키홀 잠금 노드들 중 하나 이상과 관련된 기본 키들을 가질 수 있다. 기본 키를 페이로드로 저장하는 Nut의 Nut ID는 키홀 Lock Node들(5906) 사이에서 속하는 키홀을 마킹하는 식별자와 자동으로 일치할 수 있는 키 ID로서 작용할 수 있다. 패스프레이즈 키들은 식별자로 질문을 포함하거나 포함하지 않을 수 있는 키 ID들 또는 텍스트 스트링에 의해 식별될 수 있다. 복합 멀티-레벨 패스프레이즈는 적절한 질문 목록들과 함께 적절한 키홀 식별자들 및 평문 Nut 메타데이터 부분들을 사용하여 구성될 수 있다. 5914와 5918과 같은 Lock Node들 간의 연결은 성공적으로 잠금 해제된 Lock Node가 식별자가 있는 출력 키(들)를 생성할 수 있는 유사한 방식으로 개방될 수 있다. 이 특정 예에서, 키홀 Lock Node들 중 임의의 하나를 잠금 해제하면, 링크된(5914) Lock Node(5916)의 키홀에 삽입될 수 있는 적절한 암호 키들이 드러날 수 있다. 이 시점부터, Nut Parts(5904)를 포함하는 노드들의 잠금 해제는 Nut Parts(5804)에 대해 설명된 프로세스와 유사하게 진행될 수 있다. 이러한 Nut Lock(5902) 구성은 잠금 해제 프로세스를 진행하기 위해 충족되어야 할 서로 다른 조건들을 필요로 하는 각 경로로 Nut(5900)의 페이로드를 잠금 해제하기위해 세 개의 별개의 경로들이 존재할 수 있음을 보여줌으로써 Lock Node들의 기본 구성요소와 그 조합의 유연성을 전달할 수 있다.
도 60에서, Lock Node(6000)는 다음의 섹션들을 포함하는 데이터 구조일 수 있다 : 파라미터들(6002), 입력(6006), 키 맵들(6008), Variable Lock(6012), 유도된 키(6016), 키 세트(6020), Bag(6024) 및/또는 출력(6026). 파라미터들 섹션(6002)은 Lock Node의 메타데이터, Lock ID(6030), 그리고 키 맵들의 암호화된 스트링(6010), 유도된 키(6014), 키 세트(6018), Bag(6022), 그리고 Lock Node에 대한 적절한 액세스 역할 키들(Access Role Keys)(포워드 참조는 도 83의 요소(8334)에 대한 논의에서 설명될 수 있음)에 의해 생성된 상기 암호화된 스트링들의 dign들을 보유할 수 있다. 설계 원리들은 잠금 그래프의 흐름과 유사할 수 있으며, 이 때, 각 섹션을 잠금 해제하면 다음 섹션을 열 수 있는 키들로 이어질 수 있지만, Lock Node 내의 각각의 컴포넌트는 특정 기능을 제공할 수 있다. 암호화된 스트링들에 대한 dign들은 판독자(액세스 역할)가 해독 시도 전에 특정 섹션을 인증하는데 사용될 수 있다. dign들은 적절한 판독자 액세스 키 홀더가 dign을 생성한 것을 나타내거나 보존하기 위해 약간의 수정들이 있을 수 있는 경우 섹션의 암호화된 스트링을 사용하여 특정 섹션의 판독자들(액세스 역할)에 의해 생성될 수 있다. 뿐만 아니라, 상술된 암호화된 스트링들 각각은 암호화 변환들을 포함하는 TAR들을 사용하여 데이터 구조들을 폴딩하기 위한 SDFT 방법들의 사용에 의해 구현될 수 있다. 이 절에서 설명되는 암호화된 스트링들의 수와 다양성을 고려할 때, SDFT 방법들은 코딩할 때 프로그래머가 암호화 관련 속성들을 관리하는 부담을 크게 줄일 수 있다.
키홀들
도 61에서, Lock Node의 입력 섹션(6006)은 서로 다른 두 개의 키홀들을 제공할 수 있다 : 기본 키홀(6102) 및 액세스 키홀(6104). 구조적으로, 기본 키홀(6102)은 4 개의 상이한 키 유형들을 포함하는 임의의 수의 암호 키들을 수용할 수 있다 : 대칭, 비대칭 공개, 비대칭 개인 및 패스프레이즈. 액세스 키홀(6104)은 대칭 및/또는 패스프레이즈 키 유형들을 수용할 수 있다. 주요 키홀 및 액세스 키홀은 도 34에 도시된 바와 같이 각각이 키홀 모드(ima='keyhole')에서 작동하여, 그것이 수용할 수 있는 각각의 고유 키에 대한 키홀을 나타내는 하나 이상의 KISS 데이터 구조들을 내부적으로 이용할 수 있다.
도 62는 연관된 키 ID, 키 유형 및 키 속성들(6206)을 가질 수 있으며 기본 키로 지정될 수도 있는 단일의 암호화 키(6202)를 나타낸다. 키 ID는 식별 스트링일 수 있다. 본 개시서에서 언급된 기본키 및 임의의 다른 키들은 키 모드(ima='key')에서 작동하는 도 34에 도시된 바와 같이 KISS 데이터 구조에 의해 각각 내부적으로 표현될 수 있으며, 이 때, 키->값 필드는 키로 채워지며 다른 매칭 속성 필드들은 필요에 따라 채워진다. 기본 키홀(6204)은 암호화된 키 맵(6208)을 해독할 수 있는 기본 키(6202)를 수용할 수 있다. 해독된 키 맵(6240)은 세 개의 섹션들, 메인 키(6210), Stratum Key들(6212) 및 AKS(Access Key Set)(6214)을 포함할 수 있는 구조일 수 있다. 메인 키 구조(6210)는 메인 키라고 지칭될 수 있는 대칭 키 또는 tine, 기본 키(6202)의 만료 날짜/시간, 기본 키에 대한 카운트다운 타이머 및/또는 기본 키의 만료시의 동작 명령어들을 포함할 수 있다. 대칭 키 또는 tine은 Lock Node의 Variable Lock에 의해 사용될 수 있다. 키홀 Lock Node에 대해, 키 맵 구조는 Stratum Key들(6212) 및/또는 AKS(6214)를 추가적으로 보유할 수 있다. Stratum Key들(6212)은 잠금 그래프의 Strata Lock Node들에 삽입될 키들의 세트를 보유할 수 있으며, 그것들의 Lock Node들은 자신의 Stratum 지정에 의해 식별될 수 있다. AKS(6214)는 키홀 Lock Node에 대한 자신의 액세스 키홀(6104)에 삽입될 키들의 세트를 보유할 수 있다. 암호화된 키 맵(6208)은 메인 키(6210), Stratum Key들(6212) 및 AKS(Access Key Set)(6214) 구조들을 포함할 수 있는 SDFT 폴딩된 데이터 구조일 수 있다.
도 63은 임의의 Lock Node에 대한 그리고 임의의 암호 키에 대한 키 삽입 프로세스의 흐름도를 도시한다. 단계 6304는 주어진 암호 키 및 그와 연관된 키 ID에 대하여 Nut의 나열된 Lock 노드들의 일부 또는 전부를 검색하는 것일 수 있다. 일단 암호 키가 적절한 키홀에 삽입되면(6304), 단계 6306는 해당 키에 대한 암호화된 키 맵을 복호화하고 펼치려고(unfurling) 시도할 수 있다. 암호화된 키 맵의 복호화 및 펼침(unfurling)은 그러한 실시예들에 대한 SDFT 폴딩된 암호화된 키 맵의 unraveling과 동일할 수 있다.
키홀 Lock Node에 대한 암호화된 키 맵(6208)을 성공적으로 잠금 해제하고 펼칠 때, 1) Stratum Key들은 각각의 Lock Node의 파라미터들 섹션에서 발견되는 stratum 지정과 매칭하는 각 Lock Node의 기본 키홀에 삽입될 수 있으며, 2) AKS(Acces Key Set)의 AAKSUK(Access Attribute Key Set Unlock Keys)는 Lock Node의 액세스 키홀에 삽입될 수 있다. 이러한 기본 키 잠금 해제(또는 unraveling)는 많은 기본 키들이 Lock Node에 삽입되었을 때 발생할 수 있으며, 그 후에 우리는 Lock Node의 Variable Lock에 의한 가능한 사용을 위해 집합적으로 메인 키들의 세트를 구성하는 해독된(또는 언폴딩된) 키 맵들의 세트를 가질 수 있다.
도 64는 3개의 기본 키들(6402-6406)이 기본 키홀(6400)에 삽입될 수 있는 예를 도시한다. 각각의 키(→)는 그것의 식별 키 ID와 일치할 수 있으며, 그리고 해시된 어레이 또는 KISS 키홀 구조의 슬롯에 삽입될 수 있다. 키 유형은 대칭, 비대칭 공개, 비대칭 개인 및 패스프레이즈와 같은 키 유형을 나타낼 수 있지만, 이에 국한되는 것은 아니다. Nut의 일부 실시예들에서, 사용자는 NUTS 통합을 위해 적절하게 모듈화된 상응하는 암호 방법을 가질 수 있는 모든 유형의 키를 지정할 수 있다. 이러한 키 암호 방법들은 지문 인식, 홍채 인식, 장문 인식(palm print), 음성 인식, 손글씨 패턴, 얼굴 인식, DNS 특성, 물리적 키 기기, 하드웨어 보안 키, 소프트웨어/하드웨어 기반 영지식증명(Zero Knowledge Protocol) 키들 및/또는 NFC 키들을 포함할 수 있다. 비대칭 개인 키가 RSA-2048에서 사용될 수 있는 것처럼 삽입된다면, 그것은 공개 및 개인 부분들 모두를 나타낼 수 있고, 공개 부분은 개인 부분으로부터 추출될 수 있고, 기본 키의 암호화된 키 맵을 암호화하는데 사용될 수 있으며, 이에 따라, 해독 작업은 개인 비대칭 키가 제시될 것을 요구할 수 있다. 하나의 키홀(6402)에 삽입된 하나의 키(→)에 대해 명백하게 도시된 바와 같이, 그 암호화된 키 맵(6412)은 3 개의 별개의 키 세트들(6432, 6434 및 6436)을 포함할 수 있는 키 맵 구조(6430)를 드러내기 위해 키 유형 암호화 방법론을 사용하여 해독될 수 있다. 이러한 해독 단계는 각 키(6404, 6406)에 대해 수행되어 각각의 대응하는 키 맵 세트들(6440, 6450)을 생성할 수 있다. 각각의 해독 단계는 또한 이러한 실시예들에 대한 SDFT 폴딩된 구조를 unravel하는 것과 동일할 수 있다. 패스프레이즈 키 유형의 경우, 키는 패스프레이즈일 수 있으며, 키 속성들은 사용할 패스프레이즈 유도 함수, 그리고 암호화된 키 맵을 해독할 수 있는 대칭 키를 생성하기 위해 수행할 반복 횟수를 포함하는 함수에 대한 적절한 파라미터들을 나타낼 수 있다. SDFT를 이용하는 실시예들에 있어서, 이러한 패스프레이즈 속성들은 또한 매칭하는 속성들을 갖는 적절한 유도 변환들에 액세스하기 위해 대응하는 TAR과 매치될 수 있다. 이 예를 Lock Node 다이어그램(6000) 관점에서 보기 위해, 입력 섹션(6006)은 기본 키홀(6400)을 포함할 수 있으며, 암호화된 키 맵들(6010)은 6410으로 표현될 수 있으며, 그리고 키 맵들(6008) 섹션은 6420으로 표현될 수 있다.
Variable Lock
Lock Node의 다음 부분은 도 60의 요소(6012)로 도시된 바와 같이 Variable Lock일 수 있다. Variable Lock은 Bag(6024)에 저장된 Lock Node의 콘텐츠들을 보호하는데 도움이 될 수 있는 잠금 메커니즘일 수 있다. Variable Lock은 Lock Node가 당업자에게 익숙한 몇몇 상이한 유형들의 암호화 잠금 기술들 중 임의의 것을 이용할 수 있게 할 수 있다. 예를 들어, 이러한 서로 다른 잠금 유형들은 ORLOCK, MATLOCK, XORLOCK, HASHLOCK 및/또는 SSLOCK을 포함할 수 있다. 이는 각각의 잠금 방법의 입력들 및/또는 출력들을 공통 데이터 흐름 모델에 적합하도록 정규화함으로써 달성될 수 있으며, 그에 의해, 각각의 잠금 방법이 서로 원활하게 대체될 수 있다. 이와 유사하게, 기본 키홀 및 키 맵 구조들은 Variable Lock으로 흘러들어오는 키들과 키 유형들의 수에 대한 데이터 정규화군(normalizer)으로 작동할 수 있다. 잠금 노드는 어떤 유형의 Variable Lock을 구현할 수 있는지(6030)를 나타내는 파라미터들(6002)의 세트로 각인(imprinting)될 수 있다. 이 값이 설정되면, RAT(Nut의 소유자)에 의한 Lock Node들 재작성(rekey) 및/또는 재설정이 가능할지라도 Lock Node는 이 설정을 거의 변경할 수 없다. SDFT 라이브러리는 편의를 위해 이 섹션에서 사용될 수 있는 도 30 및 그와 관련된 설명에 열거된 바와 같은 Variable Lock들의 일 실시예를 기술하지만, Lock 변환의 사용은 Lock Node의 이 기능을 수행하기 위해 필요한 요구 사항은 아니다.
도 64에서 Lock Node의 순회를 계속하면, 우리는 세 개의 메인 키들(6432, 6442 및 6452)을 갖게 된다. 도 65에서 Variable Lock이 어떻게 작동하는지를 탐색할 수 있다. Variable Lock(6502)은 유도된 키(Derived Key; DK)(6506)를 암호화된 유도 키(Encrypted Derived Key; eDK)(6504)로서 암호화함으로써 유도된 키(6506)를 보호할 수 있다. 일부 또는 모든 메인 키들(6432, 6442 및 6452)은 대칭 또는 tine 키 유형들일 수 있으며, 그리고 Variable Lock(6502)에 공급될 수 있다. Lock Node 파라미터들 섹션(6002 및 6030)에서 지정될 수 있는 Variable Lock 유형에 따라, DK 또는 eDK에 대한 암호/해독 연산을 수행하기 위해 적절한 Variable Lock 함수가 호출될 수 있다. 도 65는 메인 키들(6432, 6442 및 6452)을 사용할 수 있는 Variable Lock(6502)에 의한 DK(6506)로의 eDK(6504)의 해독 작업을 도시한다. 도 66은 메인 키들(6432, 6442, 6452)을 사용하는 Variable Lock(6502)에 의한 eDK(6504)로의 DK(6506)의 암호화 작업을 도시한다. SDFT를 사용하는 실시예에서, DK는 데이터 폴딩에 의한 Lock 변환을 이용하는 TAR에 의해 보호되는 데이터일 수 있다. 따라서, 그러한 구조를 언폴딩하면 내부에 포함된 유도 키가 나타난다.
도 67의 표는 Variable Lock들이 언급한 키 특성들 중 일부를 요약한다. Variable Lock이란 용어가 암시할 수 있듯이, 이 모델로 정규화될 수 있는 임의의 잠금 기술은 추가 Variable Lock 유형으로 추가될 수 있다. 대안적으로, 임의의 잠금 기술이 배제될 수 있다. 도 30의 표는 도 67의 표에 대응할 수 있고, SDFT가 Lock 변환들에서 Variable Lock 설계들을 어떻게 구현할 수 있는지를 나타낸다.
Lock Node의 메타데이터 섹션(6030)은 일부 또는 모든 Variable Lock들에 포함될 수 있는 공통 컴포넌트일 수 있다. 6040-6048(포워드 참조(reference))과 같은 적절한 ARK(Access Role Key)에 의해 생성되었을 수 있는 Lock Node 섹션들의 다양한 dign들(디지털 서명들)이 존재할 수 있다. 이러한 dign들 중 일부는 AKS를 통해 RAT(Root Access Tier) 액세스 역할 키, 특히 RAT 개인 키를 보유한 사람일 수 있는 Nut 소유자에 의해 생성될 수 있다. 유효한 기본 키를 가진 모든 사람은 Nut 컴포넌트들이 손상되지 않았음을 확인하기 위해 Lock Node 전체에서 다양한 RAT dign들을 인증할 수 있게 하는 RAT 공개 키를 가질 수 있다. 다이어그램에서, 때때로 RAT 공개 키는 RAT 판독자 키(reader key)라고 지칭될 수 있으며, 그리고 개인키는 RAT 작성자 키(writer key)라고 지칭될 수 있다. 이 문서의 뒷부분에서, Nut 액세스 제어 계층에 대한 자세한 논의는 이러한 특징들을 보다 깊이 탐구하고, 명시하고 그리고/또는 명확하게 할 수 있다. SDFT와 TAR들에 대한 섹션에서 이전에 언급했듯이, 암호화된 데이터의 dign들은 보호된 데이터, 그것의 dign 및 그것을 생성한 TAR을 임베디드할 수 있는 폴딩된 데이터 구조의 TAR 스펙의 일부일 수 있다. 이것은 Lock Node 내에서의 SDFT의 체계적 사용은 프로그래머의 작업 부하에 유리할 수 있다는 것을 분명히 암시한다.
도 68의 ORLOCK(OR 잠금이라고도 알려짐)는 메인 키들(6808)이라 불리는 임의의 수의 대칭 암호 키들을 수용할 수 있는 Variable Lock이며, AES-256 또는 대체 암호 같은 대칭 암호화 암호를 사용하여 eDK(6806)를 해독하려고 체계적으로 시도할 수 있다. 파라미터 섹션(6002)은 SDFT 방법들을 사용할 때 이 논리 연산 또는 바람직한 TAR에 대해 사용할 암호 방법을 나타낼 수 있다. eDK를 처음으로 성공적으로 해독하면 유도된 키(Derived Key; DK)(6816)를 생성할 수 있으며, 그리고 ORLOCK을 성공적으로 잠금 해제할 수 있다. 임의의 Variable Lock에서의 복호화 시도 전에, eDK(6806) 및 RAT 판독자 키(6802)를 사용하여 eDK(6804)의 dign이 인증될 수 있다. 인증이 성공적이면(6810), 해독 프로세스가 계속될 수 있고, 그렇지 않으면, 에러(6830)가 발생될 수 있고, 시도가 중지될 수 있다. 메인 키들(6806)은 대칭 256비트 키들과 같은 동일한 키들일 수 있지만, 이에 한정되는 것은 아니다. 이 구성에서, OR 잠금의 본질은 분리되고 키홀 및 Variable Lock 구조들로 정규화되어 모듈화할 수 있다. 폴딩된 구조에서, 인증 단계는 TAR의 일부일 수 있으며, unravel하는 행위에 의해 암묵적으로 시도될 수 있다.
도 69는 RAT 작성자 또는 Nut 소유자의 관점에서 ORLOCK의 암호화 작업을 나타낸다. 이는 임의의 메인 키(6902)를 취할 수 있고, 그리고 적절한 암호를 사용하여 DK(6906) 상에서 암호화 작업을 수행(6920)하여 eDK를 생성할 수 있다(6908). 그런 다음, RAT 작성자 키(6904), eDK(6908) 및 적절한 digning 알고리즘(6922)을 사용하여, Lock Node 파라미터들 섹션(6044)에 저장될 수 있는 eDK의 dign(6910)을 생성할 수 있다. SDFT 방법들은 eDK와 함께 이러한 속성들의 대부분을 파라미터들 섹션에 저장될 단일 데이터 객체로 간편한 방식으로 폴딩할 수 있다. Lock Node의 비-RAT 멤버들에 대한 암호화 프로세스는 간단할 수 있다. 그들은 Lock Node의 애플리케이션 메모리 내용들을 지울 수 있다. 왜냐하면, 그들은 모든 것에 대한 본래의 dign을 생성할 수 없으며, 이는 그들이 그것의 내용을 성공적으로 변경할 수 없고 그것을 dign할 수 없다는 것을 암시하기 때문이다. 또는, 그들은 이미 해독된 DK(6908)를 사용할 수 있으며, Lock Node의 관련 내용들을 암호화할 수 있지만, eDK(6910)는 그대로 둘 수 있다. 왜냐하면, eDK dign과 관련이 있을 수 있는 것은 변경될 수 없기 때문이다. 이것은 RAT 기록자들만이 DK(6906)의 값을 대체하거나 그것을 재작성(rekey)할 수 있음을 나타낼 수 있다. SDFT 방법들을 사용할 때, Lock Node의 비-RAT 멤버들은 eDK를 포함하는 원래의 폴딩된 데이터를 파라미터들 섹션에 그대로 두고 DK를 보유하는 언폴딩된 구조를 지우기로 선택할 수 있다.
도 70의 MATLOCK(matroyshka lock, casecade lock 또는 AND lock으로도 알려짐)은 메인 키들(7006)이라는 고정된 수의 대칭 암호 키들을 수용할 수 있고 AES-256 또는 대체 암호와 같은 적절한 암호화 암호(7014)를 사용하여 오름차순으로 각각의 메인 키(7008)를 사용하여 eDK(7022)를 연속적으로 해독할 수 있는 Variabl Lock이다. 파라미터 섹션은 이 논리 연산에 사용할 정확한 암호 그리고 필요할 수 있는 메인 키들의 수 또는 SDFT 방법들을 사용할 때 바람직한 TAR을 나타낼 수 있다. eDK(7022)의 성공적인 순서화된 반복적 해독들은 DK(7024)를 생성할 수 있으며, 그리고 MATLOCK의 성공적인 잠금 해제를 초래할 수 있다. 임의의 Variable Lock에서 복호화 시도 전에, eDK의 dign(7004)은 eDK(7022) 및 RAT 판독자 키(7002)를 사용하여 인증될 수 있다. 인증이 성공적이면(7010), 해독 프로세스가 계속될 수 있으며, 그렇지 않다면, 에러(7030)가 발생될 수 있고 시도가 중단될 수 있다. 이러한 구성에서, matroyshka lock의 본질은 분리되고 키홀 및 Variable Lock 구조들로 정규화되어 모듈화할 수 있다. 폴딩된 구조에서, 인증 단계는 TAR의 일부일 수 있으며, unravel하는 행위에 의해 암묵적으로 시도될 수 있다.
도 71은 RAT 작성자 또는 Nut 소유자의 관점에서 MATLOCK의 암호화 작업을 나타낸다. 이는 제시된 메인 키들(7102)의 일부 또는 전부를 취할 수 있고, 내림차순으로 그것들을 정렬할 수 있다(7110). 그 다음, 적절한 암호를 사용하여 DK(7120)에 대해 암호화 작업들(7112)을 반복적으로 수행하여 eDK(7122)를 생성할 수 있다. 그런 다음, RAT 작성자 키(7124), eDK(7122) 및 적절한 digning 알고리즘(7118)을 사용하여, Lock Node 파라미터들 섹션(6044)에 저장될 수 있는 eDK의 dign(7126)을 생성할 수 있다. SDFT 방법들은 eDK와 함께 이러한 속성들의 대부분을 파라미터들 섹션에 저장될 단일 데이터 객체로 간편한 방식으로 폴딩할 수 있다. Lock Node의 비-RAT 멤버들에 대한 암호화 프로세스는 간단할 수 있다. 그들은 Lock Node의 애플리케이션 메모리 내용들을 지울 수 있다. 왜냐하면, 모든 것에 대한 본래의 dign을 생성할 수 없으며, 이는 그들은 그들이 그것의 내용을 성공적으로 변경할 수 없고 그것을 dign할 수 없다는 것을 암시하기 때문이다. 또는, 그들은 이미 해독된 DK(7120)를 사용할 수 있으며, Lock Node의 관련 내용들을 암호화할 수 있지만, eDK(6910)는 그대로 둘 수 있다. 왜냐하면, eDK dign과 관련이 있을 수 있는 것은 변경될 수 없기 때문이다. 이것은 RAT 기록자들만이 DK(7120)의 값을 대체하거나 그것을 재작성(rekey)할 수 있음을 나타낼 수 있다. SDFT 방법들을 사용할 때, Lock Node의 비-RAT 멤버들은 eDK를 포함하는 원래의 폴딩된 데이터를 파라미터들 섹션에 그대로 두고 DK를 보유하는 언폴딩된 구조를 지우기로 선택할 수 있다.
도 72의 XORLOCK(XOR lock이라고도 알려짐)은 메인 키들(7206)이라 불리는 고정된 수(>1)의 대칭 암호 키들을 수용할 수 있고 오름차순으로(7222) 각각의 메인 키(7208)에 대해 XOR 작업들(7224)을 연속적으로 적용함으로써 계산된 키를 생성할 수 있는 Variable Lock이다. 그 다음, AES-256 또는 대안 암호와 같은 적절한 암호로 7224로부터 계산된 키를 사용하여 eDK(7210)을 해독(7228)하려고 시도할 수 있다. 파라미터 섹션(6030)은 이러한 논리 연산에 사용할 정확한 암호 그리고 2 개 이상의 키들일 수 있는 필요한 메인 키들의 수, 또는 SDFT 방법들을 사용할 때 바람직한 TAR을 나타낼 수 있다. eDK(7210)의 성공적인 해독은 DK(7212)를 생성할 수 있으며, 그리고 XORLOCK의 성공적인 잠금 해제를 야기할 수 있다. 임의의 Variable Lock에서 해독 시도 전에, eDK의 dign(7204)는 eDK(7210) 및 RAT 판독자 키(7202)를 사용하여 인증될 수 있다. 인증이 성공적이면(7220), 해독 프로세스가 계속될 수 있으며, 그렇지 않다면, 에러(7230)가 발생될 수 있고 시도가 중단될 수 있다. 이러한 구성에서, XOR lock의 본질은 분리되고 키홀 및 Variable Lock 구조들로 정규화되어 모듈화할 수 있다. 폴딩된 구조에서, 인증 단계는 TAR의 일부일 수 있으며, unravel하는 행위에 의해 암묵적으로 시도될 수 있다.
도 73은 RAT 작성자 또는 Nut 소유자의 관점에서 XORLOCK의 암호화 작업을 나타낸다. 이는 제시된 메인 키들(7302)의 일부 또는 전부를 취할 수 있고, 오름차순으로 그것들을 정렬할 수 있다(7320). 그 다음, DK(7306)를 암호화(7326)하여 eDK(7308)를 생성하기 위해 사용될 수 있는 계산된 키를 생성하기 위해 메인 키들(7304)에 대해 XOR 작업들(7322)을 반복적으로 수행할 수 있다. RAT 작성자 키(7310), eDK(7308) 및 적절한 dign 알고리즘(7328)이 사용되어, Lock Node 파라미터들 섹션(6044)에 저장될 수 있는 eDK의 dign(7312)을 생성할 수 있다. SDFT 방법들은 eDK와 함께 이러한 속성들의 대부분을 파라미터들 섹션에 저장될 단일 데이터 객체로 간편한 방식으로 폴딩할 수 있다. Lock Node의 비-RAT 멤버들에 대한 암호화 프로세스는 간단할 수 있다. 그들은 Lock Node의 애플리케이션 메모리 내용들을 지울 수 있다. 왜냐하면, 그들은 모든 것에 대한 본래의 dign을 생성할 수 없으며, 이는 그들이 그것의 내용을 성공적으로 변경할 수 없다는 것을 암시하기 때문이다. 또는, 그들은 이미 해독된 DK(7306)를 사용할 수 있으며, Lock Node의 관련 내용들을 암호화할 수 있지만, eDK(7312)는 그대로 둘 수 있다. 왜냐하면, eDK dign과 관련이 있을 수 있는 것은 변경될 수 없기 때문이다. 이것은 RAT 기록자들만이 DK(7306)를 재작성(rekey)할 수 있음을 나타낼 수 있다. SDFT 방법들을 사용할 때, Lock Node의 비-RAT 멤버들은 eDK를 포함하는 원래의 폴딩된 데이터를 파라미터들 섹션에 그대로 두고 DK를 보유하는 언폴딩된 구조를 지우기로 선택할 수 있다.
도 74의 HASHLOCK(hash lock으로도 알려짐)은 메인 키들(7406)이라 불리는 고정된 수의 대칭 암호화 키들을 수용할 수 있고 특성 순서(7422)로 제시된 메인 키들의 일부 또는 전부를 연결(7424)하여 계산된 키를 생성한 다음, 스트링에 해싱 알고리즘(7426)을 적용할 수 있는 Variable Lock이다. 그 다음, AES-256 또는 대안 암호와 같은 적절한 암호로 계산된 키를 사용하여 eDK(7410)을 해독(7428)하려고 시도할 수 있다. 파라미터 섹션(6030)은 이러한 논리 연산에 사용할 정확한 암호 및 패시, 필요한 메인 키들의 수 및/또는 메인 키들의 정렬 순서, 또는 SDFT 방법들을 사용할 때 바람직한 TAR을 나타낼 수 있다. eDK(7410)의 성공적인 해독은 DK(7412)를 생성할 수 있으며, 그리고 HASHLOCK의 성공적인 잠금 해제를 야기할 수 있다. 임의의 Variable Lock에서 해독 시도 전에, eDK의 dign(7404)는 eDK(7410) 및 RAT 판독자 키(7402)를 사용하여 인증될 수 있다. 인증이 성공적이면(7420), 해독 프로세스가 계속될 수 있으며, 그렇지 않다면, 에러(7430)가 발생될 수 있고 시도가 중단될 수 있다. 이러한 구성에서, 해싱 lock의 본질은 분리되고 키홀 및 Variable Lock 구조들로 정규화되어 모듈화할 수 있다. 폴딩된 구조에서, 인증 단계는 TAR의 일부일 수 있으며, unravel하는 행위에 의해 암묵적으로 시도될 수 있다.
도 75는 RAT 작성자 또는 Nut 소유자의 관점에서 HASHLOCK의 암호화 작업을 나타낸다. 이는 제시된 메인 키들(7502)을 취할 수 있고, 오름차순으로 그것들을 정렬할 수 있으며(7520), 그 다음 그것들을 연결할 수 있고(7522), 그것에 대해 해시 작업(7524)을 수행함으로써 계산된 키를 생성할 수 있다. 이러한 계산된 키는 DK(7506)를 암호화(7526)하기 위해 사용될 수 있으며, eDK(7510)를 생성할 수 있다. RAT 작성자 키(7508), eDK(7510) 및 적절한 dign 알고리즘(7528)이 사용되어, Lock Node 파라미터들 섹션(6044)에 저장될 수 있는 eDK의 dign(7512)을 생성할 수 있다. SDFT 방법들은 eDK와 함께 이러한 속성들의 대부분을 파라미터들 섹션에 저장될 단일 데이터 객체로 간편한 방식으로 폴딩할 수 있다. Lock Node의 비-RAT 멤버들에 대한 암호화 프로세스는 간단할 수 있다. 그들은 Lock Node의 애플리케이션 메모리 내용들을 지울 수 있다. 왜냐하면, 그들은 모든 것에 대한 본래의 dign을 생성할 수 없으며, 이는 그들이 그것의 내용을 성공적으로 변경할 수 없다는 것을 암시하기 때문이다. 또는, 그들은 이미 해독된 DK(7506)를 사용할 수 있으며, Lock Node의 관련 내용들을 암호화할 수 있지만, eDK(7512)는 그대로 둘 수 있다. 왜냐하면, eDK dign과 관련이 있을 수 있는 것은 변경될 수 없기 때문이다. 이것은 RAT 기록자들만이 DK(7506)를 재작성(rekey)할 수 있음을 나타낼 수 있다. SDFT 방법들을 사용할 때, Lock Node의 비-RAT 멤버들은 eDK를 포함하는 원래의 폴딩된 데이터를 파라미터들 섹션에 그대로 두고 DK를 보유하는 언폴딩된 구조를 지우기로 선택할 수 있다.
도 76의 SSLOCK(비밀 공유 잠금 또는 Shamir의 비밀 공유 기법으로도 알려짐)은 각각이 개별 tine 또는 비밀을 공유하는 공유(secret sharing share)일 수 있는 n 개의 메인 키들(7606)을 수용할 수 있는 Variable Lock이며, 여기서, 1 > p+1 ≤ k ≤ n 이고, p+1은 임계값이라고 불리는 필요한 키들의 최소 수일 수 있다. 비밀 키를 복구하기 위해, 해독된 키 맵들(7606)로부터의 일부 또는 모든 tine들은 Shamir의 비밀 공유 기법 또는 대안 암호와 같은 적절한 비밀 공유 암호(7622)에 제공될 수 있다. 일부 또는 모든 tine들이 유효할 수 있고 충분한 수가 존재할 수 있다면 복구가 성공할 수 있다. 그 다음, AES-256 또는 대안 암호와 같은 적절한 암호로 상기 복구된 비밀 키를 사용하여 eDK(7608)을 해독(7624)하려고 시도할 수 있다. 파라미터 섹션(6030)은 비밀 공유 및 암호화 작업들에 사용할 정확한 암호들뿐만 아니라 공유들의 수(n) 및 비밀 공유 암호에 대한 임계 카운트(p+1), 및/또는 SDFT 방법들을 사용할 때 바람직한 TAR을 나타낼 수 있다. eDK(7608)의 성공적인 해독은 DK(7610)를 생성할 수 있으며, 그리고 SSLOCK의 성공적인 잠금 해제를 야기할 수 있다. 임의의 Variable Lock에서 해독 시도 전에, eDK의 dign(7604)는 eDK(7608) 및 RAT 판독자 키(7602)를 사용하여 인증될 수 있다. 인증이 성공적이면(7620), 해독 프로세스가 계속될 수 있으며, 그렇지 않다면, 에러(7630)가 발생될 수 있고 시도가 중단될 수 있다. 이러한 구성에서, 비밀 공유 lock의 본질은 분리되고 키홀 및 Variable Lock 구조들로 정규화되어 모듈화할 수 있다. 폴딩된 구조에서, 인증 단계는 TAR의 일부일 수 있으며, unravel하는 행위에 의해 암묵적으로 시도될 수 있다.
도 77은 처음으로 Lock Node를 암호화하는 중일 수 있거나 또는 Variable Lock을 재작성하는 과정에 있을 수 있는 RAT 작성자 또는 Nut 소유자의 관점에서 SSLOCK의 암호화 작업을 나타낸다. 새로운 비밀 암호 키 K가 생성될 수 있고(7720), 그 다음 원하는 개수의 공유들(tine들)은 파라미터들(6030)에서 지정될 수 있는 적절한 비밀 공유 방법을 사용하여 K로부터 생성될 수 있다. 그 다음, 이러한 tine들은 메인 키들(7702)로서 저장될 수 있다. 단계7724에서, 키 K는 DK(7704)를 암호화하여 eDK(7706)를 생성할 수 있다. RAT 작성자 키(7708), eDK(7706) 및 적절한 dign 알고리즘(7726)이 사용되어, Lock Node 파라미터들 섹션(6044)에 저장될 수 있는 eDK의 dign(7710)을 생성할 수 있다. SDFT 방법들은 eDK와 함께 이러한 속성들의 대부분을 파라미터들 섹션에 저장될 단일 데이터 객체로 간편한 방식으로 폴딩할 수 있다. Lock Node의 비-RAT 멤버들에 대한 암호화 프로세스는 간단할 수 있다. 그들은 Lock Node의 애플리케이션 메모리 내용들을 지울 수 있다. 왜냐하면, 그들은 모든 것에 대한 본래의 dign을 생성할 수 없으며, 이는 그들이 그것의 내용을 성공적으로 변경할 수 없다는 것을 암시하기 때문이다. 또는, 그들은 이미 해독된 DK(7704)를 사용할 수 있으며, Lock Node의 관련 내용들을 암호화할 수 있지만, eDK(7706)는 그대로(untouched) 둘 수 있다. 왜냐하면, eDK dign과 관련이 있을 수 있는 것은 변경될 수 없기 때문이다. 이것은 RAT 기록자들만이 DK(7704)를 재작성(재작성(rekey))할 수 있음을 나타낼 수 있다. SDFT 방법들을 사용할 때, Lock Node의 비-RAT 멤버들은 eDK를 포함하는 원래의 폴딩된 데이터를 파라미터들 섹션에 그대로 두고 DK를 보유하는 언폴딩된 구조를 지우기로 선택할 수 있다.
Variable Lock의 설명 및 이들의 다양한 논리 연산들의 설명은 Lock Node가 입력 섹션(600)의 기본 키홀들(6102), 암호화된 키 맵들(6010), 키 맵들(6008), Variable Lock(6012), 암호화된 유도 키들(6014) 및/또는 유도된 키들(6016)을 사용하여, 상이한 잠금 기술들이 정규화되고 모듈화될 수 있도록 하는 견고한 데이터 구조를 생성하는 방법을 보여줄 수 있으며, 하나를 다른 것으로 대체하는 것은 몇몇 파라미터들(6030)의 변경 및/또는 재작성을 요구할 수 있다. 상이한 잠금 방법들의 정규화는 Nut에 대한 사용자 기본 키들이 본래 그대로(untouched)일 수 있다는 것을 보장할 수 있고, 그리고 단일 사용자 기본 키가 사용자에게 알려지지 않은 상이한 Nut들의 많은 상이한 잠금 기술들에서 사용될 수 있음을 보장할 수 있고, 그리고 어느 잠금 기술들이 특정 Nut 페이로드 보호에 적절한 잠금 기술로 간주될 수 있는지를 보장할 수 있다. SDFT 방법들이 이러한 복잡한 데이터 구조들의 실시예에서 유리한 것으로 증명될 수 있는 부분들이 강조되었다. 여기 예들이 있다. ORLOCK을 사용하면 여러 사용자들이 Lock Node의 Bag에 액세스할 수 있다 : 이는 그룹 액세스 형식일 수 있고 또는 키들 중 하나가 마스터 키를 나타낼 수 있다. MATLOCK, XORLOCK 또는 HASHLOCK은 그것의 Bag을 unravel하기 위해 특정 수의 키들이 존재할 수 있음을 보장할 수 있다 : 민감한 회사 비밀은 두 명의 특정 고위 경영진에게 각각의 비밀 키들을 제공하여 해당 내용을 볼 것을 요구할 수 있다. SSLOCK은 Bag에 액세스하기 위해 최소 수의 비밀 키들이 있어야 할 수도 있다 : 회사 지불 시스템은 최소 수의 허가된 직원(authorized personnel)에 의해 액세스될 수 있지만 단독으로 운영될 수는 없다.
각 기본 키홀을 그것의 대응 키 맵으로 구분(compartmentalizing)하면, 키 맵은 만료 날짜/시간, 카운트다운 타이머 및/또는 만료 동작과 같은(그러나 이에 국한되지는 않음) 주요 키에 대한 속성들을 포함할 수 있다. 만료 속성들 중 하나라도 설정되면, 대응하는 만료 동작이 기본 키 만료시에 수행되도록 설정될 수 있다. 예를 들어, 일반적인 만료 동작은 기본 키의 키 맵을 삭제하는 것일 수 있다. 키 맵의 삭제는 그것의 구분된 설계로 인해 키홀 Lock Node의 임의의 다른 등록된 기본 키들과 간섭하지 않을 수 있다. 만료된 기본 키를 다시 삽입하는 것은 그것에 대해 일치하는 키 맵이 없기 때문에 더 이상 유효한 키로 인식되지 않을 수 있다. 물론, 이러한 기본 키 삭제는 사용되는 Variable Lock의 유형과 관련하여 신중하게 수행되어야 한다 : ORLOCK들과 일부 SSLOCK들에 대해 삭제가 허용될 수 있지만, 이는 해당 Lock Node에 대한 잠금 상황을 형성할 수 있으므로, MATLOCK들, XORLOCK들 및 HASHLOCK들에 대해서는 역효과일 수 있다.
다양한 방식 및 계층들에서 그것의 내용을 보호할 목적으로 다수의 암호화 기법들을 사용할 수 있는 복잡한 데이터 구조들의 상호 작용은 암호화 연산마다 요구되고 그리고/또는 생성되는 비정상적으로 많은 수의 변수(variable) 속성들로 인해 구현 세부사항들에 심각한 문제를 제기할 수 있다. 이러한 상황들에서, SDFT의 유용성과 간결함이 빛을 발하며, 그러한 구현 문제를 극복하는데 도움이 되는 편리한 구성 방법들과 구조들을 제공할 수 있다. 예를 들어, 데이터의 단일 인증된 암호화는 다음 속성들이 어딘가에 저장될 것을 요구할 수 있다 : 키 유형, 키 길이, 암호 유형, 암호 모드, 초기화 벡터, 키 ID, 패딩, 패딩 유형, 패딩 길이, 블록 길이, 디지털 서명 또는 keyed MAC 스트링(digest), digest에 매칭하는 키 ID, digest 길이, digest 키 길이, 다이제스트 방법. 지금까지 제시된 Lock Node 스펙에 설명된(Lock Node에는 이후 섹션들에서 설명할 몇 가지 더 많은 컴포넌트들이 있음) 각 암호화 작업을 곱하면, 추적할 수 있는 엄청난 수의 속성일 수 있다. 대부분의 경우, 응용 프로그램 프로그래머들과 설계자들은 이러한 난제와 문제점을 알고 있을 수 있으며, 소수의 암호화 방법들과 연관된 속성 값들을 선택하고 전역적으로 구현하는 동안 이를 사용함으로써 코딩 프로세스를 단순화할 수 있다. 이러한 단순화는 더 적은 보안, 적은 유연성, 적은 기능, 더 많은 비호환성, 그리고 유지보수 또는 수정이 어려울 수 있는 컴퓨터 코드와 같은(그러나 이에 국한되지 않음) 원치 않는 결과를 초래할 수 있다.
STRATUM
도 78은 Stratum 키 사용을 강조하는 Nut(잠금 그래프)(7800)의 블록도를 도시한다. Nut Parts(7804)의 각 Lock Node는 stratum ID를 할당받을 수 있다. Lock Node들(7820-7824)은 stratum ID 'A'이며, Lock Node(7826)는 stratum ID 'B'이며, Lock Node(7828)은 stratum ID 'C'이며, 그리고 Lock Node(7830)는 stratum ID 'D'이다. strata의 지정은 임의적일 수 있지만, 개인 정보 민감성에 따라 다양한 Nut Parts을 그룹화하는 패턴을 따를 수 있다 : stratum이 깊어질수록, Lock Node에 포함된 데이터가 더 민감해질 수 있다. SAC(Stratum Access Control)의 정확한 사용으로, Nut의 Gradient Opacity를 구현할 수 있다. 예시적인 목적을 위해, 도 78에 도시된 stratum ID들은 단순한 문자들이지만, 실제적으로, (도 55로부터의 실제적으로 고유한 ID에서와 같은) Nut ID들과 같은 식별 가능한 스트링들의 임의의 세트일 수 있다.
Nut Lock(7802)을 포함하는 임의의 Lock Node는 stratum을 할당받을 수 있다. Nut(7806)의 키홀 Lock Node가 적절히 잠금해제되거나 unravel될 때, (도 62와 유사하게) 최대 3 개의 키 세트들(7842)을 포함할 수 이쓴 키 맵(7840)을 나타낼 수 있다. 이 섹션은 Stratum Key들(7850)(6212)과 그것들이 잠금 그래프에서 어떻게 작동하는지에 집중할 수 있다. 이 예에서, 우리는 각각 stratum 'A, B, C, D'에 대응할 수 있는 4 개의 stratum 키들(7852, 7854, 7856, 7857)을 발견할 수 있다. 각각의 stratum 키는 연관된 stratum ID와 함께 Stratum 키들(7850) 섹션에 저장될 수 있다. 우리는 각 stratum 키가 어떻게 사용될 수 있는지를 보여주는 도 79에 제시된 흐름도를 따를 수 있다. 일부 또는 모든 stratum 키들이 그것들의 매칭 Lock Node들의 기본 키홀들에 삽입될 수 있으면, 프로세스가 완료될 수 있고, 잠금 그래프의 순회가 Nut Lock 섹션(7802)을 넘어 계속될 때까지 기다릴 수 있다.
Stratum 키들은 Nut Parts(7804) 섹션의 Lock Node들 일부 또는 전체에 도시된 것처럼 MATLOCK Variable Lock과 함께 동작할 수 있다. SDFT 방법들을 사용할 때, MATLOCK은 관련 섹션의 바람직한 TAR에서 'lock matlock' 변환으로 표시될 수 있다. 각각의 Stratum 키는 문제의 Lock Node에 대한 MATLOCK의 필수키일 수 있다(도 79의 *). Lock Node Ouput 연결 키 또는 Stratum 키가 누락될 수 있다면, 특정 Lock Node가 MATLOCK의 정의에 따라 잠금해제되지 않을 수 있다. 따라서, 그 수준을 넘어선 일부 또는 모든 더 깊은 strata도 오픈되지 않을 수 있다. 기본 키의 키 맵(7840)에 어느 Stratum 키들이 저장될 수 있는지를 제어함으로써, Nut 소유자는 누군가가 잠금 그래프를 얼마나 정확하게 통과할 수 있는지를 명시적으로 제어할 수 있다(7860). Stratum Access Control 계층은 Nut Access Control 계층과 독립적으로 작동할 수 있으며, Variable Lock 방법과 함께 작동할 수 있다.
SAC 및 키홀들이 작동할 수 있는 방법은, 다수의 키들이 7806과 같은 키홀 Lock Node에 제공될 수 있다면, 노출된 다수의 키 맵들(7840)이 존재할 수 있고, 그리고 가능하다면, 다양한 Lock Node들에 삽입될 수 있는 다수의 Stratum 키 세트들이 존재할 수 있음을 암시할 수 있다. 단일 stratum ID의 stratum 키들은 동일한 키들일 수 있으며, 이에 따라 MATLOCK을 이용할 수 있는 Lock Node에 동일한 키를 삽입하면, 하나의 키가 해당 ID 하에서 삽입될 수 있으므로, 기본적으로 동일한 키가 키홀에서 여러번 덮어써질 수 있다. 이는 Stratum 키들의 부가적인 액세스 속성 특성일 수 있다.
Startum 키들 및 Nut 액세스 제어(다음 섹션에서 논의됨)는 모두 Additive Access Attribute 특성(property) 또는 특성(characteristic)을 나타낼 수 있다. 서로 다른 액세스 레벨들의 기본 키들을 잠금 그래프의 기본 키홀에 삽입하면 삽입된 모든 유효한 기본 키들의 액세스 레벨들의 조합 또는 결합을 나타낼 수 있는 잠금 그래프의 액세스 레벨이 발생할 수 있다. 이 특성을 강력하게 사용하는 방법 중 하나는, 잠금 그래프에 대한 특정 수준의 액세스를 얻기 위해 기본 키 조합이 필요할 수 있는 경우, 주어진 잠금 그래프에 대한 키들을 세그먼트 방식으로 배포하는 것일 수 있다. 이는 기본 키가 해당 키 보유자에 대해 주어진 액세스의 전체 그림을 제시할 수 있는 작동 모드와 대조될 수 있다.
Nut 액세스 제어
Nut 액세스 제어 또는 NAC는 Variable Lock들 및 Stratum 액세스 제어와 독립적으로 작동할 수 있는 암호화 데이터 구조들을 사용하는 액세스 제어 방법이다. NAC는 RBAC(Role Based Access Control), 그리고 RBCAC(Role Based Cryptographic Access Control) 또는 KBP(Key Based Permissions)라고도할 수 있는 CAC(Cryptographic Access Control)의 조합을 사용할 수 있다. NAC 속성 키 세트들은 단일 Lock Node들의 내부에 국한될 수 있지만, Lock Node에서, 키홀더에게 관련 Lock Node들 전체에 걸친 일관된 수준의 접근성을 허용할 수 있는 나머지 잠금 그래프를 따라 NAC 속성들을 전파(propagating)하는 메커니즘들이 있을 수 있다. 이러한 NAC 속성들은 외부 소스로부터 삽입되었을 수 있는 기본 키에 대한 잠금 해제되거나 unravel된 키홀 Lock Node에서 찾을 수 있다. Stratum 키들과 마찬가지고, NAC는 부가적인 액세스 속성 특성을 나타낼 수 있다.
KBP는 디지털 서명(dign)들을 생성하고 RSASSA-PSS(Bellare와 Rogaway가 발명한 Probabilistic Signature Scheme을 기반으로한 RSA probabilistic signature scheme with appendix) 또는 대안적 알고리즘과 같은 알고리즘들을 사용하여 데이터 스트링에 대하여 그것들을 비대칭적으로 인증하는 것과 같은 공개 키 암호화의 잘 알려진 특성들을 사용하여 배포될 수 있다. KBP의 기본 전제는 개인/공개 키 쌍이 주어지면, 개인 키 보유자(작성자)는 작성자의 개인키를 사용하여 데이터의 파슬(parcel)에 디지털 서명(dign)을 형성할 수 있고, 그 다음, 공개 키 보유자(판독자)는 판독자가 소유한 작성자의 공개 키를 사용하여, dign이 작성자에 의해 데이터의 파슬에 형성되었다는 것을 인증할 수 있다는 것이다. 인증이 실패하면, 공개 키, 데이터의 파슬 또는 dign 또는 그것들의 일부 또는 전부와 같은 무언가가 손상되었을 수 있다. 작성자는 매 수정마다 타겟 데이터 파슬에 갱신된 dign을 형성할 책임이 있을 수 있으며, 그리고 판독자는 데이터 파슬을 "판독"하거나 해독하기 전에 dign 및 타겟 데이터 파슬을 인증할 책임이 있을 수 있다. 이 프로세스는 상대방 개인키(작성자)를 가질 수 있는 사람이 생성하였거나 수정했을 수 있는 무언가를 읽을 수 있다는 것을 판독자에게 합리적으로 확신시킬 수 있다. RBCAC(Role Based Cryptographic Access Control)에서, 정의된 각각의 액세스 역할에 대해 비대칭 키 쌍이 있을 수 있으며, 그리고 역할의 "작성자"는 키의 개인 부분을 얻을 수 있으며, 그리고 역할의 "판독자"는 키의 각각의 공개 부분을 얻을 수 있다. 기능별로 데이터세트를 분리하고 서로 다른 키 쌍들을 사용하여 각각의 기능적 데이터세트를 dign함으로써, 액세스 역할들은 정확하게 정의될 수 있으며, 적절한 키 부분들을 배포함으로써 다양한 키 보유자들에게 할당될 수 있다. NUTS의 RBCAC는 하나 이상의 대칭 키들을 정의된 역할의 비대칭 키 쌍과 결합하여, 타겟 데이터세트에 대한 추가 제어 계층을 제공할 수 있다. 결합된 대칭 키의 보유자들은 해당 역할에 대한 타겟 데이터세트를 해독하고 읽을 수 있다. 이러한 결합된 대칭 키는 Variable Lock의 잠금 해제에 의해 드러난 대칭 키 그리고 eKS의 후속 키들에 의해 암호화 상단에서 타겟 데이터세트를 암호화할 수 있다. 대안적으로, 결합된 대칭 키의 존재는 eKS로부터 공개된 암호화 키의 사용에 우선할 수 있으며(overriding), 그리고 타겟 데이터세트를 대칭적으로 암호화하는 유일한 키일 수 있다. 이러한 대안은 두 번 이상 암호화되지 않을 것이므로 더 큰 타겟 데이터세트에 적합할 수 있다. 결합된 대칭 키는 타겟 데이터 세트에 대한 판독 액세스를 제어하는데 사용될 수 있다.
NAC의 실시예에서의 SDFT의 사용은 코딩을 상당히 단순화할 수 있다. 암호화 및 dign들은 수행될 기능들에 적합한 논리적으로 응집력있는(logically cohesive) TAR들에 임베디드될 수 있으며, SDFT의 unravel 프로세스는 이러한 작업들의 상세한 처리의 대부분을 자동화할 수 있다. TAR들과 연관된 임의의 지역화된 속성들은 타겟 데이터와 함께 폴딩될 수 있으며, 또는 그것의 보호 및 저장을 단순화하기 위해 다른 TAR과 추가 폴딩될 수 있다.
도 80의 표는 키 기반 허가들이 세 가지 정의된 역할들, 판독자들, 작성자들 및 검증자들, 그리고 다섯명의 역할 플레이어들인 A, B, V, X 및 Y와 함께 동작할 수 있는 방법의 예를 도시한다. 연결된 대칭 키 S를 소유한 모든 역할 플레이어들은 대칭 키 S를 사용하여 데이터를 암호화하거나 해독할 수 있는 능력을 가질 수 있다. COW(Class of Writers)인 X 및 Y는 비대칭 개인 키 R을 사용하여 상기 암호화된 데이터에 대한 dign을 형성할 수 있는 능력을 가질 수 있다. 비대칭 공개 키 U를 사용하여, COR(Class of Readers)인 A 및 B는 대응하는 디지털 서명이 암호화된 데이터에 대해 COW의 누군가에 의해 생성되었는지를 검증할 수 있는 능력을 가질 수 있으며, 그리고 그들은 대칭 키 S를 사용하여 데이터를 해독할 수 있는 능력을 가질 수 있다. 따라서, 유효한 dign을 생성하는 능력은 귀하가 데이터를 수정할 수 있는 능력을 가질 수 있고 다른 모든 판독자들은 dign이 유효한 작성자에 의해 생성된 것임을 인증할 수 있음을 암시할 수 있다. 정의된 역할들의 수는 소유자에 의해 요구되는 액세스 제어 세분성(granularity)에 의존하지만, 정의된 역할들의 일부 또는 전부는 도 80에 대해 기술된 바와 같이 방법론을 이용할 수 있다. 비대칭 공개 키 U만을 소유한 역할 플레이어는 검증자로 알려질 수 있다. 검증자는 전체 Nut를 순회할 수 있는 능력을 가질 수 있지만, 역할 클래스에 대응하는 타겟 데이터를 해독할 수는 없다. 예를 들어, COR 검증자는 오직 Nut의 페이로드가 dign에 대해 COW 공개키를 사용함으로써 적절한 COW 역할 플레이어에 의해 적절히 수정되었을 수 있음을 인증할 수만 있으며, 페이로드를 해독할 수는 없다. 왜냐하면, COR 검증자는 해독 키(S)의 사본을 가지지 않기 때문이다.
NAC는 콘텐츠의 보기 가능한(viewable) 그리고 수정 가능한 양상들에 정확하게 영향을 미치고 제어할 수 있으며, 이에 의해, Lock Node의 보기 가능한(viewable) 그리고 수정 가능한 양상들에, 그리고 이에 의해 Nut의 보기 가능한(viewable) 그리고 수정 가능한 양상들에 정확하게 영향을 미치고 제어할 수 있다. 도 81에 도시된 표는 Nut의 일부분들을 나열하지만, 원하는 만큼 더 많거나 더 적은 부분을 포함할 수 있다 : hair, tick, seal, vita, face, tale 및/또는 bale. Nut Logs들과 Nut History들에 대하여 표에서 일부 전방 참조들(forward reference)이 존재할 수 있다. 이는 이 문서의 뒷부분에서 자세히 설명될 수 있다. 각 행은 Lock Node를 나타낼 수 있으며, 그리고 Nut Part를 정의하는 데이터는 해당 Lock Node의 Bag에 보관될 수 있다. Bag Opacity 열에는 Lock Node의 메타데이터에 의해 제어될 수 있는 Lock Node의 Bag의 암호 모드가 도시될 수 있다. Bag은 Bag Opacity라고 불리는 메타데이터 설정들에 기초하여 암호화되거나 암호화되지 않을 수 있다(clear). 도 81의 표의 Nut Parts들의 일부 또는 전부가 주어진 Nut에 존재하면, Lock Node에 의해 표현될 수 있는 각각의 Nut Part는 Lock Node 연결 포인터들 및 연결 키들을 사용하여 위에서 아래로 순서대로 연결될 수 있다. 각각의 Nut Part의 Bag Opacity와 관련하여 이 표의 열을 아래로 순회하는 것은 Nut의 Gradient Opacity로 지칭될 수 있다. 적절한 외부 기본키의 소유자들은 결국 Lock Node의 Variable Lock을 잠금해제함으로써 Nut에 대한 액세스를 얻을 수 있다. 기본키의 SAC 설정들에 따라, 키 보유자는 Nut에 얼마나 멀리 순회할 수 있는지에 제한될 수 있다. NAC는 결합된 대칭 암호 키들의 신중한 배치에 의해, 비대칭 키 쌍들의 정확한 사용에 의해, 그리고 디지털 서명 방법을 사용함으로써, 어느 기본 키들이 각 Nut Part를 판독하고, 수정하고, 그리고/또는 인증할 수 있는지에 영향을 미칠 수 있다.
도 82는 일반적인 Nut에 대해 정의되고 이용될 수 있는 키 기반 허가 액세스 역할들(Key Based Permission access roles)을 나열하는 표를 도시한다. Nut 소유자의 필요에 따라 정의된 액세스 역할들이 더 많거나 더 적을 수 있으므로, 액세스 역할들은 이 목록에 의해 제한되지 않을 수 있다. 이 표는 다음과 같은 식별될 수 있는 Nut의 네가지 섹션들을 나열하지만, 이에 국한되지는 않는다 : Bale, Vita, Tale 및 All. All 섹션은 다른 액세스 역할에 의해 명시적으로 커버되지 않는 항목을 참조할 수 있다. 이로 인해 키 맵들, eDK들 및/또는 별도의 액세스 역할을 나타내는 키 쌍에 의해 지정되지 않는 암호화된 Bag들과 같은(그러나 이에 국한되지 않음) Lock Node의 일부 또는 모든 내부 작업이 수반될 수 있다. 이 논의를 위해, 키 쌍은 비대칭 키 쌍 및 결합된 대칭 키를 포함할 수 있다. 결합된 대칭 키의 존재는 액세스 클래스 검증자 역할의 존재에 의존할 수 있다. All 개인 키의 소유자는 RAT(Root Access Tier) 또는 Nut의 소유자라고 할 수 있다. 각각의 기본 키는 인증 목적으로 RAT 판독자 공개 키의 사본을 포함할 수 있는 키 맵을 가질 수 있다. Bale은 문서와 같은 Nut의 페이로드를 보유하는 Lock Node의 Bag에 보유될 수 있다. 이러한 키 쌍은 빈번한 사용으로 인해 특별히 COW(Class of Writers) 및 COR(Class of Readers)으로 명명될 수 있다. 이러한 키 쌍은 어느 기본 키가 Nut의 페이로드를 수정할 수 있는 능력을 가질 수 있는지를 제어할 수 있다. 유사한 방식으로, Nut Log는 Nut의 Vita 부분의 Bag에 보관될 수 있으며, 그리고 Logger/Log 판독자 키 쌍에 의해 제어될 수 있다. Nut History는 Nut의 Tale 부분의 Bag에 보관될 수 있으며, 그리고 Historian/History 판독자 키 쌍에 의해 제어될 수 있다. 각각의 액세스 역할 클래스에 대한 검증자 역할은 그와 연관된 dign을 인증하기 위해 해당 역할과 연관된 적어도 하나의 공개 키에 대한 액세스를 가질 수 있다. 검증자 역할은 그것이 액세스 권한을 갖지 않는 액세스 역할 클래스와 연관된 결합된 대칭 키가 존재할 수 있음을 암시할 수 있다. 유지 보수 프로세스는 Nut 부분의 유효성, 일관성 및/또는 신뢰성을 검사하기 위해 Nut 내의 정의된 검증자 역할들의 조합에 대한 액세스 권한을 부여받을 수 있지만, 보호된 데이터의 내용을 판독할 수는 없을 수 있다. 키 페어링은 이러한 세트들에만 국한되지 않으며, 요구 사항에 따라 확장되거나 축소될 수 있다. Lock Node의 임의의 암호화된 그리고/또는 암호화되지 않은 스트링들은 자체 고유의 키 쌍에 의해 생성된 dign을 가질 수 있으며, 그리고 잠금 그래프의 모든 Lock Node들은 극단적인 수준의 액세스 제어 세분화로 이어질 수 있는 이 특이성 수준을 사용할 수 있다. 그러나, 이러한 극단적인 수준의 액세스 제어 세분화는 그러한 Nuts에 대한 액세스 제어의 효과를 완화할 수 있다.
Lock Node의 Parameters 섹션은 적용할 디지털 서명 알고리즘과 비대칭 키의 길이(RSA-2048의 경우 기본값은 최소 2,048 비트)를 지정할 수 있다. 대안적으로, SDFT 사용은 특정 TAR이 그러한 기본설정(preference)을 나타낼 수 있게 하고, TAR 레이블은 Parameters 섹션에 대신 저장될 수 있다. Nut의 페이로드를 보유할 수 있는 Lock Node의 암호화된 Bag은 RAT 작성자 키를 사용하여 RAT 작성자에 의해 디지털 서명되지 않고, 오히려 RAT 작성자를 포함할 수 있는 COW 액세스를 갖는 키 보유자에 의해 디지털 서명될 수 있다. 기본 키 보유자들은 키홀 Lock Node의 키 맵의 액세스 키 세트 그리고 대응하는 AAPK(Access Attribute Propagation Key)를 통해 RAT 판독자 키에 대한 액세스 권한을 부여받을 수 있다. 이러한 RAT 판독자 키는 임의의 타당한 기본 키 보유자가 RAT 권한 영역에 있을 수 있는 Lock Node 내의 임의의 dign을 인증할 수 있게 할 수 있다(RAT 기록자 키에 대한 액세스를 가질 수 있는 기본 키 보유자에 의해 예시됨). 임의의 RAT dign의 인증 실패는 대응하는 스트링 또는 폴딩된 데이터가 손상되었을 수 있거나, 또는 RAT 판독자 키가 유효하지 않을 수 있거나, 또는 기본 키가 더 이상 유효하지 않을 수 있거나 또는 언급된 이유들 중 일부 또는 전부일 수 있다는 것을 암시할 수 있다. 애플리케이션은 이 경고를 표시할 수 있으며 그 이상으로 진행하지 않을 수 있다. 왜냐하면, Nut의 무결성이 손상되었을 수 있고 추가 해독 시도들이 성공하지 못하거나 손상된 데이터의 표시를 야기할 수 있기 때문이다.
도 83은 Nut가 NAC 액세스 키들의 초기 세트를 얻는 방법을 도시한다. 키홀 Lock Node(8300)로 시작하여, 기본키(8304)는 기본 키홀(8306)로 삽입될 수 있으며, 그리고 키 맵 구조(8310)를 나타낼 수 있는 암호화된 키 맵을 해독하거나 언폴딩할 수 있으며, 대칭일 수 있는 AAKSUK(Access Attribute Key Set Unlock Keys)(8314)로 구성된 키 세트를 포함할 수 있는 AKS(Access Key Se)(8312)가 존재할 수 있다. 각각의 개별 AAKSUK 대칭 키는 도 82의 표에 도시된 바와 같이 액세스 역할에 대응할 수 있다. 그 다음, AKS의 각각의 AAKSUK는 초기 기본 키홀(8306)과 동일한 Lock Node(8300)의 동일한 입력 섹션(8302) 내의 액세스 키홀(8320)에 삽입될 수 있으며, 이에 따라, 키 맵(8310)은 자신의 액세스 키홀(8320)을 공급할 수 있는 AKS(8312)의 키 세트를 보유할 수 있다. 이는 키홀 Lock Nodes(외향(external facing) Lock Node들)의 특별한 특성일 수 있으며, 대부분의 경우, 내부 Lock Node들에는 적용되지 않을 수 있다. 액세스 키홀(8320)에서, 각각의 적절히 삽입된 AAKSUK(8314)는 액세스 역할 설명(8332), 액세스 역할 키(Access Role Key; ARK)(8334) 및/또는 AAPK(Access Attribute Propagation Key)(8336)를 포함하는 대응 AAKS(Access Attribute Key Set)(8330)를 드러내기 위해 해독하거나 언폴딩할 수 있다. ARK(8334)는 공개(판독자) 또는 개인(작성자) 같은 주어진 역할에 대응하는 키 쌍 부분을 지정할 수 있다. AAPK(8336)는 다음에 연결된 Lock Node의 액세스 키홀로의 AAKSUK의 역할을 할 수 있는 대칭 키일 수 있다. AAKSUK들의 세트는 기본 키의 NAC 액세스 속성들, 그리고 궁극적으로는 Lock Node에서의 그것의 액세스를 정의할 수 있는 AAKS들의 세트를 구성할 수 있다. 이 다이어그램에서, AAKS(8330)은 그것이 RAT 개인 키와 COW 키를 포함하고 있기 때문에 Nut 소유자의 액세스 속성들을 지정할 수 있다. 이 다이어그램에는 AAKSUK들의 부가적인 속성 특성(이에 의해, NAC의 부가적인 속성 특성)이 설명될 수 있다; 액세스 키홀(8320)에 AAKSUK(8314)를 삽입할 때마다 부가적일 수 있도록, 기본 키홀(8306)에 삽입될 수 있는 각각의 기본 키(8304)에 대해 AKS(8312)가 존재할 수 있다. 동일한 AAKSUK들은 액세스 키홀에 의해 기존 AAKSUK를 덮어쓸 수 있으며, 이는 제시된 기본 키들 중 일부 또는 전부가 처리되었을 수 있을 때 고유 AAKS의 결합으로 이어질 수 있다. 이로 인해, 서로 다른 액세스 속성들의 기본 키들이 동시에 삽입될 수 있을 때 누적 액세스 속성 효과가 발생할 수 있다.
도 84는 AAPK들이 잠금 그래프의 나머지 Lock Node들에 걸쳐 NAC 속성들을 전파하는데 사용될 수 있는 방법을 도시한다. 키홀 Lock Node(8400)는 적절히 잠금 해제될 수 있고, 그리고 일부 또는 모든 AKS(8402)는 액세스 키홀(8404)에 삽입되어 AAKS(8420)를 초래할 수 있다. 그 다음, 액세스 속성 전파 키들(Access Attribute Propagation Keys; AAPK)(8424)은 다음 링크된 Lock Node의 액세스 키홀(8432)에 삽입될 수 있다. 이것은 키홀 Lock Node의 액세스 키홀이 채워진 방법과 유사할 수 있지만, 키들은 자체 기본 키홀에서 발견되거나 발견되지 않을 수 있는 AKS가 아니라 링크된 Lock Node에서 나온 것이다. 내부 Lock Node(8430)의 기본 키홀(미도시)은 RAT 액세스 레벨 키들을 제외하고 키 맵에 빈 AKS를 가질 수 있다. 이러한 전파 방법에 따르면, 기본 키의 액세스 속성들은 잠금 그래프의 모든 오픈된 Lock Node에 존재할 수 있다. Lock Node는 액세스 역할이 COW와 같을지라도 Lock Node 내에서 자체 용도로 생성되는 AAKS의 상이한 세트들을 갖는 것과 같이 일부 또는 전부 또는 그것의 내부 제어 메커니즘들을 분리(isolating)하고 로컬라이징할 수 있다. AAKSUK 및 AAPK 대칭 키들조차 그것들이 제대로 매핑될 수 있는 한 상이할 수 있다. 전체 Lock Node에 대한 AAKS의 전체 세트를 RAT에 할당하고 잠금 그래프 전체에 걸쳐 적절히 전파될 수 있게 하는 것은 잘-정의된 Nut들의 전제가 될 수 있다. 참고로, RAT 공개 키에 의해 암호화될 수 있고 Lock Node의 Parameters 섹션에 저장될 수 있는 AAPK 및 ARK의 완전한 세트가 존재할 수 있으며, 따라서 Lock Node를 재작성해야할 때 오직 RAT만이 드러날 수 있다.
도 85는 외부 Lock Node(8500)로부터 내부 Lock Node(8530)로의 AAPK를 사용하는 액세스 속성들의 전파를 도시한다. 다이어그램은 링크된 Node의 기본 키홀(8550) 및 액세스 키홀(8560)을 공급하기 위해 다양한 키들이 제공될 수 있는 위치들을 보여준다. 출력 섹션(8510)은 링크된 Lock Node(8530)의 기본 키홀(8550)에 대한 링크 대칭 키(8512)를 나타낼 수 있다. AAPK(8522)는 링크된 Lock Node(8530)의 액세스 키홀(8560)에 삽입될 수 있다(8524).
도 86은 이전 섹션들의 예들을 사용하여 상세히 설명된 액세스 키홀에 키들을 삽입하기 위한 흐름도를 도시한다.
도 87은 다른 실시예에 대한 키 기반 허가들의 표를 도시한다. 이 표는 쓰기 비대칭 키 쌍(UW, RW) 그리고 인스턴스별 데이터 암호 대칭 키(Sn)를 추가로 정의함으로써 도 80에 제시된 표를 더 확장시킬 수 있다. 도 80의 3개의 키들은 대안적으로 Dign 비대칭 키 쌍(UD, RD) 그리고 디폴트 데이터 암호 대칭 키(S0)로 표현될 수 있다. 추가 키들은 ARK가 Lock Node의 Bag에 기록할 수 있지만 Bag의 다른 부분을 읽을 수 없는 WriteOnly 액세스 역할을 정의할 수 있게 할 수 있다. WriteOnly 역할은 키들(RD, UD, UW 및 Sn)에 대한 액세스를 가질 수 있다. WriteOnly 역할이 메시지(Tn)를 Lock Node의 Bag에 저장하기를 원할 때, Tn을 암호화하여 암호화된 메시지(En)를 생성하기 위해 단일 인스턴스 대칭 암호화 키(Sn)를 생성할 수 있다. 그 다음, 단일 인스턴스 대칭 암호 키(Sn)는 암호화된 키(Kn)를 생성하기 위해 키(UW)를 갖는 비대칭 암호를 사용하여 암호화될 수 있다. 이제 En 및 Kn은 모두 Lock Node의 Bag에 저장될 수 있다. WriteOnly는 또한 RD 키를 사용하여 dign을 생성할 수 있으며 이를 저장할 수 있다. 메시지 인증은 간결함(coompactness) 및 조직적인 단순성을 위해 그러한 정보를 임베디드하고 자동으로 폴딩할 수 있는 인증 SDFT TAR 시퀀스의 적절한 적용에 의해 대안적으로 또는 추가적으로 수행될 수 있다. 이러한 TAR 시퀀스들은 임의의 keyed MAc 변환들을 사용하는 메시지 인증의 대안 방법을 허용할 수 있다. WriteOnly 역할 플레이어가 기록을 마칠수 있고 Sn의 메모리 내 인스턴스가 파괴되면, 역할 플레이어는 더 이상 메시지(En)를 해독하기 위해 Sn 키에 액세스할 수 없다. WirteOnly 역할이 비대칭 개인 키(RW)를 소유할 수 없기 때문이다. 판독자 및 기록자 역할들과 같이 비대칭 개인 키(RW)의 사본을 소유할 수 있는 액세스 역할들만이 암호화된 키(Kn)를 해독하여 Sn를 획득할 수 있으며, 그리고 그것을 사용하여 암호화된 메시지(En)에 대해 작업하여 원래의 메시지(Tn)를 획득할 수 있다. 인증 방법은 다수의 개별 메시지들을 포함하는 페이로드들에 대해 인증 프로세스를 보다 효율적으로 만들기 위해 Merkle 트리가 작동하는 방식과 유사한 해시 또는 dign chaining을 추가로 포함할 수 있다. WriteOnly 역할 액세스는 로컬 시스템에 의해 작동중인 Lock Node에서의 이전 메시지들의 무단 잘림(unauthorized truncation) 또는 덮어쓰기(overwriting)를 막을 수 없다. 그러나, NUTS 생태계(ecosystem)는 Nut 히스토리, 복제 및 동기화 기능들을 다양한 협업 방식(cooperative way)으로 활용함으로써 그러한 발생을 예방하거나 강조하는데 도움이 될 수 있다. 이것은 이후에 NutServers 및 Revision Control 모듈들에 대한 섹션에서 논의될 것이다.
도 87의 표에 제시된 WriteOnly 및 검증자의 제한된 역할 기능들은 컴퓨터 시스템 보안 내에 널리 퍼져 있는 "God Key" 난제와 관련된 일부 문제를 완화하는데 도움이 될 수 있다. 이는 잘 알려진 종류의 문제일 수 있다. 일례로, 시스템 관리자는 시스템(들)을 유지, 업그레이드, 수리, 설치 그리고/또는 문제 해결을 위해 시스템 또는 시스템 세트에 "God Key" 또는 모든 액세스 크리덴셜들을 제공받게 될 수 있는 경우가 있다. 산업계에서는 기술적 능력과 높은 비밀 취급 인가(elevated security clearance)를 자동으로 연관시키는 경향이 있을 수 있다. 적절한 비밀 취급 인가 확인을 통한 매우 유능하고 숙련된 시스템 관리자가 비교적 적기 때문이다. 이러한 유형의 관행은 상대방에 의해 감지될 수 없거나 타인으로부터 의도적으로 숨겨질 수 있는 일방적인 방식으로 양 당사자간의 신뢰 수준이 시간에 따라 변할 수 있는 신뢰 관계의 동적 특성을 다루지 못할 수 있다. WriteOnly 및 검증자 액세스 역할들을 신중하게 사용하면, 페이로드들은 전송 중인 데이터 또는 유휴 상태의 데이터(data at rest)에 대한 무단 액세스로부터 보호될 수 있다. 이러한 두 액세스 역할들의 적용은 기관이 기술 능력 및 비밀 취급 인가의 결합 성격(conjoined nature)을 분리할 수 있게 하여, 각각의 양상을 보다 적절하고 독립적으로 완벽하게 관리할 수 있게 할 수 있다. WriteOnly 역할은 사람들과 프로세스들이 처리의 증거로서 Nut의 Log 컴포넌트에 추가할 수 있게 할 수 있지만, 사람들과 프로세스들이 페이로드를 읽거나 Log를 편집하지 못하게 할 수 있다. 추가적으로, WriteOnly 역할은 두 Dign 키들에 액세스할 수 있으며, 그리고 인증 스트링들을 생성할 수 있으며 그것들을 검증할 수 있다. 검증자 역할은 페이로드에 대한 액세스를 허용하지 않으면서 사람들 및 프로세스들이 내부 일관성과 신뢰성에 대해 Nut를 검사할 수 있게 할 수 있다. Lock Node들은 noSQL 또는 RDBMS와 같은(그러나 이에 국한되지 않음) 임의의 데이터베이스 시스템 내에 체계적으로 수정, 적용 및 삽입되어, 필드, 레코드, 표 및/또는 데이터베이스 수준에서 액세스 제어들의 이러한 세분성을 규정할 수 있다. 간결함, 유연성, 기능들 및/또는 독립성으로 인해, Lock Node들이 컴퓨터화된 기기(computerzied appliance)에 기기 자체로의 임베디드된 액세스 게이트웨이로서 존재할 수 있다. 이는 나중에 Nut들의 인터넷에 대한 섹션에서 더 자세히 논의될 수 있다.
NAC 특징들은 타겟 페이로드에서 취해질 수 있는 동작들에 대한 전체 순열 세트(complete set of permutations)를 포함할 수 있다. NAC 구현과 함께 허용된 동작들의 단순한 상호 참조 행렬은 다음과 같이 도시될 수 있다 :
동작들 판독 작성 검증
판독 판독자 작성자 판독자
작성 작성자 WriteOnly WriteOnly
검증 판독자 WriteOnly 검증자
판독자 및 작성자 역할들은 Lock Node의 Bag에 포함된 dign을 검증하거나 인증할 수 있는 암묵적 능력을 가질 수 있다.요약하면, Lock Node에 대한 3 가지 보호 방법들이 존재한다 : Variable Locks, Stratum 액세스 제어 및/또는 Nut 액세스 제어. Variable Lock은 주로 일부 데이터 컨텐츠를 운반하는데 사용될 수 있는 Lock Node의 Bag을 보호할 수 있다. Stratum 액세스 제어는 사용자가 잠금 그래프 Strata에 얼마나 깊이 침투할 수 있는지 정의할 수 있다. Nut 액세스 제어는 Nut의 어느 부분들이 사용자에 의해 수정되고, 보이고, 쓰여지고, 디지털로 서명될 수 있는지 지정할 수 있다. 이러한 계층들의 일부 또는 전부는 Lock Node의 키홀 메커니즘 내에서 임베디드되거나 폴딩된 키 세트들에 의해 제어될 수 있다. 키홀 메커니즘은 다양한 기능을 위해 광범위한 암호 키들이 삽입되고 처리될 수 있게 하는 유연한 진입로일 수 있다. 이러한 컴포넌트들 중 일부 또는 전부가 함께 그리고/또는 개별적으로 작동하여, Nut 단위로 사용자 정의될 수 있는 풍부한 액세스 제어 세트를 제공할 수 있으며, 그리고 보호될 컨텐츠에 대해 요구될 수 있는 잠금 동작을 나타내기 위해 모듈식으로 구성될 수 있다. Lock Node의 모듈성은 또한 반복적이고, 컴팩트하고 모듈식인 설계로 인해 많은 복잡한 잠금 구조들을 간단하게 구축할 수 있다. 많은 상이한 알고리즘들이 Nut를 완전히 잠금 해제하고 이용하기 위해 사용될 수 있지만, 메커니즘들을 개시하기위한 정보는 Nut의 Lock Node들 내에 완전히 저장될 수 있는 암호화된 데이터 부분들로 표현될 수 있으며, 따라서, 그것의 액세스 제어 메커니즘들은 이식 가능하고(portable), 어떤 외부 참조 모니터들과도 독립적으로 페이로드와 함께 이동할 수 있다. 이러한 메커니즘들은 구현을 단순화하고 내부 코딩 및/또는 데이터 세부 정보의 복잡성을 보다 잘 관리하는데 도움이 되는 다양한 SDFT 방법들 및 구조들에 의해 더 구현될 수 있다.
Nut의 액세스 제어 모델들은 강제적 액세스 제어(Mandatory Access Control)(중앙 집중식), 임의 액세스 제어(Discretionary Access Control)(사용자 중심) 및 기타의 조합일 수 있다. 그것은 자체적으로 액세스 속성들의 일부 또는 전부를 저장할 수 있는 방식과 소유주가 Nut 마다 액세스 수준들을 직접 설정하여 전송성을 용이하게 할 수 있는 방식으로, 임의 액세스 제어 모델과 유사할 수 있다. 또한, 이는 일부 또는 모든 강제적 액세스 제어 모델들을 수용할 수 있으며, 그리고 그것의 키홀들, Variable Lock들 및 다른 메커니즘들에 의해 제공되는 유연성으로 인해 일부 또는 모든 환경들에 통합될 수 있다. 뿐만 아니라, 이는 Gradient Opacity, Additive Access Attributes 및/또는 NUTS에 신규할 수 있는 모듈러 Lock Node 연결과 같은(그러나 이에 국한되지는 않음) 다른 특성들을 나타낼 수 있다.
Lock Node 순회
이제 우리는 전체 Lock Node를 순회할 수 있으며, 그리고 이를 따라 상황이 어떻게 전개될지를 볼 수 있다. 도 88은 Lock Node(8800) 내에서 복호화 데이터 흐름을 도시하는 간략화된 도면을 도시한다. 도 62, 도 78, 도 83, 도 84, 도 85, 도 88과 같은 Lock Node 잠금 해제 프로세스의 상호 결합되고 통합된 묘사와 관련된 다른 도면들의 요소들에 대한 참조가 이루어질 수 있다. 참조들은 상이한 요소 번호들에 의해 번호가 매겨진 동일한 Lock Node 섹션에 대해 이루어질 수 있지만, 드릴 다운(drill down) 유형의 접근 방식에서 검사되는 동일한 섹션에 대한 다른 뷰를 나타낼 수 있다. Lock Node 잠금 해제 프로세스에서 요구될 수 있는 논리 연산들의 시퀀싱은 효율성 및/또는 다른 목적들을 위해 더 최적화될 수 있다. Lock Node을 잠금 해제하는 프로세스, 그리고 이에 의해 결국 잠금 그래프 또는 Nut를 잠금해제하는 프로세스는 이 예에서 기술될 수 있는 이러한 단계들을 포함할 수 있는데, 이러한 단계들은 Lock Node에 대한 액세스 권한 및 해독 키들을 얻기 위해 기본 키들을 사용, Lock Node의 인증, 잠금 그래프를 통한 액세스 권한 전파, Variable Lock의 논리 연산 및/또는 저장된 데이터의 해독을 포함할 수 있지만 이에 국한되지는 않는다; 이러한 단계들은 필요에 따라 확장되거나, 축소되거나, 또는 재정렬될 수 있다. 적절하다면, 잠금 그래프 및 Lock Node 내의 특정 메커니즘들은 SDFT 방법들의 적절한 적용으로부터 이익을 얻을 수 있다.
기본 키들(8804)은 입력 섹션(8806)에 삽입될 수 있고, 그리고 각각의 기본 키는 그와 연관된 암호화 방법을 사용하여, 매칭하는 암호화된 키 맵(8810)을 해독하고, 그것을 키 맵(8808) 구조로 펼치려고(unfurl) 시도할 수 있다. 각각의 키 맵(6240)은 Variable Lock(8812)에 의해 사용될 수 있는 메인 키(6210)를 생성할 수 있다. 각각의 키 맵(7840)(6240과 동일) 내에, Stratum 키들의 세트(7850)가 존재할 수 있고, 각각의 Stratum 키(예를 들어, 7852-7858)는 각각의 입력 섹션(8302)의 기본 키홀(8306)에서 잠금 그래프의 매칭하는 Strata Lock Node들(예를 들어, 7820-7830)에 삽입될 수 있다(이 예에서, 7852-7858과 같은 Stratum 키는 8304의 기본 키와 동일할 수 있다); Stratum으로 지정된 7820-7830과 같은 Lock Node들은 MATLOCK을 사용할 수 있는데, 이를 열기 위해서는 다음과 같은 최소 두 개의 키가 필요할 수 있다 : 7852 같은 Stratum 키 및 출력 섹션(8510 또는 8826)에서 발견될 수 있는 8512 같은 출력 링크 키. 키홀 Lock Node(8300)에 대해, 각각의 키 맵(8310) 내에, 액세스 키 세트(AKS)(8312)라 불리는 AAKSUK(Access Attribute Key Set Unlock Keys)(8314)의 세트가 존재할 수 있으며, 각각의 AAKSUK 키는 현재 키홀 Lock Node(8300)의 입력 섹션(8302)의 액세스 키홀(8320)에 삽입될 수 있다. 일단 AAPK들(8336)의 세트가 이러한 방식으로 획득될 수 있다면, 그것들(8522)(8336과 동일)은 다음 링크된 Lock Node(8540)의 액세스 키홀(8560)에 삽입될 수 있다. 이제 우리는 액세스 역할 키(ARK)(8334)들을 포함할 수 있는 액세스 속성 키 세트(AAKS)(8332)를 가질 수 있다. ARK는 전체 잠금 그래프에 대한 기본 키들(8304)의 액세스 역할들을 정의할 수 있다. 8840-8848 같은 다양한 Lock Node 섹션들의 dign들은 이러한 ARK들을 사용하여 인증될 수 있다. Lock ID & 메타데이터의 dign(8840)은 RAT Public ARK(8344)(이는 NAC 스펙들에 설명된 RAT 비대칭 키 쌍의 공개 부분일 수 있음) 및 섹션(8830)에 지정된 인증 알고리즘을 사용하여 인증될 수 있다. 인증하기 위해, 섹션(8830)은 대응 dign(8840) 및 RAT Public ARK(8344)와 함께 인증 알고리즘에 제출될 수 있다. 인증이 실패하면, 섹션(8830)은 손상되었을 수 있으며, Lock Node 잠금 해제 프로세스는 오류를 발생시키고 프로세스를 중단할 수 있다. 성공적으로 인증된다면, 암호화된 키 맵들의 각각의 dign(8842)은 유효한 삽입된 기본 키에 대응하는 각각의 암호화된 키 맵에 대해 인증될 수 있다. 인증하기 위해, 각각의 eKM(8810) 스트링은 대응 dign(8842) 및 RAT Public ARK(8344)와 함께 인증 알고리즘에 제출될 수 있다. 인증이 실패하면, eKM은 손상되었을 수 있으며, Lock Node 잠금 해제 프로세스는 오류를 발생시키고 프로세스를 중단할 수 있다. 모든 적절한 eKM들이 성공적으로 인증되었다면, 암호화된 유도 키의 각각의 dign(8844)가 인증될 수 있다. 인증하기 위해, 각각의 eDK(8814)는 대응 dign(8844) 및 RAT Public ARK(8344)와 함께 인증 알고리즘에 제출될 수 있다. 인증이 실패하면, eDK는 손상되었을 수 있으며, Lock Node 잠금 해제 프로세스는 오류를 발생시키고 프로세스를 중단할 수 있다. 모든 적절한 eDK들이 성공적으로 인증되었다면, 암호화된 키 세트의 각각의 dign(8846)가 인증될 수 있다. 인증하기 위해, 각각의 eKS(8818)는 대응 dign(8846) 및 RAT Public ARK(8344)와 함께 인증 알고리즘에 제출될 수 있다. 인증이 실패하면, eKS는 손상되었을 수 있으며, Lock Node 잠금 해제 프로세스는 오류를 발생시키고 프로세스를 중단할 수 있다. 모든 적절한 eKS들이 성공적으로 인증되었다면, 암호화된 Bag의 각각의 dign(8848)가 인증될 수 있다. 인증하기 위해, 각각의 eBag(8822)는 대응 dign(8848) 및 COR ARK(8348)와 함께 인증 알고리즘에 제출될 수 있다. 인증이 실패하면, eBag는 손상되었을 수 있으며, Lock Node 잠금 해제 프로세스는 오류를 발생시키고 프로세스를 중단할 수 있다. 모든 적절한 eBag들이 성공적으로 인증되었다면, 이 Lock Node는 완전히 인증된 것으로 간주될 수 있다. eBag는 COR(Class of Reader) 액세스 역할 키(8348)를 사용하여 인증될 수 있음을 유의한다. 이는 Nut의 페이로드를 보유하는 Lock Node들에 대해 true일 수 있지만, Nut 메타데이터를 그것들의 Bag들에 보유하는 Lock Node들에 대해서, 이를 인증하는데 RAT Public ARK가 대신 사용될 수 있다. 그 다음, Lock Node의 파라미터 섹션(8830)에 표시된 Variable Lock 유형에 기초하여, 키 맵들(8808)로부터의 메인 키들의 세트(7844)를 사용하여 각각의 암호화된 유도 키 스트링(eDK)(8814)에 대해 적절한 Variable Lock 알고리즘(8812)이 시도될 수 있다. eDK(8814)를 해독함으로써 Variable Lock(8812)를 성공적으로 잠금 해제하면 하나 이상의 유도 키(DK)(8816)가 생성될 수 있다. 각각의 유도 키는 파라미터들(8802)에 저장될 수 있는 대응하는 암호화된 키 세트 스트링(eKS)(8818)을 해독할 수 있다. eKS를 해독하면 출력 섹션(8826) 및 Bag 키를 보유할 수 있는 대응하는 키 세트(8820) 구조를 생성할 수 있다. 키 세트(8820)에서 발견될 수 있는 출력 연결 키(들)는 출력 섹션(8826)에 저장될 수 있고, 연결된 Lock Node(8530)가 있다면 연결된 Lock Node(8530)의 기본 키홀에 삽입될 수 있는 키로서 기능할 수 있다. Bag 키는 적절한 암호를 사용하여 Parameters 섹션에 저장될 수 있는 암호화된 Bag 스트링(eBag)(8822)를 해독할 수 있다. 해독된 Bag은 Nut(잠금 그래프)의 페이로드, 페이로드에 대한 메타데이터, Nut의 메타데이터, Bag의 메타데이터, 이들의 임의의 조합 및/또는 다른 데이터와 같은(그러나 이에 국한되지는 않음) 데이터를 보유할 수 있다. Bag 메타데이터는 Bag(8824)이 Nut Part 또는 Nut 페이로드를 보유하고 있는지 여부를 나타낼 수 있다. Bag가 Nut Part를 보유하고 있다면, 그것은 그것이 어느 Nut Part를 표현할 수 있는지 그리고 다른 적절한 Nut Part 메타데이터 및/또는 다른 데이터를 나타낼 수 있다. Bag이 Nut의 페이로드를 보유한다면, 그것은 저장된 데이터가 실제 데이터인지 또는 그것에 대한 참조인지 여부를 나타낼 수 있으며, 그리고 실제 데이터에 대한 참조라면, 그것이 어떤 유형의 참조인지, 무엇이 참조될 수 있는지, 그리고/또는 어디에 위치할 수 있는지를 나타낼 수 있다.
이러한 일련의 단계들은 Nut를 잠금 해제하기 위해 잠금 그래프의 각 Lock Node에 대해 반복될 수 있다. 도 89는 Nut 잠금 해제의 일반적인 흐름도를 도시한다. 대부분의 단계들은 이전 예에서 자세히 설명되었지만, 일부 단계들은 더 명확하게 해야 할 수도 있다. 단계8902 - Lock Node들을 적절한 순회 수준으로 조직화 : Lock Node들은 목록 유형 구조에서 행 기반 형태(row based form)로 저장될 수 있기 때문에, 잠금 그래프의 실제 토폴로지는 각 Lock Node 내에 저장될 수 있는 링크 정보를 사용하여 추출되고 구성될 수 있다. 그래프가 구성되면, Lock Node들이 적절한 순서로 순회될 수 있도록 그래프 레벨들을 적절히 할당하기 위해 하나 이상의 추가 패스들이 수행될 수 있다. 단계8908 - 일부 또는 모든 패스프레이즈 기반 키홀들을 프롬프트 : 입력 섹션의 처리 동안, 패스프레이즈 기반 키홀에 비어있는 키(패스프레이즈)가 있으면, 해당 패스프레이즈에 대해 프롬프트될 수 있다. 이러한 디폴트 동작은 다른 함수를 호출하거나 임의의 빈 패스프레이즈 키홀들을 바이패스하도록 수정될 수 있다. 흐름도에서 임의의 논리적 단계 또는 프로세스는 제기될 수 있는 오류를 가질 수 있으며, 그리고 프로세스 중단으로 이어질 수 있으며, 그리고 이것들은 더 높은 수준의 흐름도이기 때문에 자세히 명시되지 않는다 : 예를 들어, 작업을 시도하는 임의의 프로세스는 실패할 수 있고 알고리즘을 정지시킬 수 있다. 흐름도의 나머지는 이전 예의 경로를 따를 수 있다.
도 90은 NUTS 기반 시스템이 Nut에 포함되는 문서를 오픈할 수 있는 방법을 도시한다. 전방 참조가 도입된다 : NUTbook(900)은 Nut들을 사용할 수 있는 데이터 수집 조직화 애플리케이션(data collections organizing application)일 수 있으며, 그리고 패스워드, 암호 키들 및/또는 인증서들의 모음을 저장하고 조직화하는데 있어서 기본적으로 개인 PKI 역할을 수행할 수 있다. 9002와 9004와 같은 파일 심볼들은 Nut 파일을 나타내기 위해 다이어그램 전체에서 사용될 수 있다. NUTbook 시스템 내에, 메인 NUTbook 액세스 키 Nut(9002)가 존재할 수 있는데, 이는 애플리케이션으로부터 최소한의 기능을 얻기 위해 잠금 해제될 수 있다. 키는 Nut(9002) 내에 저장될 수 있으며, 그리고 메인 NUTbook key라고 불릴 수 있으며, 그리고 Nut(9002) 자체에 대한 잠금 해제 메커니즘은 패스프레이즈를 포함할 수 있다. 메인 NUTbook 키(9002) 및 문서 액세스 키(9004)와의 계층적인 키 관계가 존재할 수 있으며, 이로써, 이 구성에서 Nut들을 보유하는 임의의 문서에 액세스하려면, 문서 액세스 키가 필요할 수 있다. 따라서, 계층(hierarchy)은 문서 액세스 키(9004)를 열고 액세스하기 위해 메인 NUTbook 키(9002)를 필요로 하는 것으로 설정될 수 있다. 문서 액세스 키를 보유하는 Nut는 NUT ID #33(9016)를 가질 수 있다. 이에 따라, 페이로드(9020)에 저장될 수 있는 키는 키 ID #33으로 지칭될수 있다 : 문서 액세스 키 및 그것을 보유하는 Nut의 Nut ID는 동일한 ID(이 경우, #33)로 참조될 수 있다. 문서(9040)는 Nut ID #44(9036)를 갖는 Nut(9030)에 저장될 수 있다. 이와 유사하게, 문서는 문서 #44로 지칭될 수 있다. 사용자가 문서 #44를 열기로 결정할 때, 기본 키홀(9032) 내의 키홀들 중 하나는 그것을 열기 위해 키 ID #33이 필요할 수 있다고 지정할 수 있다. Nut #33(9004)는 NUTbook으로부터 요청될 수 있으며, 그리고 그것을 열려면, Nut(9004)가 열릴 필요가 있을 수 있다. 해당 Nut를 열려면, Nut(9002)를 열어야 할 수 있다. 사용자가 Nut(9002)에 대한 패스프레이즈로 자신의 NUTbook을 이미 초기화했을 수 있고, NUTbook이 메인 NUTbook 키를 메모리에 캐시했을 수 있다고 가정한다. 그 다음, Nut(9004)를 여는 경우에만 NUTbook의 문서 레벨 액세스에 대한 추가 패스프레이즈가 필요할 수 있으며, 일단 열 수 있다면, 연속적인 Nut 잠금 해제들이 발생하여 결국 해독된 문서 #44(9050)가 드러날 수 있다. NUTbook은 세션 동안 문서 가져오기를 신속하게하기 위해 문서 액세스 키를 제한된 시간 동안 캐시할 수 있지만, 비활성, 하이버네이션(hibernation), 화면 잠금, 시간초과 및/또는 명시적 잠금과 같은 특정 이벤트들은 문서 액세스를 위해 패스프레이즈가 다시 입력될 것을 요구할 수 있다. 이 섹션은 NUTbook 애플리케이션과 계층적 패스워드 개념들을 도입하였으며, 이는 이후 섹션에서 더 논의될 수 있다. 단일 문서를 여는데 필요할 수 있는 일련의 단계들은 많을 수 있지만, 사용된 논리의 일부 또는 전부는 Lock Node들과 그것의 반복적 프로세스들을 기반으로 할 수 있으며, 대부분은 사용자로부터 숨겨질 수 있다. 최종 결과는 데이터 조각이 9030과 같이 Nut에 저장될 수 있으며, 그리고 보안이 일부 또는 모든 환경에서 일관될 수 있다는 것일 수 있다.
도 91은 Nut의 페이로드를 보유하는 Nut의 Nut ID에 의해 Nut의 페이로드를 지칭하는 NUTS 용어의 일반적인 사용법을 보여준다. 여기서, 키 #33에 대해 태그된 키홀(9124)이 실제로 Nut ID #33(9112)를 갖는 Nut(9110)를 어떻게 찾을 수 있는지를 보여주며 그리고 Nut #33이 키홀(9124)에 삽입될 수 있는 단일 키(9114)를 보유할 것으로 기대할 수 있다. 이러한 다이어그램들과 예들 중 대부분에서, Nut가 파일에 저장될 수 있다면, Nut 파일의 파일 이름이 대부분의 작업들에서 거의 참조되지 않을 수 있다는 것을 유의하는 것이 흥미로울 수 있다.
다음 다이어그램 세트는 Variable Lock들 및 Lock Node 링크를 사용하여 Lock Node 및 잠금 그래프 모델의 유연성 및 표현력을 강조할 수 있는 잠금 그래프의 다양한 예시적 실시예들을 도시한다.
도 92는 수신자 잠금 모델의 목록의 단순화된 실시예를 도시한다 : 임의의 하나의 키(9210)는 Nut의 페이로드(9290)를 운반하는 Lock Node에 도달할 수 있는 ORLOCK Lock Node(9220)를 잠금 해제할 수 있다. 간단하게 하기 위해, Lock Node는 자물쇠로서 그림으로 표현될 수 있지만, 실제로는, Nut에 대한 일부 메타 데이터를 저장할 수 있는 완전히 기능하는 Lock Node라는 것에 유의한다.
도 93은 정렬된 잠금 모델의 간략화된 실시예를 도시한다 : 키(9310)가 먼저 제시될 수 있으며, 그 다음 둘째로, Nut의 페이로드(9390)에 대한 액세스를 가능하게 할 수 있는 키(9320)가 제시될 수 있다. MATLOCK Lock Node(9312)는 단일 키를 필요로할 수 있지만, MATLOCK Lock Node(9322)는 키(9320)와 Lock Node(9312)로부터의 연결 키 모두를 필요로 할 수 있다.
도 94는 마스터 키를 갖는 정렬된 잠금 모델의 단순화된 실시예를 도시한다 : 키(9410)가 먼저 제시될 수 있으며, 그 다음 둘째로 Nut의 페이로드(9490)에 대한 액세스를 가능하게 할 수 있는 키(9420)가 제시될 수 있다. 또는, 마스터 키(9430)가 ORLOCK Lock Node(9432)에 직접 제시되어 페이로드(9490)에 대한 액세스를 가능하게 할 수 있다. ORLOCK Lock Node(9432)는 링크 키 또는 마스터 키가 그것을 잠금 해제하도록 허용할 수 있다.
도 95는 마스터 키를 갖는 잠금 모델의 단순화된 실시예를 도시한다 : Nut의 페이로드(9590)에 대한 액세스를 허용할 수 있는 키(9510) 또는 마스터 키(9520)가 함께 또는 개별적으로 제시될 수 있다.
도 96은 마스터 키를 갖는 잠금 모델의 단순화된 실시예를 도시한다 : Nut의 페이로드(9690)에 대한 액세스를 허용할 수 있는 키(9610) 또는 마스터 키(9620)는 함께 또는 개별적으로 제시될 수 있다. 잠금 그래프(9632)에서의 MATLOCK의 위치는 이 Nut에 대해 특정 Stratum 제어들이 존재할 수 있고 그리고 일부 Nut 메타데이터를 저장하는 Nut Part일 수 있음을 나타낼 수 있다.
도 97은 안전 금고(safe deposit box) 잠금 모델의 단순화된 실시예를 도시한다 : Nut의 페이로드(9790)에 대한 액세스를 허용할 수 있는 키(9710) 및 은행 키(9712)가 함께 제시될 수 있다.
도 98은 마스터 키를 갖는 비밀 공유 잠금 모델의 단순화된 실시예를 도시한다 : 키들의 세트(9810)로부터, 비밀 공유 임계값을 충족하거나 초과하는 다수의 키들이 함께 제시될 수 있으며, 이러한 다수의 키들은 Nut의 페이로드(9890)에 대한 액세스를 허용할 수 있다. 또는, 마스터 키(9820)는 페이로드(9890)에 대한 액세스를 허용할 수 있는 ORLOCK Lock Node(9822)에 직접 제시될 수 있다. 키홀/키 맵 구조들이 SSLOCK Lock Node(9812)에서 이용되는 비밀 공유 방식에 의해 필요할 수 있는 tine을 숨길 수 있기 때문에, 키들(9810)은 패스프레이즈들, 대칭 키들 및/또는 비대칭 키들의 임의의 조합일 수 있다.
도 99는 "PrivaTegrity" 유형 잠금 모델의 단순화된 실시예를 도시한다 : 페이로드(9990)에 대한 액세스를 허용할 수 있는 사용자 키(9920)는 ORLOCK(9922)에 제시될 수 있다. 또한, Nut(9990)의 페이로드에 대한 액세스를 허용할 수 있는 9개의 키들(9910)은 MATLOCK(9912)에 함께 제시될 수 있다. "PrivaTegrity" 모델은 사용자에게 알려진 키들을 사용하여 메시지들을 안전하게 전송할 수 있는 텍스트 메시징 시스템을 구현하기 위해 David Chaum에 의해 2016년 초에 제안되었을 수 있지만, 9개의 모든 관할구역들이 그것이 중요할 수 있으며 합법적으로 보장될 수 있다는 데 동의할 수 있는 경우에만, 법 집행 기관에 특정 메시지들에 대한 액세스 권한을 부여하기 위해 9 개의 국제 관할구역들에 의해 보유되는 최대 9개의 상이한 키들을 포함할 수 있는 공모의 백도어 시스템(collusionary backdoor system)을 가질 수 있다.
도 100은 다수의 페이로드들이 단일 Nut 내에 저장될 수 있는 다중 너트 구성의 단순화된 실시예를 도시한다 : 사용자 키들(10010) 또는 마스터 키(10012)는 그것들의 Stratum 액세스 제어들에 의존할 수 있는 하나의 페이로드 또는 둘다에 액세스할 수 있다. 마스터 키(10020)는 잠금 그래프를 통과하는 순회 경로로 인해 페이로드(10092)에만 액세스할 수 있다. 이러한 잠금 그래프는 함께 작동하는 모듈식 Lock Node들과 그것의 액세스 제어 계층들의 유연성을 디스플레이할 수 있다. 별도의 데이터 파슬들은 이러한 단일 Nut 내에서 일부 또는 모두 상이한 방식으로 보호될 수 있다. 마스터 키들(10012 및 10020)이 동일할 수 있다면, 이는 양쪽 페이로드들에 대한 키 홀더 액세스를 허용할 수 있다.
도 101은 다중-Nut 구성의 단순화된 실시예를 도시한다; 사용자 키들(10110) 중 임의의 것은 그것들의 Stratum 액세스 제어들에 의존할 수 있는 일부 또는 모든 3 개의 페이로드들에 액세스할 수 있다. SSLOCK(10122)에 대한 키들(10120)은 그것의 Lock Node 연결로 인해 오직 페이로드(10194)에만 액세스할 수 있다. 잠금 그래프는 함께 그리고/또는 개별적으로 작동하는 모듈식 Lock Node들 그리고 그것의 액세스 제어 계층들의 유연성을 디스플레이할 수 있다. 별도의 데이터 파슬들은 이러한 단일 Nut 내에서 상이한 방식으로 보호될 수 있다. 이 개시의 유연한 성질은 잠금 구성들의 무한한 변형들을 허용할 수 있다.
도 102는 다수의 페이로드들을 갖는 직접 잠금 모델의 단순화된 실시예를 도시한다 : 이러한 잠금 그래프는 보통의 선형 토폴로지가 아닌 Nut의 평면 토폴로지를 도시할 수 있다. ORLOCK(10212)는 5 개의 상이한 Lock Node들에 그것을 연결하는데 필요한 다중 연결 키들을 구현하기 위한 여러 방법들이 존재할 수 있다는 점에서 흥미로운 노드일 수 있다. 일 실시예에서, ORLOCK 노드(10212)의 출력 섹션은 5 개의 출력 키들을 포함할 수 있다. 다른 실시예에서, 출력 연결 키 맵은 키 홀에 키 맵으로 임베디드될 수 있으며, 그 다음 출력 섹션으로 전파될 수 있다. 뿐만 아니라, Stratum 키들은 또한 어떤 키들이 다양한 노드들에 액세스할 수 있는지에 대한 역할을 수행할 수 있다.
도 103은 정렬된 메시지 통과 예에 대한 단순화된 실시예를 도시한다 : Nut들과 관계 기반 키들(Relationship Based Keys; RBK, 전방 참조)을 사용하는 공모 방지 설계(collusion resistant design)일 수 있다. Mr. Data(10310)는 Alice, Bob, Charlie 및 Danny와 각각 관계를 가질 수 있다. 일부 또는 모든 참가자들은 서로를 알 수 있다. 그의 관계는 각 사람과 관계 기반 키들을 가짐으로써 심볼화될 수 있다. Mr. Data는 각자에게 비밀 지침들의 세트를 보내길 원할 수 있지만, 참가자들 사이의 공모에 의해 미리 들여다 볼 가능성 없이 메시지들이 특정 순서로 읽혀지길 원할 수 있다. 이에 따라, MR. Data는 이러한 4 개의 Nut들을 각각 특정 콘텐츠들로 구성할 수 있다. Alice에게 발송된 Nut(10320)는 Alice와 Mr. Data 간의 RBK 세트를 사용하여 잠길 수 있기 때문에 Alice에 의해서만 열릴 수 있다. 10320의 내부에는 Alice를 위한 메시지와 Bob을 위한 키(KBob)가 존재할 수 있다. Alice는 그녀의 메시지를 읽을 수 있으며, 그리고 Bob에게 키(KBob)를 발송할 수 있다. Bob에게 발송된 Nut(10330)은 오직 동시에 두 개의 키들을 사용하여 열릴 수 있는 MATLOCK을 사용할 수 있다 : Bob과 Mr. Data 간의 Bob의 RBK 키, 그리고 Alice로부터의 키(KBob). 10330 내부에는, Bob을 위한 메시지와 Carlie를 위한 키(KCharlie)가 존재할 수 있다. 그는 메시지를 읽을 수 있으며, 그리고 Charlie에게 키(KCharlie)를 발송할 수 있다. Charlie에게 발송된 Nut(10340)은 오직 동시에 두 개의 키들을 사용하여 열릴 수 있는 MATLOCK을 사용할 수 있다 : Charlie와 Mr. Data 간의 Charlie의 RBK 키, 그리고 Bob으로부터의 키(KCharlie). 10340 내부에는 Charlie를 위한 메시지와 Danny를 위한 키(KDanny)가 존재할 수 있다. 그는 메시지를 읽을 수 있으며, 그리고 Danny에게 키(KDanny)를 발송할 수 있다. Danny에게 발송된 Nut(10350)은 오직 동시에 두 개의 키들을 사용하여 열릴 수 있는 MATLOCK을 사용할 수 있다 : Danny와 Mr. Data 간의 Danny의 RBK 키 그리고 Charilie로부터의 키(KDanny). 10350 내부에는 Danny를 위한 메시지가 존재할 수 있다. 그는 메시지를 읽을 수 있고, 그리고 메시지들을 정렬(ordering)하기 위한 Mr. Data의 계획이 효과가 있을 수 있다.
사이버보안 분야에서, '백도어(back door)' 기능은 주제를 둘러싼 다양한 대화에서 부정적인 의미를 나타낼 수 있다. 전통적으로, 백도어 메커니즘들은 해당 애플리케이션에 의해 처리되는 데이터에 대한 규제 없는 액세스를 허용할 수 있는 애플리케이션 레벨에서 구현되었을 수 있다. 이러한 유형의 애플리케이션 레벨은 어느 당사자(party)가 해당 백도어 엔트리에 대한 액세스 권한을 얻었는지 여부에 따라 해당 애플리케이션에 의해 처리되는 데이터의 보안을 심각하게 손상시키는 것으로 해석되었을 수 있다. 이러한 상황에서의 절충에 대한 인식은 자체 애플리케이션 메모리 내에서 암호화되지 않은 데이터를 대부분 처리하여, 백도어 사용자에게 평문 데이터에 대한 액세스를 잠재적으로 허용하는 애플리케이션의 보급으로 인해 잘 입증되었을 수 있다. NUTS에서 그리고 특히 Nut의 잠금 모델에서, 일부는 마스터 키의 사용을 Nut로의 백도어 유형으로 볼 수 있다. 그러나, 기술적으로는, Nut의 모든 잠금 모델들에서, 모든 문들(키홀들)이 앞문들이고 Nut에 대한 액세스를 얻기 위해 적절한 암호 키를 필요로 하기 때문에 상당히 다를 수 있다. NUTS API 또는 임의의 NUTS 관련 애플리케이션 실시예는 애플리케이션 수준에서 설계된 의도된 백도어를 가지지 않을 수 있다. Nut들에 이용 가능한 마스터 키 엔트리들을 가질 수 있는 합법적인 좋은 이유가 여러 가지 있을 수 있지만, 이러한 모든 엔트리들은 비밀 키에 의해서만 정의될 수 있으며, 임의의 Lock Node의 입력 섹션의 약식 검사에 의해 직접적으로 인지 가능할 수 있다(noticeable). 따라서, NUTS 관련 애플리케이션 내에서 백도어 유형 기능을 설치하려고 시도하는 애플리케이션은 먼저 Nuts의 타겟 세트에 대한 마스터 키에 대한 액세스 권한을 얻은 후에만 이를 수행할 수 있으며, 해당 마스터 키가 유효한 Nut들에만 적용 가능할 수 있다. 이는 Nut의 보안에 대한 데이터 중심 접근법의 유연성, 구획화, 보호 및/또는 탄력성을 설명할 수 있다.
NUTS의 액세스 제어의 일부 또는 모든 방법들에서, 캡슐화된 데이터 구조들 내에 암호화 키들을 숨기는 패턴이 포함될 수 있으며, 이러한 캡슐화된 데이터 구조들을 언폴딩하면 타겟 데이터 세트에 대한 액세스를 허용할 수 있는 다른 키들이 나타날 수 있다. 본 개시서에 설명된 실시예들에서, 이러한 키를 숨기는 방법들의 대부분은 데이터 캡슐화 및/또는 데이터 폴딩 방법들을 사용할 수 있다. 액세스 키들을 숨기는 방법은 구현자에 의해 만들어진 기본설정(preference)일 수 있으며, 또는 각각의 nut 내에서 매개변수화된 설정일 수 있다. 이러한 방법들은 데이터 폴딩, 데이터 캡슐화, 속성 기반 암호화, 기능적 암호화, 참조 모니터들로부터의 인증 토큰들, 또는 암호화 메커니즘을 해독하거나 잠금 해제하는 액세스 자료가 제공될 때 후속 액세스 키들의 선택적 암호화 공개(selective cryptographic revealing)를 제공할 수 있는 임의의 다른 방법을 포함할 수 있다. 본 개시서에서의 예시적 실시예들은 그것들의 간단하고 쉬운 메커니즘들 및 그들의 잘 알려진 특성들을 위해 선택될 수 있다. 다른 동등한 메커니즘은 실시예들의 특정 양상들을 간소화하거나 보다 효율적으로 할 수 있지만, 이들은 여전히 타겟 데이터세트에 대한 액세스 권한을 부여할 수 있는 액세스 속성들에 대한 액세스를 제어하는 것과 동일한 기능을 기본적으로 제공할 수 있으며, 그리고 디폴트로 임의의 참조 모니터들과 독립적일 수 있다. 임의의 동등한 액세스 속성 공개 방법은 nut의 내용물에 대한 동일한 수준의 보호를 제공하기 위해 지금까지 설명된 방법들을 대신할 수 있다.
이는 Nut 컨테이너와 그 내부 작동들에 관한 섹션을 결론지을 수 있다. 내부 메커니즘들은 직접적으로 구현되거나, SDFT 방법들의 사용에 의해 구현될 수 있음, 이는 그러한 실시예의 코딩 및 관리를 용이하게할 수 있다. Nut의 페이로드는 텍스트파일, 바이너리 애플리케이션, 이미지 파일, 원격 시스템에 대한 액세스 키, 실행 가능한 스크립트, 컴퓨터 연결을 안전하게 구축하기 위한 크리덴셜, 전체 데이터베이스, 운영체제, 다른 Nut들에 대한 링크, 스트리밍 데이터 및/또는 텍스트 메시지들과 같은(그러나 이에 국한되지는 않음) 저장 가능한 디지털 데이터일 수 있는, Nut가 궁극적으로 보호할 수 있는 것일 수 있다. Nut가 그것의 풍부한 구성 가능한 메타데이터를 통해 보유할 수 있는 내용을 설명할 수 있기 때문에, 일반적인 파일 유형들의 표준 목록은 그것의 보유 기능에 훨씬 미치지 못할 수 있다. Lock Node 아키텍처는 페이로드가 Nut들을 스팬하도록 허용할 수 있으며, 이로써 논리 컨테이너 크기를 무제한으로 만들 수 있다. 솔리드 스테이트 NUTS 호환 가능한 칩들 또는 회로를 사용할 수 있다면, 실제 기기를 Nut 자체로 바꿀 수 있으며, 이에 따라 기기는 키 홀더에 의해서만 액세스될 수 있다. 일련의 이러한 기기들은 적절한 인증을 통해서만 작동할 수 있는 전체 네트워크 및 인트라넷을 구성할 수 있다. 모듈형 Lock Node 설계의 유연한 특성은 Nut의 잠금 구성의 무산 변형들을 허용할 수 있다. 다음 섹션에서는, 평균 사용자의 손이 닿지 않는 것처럼 보일 수 잇는 기능들을 제공하기 위해 몇 가지 공통 서비스들 및 방법론들이 확장되고, 개선되고, 재-설계될 수 있는 방법을 보여주기 위해 안전한 저장소를 기반으로 Nut들을 사용할 수 있는 다양한 시스템들 및/또는 방법들이 도입될 수 있다.
모듈형 I/O
상당한 양의 프로그래머의 노력은 데이터가 프로그램에 제대로 반영되고 실행중인 메모리 공간에서 변환되고, 계산되고 그리고/또는 편집된 다음 영구적으로 올바르게 저장될 수 있는지 확인하는데 소요될 수 있다. 애플리케이션 개발의 이러한 모드의 난처한 부산물(nasty byproduct)은 파일 형식들과 그것들의 다양한 버전들의 궁극적인 구식화의 결과일 수 있다. 자신의 데이터를 소유하고, 보유하고 제어하는 것이 유용하고 훌룽한 목표일 수 있지만, 만약 그것을 제대로 읽지 못할 경우 어떤 용도로 사용합니까? 포맷을 읽고, 포맷을 작성하고, 판독된 데이터에 동작하고, 그리고/또는 판독된 데이터를 디스플레이하는 능력은 전형적인 프로그램의 기본 컴포넌트들 중 일부를 구성할 수 있다. 모듈형 I/O(MIO)는 이러한 논리 연산들을 그것에 액세스할 수 있는 사람에 의해 사용될 수 있는 모듈형 컴포넌트들의 저장소로 모듈화하는 시스템 및/또는 방법일 수 있다. MIO의 부산물은 사용자들이 파일 읽기 및 쓰기 루틴들의 이전 버전에 액세스할 수 있게 하여 오래된 데이터를 읽을 수 있도록 하는 파일 형식 변환 모듈들을 생성하는 기능일 수 있다. 상위 호환성(forward compatibility)의 개념도 제공될 수 있지만, 이 기능의 유용성은 애플리케이션 모듈들을 설계할 수 있는 프로그래머의 능숙도에 달려있을 수 있다. 일부 또는 모든 모듈들이 Nut들에 캡슐화될 수 있는 것은 MIO 시스템의 바람직한 실시예일 수 있으며, 이에 따라, 각 모듈의 인증, 보호 및/또는 액세스 제어는 디폴트로 존재할 수 있다. 도 104는 모듈형 I/O의 일반적인 컴포넌트들을 도시한다. 요소(10450)는 MIO 컴포넌트들을 저장하고 조직화할 수 있는 서버 프로세스일 수 있는 모듈형 I/O 보관소(Modular I/O Repository; MIOR)일 수 있다. MIOR는 그러한 모듈들을 위한 지능형 캐시의 역할을 할 수 있는 로컬 및/또는 원격 서버 유형 애플리케이션으로 구현될 수 있다. 다른 실시예들에서, MIOR는 로컬 기기에 로컬 캐시를 가질 수 있으므로, 공통으로 요청된 MIO 모듈들을 보다 용이하게 이용할 수 있다. 파일(10404)을 판독하고 그리고/또는 기록할 수 있는 통상적인 애플리케이션(10402)은 파일을 판독하고(10406) 기록(10408)하기 위해 개념적으로 그리고 프로그래밍 방식으로 모듈들로 분해될 수 있다. 파일(10404)은 애플리케이션(10402)에 특정할 수 있는 특정 포맷 "A"으로 포맷될 수 있다. 유사하게, 이 도면은 대응하는 데이터 파일들(10412 및 10420) 및 그들의 각각의 판독 및 기록 모듈들(10414, 10422, 10416, 10424)을 갖는 두 개의 다른 애플리케이션들(10410, 10418)을 도시하며, 판독 및 기록 모듈들(10414, 10422, 10416, 10424)은 "B" 및 "C"일 수 있는 특정 포맷들에 대해 MIOR(10450)에 저장될 수 있다. MIOR은 애플리케이션에 대해 상이한 작업들이나 절차들을 수행할 수 있는 다른 모듈들을 포함할 수 있다. 10426-10432로 표시된 것은 각각의 라벨들에 의해 지정된 바와 같이 하나의 파일 포맷으로부터 다른 파일 포맷으로의 변환들을 수행할 수 있는 파일 변환 모듈들일 수 있다 : 모듈 Convert_A_B(10426)는 파일 판독 모듈(10406)에 의해 파일 포맷 "A"로부터 애플리케이션의 메모리로 판독된 데이터를 취할 수 있으며, 그 다음 파일 판독 모듈 File_Read_B(10414)에 의해 생성될 수 있는 메모리 구조와 유사한 메모리 구조로 변환할 수 있다.
모듈형 I/O : 판독 및 기록
도 105는 MIOR(10500)을 사용하는 단순한 판독 및 기록 동작을 도시한다. 파일 포맷 "A"으로 저장될 수 있는 파일들을 처리할 수 있는 애플리케이션(10502)은 MIRO(10500)으로부터 파일 판독 모듈 File_Read_A(10506)을 요청함으로써 포맷 "A"로 포맷팅된 파일 F_A(10504)을 판독할 수 있다. 모듈(10506)이 발견되면, 모듈(10506)은 App_A(10502)로 전송(10510)되어, App_A(10502)가 파일 F_A(10504) 상의 파일 판독 모듈 File_Read_A(10506)를 설치하고 실행할 수 있다. 모듈 File_Read_A(10506)은 파일 F_A(10504)에서 파일 판독을 수행할 수 있으며, 파일 F_A(10504)의 내용을 나타낼 수 있는 내부 메모리 구조를 구성할 수 있다. 그 다음, 파일 F_A(10504)의 내용들을 나타낼 수 있는 이러한 메모리 구조는 호출 애플리케이션 App_A(10502)에 전달될 수 있다. 성공적으로 전달되면, App_A(10502)는 그것의 실행중인 메모리 공간에 존재할 수 있는 파일 F_A(10504)의 내용들로 그것의 기능들을 계속 수행할 수 있다. 다른 실시예들에서, 파일 판독 모듈(10506) 및 애플리케이션 모듈(10502) 모두가 동일한 메모리 공간을 공유할 수 있게 하는 설비(facility)가 존재할 수 있다면, 파일 판독 모듈 File_Read_A(10506)에 의해 파일 콘텐츠들이 판독될 수 있으면, 메모리 구조를 App_A(10502)에 전달할 필요가 없을 수 있다.
애플리케이션 App_A(10502)가 파일 F_A(10504)의 수정된 콘텐츠들을 파일 형태로 저장할 준비가 되면, MIOR과 컨택할 수 있으며 그리고 File_Write_A(10508)로 불리는 파일 형식 'A'에 대한 파일 기록 모듈을 요구할 수 있다. 모듈(10508)을 수신(10508)하면, App_A는 애플리케이션 메모리 구조들을 전송하기 위해 판독 프로세스와 동일한 방법을 사용하여 그것을 설치하고 실행할 수 있다. 기록 모듈(10508)은 수정된 파일 F_A(10520)를 생성할 수 있는 영구 저장소에 대한 기록 동작을 수행할 수 있다. 판독 및 기록 모듈들(10506 및 10508)을 위한 MIOR대한 요청들은 애플리케이션 개발자에 의해 적절하다고 여겨질 수 있는 임의의 순서로 행해질 수 있다. 일 실시예에서, 나중에 바람직하지 않은 장애들을 방지할 수 있는 일부 또는 모든 필요한 I/O 동작들이 애플리케이션에 의해 수행될 수 있는지 확인하기 위해, 애플리케이션은 진행 전에 일부 또는 모든 관련 I/O 모듈들을 먼저 요청할 수 있다. 다른 실시예에서, 요청 및 패치 절차들을 신속하게 처리하기 위해 유지될 수 있는 이전에 실행된 애플리케이션들에 의해 이전에 패치된 모듈들의 로컬 캐시된 MIOR이 존재할 수 있다.
당업계의 통상의 지식을 가진 자는 공유 메모리 세그먼트, 메모리 매핑된 파일들, 데이터베이스, 프로세스 간 메시지, 이진 메모리 덤프 파일들 및/또는 변환된 메모리 덤프들 같은(그러나 이에 국한되지는 않음) 2 이상의 논리 프로세스들 사이의 메모리 구조를 전달 및/또는 공유하는 많은 방법들이 존재할 수 있다는 것을 알 수 있다. MIO 시스템에서 애플리케이션 메모리 전송의 바람직한 방법은 프로세스들 사이에서 변환된 메모리 덤프들을 사용하는 것일 수 있다. JSON 판독 및 기록 기능들은 이진 데이터를 인식하도록 수정될 수 있으며, 그리고 base64 인코딩 또는 다른 2진-텍스트 인코딩 체계로 그것들을 자동으로 변환할 수 있다. 도 106은 전형적인 MIO 파일 판독 동작에 포함될 수 있는 데이터 변환들 및 전송들을 도시한다. MIO 판독 모듈 File_Read_A(10604)는 그것의 실행중인 메모리(10606)에 포맷 "A"의 F_A로 명명된 파일(10602)을 판독(10620)할 수 있다. 이에 따라, 파일(10602)의 관련 콘텐츠들은 애플리케이션 메모리 구조(10606)에서 표현(10630)될 수 있다. 애플리케이션 메모리는 JSON 호환 가능한 데이터 구조(10606)에 저장될 수 있으며, 그리고 JSON 기록 함수 호출을 사용하여 텍스트 형식(10610)으로 마샬링(marshalling)될 수 있다. 옵션으로, JSON 출력은 추가 보안을 위해 Nut 컨테이너(10608)에 임베디드될 수 있다. 이에 따라, 애플리케이션 메모리(10606)는 판독 모듈(10604) 외부에서(10608) 변환되고 저장될 수 있다. 그 다음 Nut(10680)은 App_A(10612)에 의해 열리고 메모리로 판독될 수 있고, 그리고 JSON 판독은 데이터 파슬(10610) 상에서 수행될 수 있다. 따라서, App_A의 실행 메모리(10614)에 데이터를 재구성한다. 데이터 전달 방법들(10622 및 10624)은 명령줄 인수(command line arguments), 프로세스 간 메시지들 및/또는 데이터 파일(들)을 포함할 수 있지만, 이에 한정되는 것은 아니다. 판독 애플리케이션 및/또는 데이터 처리 애플리케이션은 상이한 머신들, 동일한 머신, 개별 스레드 또는 개별 코어들 상의 개별 프로세스들일 수 있으며, 또는 애플리케이션들은 실행중인 코드를 즉시(on the fly) 수정할 수 있는 동적 기능이 있는 로컬 또는 원격 기계 상의 단일 논리 프로세스일 수 있다.
모듈형 I/O : 하위 호환성(backward compatibility)
애플리케이션들은 수명주기 동안 향상된 기능들을 갖는 버전 변경 사항을 발행함으로써 시간에 따라 점진적으로 변경될 수 있다. 이러한 버전 변경들 중 대부분은 사용자의 작업을 저장하는데 사용되는 저장 파일들의 형식 변경을 포함할 수 있다. 역사적으로, 이는 두 가지 문제로 이어질 수 있다 : 부담(encumbrance) 및 구식화(obsolescence). 부담(encumbrance)은 제품 라인의 수명 동안 모든 형식 변경에 대해 모든 버전에 하위 호환성을 추가함으로 인해 소프트웨어가 부풀어지는 경우일 수 있다. 이는 상당히 많은 포맷 버전 변경을 포함할 수 있다. 뿐만 아니라, 애플리케이션이 처리하기를 원할 수 있는 다른 제3자 또는 공개 포맷들이 있을 수 있는 경우, 소프트웨어가 더 부풀어오를 수 있다. 도 105는 애플리케이션이 활용할 수 있는 임의의 포맷의 임의의 버전에 대해, 모듈형 판독 및 기록 모듈들이 MIOR에서 이용 가능할 수 있다면, 과도한 팽창 없이 파일이 어떻게 판독되고 처리될 수 있는지를 도시한다. 뿐만 아니라, 도 105는 보다 새로운 판독 및 기록 모듈들이 어떻게 MIOR에 독립적으로 추가될 수 있는지를 나타내고, MIOR과 통신할 수 있는 모든 애플리케이션은 이제 프로그램 수정 없이 추가 형식 모듈들에 대한 액세스를 가질 수 있다. 이러한 새로운 모듈들은 동일한 애플리케이션 제품 라인에 대해 서로 다른 버전의 파일 형식을 읽을 수 있는 기능일 수 있으며, 또는 애플리케이션 개발자를 포함하여 모든 사람에 의해 작성된 제3자 파일 형식들을 판독하고 기록하기 위한 호환성 모듈들일 수 있다.
도 107은 애플리케이션 App_B(10702)의 버전이 더 최근일 수 있고 그리고 데이터 파일의 대응하는 더 새로운 포맷 버전 "B"를 사용할 수 있지만, 사용자가 파일 포맷(10704)의 이전 버전 "A"을 판독 및 기록하기를 원할 수 있는 경우의 하위 호환성 예를 도시한다. 이러한 경우를 위해 10708 및 10710과 같은 데이터 변환 모듈들은 MIOR(10700)에 생성되고 저장될 수 있다. 변환 모듈은 하나의 포맷으로 읽고 다른 포맷을 생성해야할 책임이 있을 수 있다 : 이 예에서, 변환 모듈(10708)은 "A" 포맷팅된 파일을 판독할 수 있고, 그것을 "B" 포맷팅된 파일로 변환할 수 있으며, 변환 모듈(10710)은 "B" 포맷팅된 파일을 판독할 수 있고, 그것을 "A" 포맷팅된 파일로 변환할 수 있다. 파일 F_A(10704)는 App_B(10702)에 제시될 수 있는데, App_B(10702)는 파일이 그것의 메타데이터로부터 호환되지 않는 포맷으로 있다고 결정할 수 있고, 그리고 "A"를 판독하는데 필요할 수 있고 "B" 파일들을 생성할 수 있는 판독 모듈 시퀀스에 대하여 MIOR(10700)에 요청을 진행할 수 있다. MIOR(10700)은 다음의 모듈들을 App_B(10702)에 발송함으로써 응답할 수 있다 : File_Read_A 10706, File_Write_A 10712, Convert_A_B 10708 및 Convert_B_A 10710. App_B(10702)는 파일 F_A(10704)에서 File_Read_A(10706)을 호출할 수 있고, 그 다음 File_Read_A(10706)은 Convert_A_B(10708)를 호출할 수 있으며, 그리고 "A" 형식의 그것의 메모리 구조를 모듈(10708)에 전송할 수 있으며, 그 다음, 모듈(10708)은 수신된 데이터를 "B" 형식으로 변환할 수 있으며, 그리고 그것을 App_B(10702)에 전송할 수 있다. App_B가 수정된 데이터를 다시 "A" 형식의 파일 F_A에 저장할 준비가 되면, App_B는 Convert_B_A(10710)을 호출할 수 있으며, 그리고 "B" 형식의 그것의 메모리 구조를 모듈(10710)에 전송할 수 있으며, 그 다음, Convert_B_A(10710)는 그것의 메모리 구조를 "A" 형식으로 변환할 수 있으며 그리고 File_Write_A(10712)를 호출할 수 있으며, 그리고 "A" 형식의 그것의 메모리 구조를 전달할 수 있으며, 그 다음, File_Write_A(10712)는 "A" 형식의 수정된 콘텐츠들로 파일 F_A(10714)을 덮어쓸 수 있으며, 그리고 파일 기록들을 파일 포맷 "A"으로 포맷팅할 수 있다. 보다 복잡한 예들은 적절한 이전 형식 버전으로 반복적인 변환 프로세스를 수행하기 위해 여러 변환 모듈들이 순차적으로 호출될 수 있거나 또는 개발자가 이러한 요청들을 간소화하기 위해 Convert_B_F 및 Convert_F_B와 같이 자주 사용되는 버전 변경 변환기 모듈들을 추가했을 수 있는 경우일 수 있다.
소프트웨어 팽창은 간단한 계산으로 설명될 수 있다 : 인기있는 애플리케이션이 10년마다 3가지 주요 버전 변경과 함께 5가지 주요 개정, 3가지 운영체제들에서 3가지 파일 형식 버전들을 거쳤을 수 있다고 가정하자. 또한 이러한 모든 변경사항들이 애플리케이션에 대해 상이한 버전의 I/O 루틴들을 필요로 한다고 가정하자. 이는 잠재적으로 애플리케이션의 최신 버전이 자체 내에 I/O 기능들의 최대 135 버전들을 탑재하도록 야기할 수 있다. 이것이 극단적인 경우일 수 있음을 감안할 때, 시간이 지남에 따라 애플리케이션에서 이전 버전과의 호환성(하위 호환성)을 유지하기 위해 생성될 수 있는 프로그램 코드의 확산을 이해할 수 있다. 이 특성은 소프트웨어의 부담(encumbrance) 특성이라고 지칭될 수 있다.
저장소에 지속적으로 업데이트되는 모듈들이 추가되는, 적절히 유지 관리되는 MIOR(10700)은 히스토리 I/O 형식 라이브러리로서 작동할 수 있으며, 사용자들이 언제든지 이전 버전의 데이터 파일들에 액세스할 수 있도록 허용할 수 있다 : 이는 소프트웨어 및 데이터 형식 구식화(obsolescence) 문제를 해결할 수 있다. 애플리케이션이 더 이상 생산, 판매 및/또는 유지 관리되지 않을 때, 새로운 운영체제 버전에서 실행되도록 허용할 수 있는 새로운 버전이 출시되지 않을 수 있기 때문에, 수명이 크게 단축될 수 있다. 비-호환성으로 인해 최신 컴퓨터에서 애플리케이션을 더 이상 실행할 수 없으면, 애플리케이션에 의해 포맷팅된 데이터 파일들에 액세스하기 어려울 수 있다. 영리한 사용자들과 개발자들은 이러한 문제들에 대한 다양한 해결책들을 찾았을 수 있지만, 많은 노력과 전문 지식이 필요할 수 있다. MIOR을 사용하면, 최소한 한 명의 개발자가 현재 존재하지 않는 애플리케이션과 관련된 모듈들을 유지 관리해야 할 수도 있으며, 그리고 새로운 버전의 모듈들을 주기적으로 추가하여 새로운 버전의 다양한 운영 체제들과 호환될 수 있게 해야 할 수도 있다. 이러한 유형의 일상적인 유지보수는 자동화된 유닛 테스트 도구들 그리고 자동-생성 OS 유형 및 버전의 적절한 모듈들을 적시에 사용하여 자동화될 수 있다. 업데이트된 모듈들은 MIOR에 삽입될 수 있으며, 그리고 MIOR에 액세스할 수 있는 모든 사용자는 개발자의 작업에서 이익을 얻을 수 있다; 특정 MIOR이 인터넷의 모든 사용자에 의해 액세스될 수 있다면, 인터넷의 일부 또는 모든 사용자들은 낮은 수준의 문제들과 그것들을 자동으로 해결하기 위해 호출될 수 있는 프로세스들에 대해 사용자가 알 필요 없이 이로부터 자동으로 이익을 얻을 수 있다. 소프트웨어의 하위 호환성과 상위 호환성의 문제들은 소프트웨어의 구식화(obsolescence) 특성이라고 할 수 있다.
모듈형 I/O : 상위 호환성(forward compatibility)
사용자는 때때로 수년 전에 애플리케이션을 구입, 설치 및/또는 사용한 상황을 경험할 수 있지만, 수년 동안 그 이후의 업그레이드 버전을 구입하지 않았을 수 있다. 그러나, 애플리케이션은 여전히 작동할 수 있지만, 자신보다 이전 버전의 애플리케이션과 호환될 수 있는 파일 형식들만 판독하고 기록할 수 있다. 가장 최신 버전의 애플리케이션은 과거의 어떤 시점에서 추가 기능들을 갖는 최신 파일 형식을 도입했을 수 있다. 이 상황은 사용자에게 다음과 같은 두 가지 문제를 일으킬 수 있다 : 1) 사용자의 애플리케이션 버전은 최신 형식 버전으로 포맷된 파일들을 읽을 수 없으며, 그리고 2) 이 애플리케이션으로부터 최신 형식을 판독할 수 있는 다른 프로그램들은 이전 형식의 데이터에 액세스하지 못할 수 있다. 첫 번째 문제에 대한 해결책은 상위 호환성 판독 작업(Forward Compatibility Read operation)이라고 할 수 있는데, 이에 의해, 사용자의 이전 버전의 애플리케이션은 데이터에 대해 점진적인 변환들을 수행하여 사용자가 이전 버전의 프로그램을 사용하여 새 버전으로 포맷된 파일들을 읽을 수 있게 할 수 있는 MIOR에서 모듈들의 세트를 직접 로딩할 수 있다. 두 번째 문제에 대한 해결책은 상위 호환성 기록 작업(Forward Compatibility Write operation)이라고 할 수 있는데, 이에 의해, 사용자의 이전 버전의 애플리케이션은 데이터에 대해 점진적인 변환들을 수행하여 사용자가 이전 버전의 프로그램을 사용하여 새 버전으로 포맷된 파일들을 기록할 수 있게 할 수 있는 MIOR에서 모듈들의 세트를 직접 로딩할 수 있다. 상위 호환성을 염두에 두고 작성된 프로그램들은 MIOR을 사용하여 최소한의 기능 손실로 또는 기능 손실 없이 이러한 유형의 전환을 보다 쉽고 원활하게 만들 수 있다. 더 최신 형식 버전들에서 제공되는 새로운 기능들은 덜 정교한 애플리케이션 구성들에 최적으로 매핑될 수 있으며, 또는 단지 원시 데이터로 대체될 수 있고 사용자가 나중에 수정할 수 있게 할 수 있다. 도 108은 이러한 2 개의 상이한 논리 연산들을 예를 통해 도시한다.
상위 호환성 판독 작업 : App_A(10802)는 버전 "A"로 포맷된 파일들과 호환될 수 있지만, 사용자는 더 새로운 파일 형식 "C"를 읽기를 원할 수 있다. 이러한 요청은 MIOR(10800)에 전달될 수 있으며, 그것은 이러한 회귀 변환들(regressive conversions)을 수행할 수 있는 모듈들의 시퀀스로 응답할 수 있다 : File_Read_C(10806), Convert_C_B(10808) 및 Convert_B_A(10810). 모듈 File_Read_C(10806)는 버전 "C"로 포맷팅될 수 있는 파일 F_C(10804)을 읽을 수 있다. 그 다음, 모듈(10806)은 회귀 변환 함수 Convert_C_B(10808)를 호출할 수 있으며, 그리고 자신의 메모리 구조를 그로 전송할 수 있다. 모듈 Convert_C_B(10808)는 메모리 내 데이터에 대해 변환을 수행할 수 있으며, 그리고 애플리케이션의 이전 파일 형식 버전인 "B" 형식과 호환 가능한 메모리 구조를 생성할 수 있다. 이어서, 모듈(10808)은 회귀 변환 함수 Convert_B_A(10810)를 호출할 수 있고, 그리고 자신의 메모리 구조를 그로 전송할 수 있다. 모듈 Convert_B_A(10810)는 메모리 내 데이터에 대해 변환을 수행할 수 있고 그리고 이전 애플리케이션 App_A와 호환 가능한 원하는 파일 형식 버전인 "A" 형식과 호환되는 메모리 구조를 생성할 수 있다. 모듈(10810)은 "A" 형식의 자신의 메모리 구조를 호출 애플리케이션 App_A(10802)에 전송할 수 있으며, App_A는 그것을 처리할 수 있다. 이에 따라, 최신 버전의 파일 형식은 애플리케이션에 대한 수정 없이 이전 버전의 애플리케이션에 의해 판독될 수 있다.
상위 호환성 기록 작업 : App_A(10840)는 버전 "A"로 포맷팅된 파일들과 호환될 수 있지만, 사용자는 원래의 능력을 초과할 수 있는 더 새로운 파일 형식 "C"를 작성하기를 원할 수 있다. 이러한 요청은 MIOR(10800)에 전달될 수 있으며, 그것은 이러한 점진적 변환들을 수행할 수 있는 모듈들의 시퀀스로 응답할 수 있다 : File_Write_C(10816), Convert_B_C(10814) 및 Convert_A_B(10812). App_A(10840)는 Convert_A_B(10812)를 호출할 수 있으며, 그리고 자신의 메모리 구조를 그로 전달할 수 있다. 모듈 Convert_A_B(10812)은 메모리 내의 데이터에 대한 변환을 수행할 수 있으며, 그리고 "B" 형식과 호환될 수 있는 메모리 구조를 생성할 수 있다. 그 다음, 모듈(10812)은 점진적 변환 함수 Convert_B_C(10814)를 호출할 수 있으며, 자신의 메모리 구조를 이로 전달할 수 있다. 모듈 Convert_B_C(10814)은 메모리 내 데이터에 대한 변환을 수행할 수 있으며, 그리고 "C" 형식과 호환될 수 있는 메모리 구조를 생성할 수 있다. 그 다음, 모듈(10814)은 파일 기록 함수 File_Write_C(10816)를 호출할 수 있으며, 자신의 메모리 구조를 그로 전달할 수 있다. 모듈 File_Write_C(10816)는 원하는 파일 형식 버전인 "C" 버전으로 포맷팅될 수 있는 file F_C(10818)를 기록할 수 있다. 이에 따라, 최신 버전의 파일 형식은 애플리케이션을 수정하지 않고 이전 버전의 애플리케이션에 의해 기록될 수 있다.
본 개시서는 도시된 2 개의 예들에 의해 제한되지 않는다. 변환 모듈들은 모든 운영 체제에서 애플리케이션에 대한 일부 또는 모든 버전들의 파일 형식들에 액세스하도록 생성될 수 있다. 변환 모듈들은 애플리케이션 제품 라인 내에서의 전환들로 제한되지 않을 수 있지만, 상이한 애플리케이션 제품 라인들에 걸쳐 변환들을 수행하기 위해 작성될 수 있다. 변환 모듈들은 파일을 데이터베이스로, 데이터베이스를 파일로, 파일을 데이터 스트림으로, 데이터 스트림을 파일로, 파일을 웹페이지로, 웹페이지를 파일로, 파일을 클라우드 스토리지로, 클라우드 스토리지를 파일로 그리고/또는 기타 등등과 같이(그러나 이에 국한되지는 않음) 데이터를 다른 형식들로 변환하는 것을 포함할 수 있다.
모듈형 I/O : 디스플레이
도 109는 동작중인 MIOR 디스플레이 모듈의 다이어그램을 도시한다. 애플리케이션 App_A(10902)가 파일 F_A(10904)로부터의 데이터를 자신의 메모리에 성공적으로 기록할 수 있으면, 사용자에게 파일 F_A(10904)의 내용을 디스플레이하기 위해 모듈 Display_A(10908)의 기능을 사용하는 것으로 진행할 수 있다. 디스플레이 모듈들에서, 모듈의 기능적 측면은 애플리케이션, 데이터 콘텐츠 및/또는 개발자의 설계에 따라 크게 달라질 수 있다. 일부 모듈들은 디스플레이 모듈이 애플리케이션 메모리 내 데이터에 직접 액세스할 수 있게 해주는 공유 메모리 방법들을 사용하도록 설계될 수 있으며, 다른 모듈들은 데이터를 디스플레이 모듈로 전송할 수 있으며, 이로써 디스플레이 모듈이 데이터를 표시할 수 있게 할 수 있다. 디스플레이 모듈의 다른 실시예들은 도시될 그리고 가능하다면 편집될 수 있는 데이터 유형에 대한 명령어들 및/또는 템플릿들을 포맷팅하는 스크린일 수 있다. 이러한 디스플레이 기능들의 모듈화는 호출 프로그램이 상대적으로 변경되지 않도록 하면서, 사용자 정의 디스플레이 모듈들이 다양한 하드웨어 및 OS 플랫폼들에 맞게 생성될 수 있게 할 수 있다.
NUTbook 섹션에서 이후에 논의되는 Catalog of Collections 아키텍처는 모듈식 디스플레이의 가벼운 양상을 활용할 수 있다. 상이한 컬렉션의 데이터세트를 처리, 디스플레이 및/또는 편집하기 위해 보다 큰 총체적(monolithic) 애플리케이션을 만드는 대신, NUTbook은 MIOR 아키텍처를 광범위하게 사용할 수 있다. MIOR 아키텍처는 검사중인 Nut의 페이로드 유형을 기반으로 단편적 사용자 정의를 허용할 수 있다.
모듈형 I/O :애플리케이션
도 110에서, MIOR(11000)은 11022와 같은 모듈형 애프리케이션 모듈들을 저장할 수 있다. NUTbrowser(11020)(전방 참조)는 대부분의 파일 및 디렉토리 브라우저들과 모양 및 행동이 유사한 애플리케이션일 수 있지만, Nut들을 인식할 수 있고 Nut의 광범위한 메타데이터를 살펴봄으로써 그것들에 영향을 줄 수 있다. Nut(11030)의 메타데이터(11002)는 그것이 보호 중이고 저장중일 수 있는 페이로드의 유형에 관한 정보일 수 있다. 사용자가 NUTbrowser(11020)로부터 Nut를 선택하고 그것을 열기 위해 더블클릭할 때, NUTbrowser는 Nut를 열 수 있고, 그리고 메타데이터를 읽어서, 파일을 여는데 필요할 수 있는 모듈들이 무엇인지 파악할 수 있다. 메타데이터는 애플리케이션 버전, 파일 형식 버전 및/또는 디스플레이 버전과 같은 데이터를 포함할 수 있지만 이에 국한되지는 않는다. 그 다음, NUTbrowser는 애플리케이션 App_A(11022), File_Read_A(11024) 및 Display_A(11026)를 찾기 위해 MIOR(11000)에 요청(11004)을 할 수 있다. MIOR(11000)는 일부 또는 모든 모듈들을 반환할 수 있고, 그리고 애플리케이션 App_A(11022)는 NUTbrowser(11020)에 의해 호출될 수 있다. App_A가 실행되면, Nut(11030)에 저장될 수 있는 Nut 페이로드 F_A(11028)의 컨텐츠들을 판독하기 위해 File_Read_A(11024)를 호출할 수 있다. 11024로부터 호출 모듈 App_A(11022)로 메모리 구조를 전송한 후, 디스플레이 모듈 Display_A(11026)를 호출하여 데이터 F_A(11028)를 사용자에게 보여줄 수 있다.
모듈형 I/O 애플리케이션 모듈은 그것들이 보유하고 수행할 수 있는 것들이 크게 다를 수 있다 : 일부 실시예들에서, 그것은 복잡한 논리 연산 모듈일 수 있으며; 다른 실시예에서, 그것은 전체 소프트웨어 설치 패키지를 저장할 수 있으며; 다른 실시예에서, 그것은 I/O, 디스플레이 및/또는 애플리케이션 기능들의 일부 또는 모든 양상들을 포함할 수 있으며; 다른 실시예에서, 그것은 사용자 환경의 윤회(reincarnation)를 원격 방식으로 촉진(kick start)시킬 수 있는 Genesis Nut을 포함하는 정보를 포함할 수 있다. 모듈형 I/O 애플리케이션 모듈들의 기능은 이러한 경우들에 국한되지 않는다.
판독, 기록, 디스플레이 및/또는 애플리케이션과 같은 모듈식 I/O 기능들은 MIOR 또는 컨테이너 레벨에서 액세스 제어 메커니즘들로 오버레이될 수 있으며, 이로써, 올바르게 인증된 사용자들만이 그것에 액세스할 수 있다. 이러한 액세스 제어 메커니즘들은 액세스 제어 정책, 소유권 요구사항 및/또는 보상 목적(renumerative purpose)을 위한 DRM 메커니즘들을 포함할 수 있지만 이에 국한되지는 않는다. 대부분의 액세스 제어들은 모듈들이 저장될 수 있는 Nut 컨테이너들의 특성들에서 나올 수 있다. 본 개시가 더 상세히 논의됨에 따라, 이러한 MIOR 요청들이 도출될 수 있는 메커니즘들에 관해 명확해질 수 있다. 데이터 파일 또는 그 내용이 안전한 Nut 컨테이너 내에 캡슐화될 수 있을 때, Nut의 내용에 대해 이용 가능한 다양한 레벨의 메타데이터가 존재할 수 있으며, 이러한 메타데이터는 그것을 생성한 애플리케이션 법전, 디스플레이 버전, 파일 형식 버전, 크기, 생성 시간, 최종 추정 시간, 작성자, 파일 유형 및/또는 요약과 같은(그러나 이에 국한되지는 않음) 데이터 형식의 세부사항을 지정할 수 있다. OS 버전, 애플리케이션 버전, 하드웨어 제조업체 및/또는 버전과 같은(그러나 이에 국한되지는 않음) 환경 속성들은 Nut를 여는 애플리케이션에 의해 제공될 수 있다. 환경, 데이터 콘텐츠 및/또는 요청된 작업에 관한 이러한 정보를 이용하여, MIOR는 적절한 모듈들을 검색할 수 있으며, 그리고 작업을 만족시키는 모듈들의 세트 또는 오류 메시지로 회신할 수 있다. 이러한 모듈형 I/O 모듈들은 동일한 기계 상에서, 상이한 기계들에서, 상이한 칩들 또는 코어들에서, 네트워크에서, 그리고 컴퓨팅 기기 상의 논리 프로세스(들)를 실행하는 다른 모드들에서 단일 또는 개별 프로세스들로서 실행할 수 있다. 이러한 모듈들을 통해, 구식화(obsolescence), 부담(encumbrance), 적응성, 호환성 및/또는 유연성의 문제들이 부분적으로 또는 전체적으로 해결될 수 있다.
NUT 히스토리
Nut 컨테이너는 페이로드의 히스토리를 저장하도록 구성될 수 있다. 히스토리의 형태는 주기적인 스냅샷, 점진적 델타(progressive deltas), 완전한 이벤트 시퀀스들, 또는 3 개의 또는 임의의 다른 아카이빙(archiving) 방법들의 임의의 조합을 포함할 수 있다. 히스토리의 형태는 저장되는 데이터의 유형과 애플리케이션 및/또는 데이터의 기본설정 및 디자인에 따라 다를 수 있다. NUTS 생태계는 이러한 데이터 히스토리 아카이빙 모드들을 지원하는 방법들 및 시스템들을 포함할 수 있다. 이러한 3 가지 아카이빙 방법들은 당업자에게 공지된 잘 확립된 방법들일 수 있다. Nut 히스토리의 물리적 위치는 Tale(도 81)이라는 Nut Part에 있을 수 있으며, 그것의 불투명도(opacity)는 Nut RAT에 의해 제어될 수 있다.
도 111은 문서의 2 개의 편집 세션들을 커버하는 세 가지 시점들에 걸친 그 히스토리 구조에 대한 점진적인 변화를 도시하는 단순화된 Nut 개략도를 도시한다. 시점 T1에서, Nut(11102)는 데이터 D1(11110)을 보유할 수 있고, 그것의 히스토리는 비어있을 수 있다(11112). 사용자는 시점 T2에서 데이터 D1(11110)를 편집(11126)할 수 있고, 그리고 새로운 버전 D2(11114)를 생성할 수 있다. 애플리케이션은 스냅샷 아카이빙 방법을 채용할 수 있고 그리고 Nut의 히스토리 섹션(11116)에 시간 T1에서의 데이터의 스냅샷(11118)으로서 오리지널 버전의 데이터 D1(11110)을 저장할 수 있다. 이어서, 사용자는 시각 T3에서 데이터 D2(11114)를 편집(11128)할 수 있고 그리고 새로운 버전 D3(11120)를 생성할 수 있다. 애플리케이션은 스냅샷 아카이빙 방법을 채용할 수 있고 그리고 Nut의 히스토리 섹션(11122)에 시각 T2에서의 데이터의 스냅샷(11124)으로서 이전 버전의 데이터 D2(11114)를 저장할 수 있다. 시각 T3에서, 히스토리 섹션(11133)은 이제 데이터 D3(11120)의 이전 버전들의 두 개의 별개의 스냅샷들(11118 및 11124)을 보유할 수 있다. Nut의 히스토리(11122)는 임의의 시간에 간단한 히스토리 추출 방법들을 사용하여 사용자에 의해 임의로 열람되고 추출될 수 있으며, 이에 따라 복귀(reversion)를 허용하거나 그로부터 완전히 새로운 문서들을 생성할 수 있다. 현재의 데이터에 대해 합당한 히스토리 성장(reasonable history growth)을 설정하기 위해 히스토리 섹션의 유형, 빈도 및/또는 수명을 제어할 수 있는 Nut 메타데이터 파라미터들이 존재할 수 있다. 일부 텍스트 문서들의 경우, 아카이빙의 델타 방법을 사용할 때 크기가 비교적 작을 수 있기 때문에 일부 또는 모든 변경사항들을 영원히 저장하는 것이 실용적일 수 있다. 이것은 Nut가 문서의 저장된 버전의 일부 또는 전부를 그 후 언제든지 생성할 수 있게 할 수 있다. 이진 문서들은 애플리케이션에 따라 스냅샷 또는 델타로 아카이빙될 수 있다. 특정 이벤트 구동형 애플리케이션들은 이벤트 시퀀스들의 전체 세트를 그것의 히스토리로서 아카이빙할 수 있다. Nut 히스토리는 Nut 자체에 아카이빙될 수 있으며 그리고 외부 프로그램들 및/또는 저장 시스템과 독립적일 수 있다는 것을 유의한다. NUTS 환경에 페이로드 유형에 사용할 수 있는 아카이브 방법이 존재할 수 있는 한, 모든 페이로드는 이 방식으로 역사적으로 아카이빙될 수 있다.
NUT LOG
Nut 컨테이너는 Nut의 이벤트 로그를 저장하도록 구성될 수 있다. 컴퓨터 프로세스가 Nut를 판독하고, 조작하고 그리고/또는 기록할 수 있음에 따라, Nut 자체 내에서 Nut에 대해 수행되는 논리적 작업들의 감사 추적(audit trail)을 생성하고 남길 수 있다. 감사 추적은 본질적으로 객체 관점에서 객체 단위로 존재할 수 있다. 따라서, Nut 히스토리와 Nut 로그 사이에서, 데이터 객체에 대한 개시(inception) 이후의 이벤트들의 크로니클(chronicle)은 나중의 추가 검토를 위해 다닝ㄹ 컨테이너에 저장될 수 있다. Nut 아카이브의 정확성, 내용 및/또는 세분성은 Nut들에서 작동하는 애플리케이션들의 개발자들에 의한 이러한 기능들의 규율적이고 체계적인 사용에 따라 달라질 수 있다. Nut Log의 물리적 위치는 Vita(도 81)라고 하는 Nut Part 내에 있을 수 있으며, 그것의 불투명도(opacity)는 Nut RAT에 의해 제어될 수 있다.
도 112는 Nut 상에 발생하는 2 개의 이벤트들을 커버하는 세 가지 시점들에 걸친 그 이벤트 로그 구조에 대한 점진적인 변화를 도시하는 단순화된 Nut 개략도를 도시한다. 이 예는 Nut 히스토리에 대한 도 111의 시나리오를 계속할 수 있다. 시각 T1에서, Nut(11102)는 데이터 D1(11110)를 보유할 수 있으며, 그것의 로그(11212)는 Nut(11102)가 시각 T1에서 생성되었다는 것을 나타낼 수 있는 이벤트 E1에 대한 하나의 로그 엔트리(11218)를 보유할 수 있다. 사용자는 시각 T2에서 데이터 D1을 편집(11226)하여 Nut(11104)에서 새로운 버전의 데이터 D2(11114)를 생성할 수 있다. 편집 애플리케이션은 T2에서 이벤트 로그 엔트리를 요소(11222)에 의해 표시될 수 있는 Nut log(11216)에 로깅(logging)할 수 있다. 그 후, 사용자는 시각 T3에서 데이터 D2(11114)를 편집(11228)할 수 있고 그리고 새로운 버전 D3(11120)를 생성할 수 있다. 편집 애플리케이션은 T3에서 이벤트 로그 엔트리를 요소(11224)에 의해 표시될 수 있는 Nut log(11230)에 로깅(logging)할 수 있다. 시각 T3에서, log 섹션(11230)은 이제 3 개의 별개의 이벤트 로그 엔트리들(11218, 11222 및 11224)을 보유할 수 있다. Nut의 로그(11230)는 임의의 시간에 간단한 로그 추출 방법들을 사용하여 사용자에 의해 임의로 열람되고 추출될 수 있으며, Nut에 대한 감사를 허용할 수 있다. Nut에 대한 합리적이고 적절한 로그 성장(log growth)을 설정하기 위해 log 섹션의 유형, 빈도 및/또는 수명을 제어하기 위해 Nut 메타데이터 파라미터들이 존재할 수 있다.
시스템 관리자들과 애플리케이션 개발자들은 둘 이상의 애플리케이션이 데이터 객체 수정에 관여할 때 시스템의 버그와 오류를 추적하는데 필요한 작업과 노력을 알 수 있다. 왜냐하면, 그들은 일부 또는 모든 기여하는 애플리케이션들의 이벤트 로그를 검토해야할 수 있으며(그들이 적어도 이러한 응용프로그램들에 액세스할 수 있는 경우에) 그리고 문제의 객체와 관련된 이벤트 로그 엔트리들을 필터링한 다음 객체에서 발생할 수 있는 순서로 이벤트들을 수동으로 재구성할 수 있기 때문이다. Nut Log를 사용하면, 이벤트 로그 수집, 필터링 및 재구성은 이미 객체 관점에서 객체 레벨에서 수행될 수 있다. 뿐만 아니라, Nut의 메타데이터는 객체 소유자에 의해 요구될 수 있는 이벤트 로그 메시지 세부사항의 세분화 수준을 작업 애플리케이션에 지정할 수 있다. 이러한 세분화는 다양한 연구 라인(lines of inquiries)을 추적하기 위해 간결한 디버그 수준에서 자세한 디버그 수준까지 다양할 수 있다. 민감한 일급비밀 페이로드는 액세스 히스토리에 대한 감사 추적을 수행하기 위해 가장 세부적인 레벨의 이벤트 로그 세부사항을 필요로할 수 있다. 요약하면, 이는 상기 객체에 의해 요구되는 세분화 수준별 객체마다의 임의의 애플리케이션에 의한 객체의 감사 가능한 과거를 제어하는 일관되고 맞춤설정된 방법일 수 있다. 일관된 용어는 사용 가능한 로깅 기능의 일관된 설계 및 작업들을 지칭할 수 있으며, 사용자 지정된 용어는 디자인이 수용할 수 있는 객체별 기본설정(per object preference)을 지칭할 수 있다.
관계 기반 키(Relationship Based Keys; RBK)
관계 기반 키들(RBK)이 어떻게 설정될 수 있는지에 대한 설명은 암호화 도구들을 수동으로 사용해본 사람이라면 누구나 익숙할 수 있다: Bob과 Alice는 개인적으로 의사소통하기를 원할 수 있으며, 이에 따라, 임의로 생성된 비대칭 암호 키들(공개 부분들만)을 서로 교환할 수 있으며, PGP 또는 이의 등가물과 같은 도구에서 이를 사용하여 암호화된 메시지들 및 문서들을 교환할 수 있다. Bob과 Alice에 의한 키 쌍들의 보호 및 관리는 전적으로 그들에게 맡길 수 있다. 이것은 각각의 관계가 적절히 수립되고 유지되고 활용되기 위해 신중하고 힘든 작업이 되는 경향이 있을 수 있으며, 그리고 아마 Alice와 Bob에게 암호문들, 그것들의 적절한 사용법 및/또는 키들의 보호에 대한 기본 지침서(primer)를 가질 것을 요구할 수 있다. 이러한 유형의 키 교환은 Bob 또는 Alice가 중앙 집중식 디렉토리 또는 신뢰웹(web of trust)을 통해 설정된 공개 키 인증서를 가지고 있지 않을 때 발생할 수 있다. 또한 이는 참가자 중 한명이 완전히 개인적인 통신 채널을 생성함으로써 추가된 프라이버시의 계층이 필요할 수 있다고 느끼는 경우 발생할 수도 있다.
RBK들이 Alice와 Bob 같은 사람들을 위한 기본 통신 방법이었다면 무슨 일이 발생할까? 그 결과가 무엇이었을까? 그리고 힘들지 않은 방법으로 그러한 일이 일어나기 위해 필요한 것은 무엇일까? RBK들의 설정, 유지관리 및/또는 사용의 체계적인 양상들은 자동화될 수 있다. 체계적으로 달성될 수 있는 방법의 세부사항들을 조사하기 전에 RBK들의 일관된 애플리케이션의 특성들 및 결과들 중 일부를 탐색하는 것이 건설적일 수 있다.
관계 기반 키들의 특성들
● 두 당사자들 간의 신뢰 수준은 동적 조정 가능 파라미터일 수 있다. 이는 임의의 두 당사자들 간의 실제 관계들에 대한 관찰일 수 있다 : 신뢰는 상대적일 수 있다. 신뢰는 이벤트들과 통신(communication)을 기반으로 시간이 지남에 따라 증가하거나 감소할 수 있다.
● 신뢰 수준의 일방적인 조정. 관계에 있어서 어느 당사자는 상대방에게 알리거나 알리지 않고 관계의 신뢰 수준을 일방적으로 변경할 수 있다.
● 관계 채널 건강(relationship channel health)은 메시지 문맥으로부터 결정될 수 있다. 시스템들과 키들은 누구에게든 때때로 손상될 수 있다. RBK들의 기본 사용은 한 당사자가 통신 내용을 검사할 수 있게 할 수 있고, 그리고 타인의 시스템들 또는 키들이 손상되었을 가능성을 판단할 수 있다. 가장 간단한 경우, RBK 암호화 없이 Bob으로부터 오는 메시지는 아마도 손상된(compromised) 사인일 수 있다.
● 관계의 본질은 시간이 지남에 따라 평가될 수 있다. 비정상적인 특성의 메시지가 RBK를 통해 전송되고 발송 당사자의 키가 손상되지 않았을 수 있다면, 발송 당사자는 관계의 본질을 변경했을 수 있다.
● 관계를 잃는 것은 영구적일 수 있으며, 관계의 일부 또는 전부의 히스토리는 상업적 및/또는 의미적 가치를 잃을 수 있다. 일방적으로, 각 당사자는 메시지를 차단하거나 RBK 세트를 지움으로써 관계를 끊을 수 있다. 관계 채널의 이러한 논리적 작동은 각 사용자에게 결정론적 일방적 메시지 차단 능력을 제시할 수 있다.
● 당사자들은 상호간에 준수할 수 있는 기본 규칙들을 엄격히 준수하거나 또는 시간이 지남에 따라 달라질 수 있는 관계 기본 규칙들을 잃을 위험이 있을 수 있다. 암묵적 기본 규칙들을 위반하면 디지털적으로 말해서 영구적인 방식으로 관계가 일방적으로 끊어질 수 있다.
● 이는 디지털 암호 형식에서 실제 관계에 더 가깝게 표현할 수 있게 할 수 있다. 가장 널리 사용되는 형식의 공개 키 암호화는 사람들이 관계를 형성하는 방식에 반할 수 있는 중앙 집중식 모델일 수 있다. RBK들은 분산될 수 있으며, 그리고 개인적인 방식으로 공개 키 암호화를 사용할 수 있다.
● 서브버전의 격리(Isolation of subversion). Bob의 환경에서 RBK들의 서브버전은 Bob과 그가 자신의 연락처들(즉, Alice)로 설정한 RBK 채널들에 대해 격리될 수 있다. Alice의 환경에 대한 피해는 Bob과의 채널 그리고 그들의 상호간의 역사적 소통(mutual historical communiqeus)과 분리될 수 있다. Alice에 대한 일부 또는 모든 다른 관계 채널들은 안전할 수 있으며, 그리고 Bob 환경을 침범한 해커들에 의해 침범되지 않을 수 있다.
개인 정보 관리자(Personal Information Manager 또는 PIM)는 컴퓨터 소프트웨어의 잘 알려진 애플리케이션 개념일 수 있다. 그것은 개인의 사용을 위한 생산성 및 조직 도구들을 제공할 수 있는 다양한 기능들의 혼합물(amalgam)로 널리 정의될 수 있다. PIM은 캘린더, 주소록, 연락처 관리, 패스워드 키퍼(password keeper), 메모, 이메일 관리자, 채팅 기능, 프로젝트 관리, 키 관리자, 계산기, 작업 목록 및/또는 활동 로거(activity logger)와 같은 도구들(그러나 이에 한정되지 않음)을 제공할 수 있다. PIM은 이러한 기능들 중 임의의 기능의 조합일 수 있으며, 또는 오직 단일 기능만을 제공할 수 있다. PIM은 로컬 방식으로 격리 방식으로 또는 PIM 웹 서버에서 단독으로 또는 그것의 임의의 조합에서 작동하도록 설계될 수 있다. 향후 논의에서, 주소록 또는 채팅 또는 이메일 관리자와 같은 PIM의 이러한 기능들에 대한 언급은 이러한 기능들 중 임의의 기능을 그것의 제공들의 일부로서 제공하는 PIM으로 이해될 수 있거나 또는 유일한 기능인 것으로 이해될 수 있다.
도 113은 Alice와 Bob 사이의 디지털 주소록 엔트리가 주소록의 일부 또는 모든 관계들에 대해 일관된 방식으로 RBK를 지원하도록 구성될 수 있는 방법을 도시한다. 자신의 PIM에 의해 제공되는 기능일 수 있는 Alice의 주소록(11310)은 2 개의 엔트리들을 가질 수 있다 : 자신에 대한 엔트리(11320) 및 Bob의 정보에 대한 엔트리(11330). Alice 자신의 엔트리(11320)에서, 그녀는 자신의 기본 연락처 데이터(11322) 및 일부 개인 데이터(11324)를 나열했을 수 있다. Alice의 주소록 엔트리(11320)는 저장될 수 있고 그리고 Alice의 시스템 상의 Nut 파일에 페이로드로서 안전하게 보호될 수 있다. Bob의 연락처 카드(11330)에서, Alice는 Bob의 이름과 이메일 주소 같은 Bob에 대한 일부 연락처 정보(11332)를 가질 수 있다. Bob의 주소록 엔트리(11330)는 저장될 수 있고 그리고 Alice의 시스템 상의 Nut 파일에 페이로드로서 안전하게 보호될 수 있다. 자신의 PIM에 의해 제공되는 기능일 수 있는 Bob의 주소록(11350)은 2 개의 엔트리들을 가질 수 있다 : 자신에 대한 엔트리(11360) 및 Alice의 정보에 대한 엔트리(11370). Bob 자신의 엔트리(11360)에서, 그는 자신의 기본 연락처 데이터(11352) 및 일부 개인 데이터(11354)를 나열했을 수 있다. Bob의 주소록 엔트리(11360)는 저장될 수 있고 그리고 Bob의 시스템 상의 Nut 파일에 페이로드로서 안전하게 보호될 수 있다. Alice의 연락처 카드(11370)에서, Bob은 Alice의 이름과 이메일 주소 같은 Alice에 대한 일부 연락처 정보(11372)를 가질 수 있다. Alice의 주소록 엔트리(11370)는 저장될 수 있고 그리고 Bob의 시스템 상의 Nut 파일에 페이로드로서 안전하게 보호될 수 있다. Alice와 Bob이 서로 RBK들을 설정하기로 결정할 때, 그들은 그들 사이에 사적인 양방향 통신 채널을 설정하기로 결정할 수 있다. Alice는 비대칭 키 쌍(11334 및 11336)을 생성하고, 이것들을 Bob의 주소 카드(11330) 아래에 저장하고, 키의 공개 부분(11334)을 Bob에게 전송(11344)함으로써 프로세스를 시작할 수 있다. 전송 프로세스(11344)는 패스프레이즈 보안 Nut, 종이에 쓰여진 메시지, Bob에게의 전화 통화, 세계에 알려진 Bob의 공개 키를 사용하는 메시지, 또는 당업자에게 잘 알려진 임의의 버전의 보안 키 교환 프로토콜들에 의해 달성될 수 있다. Bob이 내부에 키(11334)를 가진 이러한 메시지를 수신할 때, 그는 개인적으로 Alice에게 메시지들을 발송하기 위해 그것을 Alice의 주소 카드 엔트리(11370)에 키(11334)로서 저장할 수 있다. 그 다음, Bob은 비대칭 키 쌍(11374 및 11376)을 생성할 수 있으며, 그것들을 Alice의 주소 카드(11370) 아래에 저장하고, 그리고 메시지를 암호화하기 위해 Alice가 그에게 발송했던 공개 키(11334)를 사용하여 키의 공개 부분(11374)을 Alice에게 전송(11346)할 수 있다. Alice가 이 메시지를 수신할 때, Alice는 Bob의 메시지들에 대한 그녀의 개인키(11336)를 사용하여 Bob으로부터의 메시지를 해독할 수 있다. 그녀는 내부의 키(11374)를 추출할 수 있고, 개인적으로 Bob에게 메시지들을 발송하기 위해 그것을 Bob의 주소 카드 엔트리(11330)에 키(11374)로서 저장할 수 있다. Alice는 카드(11330)로부터의 키(11374)로 암호화된 밥에 대한 확인 메시지를 생성할 수 있고, 이를 임의의 작동하는 통신 매체를 통해 Bob에게 발송할 수 있다. Bob은 메시지를 수신한 다음, 카드(11370)로부터 키(11376)를 이용하여 그것을 해독할 수 있고, 그리고 자신의 RBK 세트가 Alice와 설정되고 활동하도록 마킹할 수 있다.
Alice와 Bob 사이의 이러한 RBK 설정 단계들은 자동화될 수 있으며 그리고 단일 동작 버튼 또는 명령으로 시작될 수 있다. 이는 NUTbook이 그것의 Contacts Collection을 관리하는 방법에 대한 운영 기반일 수 있으며, 이 문서의 뒷부분의 NUTbook 섹션에서 논의될 수 있다. 프로세스는 PIM들의 각 주소록들에 있는 일부 또는 모든 연락처 카드들에 대해 독립적으로 Bob 또는 Alice에 의해 반복될 수 있다. 결국, 각 개인은 그들의 관계들 각각에 대해 사적인 통신 채널들로 볼 수 있는 각자의 연락처에 대해 RBK 채널을 설정할 수 있다. Cathy가 Alice와 Bob의 공통 친구라면, Cathy의 Bob과의 RBK 관계는 Cathy의 Alice와의 RBK관계와 상이할 수 있으며, 그리고 RBK 구성은 그 현실을 반영할 수 있다.
이제 RBK와 그것의 체계적인 사용을 정의했으므로, Alice 또는 Bob에게 어떤 영향을 미칠 수 있을까? 두 엔티티들 간에 메시지들을 발송하기 위해 RBK를 일관되게 사용하면 통신 채널 상태를 모니터링할 수 있다. 실용적인 사용의 예는 SPAM 메일 감소일 수 있다. 상당한 양의 글로벌 인터넷 대역폭 및 데이터 저장소가 악의적인 그리고/또는 상업적인 종류의 스팸 메일에 의해 차지될 수 있다는 것을 예상할 수 있다. 우리는 많은 사람들이 그러한 대량의 스팸을 환영할 수는 없다고 가정하는 모험을 할 수 있다. 스팸 감소의 일반적인 방법들 중 일부는 콘텐츠 패턴 인식, 도메인 제외(domain exception), 주소 제외(address exception) 및/또는 법 집행에 의해 다작의 SPAM 서버들을 실제로 제거하는 것을 기반으로 하는 필터링 기술들을 사용하는 것일 수 있다. RBK 암호화가 기본 통신 방식일 수 있는 모드에서, SPAM은 보다 결정적인 방식으로 검출될 수 있다.
RBK와 같은 프로세스들을 자동화할 때의 주요 장애물들 중 하나는 사용자 친화적이고 사용자가 액세스할 수 있고 그리고/또는 사용자가 제어할 수 있는 개인 공개 키 인프라(Public Key Infrastructure; PKI) 애플리케이션들이 크게 부족했다는 것일 수 있다. Nut들의 사용과 함께 NUTbook은 PKI 갭을 채우는 것을 시도할 수 있다. 원활한 방식으로 그러한 정보를 저장하고, 조작하고 그리고 액세스하기 위한 융통성 있고 안전하며 그리고/또는 사용자가 제어할 수 있는 방법들을 제공할 수 있다.
도 114는 현재 RBK 통신 채널을 설정했을 수 있는 Alice와 Bob 사이의 SPAM을 줄이기 위한 흐름도를 도시하며, 이는 그들의 기본 통신 방법일 수 있으며, 그리고 그들은 잘 알려진 공개 이메일 주소를 사용하고 있을 수 있다. 이메일이 Alice와 Bob 사이의 RBK를 통해 암호화된다면, 그것은 Alice로부터 Bob에게로의 또는 Bob으로부터 Alice에게로의 유요한 이메일일 수 있다(11414). 각각이 다른 사람으로부터 RBK로 암호화되지 않은 이메일을 수신한다면, 이는 SPAM일 가능성이 가장 높으며, 그리고 필터링될 수 있으며, 그리고 스팸함에 저장될 수 있다(11412).
도 115는 이제 RABK 통신 채널을 설립한 Alice와 Bob 간의 SPAM을 줄이기 위한 흐름도를 도시하며, 이는 기본 통신 방법일 수 있으며, 그리고 그들은 공개되지 않은 개인 이메일 주소(익명의 이메일 주소)를 사용하고 있을 수 있다. 이메일이 Alice와 Bob 사이의 RBK를 통해 암호화된다면, 아마도 Alice로부터 Bob에게로의 또는 Bob으로부터 Alice에게로의 유요한 이메일일 수 있다(11514). 각각이 다른 사람으로부터 RBK로 암호화되지 않은 이메일을 수신한다면, 이는 SPAM일 가능성이 가장 높으며, 그리고 필터링될 수 있으며, 그리고 스팸함에 저장될 수 있다(11512). 이 예는 비공개 이메일 주소들의 세트가 오직 Alice와 Bob 사이에서만 사용되어 서로 RBK 암호화된 메시지들을 발송할 수 있으며, 그에 따라 RBK 채널 개념을 이메일 주소 레벨로 확장한다고 가정할 수 있다. 우리는 이러한 유형의 통신 채널 지향 이메일 주소들을 익명의 이메일 주소들로 정의할 수 있다.
익명의 이메일 주소를 통해 지속적으로 RBK를 사용할 수 있는 Alice와 Bob 사이의 통신 채널은 관계 그 자체의 상태를 결정하기 위해 분석될 수 있는 특정 특성들을 나타낼 수 있다. 도 115에서 기술된 바와 같이, 우리는 기본적으로 채널로부터의 암호화되지 않은 스펨 메시지들의 일부 또는 전부를 이미 제거했을 수도 있다. 이제 RBK로 암호화된 올바른 메시지들의 내용을 검사할 수 있다. 도 116의 표는 Alice-Bob 통신 채널 상태의 결정론적 문맥 기반 상태 매트릭스(Deterministic Context Based Status Matrix)를 나열한다. 그들의 관계에 어떤 일이 벌어질 수 있는지 알기 위해 Alice에 의한 콘텐츠에 대한 질적인 평가를 요구할 수 있다. 이것은 Alice에게 보내는 Bob의 메시지에 의해 입증될 수 있는 바와 같은 Bob의 행동에 기반할 수 있는 Alice에 의한 일방적인 동작 매트릭스를 도시한다.
도 116에 열거된 마지막 증상(symptom)은 Bob의 역할이 웹 판매자(web vendor)에 의해 대체될 수 있는 흥미로운 시나리오일 수 있다 : 즉, Alice는 판매자와 익명의 RBK 통신 채널을 설정했을 수 있다. 도 117의 표는 Alice-판매지 통신 채널의 건강(health)의 결정론적 문맥 기반 상태 매트릭스를 도시한다. 이제, Alice는 이 판매자가 익명의 이메일 주소들과 RBK 세트들의 채널 식별 가능한 양상들을 통해 스팸 발송자에게 자신의 정보를 판매했는지 추적할 수 있다. 이는 명확한 감사 추적으로 판매자의 마케팅 부서의 내부 작업에 투명성을 제공할 수 있다. 이러한 유형의 판매자 책임은 평균 사용자에 의한 이러한 체계적으로 세부적인 방법으로 전례가 없을 수 있다. 판매자가 Alice의 신뢰를 침해한 결과는 심각할 수 있다. 판매자가 Alice에게 연락할 수단을 영원히 잃어버릴 수 있기 때문이다. 결과적으로, 익명의 이메일 주소들 및/또는 RBK들의 적절하고 일관된 사용은 Alice가 매장에서 걸어 나와 절대 다시 돌아가지 않는 것에 디지털적으로 상응하는 것을 허용할 수 있다; 이는 판매자가 고객의 개인 정보를 남용하지 못하도록 막을 수 있다.
도 118은 판매자의 관점에서의 Alice-판매자 통신 채널의 건강의 결정성 문맥 기반 상태 매트릭스(Deterministic Context Based Status Matrix)를 도시한다. 채널 특성은 판매자에게, 판매자가 자신의 비즈니스를 보호하고 아마도 자신의 고객을 보호하기 위해 취할 수 있는 것과 동일한 유형의 일방적인 행동들을 제공할 수 있다. 판매자에 의한 이 방법론의 사용은 프라이버시 및 데이터 보안에 대한 그의 평판을 향상시킬 수도 있다. 또한, 이는 판매자가 고객 데이터의 도매의 무분별한 재판매에 관여하지 않을 수 있음을 암묵적으로 명시할 수 있다.
도 119는 RBK들의 사용이 어떻게 사용자의 시스템에서의 민감한 데이터의 손상을 격리하는데 도움이 될 수 있는지를 나타내는 그래픽 표현을 도시한다. Bob(11900)은 Alice(11910)와 Dave(11920)와의 RBK채널들을 가질 수 있다. Bob은 트로이 목마 웹 사이트를 클릭했을 수 있으며, 키 로거(key logger) 또는 이와 동등한 악의적 프로그램으로 감염되었을 수 있으며, 그 결과, 해커들은 그의 NUTbook과 같은 RBK들에 대한 보안 데이터 저장소에 침투했을 수 있다. 결과적으로, Bob의 연락처 일부 또는 전부를 갖고 있는 Bob의 RBK 세트들이 손상되었을 수 있다(11900). Bob은 그의 친구들의 일부 또는 전체와 연락을 취하여 그들에게 이러한 침해 사실을 알릴 수 있으며, 또는 그의 친구들 중 일부는 Bob과의 비공개 채널들을 사용하여 그들에게 발송되었을 수 있는 스팸 메시지들로부터 Bob 또는 자신의 시스템에 문제가 있음을 이미 추측했을 수 있다. Alice가 그녀의 RBK 세트들의 일부 또는 전부를 저장할 수 있는 Alice의 NUTbook(11910)을 보면, Alice는 Bob과의 RBK 세트(11912)를 손상된 것으로 마킹할 수 있으며, 그리고 Bob이 자신의 시스템에서 바이러스를 제거하기 위해 함께 행동할 때마다 새로운 RBK 세트를 생성할 수 있다. 이는 Alice의 손해 정도일 수 있으며, Alice가 설정했을 수 있는 다른 RBK 관계들에는 퍼지지 않는다. 이는 Alice가 그녀의 연락처와 함께 익명의 이메일 주소들을 일관되게 사용했다면 특히 사실일 수 있다. Alice는 해커들로부터 스팸을 수신할 수 있지만, SPAM은 Alice가 채널을 손상되거나 삭제된 것으로 마킹할 때 자동으로 무시될 수 있다. Bob이 준비가 되면, Alice는 새로운 RBK들의 세트와 새로운 익명의 이메일 채널을 생성할 수 있으며, 그리고 Bob과 Alice는 사적인 디지털 대화를 계속할 수 있다. Dave에 대한 프로세스는 그의 RBK 저장소(11920)에 대해 동일할 수 있다.
익명 관계(Anonymous Relationships)
지난 수십 년 동안 인터넷에서 발생하고 굳혀졌을 수 있는 디지털 관계 토폴로지들 및 관습들은 부자연스럽고 비현실적일 수 있다. 익명성은 강력한 관계 구축일 수 있으며, 그리고 개인 제품을 구입하기 위해 드럭 스토어(drug store)에 가는 것, 식사를 사기 위해 레스토랑에 가는 것, 타기 위해 택시 운전기사의 택시를 부르는 것, 그리고/또는 항의성 집회에 나타나기와 같은(그러나 이에 국한되지는 않음) 일상적인 상호 작용으로 우리가 일상적으로 즐길 수 있는 관계의 수준일 수 있다. 이러한 물리적 현실과는 달리, 인터넷상의 거의 모든 판매자는 Alice가 그들이 그녀로부터 얻을 수 있는 개인 정보의 일부 또는 전부를 포함하고 있는지 정확히 알고 싶어 할 수 있다. 많은 판매자들은 직통 전화번호를 공개하지 않음으로써 상대적으로 익명을 유지할 수 있으며, 그리고 이메일, 거래 시스템 및/또는 원격 콜센터의 원격 아웃소싱 고객 서비스 담당자를 통해 고객에게 서비스를 제공할 수 있다. 가장 널리 사용되는 익명성은 해커와 같이 숨기길 원할 수 있는 사람들에 의한 것일 수 있다. 현재, 인터넷상에 익명으로 남아있기를 원하는 사람들을 위해 많은 가짜 개인설정 웹사이트(fake persona generation website)가 있을 수 있지만, 그들은 익명성을 매우 힘들게 유지해야할 수도 있고, 양심적인 결정을 의도적으로 배제해야할 수도 있다. RBK들과 익명의 이메일 주소들을 사용하면 평균 사용자에 대한 인터넷상의 익명성이 불균형하게 될 수 있으며, 사회적 가면(fake personas) 및 일상적인 이중성(casual duplicity)에 의존하지 않고도 판매자들과의 그리고 서로 간의 더 의미있는 양방향 관계를 유지할 수 있다.
도 120은 사전-패키징된 개인 데이터 Nut들의 단순화된 개략도를 도시한다. Nut는 개인에 대한 상세한 개인 정보를 저장할 수 있다(12000). 그것은 상이한 목적들을 위해 이러한 개인 정보의 상이한 부분 집합들의 사전-패키징을 자동화할 수 있다. 12010은 단지 이름과 이메일 주소를 포함할 수 있는 단순한 개인 데이터 Nut일 수 있다. 익명의 개인 데이터 Nut(12020)는 오직 대안 이메일 주소만을 표시할 수 있다. 쇼핑 개인 데이터 Nut(12030)는 상품 구매를 위해 쇼핑 웹사이트에 일반적으로 필요한 정보 필드들을 포함할 수 있다. 마스터 정보(12000)로부터의 이러한 데이터 부분 집합들의 생성은 간단한 규칙들 및 필터들을 통해 수행될 수 있으며, 인터넷상의 등록 프로세스 동안 요구에 따라 생성될 수 있다. 판매자 또는 서비스가 데이터 Nut들을 수락할 수 있는지 여부에 관계없이, 정보는 다른 수단에 의해 필요할 때 올바른 필드에 삽입되기 위해 이용 가능하게 될 수 있다. 사용자가 익명 이메일 서비스를 이용하는 경우(전방 참조), 12020 같은 데이터 Nut는 설정된 특정 관계에 대해 동적으로 생성된 익명 이메일 주소들을 제공할 수 있다.
도 121은 Nut를 사용할 수 있는 자동화된 등록 프로세스에서의 이벤트들의 순서를 차트화한다. 인터넷상의 판매자는 개인 데이터 Nut들을 사용하고 수용할 수 있으며, RBK 채널들이 자동화된 방식으로 고객들과 설정될 수 있게 할 수 있다. 사용자는 판매자의 웹사이트를 방문할 수 있으며, 그리고 등록하기를 원할 수 있다(12100). 사용자는 자신의 NUTbook에 판매자의 웹사이트에 자동으로 등록하도록 지시함으로써 프로세스를 시작할 수 있고, 그리고 등록 사이트의 URL을 입력할 수 있다. NUTbook은 판매자가 사용자의 등록을 위해 필요할 수 있는 정보를 가져오기 위해 판매자에 질의할 수 있다(12102). NUTbook은 판매자가 요청 중일 수 있는 개인 정보의 하위 집합을 구성할 수 있고 그리고 미리보기를 표시할 수 있다. 그녀는 등록을 위해 요청된 정보가 받아들여질 수 있고 그리고 NUTbook이 관련 정보를 수집하고 프로세스를 계속할 수 있다고 결정할 수 있다(12104). NUTbook은 미리보기된 정보를 포함하는 사전-패키징된 Nut를 추출하고 생성할 수 있으며 그리고 이를 판매자의 사이트에 발송할 수 있다. 판매자는 등록 요청을 수락할 수 있으며, 사전-패키징된 Nut에 지정된 사용자의 이메일 주소로 질의를 발송할 수 있다. 사용자는 자신의 이메일에서 판매자의 질의를 수신할 수 있으며, 판매자의 질의는 사용자에게 특정 URL로 이동하여 보안문자(captcha) 또는 가능한 다른 검증 형태를 입력하도록 요청함으로써(12108), 사용자에게 사소한 등록에 관여하고 있을 수 있는 웹봇이 아닐 수 있다는 증거를 제공하도록 요청할 수 있다. 보안문자가 성공적으로 입력되면, 판매자는 그 요청이 사람으로부터 온 것이라고 납득할 수 있으며, 그리고 자동-생성된 로그인 크리덴셜, 로그인 키 및/또는 사용자와의 RBK 세트들을 설정하도록 진행할 수 있다. 사용자의 NUTbook은 판매자의 입력 카드, 관련 웹 정보, 로그인 크리덴셜, 로그인 키 및/또는 RBK 세트를 자동으로 생성할 수 있다(12112). 등록 프로세스는 개시, 개인 데이터 패키지 검토/편집 및/또는 인간 검증과 같이 프로세스의 몇 가지 지점에서 사용자와 상호작용하는 방식으로 수행될 수 있다. 로그인 이름, 패스워드 고르기, 개인 정보 입력 및/또는 판매자를 위한 패스워드 키퍼에 입력 항목을 작성하는 번거로움이 필요하지 않을 수 있으며, 자동화되었을 수 있다. NUTbook이 활성화되면, 완전히 인증된 모드로 원활하게 판매자에 즉시 액세스할 수 있다. 왜냐하면, NUTbook은 그렇게 하도록 주문될 때 사용자를 자동으로 로그인할 수 있기 때문이다. 이 프로세스는 사용자와 판매자 모두가 누릴 수 있는 이점에 대해 이 방법론을 채택한 모든 판매자와 함께 수행될 수 있다는 것에 유의한다. 사용자와 판매자에 대한 번거로움을 덜어줌으로써 데이터베이스를 위한 사용자로부터 보다 정확한 정보를 얻을 수 있으며, 아마도 그들 간의 더 많은 트랜잭션이 발생할 수 있다.
도 122는 Nuts 및 익명의 이메일 주소를 사용하는 자동화된 등록 프로세스에서의 이벤트들의 순서를 차트화한다. 인터넷상의 판매자는 Nuts들을 사용하고 수용할 수 있으며, 그리고 익명 이메일 주소를 사용하여 RBK 채널들이 자동화된 방식으로 고객들과 설정될 수 있게 할 수 있다. 사용자는 판매자의 웹사이트를 방문할 수 있으며, 그리고 등록하기를 원할 수 있다(12200). 사용자는 그녀의 NUTbook에 판매자의 웹사이트에 자동으로 등록하도록 지시함으로써 프로세스를 시작할 수 있고, 그리고 등록 사이트의 URL을 입력할 수 있다. NUTbook은 판매자가 사용자의 등록을 위해 필요할 수 있는 정보를 가져오기 위해 판매자에 질의할 수 있다(12202). 판매자가 익명 등록을 수락할 수 있으므로, NUTbook은 NUTmail 서비스에 접속할 수 있으며 그리고 그녀의 계정 하에서 익명의 이메일 주소 쌍을 요청할 수 있다. NUTbook은 새롭게 생성된 익명의 이메일 주소를 포함할 수 있는 판매자 등록에 발송될 데이터의 미리보기를 구성하고 표시할 수 있다. 그녀는 등록을 위해 요청된 정보가 받아들여질 수 있고 그리고 NUTbook이 프로세스를 계속할 수 있다고 결정할 수 있다(12204). NUTbook은 미리보기된 정보를 포함하는 사전-패키징된 Nut를 생성할 수 있으며 그리고 이를 판매자의 사이트에 발송할 수 있다. 판매자는 등록 요청을 수락할 수 있으며, 그리고 사전-패키징된 Nut에 지정된 사용자의 새로운 익명의 이메일 주소로 질의를 발송할 수 있다(12206). 사용자는 그녀의 익명의 이메일 주소에서 판매자의 질의를 수신할 수 있으며, 판매자의 질의는 그녀에게 특정 URL로 이동하여 보안문자(captcha) 또는 가능한 다른 검증 형태를 입력하도록 요청함으로써(12208), 그녀에게 사소한 등록에 관여하고 있을 수 있는 웹봇이 아닐 수 있다는 증거를 제공하도록 요청할 수 있다. 보안문자가 성공적으로 입력되면, 판매자는 그 요청이 사람으로부터 온 것이라고 납득할 수 있으며, 그리고 자동-생성된 로그인 크리덴셜, 로그인 키 및/또는 사용자와의 RBK 세트들을 설정하도록 진행할 수 있다. 사용자의 NUTbook은 판매자의 입력 카드, 관련 웹 정보, 로그인 크리덴셜, 로그인 키, 익명의 이메일 주소 및/또는 RBK 세트를 자동으로 생성할 수 있다(12212). 등록 프로세스는 개시, 개인 데이터 패키지 검토/편집 및/또는 인간 검증과 같이 프로세스의 몇 가지 지점에서 사용자와 상호작용하는 방식으로 수행될 수 있다. 로그인 이름, 패스워드 고르기, 개인 정보 입력, 이메일 주소 생성 및/또는 판매자를 위한 패스워드 키퍼에 입력 항목을 작성하는 번거로움이 필요하지 않을 수 있으며, 자동화되었을 수 있다. 그녀의 NUTbook이 활성화되면, 그녀는 완전히 인증된 모드로 판매자에 원활하게 액세스할 수 있다. 왜냐하면, NUTbook은 그렇게 하도록 주문될 때 그녀를 자동으로 로그인할 수 있기 때문이다. 이 프로세스는 개인 사용자 정보를 필요로 하지 않을 수 있으며, 생성되었을 수 있는 이메일 주소들은 이 관계를 위해 특별히 생성되었으며, 이는 사용자와 판매자 간의 관련 이메일들만이 익명의 이메일 주소들에 도달할 수 있음을 암시한다. 다양한 NUT 기반 서비스들이 이후에 논의될 수 있기 때문에, 이것들의 일부 또는 전부는 익명 등록(anonymous registration)을 제공한다.
RBK들 및 익명의 이메일 주소들을 사용하여 설정될 수 있는 통신 채널들은 RBK를 통해 모든 것을 암호화하는 디폴트 모드로 인해 결정적인 방식으로 스팸을 최소화할 수 있다. 뿐만 아니라, 관계에 대한 상호 존중(mutual respect)과 암묵적인 경계가 있을 수 있도록, 관여될 수 있는 당사자들에게 채널의 양방향 제어를 제공할 수 있다. 이러한 암묵적 관계 경계들로부터의 일탈(deviation)은 관계가 변하는 이벤트들을 정확히 지적(pinpointing)할 수 있으며, 그리고 질의들에서부터 관계를 완전히 결정적인 방식으로 절단(severing)하는 것에 이르기까지의 일방정인 반응을 일으킬 수 있다. 올바른 익명의 이메일 주소 쌍을 검색하는 것을 넘어서 Bob 또는 Alice의 데이터를 파괴하려고 시도하는 제3자의 경우, 제3자는 암호화된 메시지들과 문서들 또한 크래킹(craking)해야 할 수 있다.
자동화된 등록들을 수락하고 처리할 수 있는 웹 사이트는 나이 필터링(age filtering) 같은(그러나 이에 국한되지는 않음) 추가 서비스들을 추가할 수 있다. 부모들은 성별, 나이 및/또는 일반적인 위치와 같은(그러나 이에 국한되지는 않음) 몇몇 일반적인 신원확인 특징들을 나타내기 위해 자녀의 기기의 NUT서버에 사전 패키징된 Nut를 보관할 수 있다. 이러한 사전-패키징된 Nut는 Nuts를 수락할 수 있는 아동 친화적(child friendly) 또는 부모 사전-승인 웹사이트에 자녀를 등록하기 위해 자동으로 사용될 수 있다. 판매자는 이러한 정보, 그리고 그들이 제공할 수 있는 주류 사이트, 담배 사이트, 영화 미리보기 사이트, 성인용 콘텐츠 사이트 및/또는 총기 사이트 등과 같은(그러나 이에 국한되지는 않음) 서비스들에 기초하여 액세스 시도를 수락하거나 거부할 수 있다. 또한, 인터넷 활동 로깅 Nut는 자녀의 활동 및 디지털 행방(digital whereabouts)을 모니터링하기 위해 자녀의 기기의 NUT서버에 구성될 수 있다. 또한, 인터넷 사용에 대한 제한은 가정에서 일부 또는 모든 기기들에 걸쳐 그러한 Nuts를 사용함으로써 부모에 의해 관리될 수 있으므로, 기기 전환은 자녀의 하루 누적 인터넷 사용에 중요하지 않을 수 있다. 특정 웹 사이트에 대한 차단 또는 승인은 NUTS 기반 WiFi 라우터의 특정 구성 설정과 함께(전방 참조) 그리고/또는 기기 자체에서 이러한 자녀 식별 Nuts를 사용함으로써 달성될 수 있습니다.
NUTS 코어 애플리케이션(NUTS Core Applications)
도 123의 표는 NUTS 코어 애플리케이션 세트를 포함할 수 있는 애플리케이션들을 나열한다. 이러한 애플리케이션들은 NUTS 기술들을 활용할 수 있는 대부분의 시스템에 상주할 수 있으며, 그리고 도 124에서의 연산 컴퓨팅 기기의 단순화된 다이어그램에 도시된 바와 같이 Nut 파일들을 처리할 수 있다. 앞에서 언급했듯이, 이러한 애플리케이션들의 일부 또는 전부는 이미 본 개시서에서 이전에 논의된 자료에 의해 참조되었을 수 있다. 이러한 애플리케이션들은 Lock Node, Lock Graph, Nut Part, Nut History, Nut Log, MIO, MIOR, Nut ID들, RBK들, Gradient Opacity 및/또는 익명 관계들과 같은(그러나 이에 국한되지 않음) NUTS의 일부 또는 모든 핵심 기본 기능들 및 능력들에 대한 종속성으로 인해 본 개시서의 앞부분에서 상세하게 설명될 수 없다. 이러한 핵심 애플리케이션들 중 일부 또는 전부는 일반 파일로 구현될 수 있지만 이에 국한되지 않는 저장소의 기본 단위로 Nut를 사용하는 것을 선호할 수 있다. 이는 이러한 시스템들이 접촉, 저장 및/또는 조작하는 데이터의 일부 또는 전체에는 기본적으로 높은 수준의 보안 및 액세스 제어가 따를 수 있다는 것을 암시할 수 있다. 독자가 이러한 핵심 애플리케이션들을 보다 완벽하게 이해할 수 있도록 도울 수 있는, Lock Node 설계에 사용될 수 있는 디자인 철학은 반복, 통합, 독립성 및/또는 식별 가능성의 개념일 수 있다.
NUTS 코어 애플리케이션 : NUT서버
NUT서버는 도 125에서 사용자 기기의 단순화된 다이어그램으로 개략적으로 묘사될 수 있다. NUTS 호환 환경을 구성하고 유지하기 위해 NUT서버가 백그라운드에서 수행할 수 있는 몇 가지 주요 기능들이 있을 수 있다. NUT서버(12510)는 사용자 컴퓨팅 기기(12500)의 애플리케이션 공간에서 동작할 수 있다. 기기는 Nut 파일들(12522)이 유지될 수 있는 일부 저장소(12520)를 가질 수 있다. NUT서버는 NUTbook(12512), NUTbrowser(12514) 및/또는 기기 OS를 포함하는 다른 애플리케이션(12516)을 포함하는 다양한 애플리케이션들로 개방된 API들 통신 채널들을 제공할 책임이 있을 수 있다. NUT서버는 또한 NUT서버들을 실행중일 수 있고 그리고 가능하다면 NUTcloud(12540)과 대화하고 있을 수 있는 사용자에 속할 수 있는 다른 기기들(12530)과의 외부 연결들을 유지할 책임이 있을 수 있다. NUT 서버는 사용자 기기(12500)의 파일 시스템을 대신할 수 없을 수 있지만, 로컬 운영 체제 및 파일 시스템을 통해 작동하여 임의의 Nut 파일들에 액세스하여 처리할 수 있다.
도 126은 NUT서버의 주요 내부 부분들 및 그것의 기능들에 대한 단순화된 도면을 도시한다. 사용자 기기는 하드웨어 및 소프트웨어를 관리하는 운영체제(12600)를 가질 수 있다. 기기는 네트워크 인터페이스(12602) 및 OS(12600)를 통해 실행되는 관련 드라이버들에 의해 서비스되는 외부 통신을 가질 수 있다. 기기는 또한 첨부될 수 있고 OS(12600)에 의해 관리될 수 있는 파일 시스템(12604)을 가질 수 있다. 파일 시스템에 저장되는 것은 MIOR(12610)에 대한 데이터 저장소들일 수 있으며, 사용자 데이터는 Nuts(12606 및 12608)에 포함될 수 있다. 또한, OS(12600)는 다이어그램에 묘사된 것들(NUT서버(12620), NUTbook(12642), NUTbrowser(12644), MIOR 서버(12646) 및 다른 애플리케이션들(12648))을 포함하여 많은 애플리케이션들이 실행될 수 있는 애플리케이션 환경으로서 동작할 수 있다. NUT서버(12640)는 다른 기기에서 실행될 수 있지만, 애플리케이션 인터페이스(12636)는 그러한 통신들 또한 처리할 수 있다.
NUT서버(12620) 내에서, NUT서버로 인증을 수행할 수 있고 키 캐시를 유지할 수 있는 모듈(12622)이 존재할 수 있다. NUT서버가 시작할 때, Nut서버는 어떤 Nut의 임의의 보안 계층들에 들어갈 수 있는 권한이 없을 수 있다. 사용자 및/또는 하드웨어는 NUT서버 인증 모듈(12622)이 특정 키 세트에 대한 액세스를 얻을 수 있게 할 수 있는데 필요한 인증을 제공할 수 있다. 이는 키 세트들을 보유하는 패스프레이즈로 보호된 Nut를 가지고 사용자에게 패스프레이즈를 제공하도록 요청하는 것, Nut를 열고 그것의 페이로드 내의 키 세트들을 보호된/비보호된 메모리에 캐싱하는 것만큼 간단할 수 있으며; 또는 이는 많은 컴퓨팅 기기들에서 발견되는 바와 같은 보안 하드웨어 제공 키일 수 있으며; 또는 이는 사용자가 제공할 수 있는 USB 키와 같은(그러나 이에 국한되지는 않음) 하드웨어 토큰일 수 있다. 키 세트는 최소한 NUT서버 인증 키 및/또는 로컬 기기에 설치될 수 있는 각각의 NUTS 코어 애플리케이션에 대한 키를 포함할 수 있다. 구조적 목적 및 효율성을 위해 NUT서버에 의해 유지될 수 있는 캐시(12624)가 존재할 수 있다. 캐시의 일부는 Nut ID들의 인덱스(12626)일 수 있다. 이 인덱스는 사용자가 로컬 및 원격으로 추적하기를 원할 수 있는 일부 또는 모든 Nut ID들을 포함할 수 있다. 인덱스에서 Nut ID를 조회하는 것은 Nut ID를 찾을 수 있는 위치를 나타낼 수 있다. 캐시(12624)의 다른 부분은 자주 액세스되는 Nut들을 위한 메모리에 Nut 캐시(12628)를 유지하는 것으로 귀속될 수 있다.
NUT서버는 두 개 이상의 Nut들의 내용들을 동일한 Nut ID들로 동기화(12630)할 책임이 있을 수 있다. NUT서버가 적절하게 인증될 수 있고 사용자에 의해 소유되는 일부 또는 모든 Nut들에 액세스하기 위한 충분한 키들을 가질 수 있다면, 다양한 Nut들을 열어 그것의 내용들을 검사하고 관리할 수 있다. 각각의 Nut는 마지막 업데이트 또는 수정의 버전 번호와 타임스탬프를 보유할 수 있다. Nut에서 업데이트가 발생하고 그리고 NUT서버가 이를 통지받을 수 있거나 또는 NUT서버가 이를 알 수 있다면, 업데이트를 기록할 수 있으며, 그리고 이러한 업데이트된 Nut의 사본이 로컬로 또는 원격으로 존재할 수 있는 일부 또는 모든 위치들을 보기 위해 인덱스(12626)를 조회할 수 있다. 그런 다음, 영향을 받는 Nut들에 대한 변경사항들을 전파하고 동기화(12630)하는 것을 체계적으로 시작할 수 있다. 이러한 프로세스는 Nut ID, 버전 번호, 내부 digns, 히스토리 및/또는 로그와 같은(그러나, 이에 국한되지 않음) 각각의 Nut 내에 임베디드된 메타데이터로 인해 다소 간단할 수 있다. 최신 버전은 다양한 수정 기준이 충족될 수 있다면 단순히 기존 버전을 덮어쓸 수 있다. NUT서버가 동기화 업데이트가 발생할지 여부에 관해서 Nut의 Gradient Opacity에 의해 허용되는 것처럼, 볼 수 있는 메타데이터에 의존할 수 있기 때문에, Nut서버가 Nut를 부분적으로 또는 전체적으로 자세히 들여다봐야할(peering into) 필요는 없을 수 있다. 충분한 평문 메타데이터는 일부 Nut들이 해당 Nut들에 대한 키가 없는 NUT서버들에 의해 동기화되도록 허용할 수 있다. 버전 포킹(forking) 또는 브랜칭(branching)의 가능성이 있을 수 있는 경우, 사용자는 어떤 버전을 최신 버전으로 만들 건인지 결정하는데 관여될 수 있다. 복제 기능(12630)은 피어 NUT서버들이 이러한 유형들의 변경들을 사용자 제어 기기들을 통해 자동으로 전파할 수 있게 할 수 있다. 12630에 의해 제공되는 기능들은 그녀가 그녀의 기기들에 여러 개의 NUT서버들을 설치하고 연결할 수 있을 때 사용자를 위한 개인 NUTcloud를 구성할 수 있다. 그녀는 자동화된 방식으로 그녀의 기기들 중 임의의 기기에서 동기화된 그리고/또는 복제된 Nut들을 즐길 수 있다. 좀 더 복잡한 버전 문제가 발생하거나 Nut의 특정 이력 버전이 요청될 수 있는 경우, 개정 관리 모듈(12632)이 이러한 요청들을 처리할 수 있다. 이는 Nut에 의해 이용되는 특정 버전 델타 방법들을 이용할 수 있으며, 그리고 Nut의 원하는 버전을 생성하기 위해 더 세분화된 버전 제어를 수행할 수 있다. 이러한 Nut 특정 버전 데이터 방법들 및 Nut들의 내용 판독/기록 방법들은 로컬 MIOR에 존재할 수도 있고 존재하지 않을 수도 있으므로, 필요할 때 그러한 기능들을 공급하는 MIOR 인터페이스(12634)가 존재할 수 있다.
액세스 Nut는 웹사이트 로그인들, 데이터베이스 로그인들, 회사 시스템들, 개인 기기들, 소프트웨어 시스템들, 다른 Nut들, NUT서버들, 이메일 시스템들, 채팅 시스템들 및/또는 비밀 패스 키 및/또는 로그인 ID를 필요로하는 임의의 디지털 시스템 같은(그러나 이에 국한되지는 않음) 다른 시스템들 또는 컨테이너들에 대한 인증 크리덴셜을 포함할 수 있는 보안 Nut로서 정의될 수 있다. NUT서버는 다른 애플리케이션들이 그것의 기능들에 액세스할 수 있도록 애플리케이션 인터페이스(12636)를 제공할 수 있다. NUT서버는 그것의 애플리케이션 유형 및 설치 세부사항들로 식별될 수 있으며, 추가적으로 Nut ID도 할당받을 수 있다. 사용자 기기에 대한 NUTS 구성 파일은 파일 시스템(12604) 내의 구성 디렉토리 또는 영역을 가리킬 수 있으며, 여기서 원격 및/또는 로컬 NUT서버들과 같이(그러나 이에 국한되지 않음) 그것이 알 필요가 있을 수 있는 각각의 애플리케이션에 대한 정보를 보유하는 액세스 Nut를 찾을 수 있다. 예를 들어, 로컬 NUT서버(12620) 구성 디렉토리는 Nut ID, 유형 및/또는 원격 NUT서버(12640)에 대한 액세스 키들을 포함하는 액세스 Nut를 보유할 수 있다. 이러한 액세스 Nut를 성공적으로 열면, 원격 NUT서버(12640)에 접속하여 이를 인증하는 것을 시도하기 위해 충분한 정보를 로컬 NUT 서버(12620)에 줄 수 있으며, 이로써, 신뢰할 수 있는 통신 채널을 열 수 있고 서로의 Nut들을 발송할 수 있다. 유사한 방식으로, NUT서버가 상호작용할 수 있는 다양한 애플리케이션에 대한 구성 Nut들이 존재할 수 있다. 액세스 Nut들은 Nut이기 때문에, 피어 NUT서버들 간의 동기화, 복제 및/또는 전파가 유지될 수 있다.
NUT서버가 어떻게 작동할 수 있는지에 대한 이 설명에서, Nut 내부 구조물들의 반복적인 설계 접근법은 그것들을 구성하고 인증하는 것과 관련된 애플리케이션 및 데이터가 저장되고 액세스될 수 있는 방법까지 확장될 수 있다. 민감한 데이터는 가능한 한 많이 Nut에 저장될 수 있다. NUT서버들에 의해 제공되는 기능들과 Nut의 내장 기능들 및 특징들을 고려할 때, 이러한 단순한 스테이트먼트(statement)의 결과는 훨씬 광범위해진다. 인증되지 않은 NUT서버는 그것이 내부 액세스를 가질 수 없는 Nut들을 복제, 전파 및/또는 동기화할 수 있는 충분한 기능을 제공할 수 있다. 이는 Nut의 Gradient Opacity 때문일 수 있다 : 비공개 메타데이터를 구성하는 많은 Nut 부분들은 평문으로 저장될 수 있으며, 그리고 많은 일반적인 유지보수 작업들이 NUT서버에 의해 Nut에서 수행될 수 있도록 충분한 정보를 제공할 수 있다. Nut에 내장될 수 있는 보안 기능들로 인해, WAN 또는 인트라넷을 통해 애플리케이션들 간에 Nut들을 전송하기 위한 통신 채널들의 보안은 덜 중요할 수 있다.
액세스 Nut들을 사용하는 이 방법은 소프트웨어 설계, 프로그래밍 및/또는 사용과 관련된 수많은 문제들을 해결할 수 있다. 예를 들어, 소프트웨어 개발자들은 테스트 데이터베이스나 테스트 애플리케이션 서버와 같은 테스트 시스템에 신속하게 들어가기 위해 코드를 개발할 때 로그인과 패스워드를 그들의 코드에 하드코딩(hardcoding)할 때 어려움을 겪을 수 있다. 테스트 및 개발의 QA 및 생산 모드들로의 전환은 최소한의 테스트를 거친 단계 바로 이전에 코드에 추가 인증 절차들을 추가하여 수행될 수 있다. 액세스 Nut들을 사용하면, 가장 초기 단계에서 이를 개발 프로그램에 통합하는 것이 가능할 수 있으며, 프로세스가 변경될 필요가 없을 수 있으며, 액세스 Nut만이 변경될 수 있다. 관리자는 개발자, QA 엔지니어 및/또는 프로덕션 사용자(production user)에 대한 적절한 액세스 Nut들을 할당하고 생성할 수 있다. 이러한 액세스 Nut들은 그것들의 각각의 NUTbook 컬렉션들에 원활하게 통합할 수 있으며, 그리고 개별적으로 사인하지 않고도 그것들의 애플리케이션 리소스들에 연결할 수 있게 할 수 있다. 관리자는 실제로 액세스 Nut들의 소유권을 유지할 수 있고, 그것을 필요에 따라 변경할 수 있으며, NUT 서버들은 결국 그것을 복제 및/또는 동기화할 수 있으므로, 최종 사용자들은 결코 신경쓰지 않아도 될 수 있으며, 이에 의해, 프로젝트 관리자는 사용자들과 애플리케이션들 간의 관계들을 원격으로 그리고 안전하게 관리할 수 있다. 액세스 Nut들을 효과적으로 사용하면 임의의 사용자가 SSO(single sign on)을 위해 그들의 시스템들을 구성할 수 있다 : 그것들의 로컬 NUT서버 및 나머지 모두에 대한 SSO는 필요한 경우 자동으로 인증될 수 있다. 계층적 패스워드들(전방 참조)은 액세스 및 정보의 특정 하위 집합들에 대한 보안을 강화할 수 있다.
도 127은 Nut 캐시(12628)가 NoSQL 데이터베이스(12728)의 기능들로 대체될 수 있는 NUT서버의 대안 실시예이다. NoSQL 데이터베이스들은 일부가 객체 지향 데이터베이스들의 하위집합으로 간주될 수 있으며, 그 중 대다수는 테이블이 아닌 구조들일 수 있는 Nut-like 컨테이너들을 처리하는데 매우 효율적일 수 있다. CouchBase 같은 일부 NoSQL 데이터베이스들은 NUT서버가 직무의 일부를 수행하기 위해 사용할 수 있는 내장된 복제 및 다른 기능들을 제공할 수 있다.
NUTS 코어 애플리케이션 : MIOR 서버
모듈형 I/O 보관소 또는 MIOR는 도 128에 도시된 바와 같이 서버 기반 서비스일 수 있다. 이는 MIO 시스템들 및 방법들의 일반적인 실시예일 수 있다. 컴퓨팅 기기(12810)는 자신의 로컬 MIOR 캐시(12812)를 갖는 기기 상에서 실행되는 로컬 MIOR 서버를 가질 수 있다. 요청이 로컬 MIOR 서버에 의해 만족되지 않을 수 있다면, 잘 알려진 인터넷 기반 MIOR 서버들(12820) 또는 그들의 미러(12830)에 도달할 수 있다. 이들 각각의 캐시들(12822 및 12832)은 요청 내 적절한 MIO 모듈에 대해 검색될 수 있다. 발견되면, 그것을 사용자의 컴퓨팅 기기 상의 원래의 MIOR 서버로 다시 보낼 수 있다. 요청된 모듈들이 인터넷상의 첫 번째 MIOR 서버(12820)에서 발견되지 않을 수 있다면, MIOR 서버(12820)는 인터넷상의 다른 MIOR 서버들에 도달하여 이를 찾을 수 있다. 원래 요청은 그것이 모두 만들 수 있는 캐스케이딩 요청들의 수에 대한 시간제한 또는 캐스케이드 제한을 가질 수 있다. 일부 실시예들에서, 요청들은 적절한 경우 차단 모드가 아닌 비동기식으로 수행될 수 있다.
이 프로세스의 더 정밀한 검사는 도 129에 도시될 수 있다. 애플리케이션(12918)은 Nut 파일(12908)을 그 메모리로 판독할 필요가 있을 수 있는 로컬 기기(12910) 상에서 실행될 수 있다. Nut(12908)는 MIOR 서버(12914)로부터 그것의 페이로드에 대한 판독 및 기록 모듈들의 특정 세트를 필요로할 수 있음을 나타낼 수 있다. 애플리케이션은 그것의 로컬 MIOR 서버(12914)에 접속하여 이 Nut에 대한 판독 및 기록 모듈들을 요청할 수 있다. MIOR 서버(12914)는 자신의 로컬 MIOR 캐시(12916)가 그러한 모듈들을 가질 수 있는지를 보기 위해 로컬 MIOR 캐시(12916)를 살펴볼 수 있다. 발견되면, 상기 모듈들 그리고 로컬 시스템 또는 네트워크상의 모듈들의 위치에 대한 정보로써 애플리케이션에 응답할 수 있다. 발견되지 않으면, MIOR 서버(12914)는 12920과 같은 더 큰 MIO 보관소에 요청하기 위해 WAN(12900) 또는 MIOR 서버들의 다른 네트워크를 통해 도달할 수 있다. MIOR 서버(12920)는 다양한 모듈들에 대해 인터넷으로부터의 요청들을 서비스하도록 최적화된 전용 서버일 수 있다. MIOR 서버(12922)가 MIOR 서버(12914)로부터 요청을 수신하면, MIOR 서버(12922)는 그러한 모듈들에 대해 그것의 로컬 MIOR 캐시(12924)를 검사할 수 있다. 발견되면, MIOR 서버(12922)는 요청에 있는 모듈들로써 MIOR 서버(12914)에 응답할 수 있다. 발견되지 않으면, MIOR 서버(12922)는 이러한 모듈들을 찾기 위해 그것의 피어 그룹의 다른 MIOR 서버들에 연락할 수 있다. 그 동안, MIOR 서버(12914)에게 "찾지 못했지만 검색을 계속함"이란 메시지를 발송할 수 있다. 원격 요청이 요청된 모듈들로 되돌아오면, 로컬 MIOR 서버(12914)는 자신의 로컬 MIOR 캐시(12916)에 저장하기 전에 그것을 인증할 수 있다. 언제나 그렇듯이, 애플리케이션(12918)이 모듈을 인스턴스화하고 사용하기 위한 시간이 되면, 그것 또한 통상의 NUTS 내부 메커니즘들을 사용하여 콘텐츠들을 인증할 수 있다.
도 130은 MIOR 서버로부터 MIO 모듈들을 가져오기 위한 흐름도를 도시한다.
MIOR 서버 및 로컬 MIOR 서버 간의 인증은 원하는 경우 세션 키들 또는 익명 계정들을 통해 설정될 수 있다. 높은 수준의 서비스에는 맞춤 keyed Nut들을 이용하여 전용 모듈들에 액세스하는 것이 포함될 수 있다. 일례로, 회사는 맞춤 개발 소프트웨어(custom developed software)를 사용하는 직원들을 위해 MIOR 네트워크의 광범위한 배포를 사용하고자할 수 있지만, 직원들은 그들이 회사로부터의 액세스 Nut에 있을 수 있는 액세스 키를 가진다면 맞춤 모듈을 열고 인증할 수만 있으며, 이에 따라 독점 정보는 상대적으로 개방된 서비스 플랫폼에서 일관되게 보호될 수 있다.
MIOR 캐시의 내부 구성의 일반적인 실시예가 도 131에 도시되어 있다. 캐시(13100)는 교차 참조되고 인덱싱될 수 있는 다양한 모듈들에 대한 참조를 포함할 수 있는 인덱스 세트(13110)를 가질 수 있다. MIOR의 구조는 이 실시예에 한정되지 않고, 이러한 조직 구성들 및 기법들 중 일부 또는 전부를 포함할 수 있다. 모든 모듈이 Nut에 저장될 수 있기 때문에, 마스터 Nut ID 인덱스(13112)는 모듈들의 Nut ID들의 일부 또는 전부 그리고 그것들의 캐시 내의 위치들을 포함할 수 있다. 파일 I/O 모듈 인덱스(13114)는 설명 및 Nut ID에 의해 해당 유형의 모듈들의 일부 또는 모두를 나열할 수 있다. 파일 애플리케이션 모듈 인덱스(13118)는 설명 및 Nut ID에 의해 해당 유형의 모듈들의 일부 또는 모두를 나열할 수 있다. 파일 디스플레이 모듈 인덱스(13120)는 설명 및 Nut ID에 의해 해당 유형의 모듈들의 일부 또는 모두를 나열할 수 있다. 컬렉션 모듈 인덱스(13116)는 설명 및 Nut ID에 의해 컬렉션에 속하는 모듈들의 일부 또는 모두를 나열할 수 있다. 캐시의 효율적인 검색을 위해 작성된 다른 인덱스들이 있을 수 있다. 컬렉션 그룹들(전방 참조)(13130-13150)은 관련 모듈들이 함께 그룹화될 수 있는 방법을 시각적으로 보여주기 위해 다이어그램에 도시되어 있다. 컬렉션 그룹화 방법은 NUTbook의 작업들에서 중요한 역할을 할 수 있다.
NUTS 코어 애플리케이션 : NUTbrowser/NUTshell
도 132는 NUTbrowser 애플리케이션의 다이어그램을 도시한다. NUTbrowser는 본질적으로 NUTshell CLI(command line interface) 애플리케이션의 기능들 위에서 실행될 수 있는 그래픽 사용자 인터페이스(GUI)일 수 있다. 일반적으로 알려진 셸 프로그램(shell program)은 특히 배시 셸(bash shell), csh, cmd.exe, DOS 셸일 수 있다. 일반적으로 알려진 파일 관리자 프로그램은 Windows Explorer, Apple's Finder 및 기타 프로그램일 수 있다. 이 두 프로그램들의 사용자 직면 행동은 일반적으로 알려진 것들과 매우 유사할 수 있다. 그러나, 차이점은 NUTbrowser와 NUTshell이 Nut들을 인식할 수 있으며, 모든 Nut 파일에 저장될 수 있는 풍부한 메타데이터를 활용하기 위해 그것들을 더 완벽하게 처리할 수 있다는 것일 수 있다. 모든 Nut 파일은 두 가지 방법으로 식별될 수 있다 : 피상적인 '*.nut' 파일 이름 확장자 그리고/또는 Nut로서의 내용들에 대한 더 깊은 탐구(deeper probing). 대부분의 파일 시스템들은 파일 이름 확장 방법을 수용할 수 있다. Nut 판독 시도는 *.nut 파일이 실제로 Nut일 수 있는지 확인하려 시도할 때 또는 신뢰할 수 없는 출처로부터 로컬 시스템에 새로운 파일을 가져올 때 사용될 수 있다.
Mac OS, Windows 및/또는 Linux와 같은 가장 널리 사용되는 운영체제는 파일 이름 확장자들, 매직 넘버(magic number)들, UTI(uniform type identifier)들, 파일 시스템 특성들 및/또는 다른 것들을 포함하는 파일 유형을 식별하는데 몇 가지 방법들을 사용할 수 있다. 파일 이름 확장자들은 가장 피상적인 방법일 수 있다. 파일 이름이 변경될 수 있을 때, 그것의 콘텐츠 유형과 인식 사이의 연결이 끊어질 수 있기 때문이다. 매직 넘버들 및 UTI는 콤팩트하지만, 파일의 머리 부분에 임베디드된 메타데이터의 제한된 형태일 수 있으며, 그리고 콘텐츠의 형식이 무엇인지 교차 참조하기 위해 파일 형식의 인덱스에 액세스해야할 수 있다. 파일 유형들의 이러한 인덱스는 OS, 파일 시스템, 또는 다른 외부 시스템에 존재할 수 있다. 파일 시스템 속성들은 파일 시스템의 인덱스 메커니즘 내에서 그것의 인스턴스에 첨부될 수 있는 파일 객체의 속성들로 표현될 수 있다. 이 정보는 그것을 기록하고 인식할 수 있는 파일 시스템/운영 체제 조합의 도메인 내에서만 유효할 수 있다. Nut 메타데이터는 페이로드의 유형을 지정할 뿐만 아니라, 그것을 어떻게 읽고, 기록하고, 디스플레이하고 그리고/또는 실행할 수 있는지도 지정할 수 있다. 컨텐츠들을 성공적으로 처리하는데 필요할 수 있는 다양한 모듈들의 일부 또는 모든 버전들을 지정할 수 있다. 실제로, Windows 레지스트리 엔트리들 및/또는 Mac OS 속성 목록들과 같은(그러나 이에 국한되지 않음) 컨텐츠들을 처리하기 위해 임의의 그리고 모든 외부 참조 테이블에 대한 일부 또는 모든 종속성들을 제거할 수 있다. 이를 통해, Nut는 그것의 내용에 액세스하는데 필요할 수 있는 필수 컴포넌트들을 자체-기술하고 자체-규정할 수 있으며, MIOR 서버는 액세스시 부족할 수 있는 임의의 컴포넌트들을 자동 설치할 수 있다.
NUTbrowser/NUTshell은 임의의 선택된 Nut의 메타데이터를 읽을 수 있으며, 그리고 MIOR 서버(13250)에 액세스(13232)함으로써 Nut의 컨텐츠들에 대한 적절한 애플리케이션을 열고, 디스플레이하고, 그리고/또는 실행하려고 시도하기 위해 다양한 다른 NUT 코어 애플리케이션들과 통신할 수 있다. 사용자가 NUT서버(13240)에 적절하게 인증되었다면, NUTbrowser/NUTshell은 조금 더 Nut들을 적절하게 열기 위해 필요한 액세스 Nut들의 일부 또는 전부에 대한 액세스(13234)를 가질 수 있다. 실제로, NUTbrowser/NUTshell은 Nut를 적절하게 처리할 수 있는 임의의 애플리케이션과 동일하게 작동할 수 있다.
로컬 시스템에서 사용될 수 있는 영구 저장소에 따라, NUTbrowser/NUTshell은 Nut ID들이 상이할 수 있는 한 동일한 파일 이름의 여러 Nut들이 동일한 저장소 영역에 존재하도록 허용할 수 있다. 데이터베이스 및 객체 파일 시스템들과 같은 일부 저장 시스템들은 파일 이름에 민감하지 않을 수 있다. 대부분의 클라우드 기반 저장소 시스템의 경우, Nut ID 식별 방법은 기존 경로이름 방법보다 더 기본적으로 적합할 수 있다.
NUTS 코어 애플리케이션 : NUTbook
도 133에 NUTbook의 개략도가 도시되어 있다. 지금까지, 일반적인 Nut 처리 애플리케이션은 유사한 컴포넌트들과 친숙해 보일 수 있다; 그것은 도 134에서 더 일반화된 Nut 프로세싱 프레임워크의 기초를 형성할 수 있고, 도 132에서 NUTbrowser 애플리케잇녀이 동작할 수 있는 방법과 유사하게 기능할 수 있다. NUTbook은 NUT 서버(13334) 및 MIOR 서버(13332)에 대한 필수 인터페이스들을 가질 수 있다. 그것은 13322 및 13324로 표시된 바와 같이 그것들에 의해 제공되는 기능들을 제공하기 위해 필요에 따라 MIOR 모듈들(13326-13330)을 처리할 수 있다. NUTbook의 메인 기능은 카드 카탈로그라고 불리는 정리된 세트의 캐시들(13336)을 유지하는 것일 수 있다. NUTbook은 도 135에 도시된 바와 같은 데이터 컬렉션들로 구성되는 전자 카드 카탈로그일 수 있다. NUTbook은 일반적인 개인 정보 관리자에서 볼 수 있는 기능들 중 일부를 제공할 수 있다. NUTbook은 왜 카드 카탈로그인가? 다음은 왜 그것이 타당할 수 있는지에 대한 여러 가지 이유들의 목록이다 :
● 사용자는 임의의 데이터 세트를 수집, 처리 및 구성하는 쉬운 방법이 없을 수 있다.
● 일반적으로, 그것은 스프레드시트, 텍스트 파일 또는 간단한 데이터베이스에서 비공식적으로 수행될 수 있다.
● 보관소가 컬렉션에 항목 당 데이터파일을 포함할 수 있는 안전한 방식으로 상이한 데이터 컬렉션들을 수집, 조직화 그리고/또는 카탈로그화하기 위해 쉽게 액세스할 수 있는 일반 유틸리티가 없을 수 있다.
● PKI 인증서들, 연락처 카드들, RBK 세트들, 웹 로그인, 야구 통계, VPN 로그인 및 크리덴셜, 자동차 히스토리, DVD 컬렉션, 스탬프 컬렉션, 도서 컬렉션, 아동 의료 기록 등... 이들은 데이터 또는 카드들의 상이한 컬렉션으로 간주될 수 있다.
● Nut는 사용하고 운반하기 쉬울 수 있는 안전한 방법으로 각 유형의 항목을 안전하게 저장할 수 있다.
● 따라서, NUTS를 원활하게 작동시키는데 필요할 수 있는 암호화 키들의 일부 또는 전부를 Nut들에 저장할 수 있다.
● NUTbook 애플리케이션 내에서 Nut ID들 및 임의의 옵션의 검색 인덱스 메타데이터를 인덱싱함으로써 이러한 카드 컬렉션들에 액세스할 수 있다.
● NUT 서버들은 특정 중요한 카드 유형들을 알고 있을 수 있으며, 그리고 많은 작업들에서 그들의 처리의 우선 순위를 지정할 수 있다.
● 다중-NUT 서버 환경에 존재할 수 있는 Nut는 기본적으로 복제, 동기화, 로깅, 전체 히스토리, 암호화 및/또는 액세스 제어를 항목 당 하나의 파일로 패키지화하여 쉽게 전송할 수 있다.
NUTbook은 이용 가능한 하드웨어에 따라 보호되거나 보호되지 않은 메모리의 형태일 수 있는 키 캐시(13520)를 포함할 수 있다. 키 캐시는 만료되기 전에 사용될 수 있는 횟수, 만료 시간 및/또는 만료 이벤트들 등과 같은(그러나 이에 국한되지는 않음) 첨부된 적절한 속성들을 사용하여 자주 사용되는 액세스 키들을 저장할 수 있다. 메인 카탈로그 캐시(13550)는 추적할 수 있는 Nut들의 마스터 Nut ID 인덱스를 가질 수 있다. 캐시는 PKI 인증서들(13562), 연락처 카드들(13564), NUT서버 액세스 카드들(13566), 문서 제어 카드들(13568) 및/또는 임의의 다른 정의된 컬렉션들(13570)과 같은(그러나 이에 국한되지는 않음) 데이터의 상이한 컬렉션들로 구성될 수 있다. 이러한 컬렉션들은 NUTbook 및 이용 가능한 하드웨어의 구성에 따라 메모리에, 데이터페이스에, 파일 시스템상에, 또는 다른 저장 메커니즘에 저장될 수 있다. 데이터베이스 및 파일 시스템 저장소는 그것들이 네트워크 인터페이스를 통해 로컬로 액세스될 수 있는 한 원격 위치에 있을 수 있다. 도 136은 NUTbook 카탈로그 캐시가 어떻게 구성될 수 있는지에 대한 레이아웃의 예일 수 있다.
NUTbook에 저장되는 데이터는 PIM, 패스워드 키퍼, PKI 인증서 관리자, 키 링, 주소록, 메모 작성 애플리케이션, 레서피 북(recipe book), CD 컬렉션 인덱스, 스탬프 컬렉션 인덱스, 도서 컬렉션 인덱스, 의료 기록 및/또는 컬렉션으로 표현될 수 있는 임의의 다른 데이터 세트들의 집합체일 수 있다. 평균 사용자를 위한 현재 기술 상태는 그들의 삶의 이질적인 부분들을 기능적 디지털 형태로 디지털적으로 구성하기 위해 그들에게 많은 선택권을 제공하지 않을 수 있다. 주소록 애플리케이션은 수없이 많지만, 원활하고 간편한 상호 호환성이 부족할 수 있다. 가장 현명한 사용자들은 그들의 주소록에 민감한 패스워드를 저장하지 않을 수 있으며 그리고 특정 목적을 위해 패스워드 키퍼 애플리케이션을 평가하고 사용할 수 있다. 단지 이러한 두 가지 간단한 애플리케이션, 즉 주소록 및 패스워드 키퍼에 대해서도, 사용자가 운영체제 호환성, 동기화, 클라우드 풋 프린트, 백업, 웹 브라우저 통합 등과 같은 기능들을 고려한다면, 의사 결정 매트릭스가 여러 차원으로 확장되었을 수도 있다. 또한, 패스워드 키퍼와 주소록 간에 양호한 통합이 보장되지 않을 수도 있다. 사용자가 가족 구성원의 의료 기록, 자동 서비스 기록, 주택 관리 일정, 자녀 수업과 관련된 학교 로그인, 애완동물 수의학 기록(pet veterinary records), 디지털 기기 정보 및/또는 다른 데이터 컬렉션들을 추적하기를 원한다면, 각각의 유형의 데이터에 대해 서로 다른 애플리케이션을 사용하여 다양한 상이한 형식들로 수행해야할 수 있다. 스프레드시트의 일반적인 사용은 이러한 이질적인 데이터 세트를 조직화하는 것일 수 있으며, 사용자를 위한 범용 데이터베이스로 작동할 수 있다. NUTbook은 사용자가 일부 또는 모든 유형의 정보를 Nut 형식으로 체계적으로 저장하도록 허용할 수 있으며, 그리고 데이터 사용을 임의의 Nut 호환 애플리케이션에 통합할 수 있다. 적절하게 형성되고 식별될 수 있는 데이터는 정의된 구조를 이용할 수 있는 애플리케이션에 의해 기능적으로 만들어질 수 있다. 보안, 동기화, 복제, 백업 및/또는 비-구식화 같은(그러나 이에 국한되지 않음) NUTS 환경의 특징들 중 일부 또는 전부는 NUTbook의 모든 Nut에서 사용될 수 있다.
비-구식화 및/또는 시간 호환성은 MIOR을 사용하는 중요한 특성일 수 있다. MIOR와 함께 NUTbook 내에서 컬렉션들을 사용함으로써, 사용자는 다음과 같은 몇 가지 이점들을 얻을 수 있다 : 그들이 생성할 수 있는 데이터는 그들의 것일 수 있고, 그것은 안전할 수 있으며, 그리고 그들은 무기한으로(또는 NUTS가 활성화되고 지원될 수 있는 한) 그들의 데이터에 액세스할 수 있는 합리적인 기대를 가질 수 있다. NUTbook은 또한 데이터베이스 사용자의 세계와 파일 사용자의 세계 사이의 다리 역할을 할 수 있다. 그것은 파일 형식으로 저장된 레코드의 형태로 데이터베이스의 이점을 제공할 수 있다. 특정 컬렉션에 대한 판독/기록 기능을 위한 MIO 모듈은 사용자가 염두에 둘 수 있는 특정 컬렉션의 세부사항들을 캡처하는 것과 관련된 필드들의 조직화된 스펙 세트일 수 있지만 이 모델에 국한되지 않을 수 있다. 일부 실시예들에서, 판독/기록 모듈들은 다양한 데이터베이스에 대한 인터페이스일 수 있으며, 그리고 호출 애플리케이션에 대한 필드 매핑 및 변환 기능을 제공할 수 있다. 다른 실시예들에서, 이는 소프트웨어 회사의 라이센싱된 키들을 사용하여 페이로드의 독점적 바이너리 포맷들을 해독하는 판독/기록 모듈일 수 있다. 모듈들이 데이터에 액세스하는데 사용될 수 있는 다양한 방법은 매우 다양할 수 있으며, 그리고 애플리케이션 개발자의 목표에 따라 많은 치환(permutation)을 가질 수 있다. 특정 컬렉션의 기본 구조는 간단한 기존 템플릿들에서 시작하여 프로그래밍 지식이 거의 없는 사용자에 의해 커스터마이징될 수 있다. 새롭고 유용한 컬렉션들은 그들의 개인적인 사용을 위해 로컬 MIOR에 추가될 수 있으며 그리고 Nut 파일들을 통해 다른 사람들과 공유될 수 있다. 또한, 몇몇 승인 절차 후에 누구나 사용할 수 있도록 인터넷 MIOR 서버에 제출될 수도 있다.
이제 NUTbook의 동기들과 설계 목표들 중 일부에 대해 살펴보았으므로, NUTbook이 PKI 역할을 할 수 있고 궁극적으로 평균 사용자를 위해 SSO 수준의 서비스를 제공할 수 있는 방법에 초점을 맞출 수 있다. 도 137은 계층적 패스워드들의 개념을 개략적으로 도시한다. NUTS 용어로, 패스워드들은 패스프레이즈와 동일할 수 있다. 왜냐하면, Nut는 두 형식을 모두 허용할 수 있으며, 임의의 패스워드 대신에, 사용자는 하드웨어 토큰들, 인코딩된 바이너리 키들 또는 비밀 키를 제공할 수 있는 임의의 다른 방법을 사용할 수 있기 때문이다. 패스워드들, 그리고 두 가지 요소 인증들, 로그인 규칙들, 사용자 정의 패스워드 규칙들, 사용자 정의 웹 페이지들 및/또는 하드토큰들과 같은(그러나 이에 국한되지는 않음) 패스워드 관련 차별화 요소들의 잡초와 같은 확산은 급속히 통제 불능의 상태가 될 수 있으며, 그리고 사용자를 많은 웹 사이트에서 패스워드를 매우 쉽게 기억할 수 있는 정신 상태로 둘 수 있으며, 이에 따라, 사용자는 개별 판매자들이 고객을 위해 시스템을 보다 안전하게 유지하려는 노력을 방해할 수 있다. NUTS의 바람직한 솔루션은 효과적인 SSO 액세스를 허용하기 위해 가능한 한 적은 수의 패스워드를 사용하는 것일 수 있으며, 계층적 패스워드들이 이 접근법을 구현할 수 있다. NUT서버 및 NUTbook에 대한 기본적인 인증을 허용할 수 있는 메인 패스워드(13710)가 존재할 수 있다. 메인 패스워드는 키 캐시(13520)에 캐시될 수 있는 키를 포함하는 Nut를 열 수 있으며, 그리고 세션이 끝나거나 미리 결정된 이벤트가 끝난 후 자동 삭제되도록 구성될 수 있다. 메인 키는 대부분의 NUT서버 및 NUTbook 기능들을 효과적으로 사용하기에 충분할 수 있다. 쇼핑(13714), 업무(work)(13716), 금융(13718) 및/또는 통신(communication)(13712)과 같은(그러나 이에 국한되지는 않음) 제2 레벨 패스워드들이 존재할 수 있다. 이러한 패스워드들은 유효한 메인 패스워드를 성공적으로 입력한 후에만 입력될 수 있으며, 이에 따라 그들은 패스워드들의 계층을 존중할 수 있다. 이러한 제2 레벨은 사용자가 상이한 데이터 그룹에 대해 상이한 보안 수준을 분리하고 격리할 수 있게 할 수 있다. 제2 레벨의 각각의 패스워드는 사용자가 그것들의 노출을 제어할 수 있도록 키 캐시(13520)에서 서로 다른 수명을 갖도록 구성될 수 있다. 예를 들어, 사용자는 은행 컬렉션 카드에 인터넷 은행 계좌 로그인 정보를 가지고 있을 수 있으며, 단일 사용 기간을 가질 수 있는 금융 키를 사용하여 이를 안전하게 보관할 수 있다. 그 다음, 그는 은행 카드에 저장된 로그인 및 패스워드에 액세스함으로써 은행 웹 사이트에 액세스하려고할 때마다 금융 패스워드를 입력해야할 수 있다. 각 은행 카드 내에서, 웹 사이트 패스워드는 엔트로피를 최대화하기 위해 무작위로 생성될 수 있고, 그리고 NUTbook에 의한 자동 로그인 사용을 위해 저장될 수 있다. 더 많은 레벨이 추가될 수 있지만, 사용자 정보의 복잡성과 사용자가 암기하길 원할 수 있는 양에 따라 다르다. 일부 또는 모든 계층적 패스워드들을 건너뛸 수 있는 마스터 패스워드(13720)가 존재할 수 있다. 마스터 패스워드는 최대한의 보호를 위해 신중하게 선택되거나 임의로 생성될 수 있으며, 그리고 안전한 장소에 보관될 수 있다. 이 계층적 암호 방법론을 사용하면, 사용자는 추측하기 어려울 수 있지만 암기해야할 패스워드 수의 감소로 인해 사용자에 의해 더 쉽게 기억될 수 있는 패스워드 세트를 신중하게 선택하기만 하면 될 수 있으며, 이는 SSO 액세스의 기초를 형성할 수 있다.
도 138은 개인 문서 Nut(13806)를 여는 패스워드 입력 프로세스를 도시한다. 이 문서는 메인 레벨 키에 의해서만 보호될 수 있으므로, NUT서버로 인증하기 위해 메인 키에 액세스하기 위해(13804) 메인 패스워드(13710)를 입력하는 것은 개인 문서(13806)를 보관하는 Nut를 열기에 충분할 수 있다. 도 139에서, 마스터 패스워드(13720) 경로는 메인 패스워드 경로와 정확히 동일할 수 있다.
도 140은 제2 레벨 업무 패스워드(13716)에 의해 보호되는 업무 문서가 열릴 수 있는 방법을 도시한다. 메인 패스워드(13710)는 메인 키에 액세스하기 위해 공급될 수 있고, 그 다음 업무 패스워드는 업무 문서 Nut(14010)를 잠금 해제할 수 있는 업무 레벨 키에 액세스하기 위해(14008) 입력될 수 있다. 도 141에서, 마스터 패스워드(13720)의 잠금 해제 경로는 도 139에서와 동일하게 유지될 수 있으며, 여전히 단일 단계 액세스일 수 있으므로, 마스터 패스워드는 보다 안전한 방식으로 생성될 수 있다.
도 142는 NUTbook 키 캐시(13520)의 보다 상세한 다이어그램을 도시한다. 그것은 NUT서버들과 관련된 키들에 대해 분할된 섹션(14210)을 가질 수 있고, 그리고 그것은 다양한 카드 컬렉션들에서 사용하기 위해 분할된 섹션(14230)을 가질 수 있다.
도 143은 NUTbook이 카탈로그 카드를 볼 수 있는 방법에 대한 프로세스 흐름도를 도시한다.
보유된 소유권(retained ownership)은 상이한 소유주들의 Nut들이 섞이는 것과 관련된 개념일 수 있다. Alice가 Acme 회사에서 새로운 일자리를 얻었고, 그들 모두 NUTS 기반 애플리케이션들을 사용하여 각각의 연락처 및/또는 디지털 키들의 구성의 세부사항을 관리할 수 있다고 가정한다. 추가적으로, Acme는 Nut들을 사용하여 액세스 Nut들을 제어할 수 있고 그리고 부서별 그리고/또는 직원 액세스 레벨에 따라 회사 문서들을 신중하게 잠글 수 있다. Alice가 고용되면, Acme의 HR 부서는 Alice에게 일반 기업 액세스 Nut를 발급할 수 있다 : 이는 Alice가 내부 회사 연락처 목록, 고객 목록 및/또는 다양한 회사 문서와 같은 정보를 조회할 수 있게 할 수 있는 액세스 Nut일 수 있다. Acme의 NUTS 시스템들은 직원의 특정 액세스 Nut 및 회사 마스터 키에 의해 잠긴 래핑 Nut에 페이로드의 사본을 래핑함으로써 Nut들에 저장될 수 있는 민감한 문서들에 대한 액세스를 제공하도록 커스터마이징 그리고/또는 구성되었을 수 있다. 이러한 기업 Nut들의 소유권(RAT)은 항상 Acme일 수 있다. 마찬가지로, Alice의 개인 Nut들은 항상 그녀를 RAT로서 가질 수 있다. 암호 방식으로 소유자를 명확하게 정의하는 기능을 통해, 각 Nut는 NUTS 환경 내의 각 소유자에 의해 적절하게 취급될 수 있다. Nut들의 이러한 보유된 소유권 특성을 통해, Alice는 그녀가 사용하고 제어할 수 있는 모든 기기에서 그녀의 Nut들을 Acme의 Nut들과 혼합할 수 있다. 이는 Alice의 기기들에서 Acme들의 Nut들에도 똑같이 적용될 수 있다. Alice와 Acme는 모두 각각의 액세스 Nut들의 수명을 상대적으로 짧은 기간으로 설정할 수 있다. 예를 들어, 수명은 외부 시스템(foreign system)들에 저장된 Nut들에 대해 60 일로 설정될 수 있다. 따라서, 매 60일마다, 키들은 그들에 의해 소유되는 Nut들의 각 소유자에 의해 갱신될 수 있고, 아니면 그것들을 관리하는 외부 NUT서버들에 의해 자동으로 삭제될 수 있다. 적절한 NUT서버들이 적절한 액세스 Nut에서 삭제 명령들을 발송할 수 있고 소유자의 영향을 받는 Nut들의 일부 또는 전부를 체계적으로 삭제하도록 인코딩될 수 있다면, 삭제들이 강제로 발생할 수 있다. 이에 따라, 각 당사자는 직접적으로 또는 간접적으로 외부 시스템들의 Nut들에 대한 제어를 유지할 수 있다. 따라서, Alice가 새 직장으로 떠난다면, Alice는 자신이 회사 데스크톱에 복사본을 남긴 그녀의 개인 연락처 정보가 60일 이내에 자동으로 삭제될 수 있음을 알 수 있다. Alice의 개인 기기들에 남아있는 Acme 소유의 Nut들에도 동일한 내용이 적용될 수 있다 : 갱신된 액세스 Nut가 없다면, 더 이상 시스템에 연관된 Nut들이 없다. 이러한 유형의 Nut 섞음은 일을 집에 가져가기 위한 서로 다른 세트의 보안 조치들 그리고 두 개 이상의 개별 연락처 목록들을 저글링(juggling)하는 오래된 문제를 해결하기 위한 것일 수 있다. 이제 Alice는 개인적인 생활과 직장 생활에서 그녀의 개인 NUTbook을 연락처의 주된 소스로서 항상 사용할 수 있으며, 그리고 그것이 안전할 수 있다고 합리적으로 확신할 수 있다.
다른 실시예에서, NUTbook 연락처 카드는 지인에 대한 개인 정보를 포함하는 외부 Nut들을 임베딩하거나 이에 대한 참조를 운반할 수 있다. Bob으로부터의 외부 Nut는 Alice가 아니라 Bob에 의해 소유될 수 있다. Bob은 Alice에게 자신에 대한 사전 패키징된, 제한된 세부 연락처 Nut를 발송할 수 있고, 그리고 Alice의 NUTS 환경에서 소유권을 유지할 수 있다. Bob에 대한 Alice의 NUTbook 엔트리는 이러한 Nut를 Bob에 대한 그녀의 연락처 엔트리에 직접적으로 또는 참조로 임베딩할 수 있다. Bob이 새로운 우편 주소, 새로운 직장 주소, 전화번호 또는 다른 영향을 받는 정보와 같이 자신에 대한 일부 또는 모든 정보를 변경할 때마다, 그는 임의의 이용 가능한 수단을 통해 Alice에게 자신의 사전-패키징된 연락처 Nut에 대한 업데이트를 발송할 수 있으며, Alice의 NUT서버가 이를 인식하면, Alice의 NUTbook의 Bob에 대한 카드에 있는 적절한 임베딩된 외부 Nut를 자동으로 업데이트할 수 있다. 그런 다음, Alice의 NUTbook은 연락처 애플리케이션을 실행하여 업데이트된 카드를 처리할 수 있으며, 이는 Bob에 대한 Alice의 카드의 업데이트로 이어질 수 있다. 이 마지막 단계는 Bob에 대한 Alice의 카드 항목이 Bob의 정보에 대한 과거 기록을 결코 잃어버리지 않을 수 있음을 확인할 수 있으며, Alice가 원하는 경우, Alice는 Bob의 정보에 대한 다양한 이력적 변경 사항들을 추적할 수 있다. 이러한 단계들의 일부 또는 전부는 잘 확립되고 신뢰할 수 있는 RBK 관계들에 개입하지 않고 자동으로 수행될 수 있다. 이것은 Alice의 신뢰할 수 있는 RBK 관계들의 일부 또는 전부가 수동 개입이 거의 없거나 전혀 없이 연락처 정보를 업데이트했을 수 있음을 의미할 수 있으며, 이로써, Alice와 그녀의 친구들 각각의 시간과 노력을 크게 절감할 수 있다. Alice가 99 개의 RBK 연락처들을 갖고 50 번의 업데이트들이 발생할 수 있다면, 오직 50 가지의 변화들만이 영향을 받는 사람들에 의해 개시되어야 할 수 있으며, 그리고 나머지는 각각의 영향을 받는 사람의 NUT서버들에 의해 자동으로 처리될 수 있다. 전통적인 주소록 설정에서, 50 개의 업데이트들은 영향을 받는 개인에 의해 50 개의 업데이트들이 될 수 있고, 99 명의 친구들에 대한 50개의 알림들은 그들에게 변경사항을 알리고, 99명의 친구들 각각은, 관여될 수 있는 100 명의 사람들에 의해 소비된 공동의 시간(collective time)은 말할 것도 없고, 50 건의 업데이트들이 생성할 수 있는 약 10,000 건의 이벤트들에서 일정 수준의 사본 오류(transcription error)와 함께 자신의 주소록에 최대 50 개의 업데이트들을 만들 수 있다. 이 실시예는 대안적으로 중앙 집중화된 서비스를 가짐으로써 해결될 수 있지만, 이러한 서비스들은 제한된 프라이버시, 액세스, 소유권 및/또는 제어를 제공할 수 있다. NUTS 솔루션은 높은 수준의 프라이버시, 히스토리, 감사추적 및/또는 소유권을 일관성 있게 유지하는 것을 시도하면서 가능한 한 분권화를 강조할 수 있다.
NUTS 기반 서비스들
NUTS 기반 서비스들은 Nut들이 여러 원격 당사자들 간에 사용될 수 있도록 인터넷과 같은 더 넓은 네트워크로 Nuts 사용을 확장할 수 있다. 도 144의 표는 NUTS가 지원하고 제공할 수 있는 다양한 웹 기반 서비스들의 예들을 나열하고, 도 145는 이러한 서비스들에 대한 단순화된 네트워크 레이아웃을 도시한다. 일부 또는 모든 서비스들은 최저 수준이 제약 조건을 갖고 무료로 제공되는 다중-계층의(multi-tiered) 서비스 패키지들을 제공할 수 있다. 높은 계층의 패키지들(higher tiered packages)에 대한 지불은 별도로 구매한 서비스 크레딧 바우처들(service credit vouchers)을 통해 직접적으로 또는 익명으로 이루어질 수 있다. 서비스들의 일부 또는 전부는 다양한 수준으로 익명으로 사용될 수 있다.
NUTS 기반 서비스들 : NUTmail
도 146에 도시된 NUTmail 서버는 등록된 사용자들 사이에서 Nut들을 통해 일부 또는 모든 메시지들을 통과시키는 웹 기반 이메일 서비스를 도시한다. 또한, 자동 등록, 익명 등록, 익명 채널 및/또는 RBK 기반 통신을 지원할 수 있다. 서버는 NUTbook 및/또는 NUTserver 애플리케이션들과 상호작용할 수 있다. NUTmail은 이메일을 관리, 편집, 디스플레이, 구성, 발송 및/또는 수신할 수 있도록 사용자의 기기 상에서 실행될 수 있는 클라이언트 컴포넌트를 가질 수 있다.
도 147은 자동화된 방식으로 NUTmail 서버상에 익명 등록을 설정하는 프로세스를 도시한다. 사용자는 이메일 주소, 텍스트 가능 전화번호 및/또는 웹 브라우저와 같은(그러나 이에 국한되지는 않음) 선호되는 이미-존재하는 연락 방법을 포함할 수 있는 사전-패키징된 Nut를 이용하여 서버에 접촉할 수 있다(14700). 서버는 요청을 수락할 수 있으며(14702), 그리고 선호되는 연락 방법을 사용하여 사용자에게 요청을 발송할 수 있다(14704). 사용자는 요청으로부터 요구되는 정보를 입력할 수 있으며, 서버는 14706에서 암호 방법의 최대 엔트로피를 이용할 수 있는 무작위로 생성된 로그인 ID 및 패스워드를 생성할 수 있다. 또한, 서버는 사용자와 서버/관리자 간의 일부 또는 모든 통신들에 사용될 수 있는 사용자와의 RBK 쌍을 생성할 수 있다. 사용자는 자신의 연락처 정보에 대한 카드 내 NUTbook에 로그인 크리덴셜과 RBK 쌍을 저장할 수 있다(14708). 따라서, 사용자는 주로 자동화된 방식으로 NUTmail 서버에 자동으로 등록할 수 있다(14710).
등록 프로세스 동안 생성될 수 있는 로그인 ID와 RBK는 오직 사용자가 NUTmail 서버와 통신하는데만 사용될 수 있다 : 어떤 면에서는, 사용자와 서버 간의 개인 채널(private channel)로 간주될 수 있다. 사용자가 NUTmail을 또한 사용할 수 있는 다른 사람과 통신하기를 원할 때, 도 148에 도시된 바와 같이, NUTmail 서버 상에 그 사람과의 통신 채널이 설정될 필요가 있을 수 있다. 통신 채널은 별칭(alias)으로서 각 사용자의 등록된 계정들에 첨부될 수 있는 한 쌍의 랜덤하게 생성된 이메일 별칭을 포함할 수 있다. 관계의 익명성을 보다 잘 유지하기 위해, NUTmail 서버는 통신 채널이 설정되고 검증될 수 있으면 이러한 별칭 쌍들을 추적하지 못할 수 있다. 이러한 별칭들은 채널의 두 참가자들에 의해서만 사용될 수 있다는 점에서 RBK와 기능면에서 유사할 수 있다. 별칭 생성의 랜덤 특성은 인터넷을 통한 이메일 전송 중에 참가자들의 아이덴티티들에 대한 힌트를 제공하지 않을 수 있다. 이메일 내용 자체는 페이로드를 추가로 보호하는 RBK 방법들에 의해 보호되는 Nut에 인케이싱될 수 있다. 이는 원치 않는 SPAM 및/또는 제3자 이메일 스니핑(email sniffing)의 일부 또는 전부를 최소화할 수 있는 관계 기반 방법들 및 난독화들의 두 개의 별개의 계층들을 제공할 수 있다. 일단 통신 채널이 적절하게 설정될 수 있으면, 이메일들의 교환은 도 149에 도시된 바와 같이 상당히 표준적일 수 있다.
NUTmail 서버에 대안 보안 근거는 다음과 같이 요약될 수 있다 :
● 익명 등록은 손상된 서버가 등록된 사용자들 및/또는 그들의 이메일 내용들에 대해 거의 공개하지 않을 수 있음을 의미한다.
● RBK로 암호화된 Nut들 내의 이메일 캡슐화는 또 다른 독립적인 콘텐츠 보안 계층을 제공할 수 있다. 해킹된 서버들은 Nut들에 의해 보안되는 메시지들만 공개할 수 있다.
● 별칭 쌍들을 이용하는 NUTmail 통신 채널들은 이메일 메타데이터를 난독화시킬 수 있다.
● 서버는 별칭 페어링 데이터를 영구적으로 저장하지 않을 수 있으며, 채널이 검증될 때까지만 저장할 수 있다.
● 서버는 매우 짧은 기간 동안 이메일 메시지들을 저장할 수 있다. 이것은 사용자에 의해 구성될 수 있지만, 기본값은 서버 외부에 적어도 2 개의 사본들이 존재할 수 있는 사용자의 NUTmail 클라이언트 또는 NUT서버로부터의 정보를 수신한 후에 또는 사전-구성된 기간 후에 메시지들이 삭제(expunging)될 수 있다는 것이다.
● 짧은 히스토리의 이메일들은 서버가 매우 작은 장기간 데이터 저장 요구사항을 가질 수 있게 할 수 있다.
● 랜덤하게 생성된 로그인들, 별칭들, 패스워드들 및/또는 RBK들은 사용 가능한 데이터 엔트로피를 최대한 활용하여 보안을 강화할 수 있다.
가능할 수도 있지만 NUTbook의 통합 사용 없이 NUTmail 서버를 사용하는 것은 쉽지 않을 수 있다. 로그인 ID, 패스워드 및/또는 별칭들은 최대 엔트로피 방법들을 사용하여 생성될 수 있으며, 그리고 긴 스트링의 랜덤 문자들이 뒤죽박죽 섞인 것처럼 보일 수 있다. 관계와 별칭 쌍 사이에 1:1 대응이 있을 수 있으므로, 사용자가 추적해야할 수 있는 별칭들의 수는 매우 빠르게 많아질 수 있다. 이러한 통신 방법의 이점은 참가자들에 의해 생성된 데이터가 쓸모없게 될 수 있으며 그리고 일부 의미는 타겟팅된 데이터 감시 및/또는 정교한 재구성 기법들을 통해서만 추출될 수 있다는 것일 수 있다.
NUTmail 서버의 데이터 저장 요구사항들은 일반 이메일 서버와 상이할 수 있다 : 그것은 지속적으로 사용자당 훨씬 적은 공간을 사용할 수 있다. 사용자의 NUT서버 또는 NUTmail 클라이언트가 NUTmail 서버의 외부에 적어도 두 개의 이메일 사본들이 존재할 수 있다고 나타낼 수 있을 때, NUTmail 서버는 해당 이메일 Nut를 영구적으로 삭제할 수 있다. 이러한 유형의 단순 규칙은 채널의 각 참가자가 각각 최소 2 개 이상의 코뮈니케(communique) 사본을 수립할 수 있게 할 수 있다. NUTmail 서버는 등록된 각 클라이언트의 NUT서버들을 활용하여 가능한 한 장기간의 스토리지를 오프로드할 수 있으며, 이에 의해, 사용자 당 자체 지속적 저장 요구사항을 감소시킬 수 있다. NUTmail 서버는, 각 사용자가 자신의 NUTmail 클라이언트/NUT서버 시스템들에 이전 이메일들을 다운로드하고 복제했을 수 있기 때문에, 등록된 사용자들에 대해서 새로운 이메일 메시지들만 가질 수 있다.
NUTS 기반 서비스들 : NUTchat
NUTchat는 Nut들에 기반한 익명의 채팅 서비스일 수 있다. 이는 다음과 같은 채팅 기능들을 제공할 수 있다 :
● 이는 익명의 등록, 쌍으로의(pairwise) 랜덤 별칭들 및/또는 RBK들을 지원할 수 있다.
● 익명을 위해 로컬 NUTchat 허브에 전화번호들을 제공할 수 있다.
● 동시 휴대전화 & 비-휴대전화 채팅을 지원할 수 있다.
● SMS/MMS 및 인터넷 기반 채팅 세션들을 동시에 지원할 수 있다.
● NUTmail 서버와 유사한 히스토리 기능을 지원할 수 있다.
● 채팅 히스토리는 각 연락처 엔트리 저장소 내에 저장되거나, 또는 Nut에 저장될 수 있으며, 그리고 전화번호 또는 채팅 주소가 아닌 타겟 연락처 엔트리에 의해 참조될 수 있다.
● 채팅 히스토리는 NUTchat 서비스 없이도 개인적인 용도를 위해 영구적으로 저장될 수 있다.
● NUTchat은 Nut에 포함될 수 있는 채팅 메시지들에 대한 전문 서비스일 수 있다.
● 랜덤하게 생성된 로그인들, 별칭들, 패스워드들 및/또는 RBK들은 사용 가능한 데이터 엔트로피를 최대한 활용하여 보안을 강화할 수 있다.
● 메시지 전달을 보장하고 가상 채팅 세션들을 표시하기 위해 통신 경로들을 다중화할 수 있다.
도 150에는 NUTchat에 대한 네트워크 다이어그램의 예가 도시되어 있다. 등록 절차들은 NUTmail 서버들에 의해 이용되는 방법들과 유사할 수 있으며, 그리고 사용자들을 위해 익명의 기능들을 일부 또는 전부 제공할 수 있다. 사용자 기기상에서 실행되는 Nut 기반 NUTchat 클라이언트가 존재할 수 있으며, 그리고 도 151의 세 참가자들 간의 채팅 세션에 대한 기본 데이터 흐름 구성이 도시되어 있다. 이것은 NUTchat 서버(15100)가 중간에서 조정자의 역할을 하는 표준 텍스트 메시지 전달 토폴로지일 수 있다. NUTchat이 Nut들을 기반으로 할 수 있기 때문에, 세션의 전체 채팅 히스토리는 Nut에 저장될 수 있으며, 이에 따라, 적절하게 구성된다면, NUTserver 복제/전파/동기화 기능들을 자동으로 활용할 수 있다. NUTserver는 NUTchat Nuts에 우선순위를 부여하도록 구성될 수 있어서, 그것들은 채팅 세션에서 실시간 상호작용 특성으로 인해 보다 신속하게 처리될 수 있다. 도 151을 자세히 보면, 동일한 채팅 Nut들이 여러 위치에 존재한다는 것을 알 수 있다; 이는 채팅 토폴로지가 다수의 물리적 위치들에서 데이터 상태들의 간소화된 동기화와 동등할 수 있음을 나타낸다. 도 152는 사용자의 NUT서버들을 사용하여 NUTchat을 복제할 수 있는 프로세스의 데이터 흐름들의 예이다. 각각의 채팅 참가자가 Nut(15122-15126)에 채팅 세션 히스토리의 일부 또는 전부를 저장할 수 있기 때문에, NUT 서버(15238)는 15242 같은 피어 NUT 서버들을 통해 그러한 Nut들에 변경 사항을 전파할 수 있다. 이 체계적인 방식으로 데이터를 적절히 동기화함으로써, 사용자가 그의 기기 #4(15240) 상에 NUTchat 클라이언트(15260)를 불러올 때, 그는 그가 기기 #2에 남긴 세션 히스토리와 동일한 세션 히스토리를 볼 수 있으며, NUTchat 서버가 기기 #4를 최신 상태로 유지하는데 아무런 영향을 미치지 않았다. 채팅 세션이 개시될 때, 그리고 각각의 NUTchat 클라이언트들에 의한 채널의 양측에 있는 채팅 Nut들의 검사가 그것이 비동기되었다고 판단할 때, 세션을 최신 버전으로 업데이트하기 위해 강제 동기화 절차가 자동으로 개시될 수 있다(채팅 히스토리의 분류는 기본적으로 Nut 히스토리로도 알려진 페이로드의 새로운 상태로 볼 수 있다는 것에 유의한다). 예를 들어, Alice는 Bob과 오랫동안 지속되어온 익명의 NUTchat 채널을 가질 수 있지만, 어떻게든, Alice는 그녀의 스마트폰에서 이 세션 히스토리를 저장하는 그녀의 채팅 Nut를 잃어버렸거나 삭제했을 수 있다. Alice는 Bob과의 이러한 NUTchat 세션을 재개하고 그리고 NUTchat 서버를 통해 연락할 수 있을 때, 서버는 Alice와 Bob 모두로부터 세션의 버전 번호를 수신할 수 있으며, 그리고 Bob이 Alice보다 최신 버전을 가질 수 있음을 나타낼 수 있다. 그 시점에서, Bob의 채텅 Nut의 사본이 자동으로 요청되어 NUTchat 서버를 통해 Alice에게 발송될 수 있으며, 그리고 Alice의 NUTchat 클라이언트는 Bob의 세션 히스토리를 자체 히스토리로 받아들일 수 있으며, 채팅 세션은 히스토리와 그에 따른 컨텍스트의 공통 뷰로 계속될 수 있다. NUTchat 서버에 의해 이 시나리오에서 사용되는 저장소는 거의 없을 수 있으며, 그리고 일부 또는 모든 세션 정보는 최종 사용자들이 그들의 제어 하에 저장할 수 있다. 채팅 세션 버전들이 동기화된 후에, 서로에게 발송된 채팅 메시지들은 전체 히스토리가 아닌 세션의 새 채팅 메시지만 보유한 Nut들에 포함될 수 있으며, 각 끝에 있는 NUTchat 클라이언트들은 각각 누적 채팅 세션을 업데이트할 책임이 있으며, 따라서 진행 중인 채팅 세션에서 데이터 전송 크기를 줄일 수 있다.
뿐만 아니라, Alice의 NUTbook은 Bob에 대한 Alice의 연락처 항목에서 채팅 Nut들과 이메일 Nut들을 참조하거나 가리키도록 참조할 수 있으며, 이로써, Bob과 관련된 이력적 통신들의 일부 또는 전부는 Bob의 정보에 따라 인덱싱될 수 있으며, 이는 Alice의 통제하에 저장된 관계에서의 체계적인 상황 대조를 야기할 수 있다.
NUTchat 클라이언트들은 신뢰성, 중복 및/또는 난독화를 위해 경로에 관계없는(path agnostic) 채팅 세션들을 포함할 수 있는 대화에 참여할 수 있다. 도 153은 최대 3 개의 상이한 채팅 서비스들 및/또는 채팅 ID들을 사용할 수 있는 Bob과 Alice 사이의 3 개의 개별적인 채팅 세션들에 대한 전형적인 데이터 흐름 패턴을 도시한다. 때때로, 이러한 유형의 분리 및 구분이 관련 당사자에게 바람직하고 편리할 수 있다. 다른 경우에는, 이는 다른 참가자가 선택한 사항에 따라 사용자에게 강제될 수 있다 : 예를 들어, Bob은 채팅 서비스 B에서만 계정을 원할 수 있으므로, Alice는 Bob과 채팅하기 위해 서비스 B에서 로그인을 생성하는 것이 강제될 수 있다. 그러나, NUTchat 클라이언트가 다른 채팅 서비스들과 인터페이스할 수 있는 정도까지는, 동일한 두 사람들 간의 다수의 개별 채팅 세션들이, 대화(Dialogue)라고도 불리는 도 154에 도시된 바와 같은 경로에 관계없는 채팅 세션으로 응집될 수 있다. 채팅 Nut들은 메시지들의 기본 매개체가 될 수 있으므로, 일부 또는 모두가 버전 번호를 가질 수 있으며, Nut의 복사본이 일부 또는 모든 3 개의 채팅 세션 경로들에서 동시에 발송될 수 있다. 어떤 채팅 Nut이든 먼저 다른 NUTchat 클라이언트에 도착할 수 있는 채팅 Nut는 처리될 수 있고 나머지는 무시될 수 있다(또는 NUT서버 Nut 병합으로 병합된 다음 버려질 수 있다). 때때로, 전송 제한사항의 특성으로 인해, 채팅 Nut들은 전송 플랫폼에 적합한 간결하고 안전한 텍스트 메시지들로 변환될 수 있다. 이 방법에서, 대화는 여러 경로들을 통해 보존될 수 있으며, 가장 최신 버전만 각 참가자에게 표시될 수 있으며, 프로세스는 개별 채팅 서비스 제공자들의 저장 및/또는 조직화 기능에 의존하지 않고 그들의 전송 메커니즘들에만 의존할 수 있다. 중복(redundant) 경로들은 대화의 전송 실패를 최소화하거나 사실상 제거할 수 있다. 각각의 전송 서비스가 저장할 수 있는 히스토리는 메시지 단위로 Nut에 의해 보호될 수 있으므로 쓸모가 없을 수 있다. 따라서 컨텐츠들은 불투명할 수 있다. 전송 메커니즘들은 이메일 서버들, ftp 서버들, 네트워킹된 파일 시스템들, 포인트-투-포인트 연결들, WiFi 프로토콜들, 블루투스 프로토콜들 및/또는 임의의 다른 디지털 전송 방법과 같은(그러나 이에 국한되지는 않음) Nut가 통과되도록 허용할 수 있는 임의의 채널일 수 있다. Nut의 동기화 특성들은 사용자들이 Nut에 액세스할 수 있도록 적어도 2 명의 작성자들과 공통 방법을 갖도록 구성되는 공유 가능한 Nut만을 사용함으로써 채팅 세션이 관여되도록 허용할 수 있다. 이 실시예는 사용자의 데이터를 서비스와 독립적으로 보호하고 사용자에 의한 전송 메커니즘의 전반적인 신뢰성을 강화하면서 채팅 시스템들의 기능을 배제(disintermediating)하는 것이 얼마나 간단한지 보여줄 수 있다.
NUTS 기반 서비스들 : NUTcloud
NUTcloud는 도 155에 도시된 바와 같이 임의의 NUTS 사용자가 이용할 수 있는 인터넷 기반 저장 서버일 수 있다. NUTcloud는 익명 등록, 쌍으로의 랜덤 별칭들 및/또는 RBK들을 지원할 수 있다. 개인 NUTS 서버들과 원활하게 통합하여 개인 NUTS 네트워크의 도달 범위 및 가용성을 확장할 수 있다. NUTcloud는 Nut들을 저장할 수 있으며, 저장소 및 대역폭 제한은 서비스 계층 레벨들 및 사용자가 구성할 수 있는 정책들의 영향을 받을 수 있다. NUTcloud 계정은 더 영구적인 그리고/또는 액세스 가능한 저장소를 공급하기 위해 다른 NUTS 기반 서비스들과 상호 운용될 수 있다 : 즉, NUTmail 및/또는 NUTchat 메시지들을 백업할 수 있다.
기본 서비스 레벨에서는, 일반적인 개인용으로 충분한 수준의 저장소 및 대역폭을 제공할 수 있다. 주요 목적은 인터넷상의 임의의 액세스 포인트에서 Nut들에 저장되는 데이터의 액세스를 용이하게하는 것일 수 있다. 이는 NUT 서버들과 원활하게 통합되어 집이나 도로에서 Alice의 데이터의 일부 또는 전부를 동기화할 수 있다.
NUTcloud는 개인 NUT서버와 함께 임의의 인터넷 기반의 중앙 관리 클라우드 서비스와 동등 이상의 수준의 동기화를 제공할 수 있다 : 그러나, 인기있는 무료 클라우드 동기화 서비스들과는 달리, NUTcloud는 완전한 익명성, 사용자 제어 프라이버시, 전체 히스토리, 전체 감사 추적 및/또는 보안 데이터 소유권을 제공할 수 있다.
NUTS 기반 서비스들 : NUTnet
NUTnet은 도 156에 도시된 바와 같이 NUTS 사용자가 이용할 수 있는 Nut 기반 웹서버일 수 있다. NUTnet은 익명 등록, 쌍으로의 랜덤 별칭들(pairwise random aliases) 및/또는 RBK들을 지원할 수 있다. NUTnet은 Nut들을 저장할 수 있으며, 그것의 저장소 및 대역폭 제한은 서비스 계층 레벨들 및 사용자가 구성할 수 있는 정책 설정들의 영향을 받을 수 있다. NUTnet 계정은 더 영구적인 그리고/또는 액세스 가능한 저장소에 액세스하기 위해 다른 NUTS 기반 서비스들과 상호 운용될 수 있다 : 예를 들어, NUTcloud 및/또는 NUT 서버들로부터 Nut들을 가져올 수 있다.
Nut들에 저장된 웹 페이지 콘텐츠를 공유하면 사용자들이 콘텐츠를 볼 수 있는 사람을 제어할 수 있으며, 그리고 그것은 암호화 수준에서 수행될 수 있다. 포스팅된 페이지들을 보기 위해 사람은 콘텐츠 소유자와의 RBK 쌍을 가질 수 있다. 이것은 반-사회적 소셜 네트워크(anti-social social network), 사적 소셜 네트워크 및/또는 인증된 소셜 네트워크일 수 있다고 말할 수 있다. 콘텐츠에 대한 키가 없기 때문에, NUTnet 서버 또는 다른 인증되지 않은 제3자에 의해 채굴되는 콘텐츠가 없을 수 있다. 콘텐츠가 Nut들에 저장되고 보안될 수 있는 한, 소유자는 그에 대한 통제권을 유지할 수 있다. 또한, 그것이 Nut들을 국부적으로 복제하고 동기화하도록 구성되어 있다면, 소유자는 로컬 Nut 저장소의 포스팅과 관련된 일부 또는 모든 히스토리를 볼 수 있다. 친한 친구들 및 가족 간의 사진 및 비디오 공유가 사적인 문제일 수 있으며 제3자가 창작자 모르게 그리고/또는 창작자의 허락 없이 자신의 사용을 위해 사본을 소유할 권리를 가질 수 없다고 느끼는 때가 있을 수 있다. NUTnet은 사용자 그룹 내에서 프라이버시를 필요로 하는 이러한 상황을 위해 생성될 수 있다.
전문 사진사들은 잠재 고객들이 엄청난 양의 세부사항을 갖는 저작권으로 보호된 사진을 볼 수 있도록 개인 웹페이지를 만들 수 있으며, 그리고 누가 그리고 얼마나 오래 키를 발급받을 수 있는지 제어할 수 있다. 웹페이지 Nut들은 사진의 일부 또는 모든 활동을 기록하여 사진사를 위한 감사 추적을 형성할 수 있다. 프로젝트 관리자들은 프로젝트 회원들 간의 활동 조정을 위해 개인 웹페이지를 만들 수 있다. 보안 관점에서 볼 때, 등록 프로세스는 Nut에 내장된 액세스 제어들로 인해 불필요할 수 있지만, NUTnet 서버에서 조직화 및 구획화 기능을 수행할 수 있다.
NUTS 기반 서비스들 : NUThub
현재, IoT(Internet of Things)가 통신 그리고/또는 기능할 수 있는 방식에 대하여 일반적으로 인정되는 표준이 없을 수 있다. IoT는 내장된 네트워크 기능을 가질 수 있는 하드웨어 제품들이 점차 늘어나고 있으며, 그리고 사용자들이 다양한 개인용 컴퓨팅 기기들에서 제품의 기능들을 원격으로 제어하고 모니터링할 수 있게 할 수 있다. 많은 IoT 제품들은 때로는 제품의 사용자-소유자가 모르는 사이에 그것들의 센서들로부터의 일정한 데이터 스트림을 제조 공급 업체에 보내서, 제조 공급 업체가 그것을 수집하고 분석할 수 있게 할 수 있다. 이러한 IoT 기기들의 일부 또는 전부의 작동 모드는 제품들이 사람의 집에서 가장 사적인 영역들을 대상으로 할 수 있기 때문에 데이터 수집 범위 및 방법들에 기초하여 많은 프라이버시 침해 문제를 야기할 수 있다. 몇몇 사용법을 얻기 위한 IoT 프레임워크는 IoT 하드웨어 공급업체들에 의해 자사 제품군용으로 공급될 수 있다. NUThub는 Nut들의 인터넷(Internet of Nuts; IoN)이라고 하는 NUTS 호환 가능한 IoT-유형 기기들에 의해 생성될 수 있는 Nuts 기반 메시지들의 처리를 용이하게 하는 패킷 포워딩 서비스일 수 있다. 도 157의 네트워크 다이어그램에 도시된 바와 같이, IoN은 집에서 IoN 호환 기기들과 안전하게 그리고 개인적으로 통신하기 위한 NUTS 기반 표준일 수 있다. NUThub에서 가장 낮은 서비스 등급은 임의의 NUTS 기반 서비스에 등록된 계정을 가질 수 있는 사람이면 누구나 사용할 수 있다. 계정은 익명일 수 있다. NUThub는 Nuts들과 함께 작동할 수 있으며, 일정량의 메시지들을 대기행렬로 정리할 수 있다(queue). NUThub는 NUTcloud 및/또는 NUT서버와 원활하게 인터페이싱하여 추가 저장소에 액세스할 수 있다.
NUThub 토폴로지는 여러 가지 방식으로 작동하도록 구성될 수 있다. 직접 토폴로지가 도 158에 도시되어 있으며, 여기서, 사용자의 집에 있는 모든 IoN 기기는 IoN 판매자 서버들(15804), NUThub(15802) 및/또는 사용자 제어 기기들(15806, 15822 및 15824)에 독립적으로 연결할 수 있다. 이 토폴로지는 판매자들이 가정의 기기들에 더 직접 액세스할 수 있게 할 수 있으며, 그리고 사용자는 각각의 기기의 필터링 기능들의 범위까지만 출력되는 Nut 패킷들을 필터링할 수 있다 : 이는 오늘날 IoT 기기들에 의해 사용되는 주된 통신 방법일 수 있다.
바람직한 NUThub 토폴로지는 도 159에 도시된 간접적인 것일 수 있다. 일부 또는 모든 IoN 기기들은 LAN(15920)을 떠난 다음 NUThub(15902)를 횡단하기 전에 지정된 NUT서버 허브(15930)를 통해 통신할 수 있다. 이 토폴로지는 Alice의 컴포트 레벨(comfort level)에 기초하여 Alice의 집을 떠나는 IoN 메시지들에 대한 필터링 규칙들의 미세 조정을 허용할 수 있다. NUT 서버 허브 기기(15930)는 데스크탑 PC, 특수 목적 장치를 포함할 수 있으며, 또는 심지어 WiFi 라우터(15920)의 일부일 수 있다. 지정된 NUT 서버 허브(15930)가 꺼져 있거나 사용할 수 없다면, 외부 세계와 통신할 수 있는 IoN 기기가 없을 수 있다.
NUT서버 허브의 구성은 도 160에 도시되어 있다. 친숙한 NUT 서버(15930) 내에는, NUT 허브/IoN 인터페이스(16032)라는 컴포넌트가 존재할 수 있다. 이 모듈은 NUThub(15903), IoN 기기들(15922) 및/또는 다른 NUT 서버 허브들(16052)과의 통신을 담당할 수 있다. 인터페이스 모듈(16032)은 IoN 장치들 및 IoN 제어 기기들 모두로부터의 IoN Nut 메시지들을 로깅, 큐잉, 포워딩, 중계, 처리 및/또는 필터링할 수 있다.
도 161에는 NUThub/IoN 인터페이스가 보다 상세히 도시되어 있다. 인터페이스(16032)는 이러한 7 가지 기능들 또는 다른 추가 기능들 중 일부 또는 전부를 포함할 수 있다. IoN 기기 인덱스(16112)는 사용자에 의해 등록된 일부 또는 모든 IoN 기기들을 추적할 수 있다. IoN 기기 인증(16114)은 IoN 기기들과의 메시지들을 인증하고 암호화할 수 있다. 인터페이스는 사용자의 메시지 필터들 및 규칙들(16116)을 추적할 수 있다. 메시지 로거(16118)는 일부 또는 모든 IoN 메시지들을 영구 저장소에 로깅할 수 있다. 메시지 대기열(16120)은 전달할 수 없는 메시지들을 일시적으로 저장할 수 있다. 기기 키 캐시(16122)는 IoN 메시지들을 인증하고 암호화하기 위한 일부 또는 모든 액세스 키들을 저장할 수 있으며, 그리고 이는 이용 가능하다면 보호 메모리 하드웨어 내에서 구현될 수 있다. 원격 제어 인터페이스(16124)는 IoN 기기 특정 기능들이 원격으로 활성화될 수 있게 할 수 있는 모듈일 수 있다.
도 162에는 임의의 IoN 기기 상의 NUThub/NUT서버/IoT 인터페이스가 보다 자세히 도시되어 있다. 인터페이스(16210)는 이러한 7 개의 기능들 또는 다른 추가 기능들 중 일부 또는 전부를 포함할 수 있다. Nuts 인덱스(16212)는 IoN 기기들을 운영하고 관리하는 것과 관련된 기기에 저장된 Nut들의 일부 또는 모두를 추적할 수 있다. 인증 모듈(16214)은 기기와의 그리고/또는 기기로부터 판매자, NUThub 및/또는 NUT서버 hub로의 메시지들을 인증하고 암호화할 수 있다. 인터페이스는 사용자의 메시지 필터들 및 규칙들(16216)을 추적할 수 있다. 메시지 로거(16218)는 일부 또는 모든 IoN 메시지들을 영구 저장소에 로깅할 수 있다. 메시지 대기열(16220)은 배달할 수 없는 메시지들을 일시적으로 저장할 수 있다. 기기 키 캐시(16222)는 IoN 메시지들을 인증 및 암호화하기 위해 일부 또는 모든 액세스 키들을 저장할 수 있으며, 그리고 이는 이용 가능하다면 보호 메모리 하드웨어 내에서 구현될 수 있다. 원격 제어 인터페이스(16224)는 IoN 기기 특정 기능들이 원격으로 활성화될 수 있게 할 수 있는 모듈일 수 있다. IoN 기기는 하드웨어 제한으로 인해 사용자 정의 필터링에 대한 제한된 기능 세트를 가질 수 있다. 이는 또한 그것이 로깅 및 큐잉할 수 있는 메시지들의 양을 제한할 수 있는 저장용량 제한을 가질 수 있다. 이에 따라, 히스토리 및 감사 추적이 중요할 수 있다면, 사용자는 도 159에 도시된 바와 같이 간접 IoN 토폴로지를 사용하도록 강력하게 권유될 수 있으며, 이는 사용자가 NUT 서버 허브에 의해 제공될 수 있는 향상된 기능들에 액세스할 수 있게 할 수 있다. 이러한 인터페이스(15922)는 IoN/IoT 특정 기기들에 제한되지 않으며, 임의의 컴퓨팅 기기는 개발자가 그것을 위해 하나 생성할 수 있다면 유사한 인터페이스를 가질 수 있으며, IoN 기기의 동작 모드들을 따른다; 또한, NUT서버 버전이 실행중인 임의의 기기는 IoN 기기로서 작동할 수 있다.
Alice가 IoN 기기를 구입할 때, Alice는 네트워크에 그것을 추가하고 구성해야할 수 있다. 도 163의 흐름도는 그녀의 새로운 IoN 기기를 그녀의 NUTS 기반 네트워크에 적절히 등록하기 위해 Alice가 취할 수 있는 단계들을 도시한다. IoN 기기를 구성하는 방법은 Alice의 NUTbook을 통해 IoN 기기와의 RBK 관계를 설정하는 것일 수 있다. 단계들(16302 및 16304)은 NUT서버 허브가 그녀의 NUTbook에 기기 특정 정보를 중계하도록 허용할 수 있고, 그 다음, NUTbook은 IoN/IoT 기기 카탈로그 카드를 생성하고, 모델, 버전 및/또는 일련 번호를 기입하고, RBK 쌍들을 생성하며, 그리고 그것을 NUT 서버 허브를 통해 IoN 기기로 다시 전송할 수 있다. IoN 기기용 카탈로그 카드를 작성하는 동작은 Nut를 생성하여, 해당 Nut에 대한 Nut ID를 생성할 수 있다; 이에 따라, IoN 기기는 이후 카탈로그 카드 Nut의 Nut ID로 각인될 수 있다. 이 단계는 홈 네트워크에서 새 기기의 IP 주소를 선택하는 것과 비슷할 수 있지만, Nut ID를 사용하면 얻을 수 있는 잠재적 이점이 훨씬 커질 수 있다. 또한, IoN 기기에 대한 할당된 Nut ID는 실제 IP 주소 및/또는 위치와 관계없이 기기를 참조하기 위한 영구적인 방법의 역할을 할 수도 있다. IoN 기기는 공장 상태들로 재설정될 수 있으며, 이로써 새로운 Nut ID는 새 소유자 또는 동일한 소유자에 의해 각인될 수 있다.
IoN 카탈로그 카드가 Alice의 NUTbook에 저장되면, 구성 프로세스는 단계 16306으로 진행할 수 있으며, 그리고 기기의 구성 데이터를 해독하고, 이를 디스플레이하고 그리고/또는 이를 설정하기 위해 필요한 MIO 컴포넌트들이 존재할 수 있는지 확인할 수 있다. 구성 화면에서 적절한 설정이 이루어지면, Alice는 그 기기에 대한 그녀의 IoN 카탈로그 카드에 설정을 저장할 수 있으며, 그것을 NUT 서버 허브 인터페이스에 제출하여 IoN 기기에 전송되게 할 수 있다(16314). 기기는 구성 Nut를 수신할 수 있으며, 이를 인증할 수 있으며, 이를 해독할 수 있으며, 이를 검증한 다음 내부 시스템에 변경사항을 적용할 수 있다. 완료되면, NUT 서버 허브에 그것의 상태를 나타내는 Nut를 되돌려 보낼 수 있다. Alice는 이 기기를 모니터링하고 있을 수 있으며, 그녀는 그것으로부터 메시지들을 자동으로 볼 수 있다.
IoN 기기들은 일부 또는 모든 메시지들이 Nut들일 수 있는 모드에서 작동할 수 있으며, 이에 따라 기본적으로 Nut들과 동일한 수준의 프라이버시 및 제어를 제공받을 수 있다. Nut들이 MIO 컴포넌트들을 사용할 수 있기 때문에, 기기들에 대한 소프트웨어 구성, 펌웨어 및/또는 소프트웨어 업데이트들은 동일한 MIOR 메커니즘을 통해 제출될 수 있으며, 그리고 구식이 될 가능성이 낮을 수 있다. NUThub는, 필요하다면 모든 것이 사용자에 의해 모니터링되고, 로깅되고 그리고/또는 제어될 수 있다는 것과, 그리고 IoN에 의해 수집될 수 있는 일부 또는 모든 출력 정보가 사용자의 프라이버시 선호를 존중하기 위해 필터링될 수 있다는 것을 사용자에게 보장하도록 구성될 수 있다. 이 실시예에서, NUTS 핵심 철학은 물리적 기기들로 확장될 수 있으며, 이로써, 귀하가 소유하고 있는 기기는 일부 또는 모든 시간에 귀하의 통제 하에 있을 수 있으며, 그리고 생성할 수 있는 일부 또는 모든 데이터 또한 귀하의 것일 수 있다. 이 시나리오에서 MIO 및 그것의 기능들의 능력은 명백할 수 있다. 왜냐하면, 적절한 MIO 컴포넌트가 있는 임의의 데이터 형식이 많은 독점 프로토콜들과는 달리 사용자에 의해 검사될 수 있기 때문이다.
이는 우리를 16124 및 16224로 도시된 원격 제어 인터페이스라고 불리는 중요한 모듈로 이끌 수 있다. 이는 사용자 또는 판매자가 IoN/IoT 기기와 대화할 수 있게 하고, 그리고 이것이 명령 Nut들(Command Nuts)이라고 하는 명령에서 원격으로 작동하게 할 수 있는 방법일 수 있다. RBK 인증 명령 Nut들이 처리될 수 있고, 그리고 기기 소유자(RAT)는 그것에서 사용 가능한 임의의 명령을 실행할 수 있다. 이러한 인증 요구사항은 사용자가 판매자의 액세스 권한을 조정함으로써 판매자와의 관계를 완전히 제어할 수 있게 할 수 있다. 사용자는 기기 판매자가 그것에 대한 전체 액세스 권한을 가질 수 있게 할 수 있고, 하위 액세스 권한을 가질 수 있게 할 수 있고, 그리고/또는 액세스 권한을 가질 수 없게 할 수 있다. 이는 IoN/IoT 기기들을 진입점으로 사용하는 Alice의 홈 네트워크에 대한 무단 액세스를 방지할 수 있다 : 각각의 IoN/IoT 액세스 포인트는 이제 NUTS 기반 보안으로 강화될 수 있다. Nut들이 전파되고 인트라넷 및/또는 인터넷을 통해 전송될 수 있는 방법의 광범위한 특성을 언급했으므로, 기본적으로 IoN 명령 Nut는 IoN 기기에 대한 적절한 경로가 있을 수 있는 곳으로부터 발송될 수 있다. 도 164의 흐름도는 원격 제어 인터페이스가 명령 Nut들을 처리할 수 있는 방법을 도시한다.
NUThub 및 그것의 원격 제어 인터페이스의 특성상, Alice는 연결이 존재할 수 있는 모든 곳에서 Alice의 NUTS 호환 기기들의 일부 또는 전부를 완벽하게 제어할 수 있다. 이는 RBK 쌍으로 표현되는 Alice의 NUTbook 관계들에 의해 제어되는 동안 사용자 지정 메시지들이 발송되게 하는 보안 프로토콜을 제시할 수 있다. 이는 Alice를 위해 Alice의 모든 IoN 기기들에 대한 중앙 집중식 보기(centralized view)를 제시할 수 있지만, 분산 방식으로 설치, 구성 및/또는 유지될 수 있다. Alice가 Nut들을 제어하면, Alice는 그녀의 기기들 일부 또는 전부를 제어할 수 있다. 이는 Alice가 NUTS의 SSO 기능을 사용하기로 결정했을 때 Alice가 패스프레이즈를 매우 신중하게 선택하거나 또는 하드웨어 기반 키를 사용해야하는 또 다른 이유일 수 있다. 이러한 실시예들에서, 판매자의 역할은 Alice의 집의 개인 영역에 위치할 수 있고 Alice에 속하는 개인 기기의 초대받지 않은 원격 관리자의 역할이 아니라, 하드웨어 제조업체의 역할로 축소될 수 있다. NUTS 환경의 보안은 제조업체의(개발자의) 선호도 및/또는 이점들에 편향될 수 있는 현재의 IoT 프로토콜보다 더 통일되고, 강화되고 그리고/또는 사용자 제어 가능한 장벽을 제시할 수 있다.
NUTS 기반 서비스들 : NUTS 인증 서버
NUT 서버 프로세스들 및 프로토콜들의 무결성은 그것이 예상대로 동작할 수 있다는 것을 신뢰하는데 필수적일 수 있으므로, NUT 서버 설치를 지속적으로 검증하는 NUTS 인증 서버(NUTS Certification Server; NCS)가 존재할 수 있다. 도 165에 도시된 바와 같이, NCS는 임의의 NUTS 사용자가 이용할 수 있고, 그리고 익명 등록, 쌍으로의 랜덤 별칭들 및/또는 RBK들을 지원할 수 있다. 이는 계층화된 서비스 레벨을 가질 수 있으며, 이 때, 최상위 레벨은 NCS 회사의 공식 인증이며 "NUTS 인증"이다. NCS의 메인 기능들은 Nut들의 적절한 삭제를 위해 NUT서버들을 모니터링하고 그리고/또는 NUT서버 프로토콜들, 동작들 및/또는 프로세스들을 사용하여 무단 변조(unauthorized tampering)를 감지하는 것일 수 있다. 영리한 프로그래머들이 프로브들을 식별할 수 있고 그것을 우회(circumventing)할 수 있기 때문에, 익명 등록 작업 방식의 아키텍처는 NUT서버들로의 NCS 프로브들이 사실상 감지되지 않도록 할 수 있다. 이는 사용자가 NUT 서버들에서 활성화하도록 선택할 수 있는 자발적 서비스 레벨일 수 있다. 타겟 NUT서버에 테스트 Nut들을 주입하기 위해 그리고 NUT서버 프로토콜들에 따라 특정 동작들이 적용되었을 수 있는지 감지하기 위해 NCS에 의해 개시되는 자동화된 절차들이 존재할 수 있다. 높은 수준의 서비스에서, 테스터들의 적극적인 참여는 원격 NUT서버의 상태에 대한 보다 철저한 평가를 가능하게 할 수 있다.
판매자들은 고객들에게 알려질 수 있는 NUT 서버 준수 수준을 지속적으로 유지하고 그들의 Nut들이 적절하게 처리될 수 있음을 보장하기 위해 NUTS 인증 레벨 테스트에 가입할 수 있다. 또한, 테스트 프로세스는 고객에게 알려지지 않은 클라이언트의 NUTS 환경에 대한 무단 변경을 강조 표시할 수 있다. 고객 측에서, NUTS 시스템들 및 방법론들을 사용하고 있을 수 있지만 "NUTS 인증"이 아닐 수 있는 판매자는 Nut들을 처리 정책에 대해 더 많은 문의들을 요구할 수 있다. 사용자들은, 온라인 판매자와의 협업에 앞서 그들의 인증 상태 또는 그것의 부족을 평가하기 위해, NUT서버들 및/또는 NUTbook들이 공개적으로 사용할 수 있는 NCS 데이터베이스 상의 룩업 테이블과 상호작용하도록 구성할 수 있다.
도 166에서, NCS(16520)는 원격 판매자 NUT 서버들(또는 개인 NUT 서버들)(16620-16624)의 행동을 평가할 수 있게 할 수 있는 기능들을 수행할 수 있다. 만료 무결성 프로빙(expiration integrity probing)(16602)은 Nut들이 시스템에 주입될 수 있고(16604) 그리고 만료 시간 후에 그 시스템 상에 존재하기 위해 원격 제어 인터페이스(16610)에 의해 프로빙될 수 있는 방법일 수 있다. 예를 들어, 원격 NUT서버에서 만료된 Nut들이 발견되면, NUT서버는 규격을 벗어날 수 있으며(out of compliance) 그리고 "NUTS 인증"이 아닐 수 있다. 장시간 주입 테스트(16608)는 NUT서버들을 더 오랜 시간 동안 그리고 지속적으로 테스트할 수 있다. 결과 분석 및 인증(16606)은 다양한 주입 테스트들에 대한 원격 NUT 서버들의 준수(adherence)를 평가할 수 있으며, 그리고 NUT 서버 설치의 등급을 정할 수 있다(grading). 설치된 NUT서버들의 버전 및 패치 버전을 확인하는 것은 NUT 서버들이 업데이트되고 규제를 준수할 수 있는지 확인하는데 필수적일 수 있다. 오래된 버전은 NUTS 보안 프로토콜들의 느슨한 유지관리 및/또는 승인되지 않은 사용자 지정 수정들이 이루어졌을 수 있으므로 채용(aoption)이 느려질 수 있음을 나타낼 수 있다. 또한, 테스팅은 다양한 민감한 이진 코드 세그먼트의 해시 서명들을 확인하는 것 그리고/또는 익명의 인터넷 주소에서 주입을 포함할 수 있지만 이에 국한되지는 않는다. NUT서버를 NCS 서비스에 익명으로 등록하면 RBK들이 보다 안전한 방식으로 더 심층적인 테스트를 위해 설정될 수 있다.
충분한 지식과 자원으로 임의의 사람 또는 그룹이 NCS에 의한 테스팅을 결국 우회할 수 있기 때문에, NCS는 NUT 서버가 손상되지 않았을 수 있음을 보장하지 않을 수 있다. 현장 검사를 통해 NUTS 인증 수준이 높아질 수 있다. 평균적인 사용자의 경우, 최상위 레벨에서 인증되지 않았을 수 있는 임의의 상업용 NUT 서버를 사용하지 않는 것이 좋을 수 있다. 개인 NUT 서버들을 사용하는 경우, NCS로부터의 기본 수준의 자동 무료 테스팅은 그것을 사용하기 전에 최소한의 요구사항일 수 있다.
WiFi/이더넷 라우터를 위한 NUTS 기반 네트워킹
도 167은 개인용 NUTS 기반 WiFi/이더넷 라우터(16710)에 대한 네트워크 레이아웃의 실시예를 도시한다. 라우터는 WiFi 통신과 관련된 일반 프로토콜을 사용하여 작동할 수 있을 뿐만 아니라 Nuts 기반 메시징을 대체 프로토콜로서 사용할 수도 있다. NUTS WiFi 라우터는 임의의 IoN 기기와 마찬가지로 설치 및 구성될 수 있으며, 이에 의해, 소유자는 그와 RBK 관계를 설정하고 NUTbook을 통해 IoN 카탈로그 카드에 정보를 저장할 수 있다. 구성 프로세스 동안, 사용자는 카탈로그 카드 항목들에 의해 표시되는 기기들의 대부분을 가질 수 있으므로, Nut ID들에 의해 라우터에서 액세스를 허용하기를 원할 수 있는 일부 또는 모든 기기들을 등록할 수 있다. 발신 Nut 메시지들은 송신 기기의 Nut ID를 포함할 수 있으며, 이에 따라, 액세스를 위해 등록 목록에 대해 적절히 조사될 수 있다. 그 다음, 라우터는 다양한 기기들과 그 자체 사이의 관계들을 설정하도록 지시받을 수 있으며, 따라서, Nut 메시지들의 내용들에 대한 보안 통신을 허용할 수 있다. NUTS WiFi 라우터에서 메시지들을 처리하기 위한 순서도는 도 168에 도시되어 있다. 등록된 기기들에 의해 라우터를 통과할 수 있는 일부 또는 모든 메시지들은 인증될 수 있다. 단계 16818는 NUTS 기반 라우터들에서 이용 가능할 수 있는 흥미로운 특징을 보여준다. 등록되지 않은 기기는 RBK들을 사용하지 않는 액세스를 위해 라우터에 연결할 수 있다. 이것이 발생할 때, 다음과 같은 Wi-Fi 액세스들의 상이한 카테고리들에 대한 대역폭 할당 및 제한사항에 대한 소유자 지정 구성 설정을 조회할 수 있다 : 등록됨, IoT 및/또는 게스트. 등록된 기기들은 요청된 사용 및 대역폭의 유형에 제한 없이 설정될 수 있다. IoT/IoN 기기들은 자체 카테고리를 가질 수 있으며, 그리고 등록된 기기들과 동일한 레벨의 인증을 필요로 할 수 있지만 그룹으로 별도 관리될 수 있다. 도 169의 표는 정의된 카테고리들 그리고 그들이 라우터를 통해 가질 수 있는 액세스 유형을 도시한다. 게스트 기기들에는 일반적인 프로토콜들을 사용하지만 제한이 있는 액세스 권한이 주어질 수 있다. 카테고리 기반 속성 한계들에 대한 예시적인 구성이 도 170에 도시된다. 소유자는 만료, 대역폭, 총 대역폭, 카테고리 유형의 최대 연결들, 목적지들 및/또는 메시지 모드들과 같은(그러나 이에 국한되지 않음) 기기별 제한들을 지정할 수 있다. 이러한 방식으로, 게스트 기기들은 특정 제한 사항들 내에서 알 수 없는 NUTS WiFi 라우터를 통해 인터넷에 액세스할 수 있지만, 인증된 NUTS 인트라넷은 NUTS 레벨 보안 방법들에 의해 보호될 수 있다. 이 방법론은 사실상 WiFi 통신의 프레임 워크 내에서 별도로 관리 가능한 채널 카테고리들을 생성할 수 있다.
사용자의 일부 또는 모든 등록된 기기들은 이제 식별을 위해 내부적으로 할당된 IP 주소들과 독립적일 수 있지만 카탈로그 카드의 Nut ID들에 따를 수 있다. 이는 일부 네트워크 또는 모든 네트워크에서 데이터 및 하드웨어를 보다 보편적인 방식으로 더 실체적이고(tangible) 기능적으로 만들 수 있는 NUTS의 속성일 수 있다. 라우터는 등록된 기기들의 Nut ID들에 대해 매핑된 동적 IP 주소 할당들을 추적할 수 있다. 장래의 반복들 및 다른 실시예들에서, 하드웨어 제조사들은 다양한 기기들의 이더넷 인터페이스들에 액세스하기 위해 IP 주소들 및/또는 MAC 주소들과 함께 Nut ID들이 사용될 수 있게 할 수 있다. Nut ID들을 식별하는 기기는 PC의 OS 설치에 시스템 이름을 할당하는 것과 동일하다고 생각될 수 있지만, 이는 체계적이고 실질적으로 고유할 수 있으며, 따라서, 이더넷 카드를 변경하거나 이더넷 카드를 시스템에 추가하는 것은 새로운 IP 주소들 및/또는 MAC 주소들을 제시할 수 있지만, 이는 기기와 관련된 Nut ID를 변경하지 않을 수 있다.
자녀의 인터넷 액세스에 대한 부모 감독은 기기 및 사용자 레벨에서가 아니라 또는 기기 및 사용자 레벨에 추가하여 NUTS 기반 WiFi 라우터를 사용하여 라우터 레벨에서 모니터링되고 제한될 수 있다. 등록된 기기 트래픽을 엔벨로프(enveloping)할 수 있는 메시지 Nut은 부모의 선호도에 의해 트래픽을 더 필터링하는데 사용될 수 있는 사용자 식별 정보를 포함할 수 있다.
Nuts를 이용한 애플리케이션 래핑(Application Wrapping with Nuts)
클라우드 서비스들, 앱 스토어 및/또는 관련 앱들의 출현 및 개발은 다양한 기기들에서 애플리케이션들의 모듈화 및/또는 이동성(transferability)의 일부 형태를 허용하였을 수 있다. 그러나, 테스크톱 또는 랩탑 컴퓨터들의 경우 그렇지 않을 수 있다. 그것들 상에서 실행할 수 있는 대부분의 애플리케이션들은 수동 설치 및/또는 유지 관리를 필요로 할 수 있다. 이는 기계 설정을 쉽게 하기 위해 시스템 관리자에 의해 사전 선택된 애플리케이션 패키지들이 사용자 설치 팩(custom install pack)으로 롤업될 수 있는 잘 관리된 제도적 환경(institutional environment)의 경우에도 마찬가지일 수 있다. 또는, 그들은 컴퓨터들로 스워핑(swapping)될 수 있는 복제된 사전 설치된 애플리케이션들을 디스크에 생성할 수 있다. 실행 환경의 경우, 개인들 및/또는 관리자들이 특정 기기에 설치될 수 있는 모든 프로그램을 모니터링하고 권한을 부여하는 것이 매우 어렵고 힘들 수 있다. 매우 엄격한 계정 규칙들은 사용자의 생산성 저하 또는 시스템 부서의 인력 요구 증가로 이어질 수 있다.
잘 구성된 Nut에 래핑된 애플리케이션은 이러한 많은 문제들을 해결할 수 있다. Nut 래핑된 애플리케이션들만 실행되도록 로컬 운영 체제가 수정될 수 있다. 그 영향은 여러 가지 일 수 있다. 이렇게 하면 승인되지 않고 검사되지 않은 애플리케이션들의 승인되지 않은 설치들 및 실행들의 일부 또는 전부를 방지할 수 있다. 정책들은 관리되는 제도적 환경에서 액세스 키들의 중앙 집중식 관리에 의해 시행될 수 있다. 무방비 상태인 바이너리(naked binary)의 실행을 포함할 수 있는 바이러스 감염 벡터들은 크게 감소될 수 있다. NUT서버 복제 및 동기화 기능들은 일부 또는 모든 기기들에서 최신 버전의 설치된 소프트웨어를 쉽게 전파할 수 있다. 적절하게 래핑된 Nut들은 성공적인 동기화시 원격 제어 인터페이스를 사용하여 자동으로 설치하도록 원격으로 명령을 받을 수 있다. 도 171에 도시된 바와 같이 NUT서버들을 사용하여 기기 환경 백업 및 복제가 자동화될 수 있다. 컴퓨팅 기기(17100)는 실패했을 수 있는 기기에 대한 Nuts의 백업을 저장할 수 있다. 새 기기(17140)를 설치할 준비가 완료되면, 올바르게 설치되어야할 필요가 있을 수 있는 애플리케이션은 NUT 서버(17144) 및 그것의 액세스 키들일 수 있다. 그 다음, 올바른 키들을 가진 컴퓨팅 기기들로부터의 복제 명령은 기기 1에서 기기 2로의 일부 또는 모든 관련 Nut들의 복제를 개시할 수 있으며, 그 다음, 일부 또는 모든 Nut 래핑된 애플리케이션들의 필요한 설치를 수행할 수 있다.
표면적으로, 이 방법은 하드 드라이브를 복제하거나 잘 조달된(well procured) 설치 스크립트를 갖는 것과 그렇게 다르지 않을 수 있지만 몇 가지 중요한 차이가 있을 수 있다. Nut 래핑된 애플리케이션은 특정 바이너리 그 자체가 아니라 애플리케이션의 스펙일 수 있다. 바이너리는 기관 MIOR(institutional MIOR)에 저장될 수 있으며, 그 다음, MIO 메커니즘들은 Nut 래핑된 애플리케이션 스펙의 개방 프로세스(opening process) 동안 인계받아, 그것이 대체할 수 있는 원래 기기와 동일하거나 동일하지 않을 수 있는 기기의 현재 운영 체제에 대한 올바른 버전의 애플리케이션을 가져올 수 있다. 이러한 MIOR 사용은 이기종(heterogeneous) 운영 체제 및/또는 하드웨어를 포함하는 컴퓨팅 환경에서 애플리케이션 버전을 제어하는 방법일 수 있다. 실제로, NUTS 기술을 사용하면 이러한 프로세스들 중 일부 똔느 전부가 인터넷의 어느 곳에서나 발생할 수 있게 할 수 있으며, 이에 따라, 새로운 기계들은 원격 방식으로 기관을 대신하여 설치 및 유지 관리될 수 있다.
예를 들어, 1주일간 도로 여행 중에 영업사원이 랩탑을 도난당했을 수 있으며, 그의 랩탑에는 그가 클라이언트 미팅 때 사용하길 원할 수 있는 20 개의 고객 맞춤형 프리젠테이션과 기밀 클라이언트 보고서들이 포함되었을 수 있다. 회사에서 NUTS를 사용 중이었다고 가정하면, 영업사원은 가장 가까운 컴퓨터 상점에 가서 시스템 관리자의 안내에 따라 교체용 노트북을 구입할 수 있다. 그 다음, 그는 그 랩탑에 인터넷으로부터 다운로드된 표준 NUT서버를 설치할 수 있다. 관리자는 이메일을 통해 Genesis Nut라 불리는 특수하게 인코딩된 액세스/설치 Nut를 그에게 발송할 수 있으며, 영업사원은 웹 브라우저 기반 회사 이메일 페이지로부터 그의 새로운 랩탑에 이러한 Genesis Nut를 다운로드할 수 있다. 관리자는 영업사원을 호출하고 그에게 Genesis Nut의 잠금을 해제할 수 있는 비밀 패스프레이즈를 알려줄 수 있다. 로컬 NUT서버/NUT브라우저를 사용하여 잠금을 해제하면, Genesis Nut는 인터넷을 통해 필요한 일부 또는 모든 프로세스를 시작하여, 영업사원이 분실한 랩탑에서 회사 서버들과의 가장 최근 동기화로부터 애플리케이션들과 데이터를 복제할 수 있다. 백업에 있는 데이터의 양에 따라 몇 분에서 몇 시간 만에, 영업사원은 자신의 연락처, 애플리케이션 및/또는 데이터 Nut들 일부 또는 전부를 새 랩탑에 재설치하여 이들을 완전히 가동할 수 있으며, 이는 기업 MIOR가 제대로 시드되고(seeding) 유지 관리되는 한 서로 다른 브랜드의 랩톱들과 서로 다른 운영 체제들에서 수행될 수 있다. 이 복사 작업과 병행하여, 관리자는 도둑이 인터넷에 연결하여 랩탑을 구동하는 경우를 대비해 도난당한 랩탑에 저장된 회사 소유의 Nut들의 일부 또는 전부에 대한 자체 삭제 명령들을 도난당한 랩탑에 발송할 수 있다. 랩탑에 있는 Nut들이 이미 회사 Nut 만료 정책들로 개별적으로 보호되어있을 수 있으므로 이는 사전 예방 조치일 수 있다.
다른 실시예에서, 하드웨어 내장된 NUT서버는 액세스 가능한 소스 NUT서버들 및 MIOR 서버들이 있는 네트워크에 연결할 수 있는 초기화되지 않은 컴퓨팅 기기에 통합될 수 있다. Genesis Nut는 기기 상에 로딩되어 액세스 될 수 있으며, OS, 드라이버, 애플리케이션, 애플리케이션 구성 데이터 및/또는 사용자 데이터를 포함하는 이러한 초기화되지 않은 컴퓨팅 기기 상으로의 컴퓨팅 환경의 완전한 설치를 유도할 수 있는 프로세스들을 개시할 수 있다. OS의 선택은 액세스 가능한 MIOR 캐시들의 기기 및 컨텐츠들을 조사할 때 사용자에게 맡겨질 수 있다. 애플리케이션들은 사용자가 상이한 Nut들에 액세스함에 따라 점진적으로 설치되거나, 또는 사용자의 Nut들에 액세스하기 위해 필요한 애플리케이션들의 전체 목록에 대해 소스 NUT서버를 쿼리함으로써 한번에 모두 설치될 수 있다.
이벤트 처리 서비스(Event Processing Service; EPS)
NUThub는 IoN/IoT 기기들 및 NUT서버들과의 Nut 기반 통신들을 허용할 수 있다. 이벤트 처리 서비스(Event Processing Service; EPS)는 도 172에 도시된 바와 같이 이벤트를 생성하거나 이에 반응하기를 원할 수 있는 IoN 기기들 및 애플리케이션들에 의해 생성될 수 있는 이벤트들을 보관하기 위한 조정자(coordinator)로 작동할 수 있다. 일부 또는 모든 이벤트들이 Nut들에 포함될 수 있기 때문에, 기기들 간에 횡단할 수 있는 경로(traversable route)가 존재할 수 있는 한 임의의 이벤트가 임의의 네트워크를 통해 전달될 수 있다. 이는 사용자가 로컬 및 원격 IoN/IoT 기기들 및/또는 NUT 서버 시스템들에서 원하는 이벤트들을 모니터링할 수 있게 할 수 있다. 이는 사용자가 로컬 및/또는 원격 기기들에서 스케쥴링된 이벤트들이나 임시(adhoc) 이벤트들을 트리거할 수 있게 할 수 있다. 이벤트들은 원하는 경우 일부 또는 모든 사용자 기기들에 복제될 수 있다. EPS는 원격 제어 인터페이스와 함께 작동하여, 기기별 명령들이 이벤트들에 기초하여 개시되도록 허용할 수 있다. 도 172는 기기(17200) 상의 로컬 캘린더 애플리케이션(17208)이 기기(17210) 상의 NUT서버(17212)에 의해 도달될 수 있는 IoN 기기(17220)상에서 실행될 시간 지정된 이벤트를 로컬 EPS(17204)를 통해 트리거할 수 있는 시나리오를 구현한다. 로컬 EPS(17204)는 타겟 IoN 기기(17220)에 액세스할 수 있는 다른 EPS(17214)에 상기 이벤트를 중계할 수 있다. 그 다음, EPS(17214)는 그 이벤트/명령을 그것의 로컬 NUT서버(17212)에 중계할 수 있고, 그 다음, 로컬 NUT서버(17212)는 그것의 IoN/IoT 인터페이스를 사용하여 이벤트/명령 Nut를 IoN 기기(17220)에 전달할 수 있다. 이벤트/명령 Nut를 수신하면, IoN 기기(17220)는 명령을 인증할 수 있으며, 그 다음 그것의 원격 제어 인터페이스를 통해 명령을 실행할 수 있다. 그러한 이벤트들의 예들은, 스케쥴에 따라 원격 서버들을 구동하는 것, 스케쥴에 따라 이메일을 발송하는 것, 시스템 상태들과 관련된 채팅 메시지들을 발송하는 것, 아침에 IoN 호환 커피 기계에서 커피를 내리는 것, 스마트 서모스탯의 온도 설정을 변경하는 것 그리고/또는 추운 겨울 아침에 커피 내리는 것이 끝나고 20분 후에 자동차를 예열하는 것과 같이(그러나 이에 국한되지는 않음) 다양할 수 있다.
EPS는, 이벤트 Nut 저장소 영역(17216 및 17206)에, 실행중일 수 있는 각 기기에서 수신되고 생성되었을 수 있는 과거 이벤트를 저장할 수 있다. 이는 통신 및 기기 실패에 대한 이벤트 대기열뿐만 아니라 이벤트 저장소로도 작용할 수 있다. 사용자 및 관리자는 나중에 이러한 이벤트들을 검색할 수 있으며, 그 이후 어떤 사용을 위해 그것을 분석할 수 있다. NUTcloud 계정을 가진 사용자는 그녀의 이벤트들이 복제되게 할 수 있으며, 이로써, 이벤트들은 임의의 인터넷 액세스에서 볼 수 있다. 일부 또는 모든 이벤트들은 Nut로 보호될 수 있으며, 사용자에 의해 소유될 수 있다. NUThub는 EPS의 대기열 기능(queuing capability)을 활용하기 위해 그것과 원활하게 인터페이싱할 수 있다.
EPS 및 보관소를 이용하는 애플리케이션의 예는 가정용 알람 시스템이 배터리로 동작되는 센서들 중 일부의 배터리 충전량이 적을 수 있다고 경고하기 시작할 때일 수 있다. 가정용 알람 시스템은 관여될 수 있는 유닛을 지정하는 배터리 부족 이벤트를 생성할 수 있으며, 그리고 알람 유지관리 회사와 업무 통화(service call)를 요청할 수 있다. 알람 회사는 이메일을 통해 사용자에게 문제를 서비스할 수 있는 다양한 시간을 제안할 수 있으며, 그리고 사용자는 상이한 시간 제안을 하거나 그들이 제안한 시간을 수락할 수 있다. 수락하면, 알람 회사와 사용자 기기들상의 캘린더들은 모두 약속 정보로 자동으로 업데이트될 수 있다. 알람 시스템은 알람 회사와의 제한된 RBK 관계를 가질 수 있으며, 이에 따라, 주택 소유자의 암묵적인 승인으로 안전하게 진단할 수 있다.
애플리케이션 Nut들을 가진 상황 인식 컴퓨팅(Contextual Computing with App Nuts)
검색 습관, 검색 히스토리, 기기 스펙, 웹 시청 습관, 쇼핑 경향, 블로그 콘텐츠, 소셜 네트워크, 비즈니스 네트워크, 이메일 컨텐츠, 문자 메시지, 사진 및/또는 심지어는 그것들의 DNA의 디지털화된 분석과 같은(그러나 이에 국한되지는 않음) 웹 회사들에 의한 사용자의 디지털 파편(digital detritus)의 일부 또는 모든 측면들에 대한 태연한 영토 침해(unabashed land grab)가 존재할 수 있다. 이러한 사용자 생성 데이터의 압도적인 다수는 데이터를 생성했을 수 있는 사용자에 의해 소유, 액세스, 검토, 변경, 삭제 및/또는 제어될 수 없다. NUTS 기술을 사용하면, 애플리케이션 개발자는 사용자 생성 데이터를 더 쉽게 생성할 수 있으며, 그리고 사용자의 사용 및 보관을 위해 사용자에게 사본을 제공하는 것이 쉬워질 수 있다. 그것은 사용자 정의(customization)를 허용하기 위해 MIO를 통해 컨텐츠 포맷들에 따라 다를 수 있는 공통 보안 컨테이너를 제공할 수 있다. 사용자의 디지털 풋 프린트의 대부분을 커버할 만큼 충분히 일반적인 웹 서비스 판매자들은 극히 소수이다; 예를 들어, Amazon은 당신의 쇼핑 선호도(shopping preference)들 중 일부만 알 수 있으며, Google은 당신의 검색 기록 중 일부만 알고 있을 수 있다. 따라서, 웹 판매자들은 일반적으로 그들이 제공하는 서비스에 기초하여 사람의 습관들의 부분적 슬라이스들을 조합할 수 있다. 사용자의 디지털 소재 및 활동들의 일부 또는 모두를 수집하는 가장 유리한 지점은 사용자에 의한 사용자를 위한 것일 수 있다. 판매자 및 사용자 애플리케이션에 대한 전형적인 네트워크 레이아웃은 도 173에 도시되어 있는데, 여기서, 판매자는 로컬 브라우즈 기반 쿠키들을 사용하여 사용자 또는 그의 현재 세션을 태깅(tagging)할 수 있으며, 그리고 빅 데이터 수집 서버들을 사용하여 애플리케이션들로부터의 그리고 애플리케이션 상의 일부 또는 모든 활동들을 기록할 수 있다.
사용자가 그들의 자체 보관 및 사용을 위해 Nut에서 그들의 세션들의 전체 기록을 제공할 수 있는 애플리케이션들과 인터페이싱한다면, 사용자는 결국 도 174에서 도시된 바와 같이 그녀의 디지털 여행(digital excursions)의 다양한 측면들을 수집할 수 있게 된다. 이러한 세션 히스토리들은 도 175에 도시된 바와 같이 사용자에게 더 많은 편의들을 제공하기 위해 컨텍스트에 민감한 애플리케이션들에 의해 분석이 수행될 수 있는 컨텍스트(context)를 제공할 수 있다. 애플리케이션은 세션 히스토리들을 App Nut(17414)에 저장할 수 있으며, 이는 결국 사용자가 설치했을 수 있는 일부 또는 모든 다른 애플리케이션들에 의해 사용되어, 사용자에게 적절하게 도움을 줄 수 있다. 상황에 대한 적절한 분석은 사용자가 달성하고자 할 수 있는 작업의 본질을 이끌어낼 수 있다. 회계 애플리케이션(17524)은 사용자가 수행했을 수 있는 청구서 지불 및 당좌 예금 계좌 활동들의 일부 또는 전부에 대해 그것의 세션들을 애플리케이션 Nut(17414)에 기록할 수 있다. 이러한 세션 히스토리를 판독할 수 있는 패턴 인식 애플리케이션(17520)은 이를 분석할 수 있고 그리고 매월 청구서를 지불하기 위해 취해진 과거 단계들을 추천할 수 있고, 그리고 사용자 대신 수행할 수 있는 작업들의 미리보기를 제공할 수 있다. 사용자가 그 분석에 동의하면, 사용자 이름 하의 다양한 계정들을 사용하여 관련 청구서들의 일부 또는 전부를 자동으로 지불하기 위해 이러한 단계들을 실행할 수 있다. 이러한 애플리케이션 Nut는, 사용자가 NUTcloud(17500)를 통해 그녀의 Nut들을 동기화하면, 인터넷을 통해 사용자가 이용할 수 있다.
애플리케이션 Nut들에 의해 저장되는 컨텍스트(context)의 또 다른 유용한 측면은 반복 가능한 절차들의 측면일 수 있다. 이는 개발자들이 선호할 수 있는 CLI(command line interface)들 간의 공통적인 특징일 수 있으며, 여기서, 이전 명령들은 필요에 따른 옵션의 재실행을 위해 저장될 수 있다. 애플리케이션 Nut들은 거의 모든 호환되는 애플리케이션에서 사용자의 요구에 따라 동일한 유형의 절차 리콜들(procedural recalls)을 제공할 수 있다. 여행 애플리케이션을 저장하는 컨텍스트는 사용자에 의한 웹상에서의 초기 검색 후에 app Nut에서 제안되는 여행에 대한 요구사항들의 본질을 제공할 수 있다. 나중에, 사용자는 컨텍스트에 민감한 여행 검색 애플리케이션(context sensitive travel search)을 사용하여 그것들에 대한 증류된 요구사항들(distilled requirements)을 다시 실행함으로써 그녀의 바람직한 여행 아울렛(travel outlet) 중 일부 또는 모두에 대한 검색을 자동으로 재개할 수 있다. 이를 통해 각 여행 웹사이트들에서 다양한 양식들을 다시 입력하는데 소요되는 시간을 줄일 수 있고, 그녀의 옵션들 중 일부 또는 모두의 자동 요약을 생성할 수 있다. 뿐만 아니라, 프로세스가 사용자에 의해 완전히 제어될 수 있고 일부 또는 모든 민감한 정보가 그녀의 NUTbook에 의해 저장될 수 있기 때문에, 그녀에게 가장 개인화되고(most personalized) 의미있는 결과를 얻기 위해서, 그녀가 마일리지 특권 및/또는 멤버쉽을 가질 수 있는 판매자들에 대한 질의들은 컨텍스트에 민감한 여행 검색 애플리케이션에 의해 적절히 적용될 수 있다. 사용자가 전적으로 그녀의 민감한 디지털 정보의 일부 또는 전체에 대한 규제가 없는 액세스를 해당 판매자에게 일부 또는 모든 시간에 제공할 수 있고 그것을 완전히 신뢰하지 않는 한, 이러한 유형의 심층 컨텍스트 민감한 검색들은 단일 판매자에 의해 수행되는 것이 사실상 불가능할 수 있다; 이는 평균적인 디지털적으로 민감한 사용자에게 매우 의심스러운 제안일 수 있다.
다른 실시예에서, 도 176은 사용자의 IoN/IoT 기기들 그리고 그녀가 집에서 그녀의 일상생활을 위해 가입할 수 있는 다양한 유틸리티들 및 서비스들에 대한 네트워크 레이아웃을 도시한다. 어떤 단일 회사도 사용자의 전체 가정생활을 디지털 방식으로 수집할 수는 없을 수 있다. 그러나, 사용자의 일부 또는 모든 기기들이 app Nut들을 생성하였고 사용자가 사용자의 다양한 디지털 컨텍스트들을 분석할 수 있는 애플리케이션을 갖는다면 사용자가 이를 수행할 수 있다. 에너지 절약 상황에 민감한 애플리케이션은 사용자 집에 있는 다양한 전자 제품들에 의한 전기 사용을 분석할 수 있으며, 그것을 전기 회사의 피크 및 오프-피크(off-peak) 레이트들과 병합하여, 사용자를 대 신해서 애플리케이션에 의해 자동으로 규정될 수 있는 에너지 절약 조치들을 제안할 수 있다. 각 기기의 개인적인 사용 습관을 분석하여, 과거의 일련의 환경들을 인식할 때 사용자에게 편리한 조합들을 조정할 수 있다. IoN/IoT 기기들은, 주기적으로 실행되는 자가 진단들로 고장난 부품이나 차선의 작동 판독값들이 밝혀지면, 사용자에게 유지보수 요구사항들을 알려줄 수 있다.
기기들의 소유자에 의해서가 아니라 제조업체들 및/또는 잠재적인 불법 해커들에 의해서 전적으로 제어될 수 있는 다양한 환경 센서들을 포함하는 IoT 기기들에 대한 보안 문제가 있을 수 있다. 도 177은 2 개의 IoN 기기들 및 그것들의 각각의 제조업체들의 네트워크 레이아웃의 예를 도시한다. 애플리케이션 Nut들(17734, 17744)이 각각의 IoN 기기(17730, 17740)에 의해 생성될 수 있다면, 로컬 저장소(17724) 내의 NUT 서버(17722)에 의해 국부적으로 보관될 수 있다. 나중에 이러한 보관된 app Nut들은 사용자가 제3자가 수집하기에 부적절하다고 판단하는 민감한 정보를 삭제하기 위해 그것들을 제조업체들에 보내기 전에 사용자에 의해 검토되고 필터링될 수 있다. 도 178에서, 상황 인식 분석 애플리케이션(17808)은 그녀의 프라이버시를 제3자에게 노출시키는 것을 모르는 것을 최소화하기 위해 자신의 IoN/IoT로 생성된 메시지들의 일부 또는 전부에 대한 특수화된 루틴 필터링(specialized routine filtering)을 제공할 수 있다. 이러한 방식으로, 제3자는 각 소유자가 허용할 수 있는 정도까지만 판매되는 각 기기에서 일부 데이터를 수집할 수 있으므로, 그들은 평균 구매자가 그들에게 기꺼이 줄 수 있는 개인 정보가 무엇인지 추론할 수 있다.
결론 및 철학(Conclusion and Philosophy)
상세하게 설명된 다양한 실시예들 및 시나리오 예들은, 데이터가 데이터를 생성한 사용자에게 속하고 사용자가 그러한 데이터의 노출을 정밀하게 제어하는 수단을 가질 수 있다는 핵심 NUTS 철학에 기초할 수 있다. 설계는 대안적인 암호 방법들, 상이한 길이의 키들, 상이한 데이터 변환들 및/또는 상이한 잠금 메커니즘들과 같은(그러나 이에 국한되지는 않음) 변형들 및/또는 대안들을 수용할 만큼 충분히 유연할 수 있다. SDFT는 프로그래머가 가장 낮은 레벨에서 데이터를 변환할 수 있는 유용한 도구 세트를 제공하며, 그리고 구조화된 암호화 프로그래밍이 NUTS 구조들 및 다른 복잡한 암호화 구조들을 구성할 수 있도록 도움을 줄 수 있다. SDFT는 유연하고 일반적인 방식으로 변환 명령들과 쌍을 이루는 데이터의 이식성(portability)을 허용한다. NUTS의 다양한 실시예들은 기존의 조직적인 보안 인프라들에 맞게 커스터마이징될 수 있으며, 또는 단일 사용자를 위한 독립형 설치들일 수 있다. 데이터의 유형성(tangibility)은 NUTS가 제안하는 중요한 철학일 수 있으며, 그리고 사용자가 간단한 방식으로 그들이 생성할 수 있는 데이터를 저장, 조작 및/또는 검토할 수 있는 기능을 구현하는 동시에, 가장 정교한 관리 시스템들에 적합한 특징들을 제공할 수 있다. 결론적으로, NUTS는 개별 사용자들에게 디지털 작품들 및 데이터를 구성하는 현재 방법의 대안을 제공할 수 있다.

Claims (20)

  1. 데이터를 처리하는 방법으로서, 상기 방법은 :
    적어도 하나의 프로세서가, 적어도 하나의 입력 데이터 및 0개 이상의 입력 키들이 제공되는, 하나 이상의 키들을 필요로 하는 암호화 함수를 동작시키는 단계를 포함하며,
    입력 키가 제공되지 않은 암호화 함수는 적절하게 형성된 원래의 키들의 필요한 세트를 생성하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터 및 상기 필요한 적절하게 형성된 키들의 생성된 세트를 생성하고;
    입력 키들의 부분 세트가 제공되는 암호화 함수는 원래의 적절하게 형성된 키들의 필요한 누락 세트를 생성하고 그것들을 논리적 순서로 상기 입력 키들의 부분 세트와 결합하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 암호화해서 적어도 하나의 출력 데이터 및 상기 결합된 키 세트를 생성하고;
    입력 키들의 필요한 세트가 제공되는 암호화 함수는 상기 포워드 모드에서 동작할 때에, 각 입력 키의 구조를 체크하여 필요한 입력 키들의 검증된 세트를 이용하여 상기 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터를 생성하며;
    상기 입력 키들의 필요한 세트가 제공되는 암호화 함수는 리버스 모드에서 동작할 때에, 각 필요한 입력 키들의 구조를 체크하여 상기 필요한 입력 키들의 검증된 세트를 이용하여 상기 적어도 하나의 출력 데이터를 처리해서 상기 적어도 하나의 입력 데이터를 생성하는, 방법.
  2. 제1항에 있어서,
    상기 암호화 함수는 복수의 키들을 필요로 하며, 상기 암호화 함수는 상기 원래의 키들을 미리 정해진 순서로 시퀀싱하는, 방법.
  3. 제1항에 있어서,
    상기 암호화 함수는 복수의 암호화 함수들을 포함하는, 방법.
  4. 데이터를 처리하는 방법으로서, 상기 방법은 :
    적어도 하나의 프로세서가, 적어도 하나의 입력 데이터 및 0개 이상의 입력 키들이 제공되는, 하나 이상의 키들을 필요로 하는 암호화 함수를 동작시키는 단계를 포함하며,
    입력 키가 제공되지 않은 암호화 함수는 적절하게 형성된 원래의 키들의 필요한 세트를 생성하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터 및 상기 필요한 적절하게 형성된 키들의 생성된 세트를 생성하고;
    입력 키들의 부분 세트가 제공되는 암호화 함수는 원래의 적절하게 형성된 키들의 필요한 누락 세트를 생성하고 그것들을 논리적 순서로 상기 입력 키들의 부분 세트와 결합하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 암호화해서 적어도 하나의 출력 데이터 및 상기 결합된 키 세트를 생성하고;
    입력 키들의 필요한 세트가 제공되는 암호화 함수는 상기 포워드 모드에서 동작할 때에, 필요한 입력 키들의 세트를 이용하여 상기 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터를 생성하며;
    상기 입력 키들의 필요한 세트가 제공되는 암호화 함수는 리버스 모드에서 동작할 때에, 상기 필요한 입력 키들의 세트를 이용하여 상기 적어도 하나의 출력 데이터를 처리해서 상기 적어도 하나의 입력 데이터를 생성하는, 방법.
  5. 제4항에 있어서,
    상기 암호화 함수는 포워드 모드에서 동작할 때에, 제공된 입력 키들의 구조를 처리하기 이전에 확인하는, 방법.
  6. 제4항에 있어서,
    상기 암호화 함수는 리버스 모드에서 동작할 때에, 제공된 입력 키의 구조를 처리 이전에 확인하는, 방법.
  7. 제4항에 있어서,
    상기 암호화 함수는 복수의 키들을 필요로 하며, 상기 암호화 함수는 상기 원래의 키들을 미리 정해진 순서로 시퀀싱하는, 방법.
  8. 제4항에 있어서,
    상기 암호화 함수는 복수의 암호화 함수들을 포함하는, 방법.
  9. 데이터 처리 장치로서, 상기 데이터 처리 장치는:
    적어도 하나의 프로세서 및 상기 적어도 하나의 프로세서에 연결된 적어도 하나의 메모리를 포함하며,
    상기 적어도 하나의 프로세서는 상기 메모리에 저장된 암호화 함수를 작동시키며, 상기 암호화 함수는 적어도 하나의 입력 데이터 및 0개 이상의 입력 키들이 제공되는, 하나 이상의 키들을 필요로 하며,
    입력 키가 제공되지 않은 암호화 함수는 적절하게 형성된 원래의 키들의 필요한 세트를 생성하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터 및 상기 필요한 적절하게 형성된 키들의 생성된 세트를 생성하고;
    입력 키들의 부분 세트가 제공되는 암호화 함수는 원래의 적절하게 형성된 키들의 필요한 누락 세트를 생성하고 그것들을 논리적 순서로 상기 입력 키들의 부분 세트와 결합하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 암호화해서 적어도 하나의 출력 데이터 및 상기 결합된 키 세트를 생성하고;
    입력 키들의 필요한 세트가 제공되는 암호화 함수는 상기 포워드 모드에서 동작할 때에, 각 입력 키의 구조를 체크하여 필요한 입력 키들의 검증된 세트를 이용하여 상기 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터를 생성하며;
    상기 입력 키들의 필요한 세트가 제공되는 암호화 함수는 리버스 모드에서 동작할 때에, 각 필요한 입력 키들의 구조를 체크하여 상기 필요한 입력 키들의 검증된 세트를 이용하여 상기 적어도 하나의 출력 데이터를 처리해서 상기 적어도 하나의 입력 데이터를 생성하는, 데이터 처리 장치.
  10. 제9항에 있어서,
    상기 암호화 함수는 복수의 키들을 필요로 하며, 상기 암호화 함수는 상기 원래의 키들을 미리 정해진 순서로 시퀀싱하는, 데이터 처리 장치.
  11. 제9항에 있어서,
    상기 암호화 함수는 복수의 암호화 함수들을 포함하는, 데이터 처리 장치.
  12. 데이터 처리 장치로서, 상기 데이터 처리 장치는:
    적어도 하나의 프로세서 및 상기 적어도 하나의 프로세서에 연결된 적어도 하나의 메모리를 포함하며,
    상기 적어도 하나의 프로세서는 상기 메모리에 저장된 암호화 함수를 작동시키며, 상기 암호화 함수는 적어도 하나의 입력 데이터 및 0개 이상의 입력 키들이 제공되는, 하나 이상의 키들을 필요로 하며,
    입력 키가 제공되지 않은 암호화 함수는 적절하게 형성된 원래의 키들의 필요한 세트를 생성하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터 및 상기 필요한 적절하게 형성된 키들의 생성된 세트를 생성하고;
    입력 키들의 부분 세트가 제공되는 암호화 함수는 원래의 적절하게 형성된 키들의 필요한 누락 세트를 생성하고 그것들을 논리적 순서로 상기 입력 키들의 부분 세트와 결합하는 포워드 모드에서 동작하여, 적어도 하나의 입력 데이터를 암호화해서 적어도 하나의 출력 데이터 및 상기 결합된 키 세트를 생성하고;
    입력 키들의 필요한 세트가 제공되는 암호화 함수는 상기 포워드 모드에서 동작할 때에, 필요한 입력 키들의 세트를 이용하여 상기 적어도 하나의 입력 데이터를 처리해서 적어도 하나의 출력 데이터를 생성하며;
    상기 입력 키들의 필요한 세트가 제공되는 암호화 함수는 리버스 모드에서 동작할 때에, 상기 필요한 입력 키들의 세트를 이용하여 상기 적어도 하나의 출력 데이터를 처리해서 상기 적어도 하나의 입력 데이터를 생성하는, 데이터 처리 장치.
  13. 제12항에 있어서,
    상기 암호화 함수는 포워드 모드에서 동작할 때에, 제공된 입력 키들의 구조를 처리하기 이전에 확인하는, 데이터 처리 장치.
  14. 제12항에 있어서,
    상기 암호화 함수는 리버스 모드에서 동작할 때에, 제공된 입력 키의 구조를 처리 이전에 확인하는, 데이터 처리 장치.
  15. 제12항에 있어서,
    상기 암호화 함수는 복수의 키들을 필요로 하며, 상기 암호화 함수는 상기 원래의 키들을 미리 정해진 순서로 시퀀싱하는, 데이터 처리 장치.
  16. 제12항에 있어서,
    상기 암호화 함수는 복수의 암호화 함수들을 포함하는, 데이터 처리 장치.
  17. 데이터를 폴딩(folding)하는 방법으로서,
    적어도 하나의 프로세서에 의해, 다수의 논리 연산들을 사용하여 적어도 하나의 출력 데이터 객체를 생성하기 위해 적어도 하나의 입력 데이터 객체를 처리하는 단계로서, 상기 데이터 폴딩은 상기 적어도 하나의 입력 데이터 객체 중 동일한 하나의 입력 데이터 객체에 대해 별개의 단계들로 수행되는 다수의 논리 연산들의 전체 시퀀스의 적어도 하나의 본질과 함께, 데이터 구조의 적어도 하나의 데이터 필드의 적어도 하나의 출력 데이터를 캡슐화하며, 상기 다수의 논리 연산들의 전체 시퀀스의 적어도 하나의 본질은 상기 데이터 구조의 적어도 하나의 명령 필드에서 캡슐화되는, 단계; 및
    적어도 하나의 프로세서에 의해, 상기 데이터 구조의 적어도 하나의 명령 필드로부터 상기 다수의 논리 연산들의 전체 시퀀스의 캡슐화된 적어도 하나의 본질을 사용하여 상기 적어도 하나의 입력 데이터 객체 중 동일한 입력 데이터 객체를 생성하기 위해 상기 데이터 구조의 적어도 하나의 데이터 필드로부터 상기 적어도 하나의 출력 데이터 객체를 처리하는 단계를 포함하는, 방법.
  18. 제17항에 있어서,
    상기 다수의 논리 연산들은 변환(transmutation)을 포함하는, 방법.
  19. 제17항에 있어서,
    상기 적어도 하나의 출력 데이터 객체는 컴퓨팅 환경에 저장 가능한, 방법.
  20. 제17항에 있어서,
    상기 적어도 하나의 출력 데이터 객체는 다른 컴퓨터 프로세스에 전송 가능한, 방법.
KR1020227033687A 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장 KR102649209B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020247008644A KR20240038828A (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662395084P 2016-09-15 2016-09-15
US62/395,084 2016-09-15
PCT/US2017/049661 WO2018052726A1 (en) 2016-09-15 2017-08-31 Encrypted userdata transit and storage
KR1020197004510A KR102482406B1 (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020197004510A Division KR102482406B1 (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020247008644A Division KR20240038828A (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장

Publications (2)

Publication Number Publication Date
KR20220137788A true KR20220137788A (ko) 2022-10-12
KR102649209B1 KR102649209B1 (ko) 2024-03-20

Family

ID=61560000

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020227033687A KR102649209B1 (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장
KR1020197004510A KR102482406B1 (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장
KR1020247008644A KR20240038828A (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장

Family Applications After (2)

Application Number Title Priority Date Filing Date
KR1020197004510A KR102482406B1 (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장
KR1020247008644A KR20240038828A (ko) 2016-09-15 2017-08-31 암호화된 사용자 데이터 송신 및 저장

Country Status (14)

Country Link
US (7) US10671764B2 (ko)
EP (1) EP3513298A4 (ko)
JP (2) JP7076819B2 (ko)
KR (3) KR102649209B1 (ko)
CN (2) CN117692170A (ko)
AU (4) AU2017325928C1 (ko)
BR (1) BR112019003128A2 (ko)
CA (1) CA3031531A1 (ko)
CR (1) CR20190075A (ko)
EA (1) EA201990315A1 (ko)
IL (1) IL274473B (ko)
MX (2) MX2019002385A (ko)
TW (3) TW202333054A (ko)
WO (1) WO2018052726A1 (ko)

Families Citing this family (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3377982A4 (en) * 2015-11-18 2019-07-31 Level 3 Communications, LLC SERVICE ACTIVATION SYSTEM
US10374809B1 (en) 2016-12-13 2019-08-06 Amazon Technologies, Inc. Digital signature verification for asynchronous responses
US10887090B2 (en) * 2017-09-22 2021-01-05 Nec Corporation Scalable byzantine fault-tolerant protocol with partial tee support
US10491577B2 (en) * 2017-10-18 2019-11-26 Blue Jeans Network, Inc. Secure, customer-controlled storage for cloud-managed meeting details
US10903997B2 (en) * 2017-10-19 2021-01-26 Autnhive Corporation Generating keys using controlled corruption in computer networks
US11329817B2 (en) * 2017-10-19 2022-05-10 Devi Selva Kumar Vijayanarayanan Protecting data using controlled corruption in computer networks
US10061932B1 (en) * 2018-01-04 2018-08-28 WindTalker, LLC Securing portable data elements between containers in insecure shared memory space
US10817649B2 (en) * 2018-01-09 2020-10-27 Saudi Arabian Oil Comapny Unicode conversion with minimal downtime
US10878036B2 (en) * 2018-01-17 2020-12-29 Actian Corporation Maintaining character set compatibility in database systems
US20190238323A1 (en) * 2018-01-31 2019-08-01 Nutanix, Inc. Key managers for distributed computing systems using key sharing techniques
US10693662B2 (en) * 2018-02-22 2020-06-23 Idlogiq Inc. Methods for secure serialization of supply chain product units
US11088826B2 (en) * 2018-02-27 2021-08-10 International Business Machines Corporation Managing assets with expiration on a blockchain
US11687794B2 (en) * 2018-03-22 2023-06-27 Microsoft Technology Licensing, Llc User-centric artificial intelligence knowledge base
US20190318118A1 (en) * 2018-04-16 2019-10-17 International Business Machines Corporation Secure encrypted document retrieval
CN108959128B (zh) * 2018-06-04 2023-03-31 浙江大学 Crypt-SHA512加密算法的加速装置与方法
EP3591926A1 (en) * 2018-07-03 2020-01-08 Assa Abloy AB Providing connectivity for a plurality of iot devices
CN109086608A (zh) * 2018-07-20 2018-12-25 西安四叶草信息技术有限公司 一种检测文件上传漏洞的方法、终端设备和服务器
US11216592B2 (en) * 2018-08-02 2022-01-04 Qualcomm Incorporated Dynamic cryptographic key expansion
CN110825922B (zh) * 2018-08-14 2020-08-04 阿里巴巴集团控股有限公司 数据统计方法和装置
TWI819072B (zh) * 2018-08-23 2023-10-21 美商阿爾克斯股份有限公司 在網路運算環境中用於避免環路衝突的系統、非暫態電腦可讀取儲存媒體及電腦實現方法
US11119670B2 (en) * 2018-09-14 2021-09-14 SeaPort, Inc. Methods and systems for efficient encoding and decoding communications
US11741196B2 (en) 2018-11-15 2023-08-29 The Research Foundation For The State University Of New York Detecting and preventing exploits of software vulnerability using instruction tags
CN109743287A (zh) * 2018-12-06 2019-05-10 广东电网有限责任公司 一种基于数据隔离的数据重组方法及装置
TWI682296B (zh) * 2018-12-06 2020-01-11 啓碁科技股份有限公司 映像檔打包方法及映像檔打包系統
US11985112B2 (en) * 2018-12-18 2024-05-14 Bae Systems Information And Electronic Systems Integration Inc. Securing data in motion by zero knowledge protocol
KR102570688B1 (ko) * 2018-12-27 2023-08-28 한국전력공사 데이터 보안 장치
US20200210595A1 (en) * 2018-12-30 2020-07-02 Sze Yuen Wong CryptoJSON Indexed Search Systems and Methods
US10389708B1 (en) 2019-01-03 2019-08-20 Capital One Services, Llc Secure authentication of a user associated with communication with a service representative
US20200228505A1 (en) 2019-01-10 2020-07-16 Pango Inc. Private Exchange of Encrypted Data Over A Computer Network
US10937339B2 (en) * 2019-01-10 2021-03-02 Bank Of America Corporation Digital cryptosystem with re-derivable hybrid keys
US11232104B2 (en) * 2019-01-21 2022-01-25 International Business Machines Corporation Join and predicate filtering using string lengths for variable character fields
CN109886048B (zh) * 2019-02-12 2023-01-13 苏州超块链信息科技有限公司 一种基于密码学难度累积的数据一致性保护方法
CN109829719B (zh) * 2019-02-22 2021-06-25 中国农业银行股份有限公司 一种无连接的跨账本DvP结算方法及系统
US11763011B2 (en) 2019-02-25 2023-09-19 Oocl (Infotech) Holdings Limited Zero trust communication system for freight shipping organizations, and methods of use
SG11202109273QA (en) * 2019-02-25 2021-09-29 Oocl Infotech Holdings Ltd Zero trust communication system for freight shipping organizations, and methods of use
US11228434B2 (en) 2019-03-20 2022-01-18 Zettaset, Inc. Data-at-rest encryption and key management in unreliably connected environments
CA3058236C (en) 2019-03-27 2020-08-25 Alibaba Group Holding Limited Retrieving public data for blockchain networks using highly available trusted execution environments
EP3673435B1 (en) 2019-03-27 2022-05-25 Advanced New Technologies Co., Ltd. Improving integrity of communications between blockchain networks and external data sources
KR102274294B1 (ko) 2019-03-29 2021-07-08 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 고 가용성의 신뢰 실행 환경을 사용하여 블록체인 네트워크에 대한 액세스 데이터를 리트리빙하는 방법
US11853454B1 (en) * 2019-05-31 2023-12-26 Ca, Inc. Systems and methods for preparing a secure search index for securely detecting personally identifiable information
CN113874876A (zh) 2019-06-05 2021-12-31 万事达卡国际公司 用于分布式计算系统的安全模型
CN110246207A (zh) * 2019-06-13 2019-09-17 四川长虹电器股份有限公司 基于多图层的图形验证码生成方法
CN110267001B (zh) * 2019-06-17 2021-11-16 视联动力信息技术股份有限公司 一种视联网设备信息管理方法及装置
WO2020256734A1 (en) * 2019-06-21 2020-12-24 Bae Systems Information And Electronic Systems Integration Inc. Control of mission data tool application program interfaces
CN110446108B (zh) * 2019-06-28 2022-04-22 中国传媒大学 一种媒体云系统及视频加密、解密方法
CN112307487A (zh) * 2019-08-02 2021-02-02 中国电信股份有限公司 消息处理方法和装置、消息集群服务器
US11265709B2 (en) 2019-08-08 2022-03-01 Zettaset, Inc. Efficient internet-of-things (IoT) data encryption/decryption
US11356274B2 (en) * 2019-09-20 2022-06-07 Kaleidoscope Blockchain, Inc. Verifying a set of remotely stored data
US11533127B1 (en) 2019-09-20 2022-12-20 Kaleidoscope Blockchain, Inc. Determining data availability
CN110708058B (zh) * 2019-10-24 2023-05-30 大连东软信息学院 一种基于全自旋逻辑器件的2-4线译码器及其控制方法
CN112825054B (zh) * 2019-11-21 2023-09-05 杭州海康威视数字技术股份有限公司 一种数据处理方法及电子设备
US11119995B2 (en) * 2019-12-18 2021-09-14 Ndata, Inc. Systems and methods for sketch computation
US10938961B1 (en) 2019-12-18 2021-03-02 Ndata, Inc. Systems and methods for data deduplication by generating similarity metrics using sketch computation
US11641346B2 (en) 2019-12-30 2023-05-02 Industrial Technology Research Institute Data anonymity method and data anonymity system
CN113312326B (zh) * 2020-02-26 2024-04-16 伊姆西Ip控股有限责任公司 用于存储管理的方法、电子设备和计算机程序产品
US11265144B2 (en) * 2020-03-09 2022-03-01 International Business Machines Corporation Consistent ciphertext creation
US11544389B2 (en) * 2020-03-16 2023-01-03 Acronis International Gmbh Systems and methods for performing secure computing while maintaining data confidentiality
KR20230021642A (ko) 2020-04-09 2023-02-14 너츠 홀딩스 엘엘씨 너츠: 유연한 계위 객체 그래프
US10873852B1 (en) 2020-04-10 2020-12-22 Avila Technology, LLC POOFster: a secure mobile text message and object sharing application, system, and method for same
US11151229B1 (en) 2020-04-10 2021-10-19 Avila Technology, LLC Secure messaging service with digital rights management using blockchain technology
US11175989B1 (en) * 2020-04-24 2021-11-16 Netapp, Inc. Pooling blocks for erasure coding write groups
US11368287B2 (en) 2020-05-19 2022-06-21 International Business Machines Corporation Identification of a creator of an encrypted object
EP3917103A1 (de) * 2020-05-29 2021-12-01 Siemens Aktiengesellschaft Verfahren, system, sender und empfänger zum authentifizieren eines senders
US11238757B2 (en) * 2020-06-11 2022-02-01 Fmr Llc Shifting substitution cipher based efficient vaultless data tokenization apparatuses, methods and systems
US11606346B2 (en) 2020-06-29 2023-03-14 Rockwell Automation Technologies, Inc. Method and apparatus for managing reception of secure data packets
US11599649B2 (en) * 2020-06-29 2023-03-07 Rockwell Automation Technologies, Inc. Method and apparatus for managing transmission of secure data packets
EP3933630A1 (en) * 2020-06-30 2022-01-05 Nxp B.V. Method and apparatus to adjust system security policies based on system state
CN111931200B (zh) * 2020-07-13 2024-02-23 车智互联（北京）科技有限公司 一种数据序列化方法、移动终端和可读存储介质
US11962709B1 (en) * 2020-07-15 2024-04-16 Marvell Asia Pte, Ltd. Structures and methods for deriving stable physical unclonable functions from semiconductor devices
CN112104615B (zh) * 2020-08-24 2021-07-20 清华大学 基于IPv6地址的文件可信判断的处理方法及装置
TWI744002B (zh) * 2020-09-22 2021-10-21 財團法人資訊工業策進會 資料傳輸系統與資料傳輸方法
CN112395304B (zh) * 2020-10-30 2024-01-02 迅鳐成都科技有限公司 基于数据行为模拟的数据安全计算方法、系统及存储介质
CN112347103B (zh) * 2020-11-05 2024-04-12 深圳市极致科技股份有限公司 数据同步方法、装置、电子设备及存储介质
US20220141221A1 (en) * 2020-11-05 2022-05-05 T-Mobile Innovations Llc Smart Computing Device Implementing Network Security and Data Arbitration
TWI749866B (zh) * 2020-11-12 2021-12-11 南亞科技股份有限公司 資料處理裝置與資料處理方法
KR102519357B1 (ko) 2020-11-18 2023-05-03 (주)에프알텍 O-RAN 프론트홀의 5G mmWave 광대역 빔포밍 MIMO 서비스 방법과 그 장치
CN112241547B (zh) * 2020-11-23 2023-06-06 中国联合网络通信集团有限公司 车辆数据加密分析方法、边缘服务器及存储介质
KR102497155B1 (ko) 2020-11-24 2023-02-07 주식회사 에스원 방범 시스템에서 감지 루프에 대한 강제 루핑을 검출하기 위한 장치 및 이를 위한 방법
CN112492580B (zh) * 2020-11-25 2023-08-18 北京小米移动软件有限公司 信息处理方法及装置、通信设备及存储介质
JP7175480B2 (ja) * 2020-12-02 2022-11-21 株式会社アーリーワークス 情報処理システム及びプログラム
KR20220081256A (ko) 2020-12-07 2022-06-15 주식회사 마이지놈박스 블록체인 기술을 이용한 dna 데이터의 인증과 무결성 확보를 위한 장치
KR102293404B1 (ko) 2020-12-07 2021-08-26 주식회사 마이지놈박스 블록체인 기술을 이용한 dna 데이터의 인증과 무결성 확보를 위한 장치 및 이를 위한 방법
CN112541186B (zh) * 2020-12-21 2022-03-18 中国电子科技集团公司第三十研究所 一种基于运动状态感知的密码抗失控系统及方法
US11327721B1 (en) * 2021-02-08 2022-05-10 Marco Renedo System for extending functionality of a computer programming language, and related method and software
CN113222829B (zh) * 2021-02-25 2023-04-25 安徽师范大学 基于Bernstein基的数字图像分存方法及图像复原方法
US11868275B2 (en) 2021-06-24 2024-01-09 International Business Machines Corporation Encrypted data processing design including local buffers
US12008150B2 (en) 2021-06-24 2024-06-11 International Business Machines Corporation Encrypted data processing design including cleartext register files
US11856090B2 (en) 2021-06-24 2023-12-26 International Business Machines Corporation Data protection optimization
CN113259390B (zh) * 2021-06-25 2021-09-14 深圳市爱挖网络科技有限公司 一种用于招聘平台的账号安全防护系统
CN113360505B (zh) * 2021-07-02 2023-09-26 招商局金融科技有限公司 基于时序数据的数据处理方法、装置、电子设备及可读存储介质
CN113497806B (zh) * 2021-07-05 2023-07-04 国铁吉讯科技有限公司 一种远程登录方法、装置及存储介质
CN113569262B (zh) * 2021-07-30 2022-05-10 立信(重庆)数据科技股份有限公司 基于区块链的密文存储方法及系统
US20230086809A1 (en) * 2021-09-17 2023-03-23 BCD International, Inc. Combined security and video camera control system
CN114154123B (zh) * 2022-02-09 2022-05-17 北京天防安全科技有限公司 应用于Python项目的加密保护方法
CN116629871B (zh) * 2023-07-21 2023-10-17 济南正浩软件科技有限公司 一种订单线上支付系统及支付方法
TWI832800B (zh) * 2023-09-19 2024-02-11 英業達股份有限公司 多種規格點燈的硬碟背板
CN117421759B (zh) * 2023-12-19 2024-03-29 长春市鸣玺科技有限公司 基于大数据信息进行处理的工程资料管理系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080248782A1 (en) * 2006-04-07 2008-10-09 Mobitv, Inc. Providing Devices With Command Functionality in Content Streams
US20140195804A1 (en) * 2012-10-12 2014-07-10 Safelylocked, Llc Techniques for secure data exchange
US20140245025A1 (en) * 2013-02-22 2014-08-28 Spideroak Inc. System and method for storing data securely
US20150347480A1 (en) * 2014-05-30 2015-12-03 Georgetown University Process and Framework For Facilitating Data Sharing Using a Distributed Hypergraph

Family Cites Families (118)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5870474A (en) 1995-12-04 1999-02-09 Scientific-Atlanta, Inc. Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers
JPH08263438A (ja) 1994-11-23 1996-10-11 Xerox Corp ディジタルワークの配給及び使用制御システム並びにディジタルワークへのアクセス制御方法
US5715403A (en) 1994-11-23 1998-02-03 Xerox Corporation System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar
US7690043B2 (en) * 1994-12-19 2010-03-30 Legal Igaming, Inc. System and method for connecting gaming devices to a network for remote play
US5933501A (en) 1996-08-01 1999-08-03 Harris Corporation `Virtual` encryption scheme combining different encryption operators into compound-encryption mechanism
US6249866B1 (en) 1997-09-16 2001-06-19 Microsoft Corporation Encrypting file system and method
US6324650B1 (en) 1998-03-16 2001-11-27 John W.L. Ogilvie Message content protection and conditional disclosure
US6205549B1 (en) 1998-08-28 2001-03-20 Adobe Systems, Inc. Encapsulation of public key cryptography standard number 7 into a secured document
US6185684B1 (en) 1998-08-28 2001-02-06 Adobe Systems, Inc. Secured document access control using recipient lists
US6823068B1 (en) 1999-02-01 2004-11-23 Gideon Samid Denial cryptography based on graph theory
DE19906450C1 (de) * 1999-02-16 2000-08-17 Fraunhofer Ges Forschung Verfahren und Vorrichtung zum Erzeugen eines verschlüsselten Nutzdatenstroms und Verfahren und Vorrichtung zum Entschlüsseln eines verschlüsselten Nutzdatenstroms
US6845449B1 (en) 1999-07-23 2005-01-18 Networks Associates Technology, Inc. System and method for fast nested message authentication codes and error correction codes
US6976168B1 (en) 1999-07-23 2005-12-13 Mcafee, Inc. System and method for adaptive cryptographically synchronized authentication
US20110208567A9 (en) * 1999-08-23 2011-08-25 Roddy Nicholas E System and method for managing a fleet of remote assets
US20020184485A1 (en) * 1999-12-20 2002-12-05 Dray James F. Method for electronic communication providing self-encrypting and self-verification capabilities
US20050015608A1 (en) 2003-07-16 2005-01-20 Pkware, Inc. Method for strongly encrypting .ZIP files
GB0023409D0 (en) 2000-09-22 2000-11-08 Integrated Silicon Systems Ltd Data encryption apparatus
US6862354B1 (en) * 2000-09-29 2005-03-01 Cisco Technology, Inc. Stream cipher encryption method and apparatus that can efficiently seek to arbitrary locations in a key stream
US7010570B1 (en) 2000-10-16 2006-03-07 International Business Machines Corporation System and method for the controlled progressive disclosure of information
CN1483263A (zh) 2000-10-26 2004-03-17 ���ĺ� 多媒体多点传送内容的初始免费预览
US7436964B2 (en) 2000-12-19 2008-10-14 At&T Mobility Ii Llc Synchronization of encryption in a wireless communication system
US7136859B2 (en) 2001-03-14 2006-11-14 Microsoft Corporation Accessing heterogeneous data in a standardized manner
US7043637B2 (en) 2001-03-21 2006-05-09 Microsoft Corporation On-disk file format for a serverless distributed file system
US6981138B2 (en) 2001-03-26 2005-12-27 Microsoft Corporation Encrypted key cache
US7185205B2 (en) 2001-03-26 2007-02-27 Galois Connections, Inc. Crypto-pointers for secure data storage
US7509492B2 (en) 2001-03-27 2009-03-24 Microsoft Corporation Distributed scalable cryptographic access control
US7461405B2 (en) * 2001-04-26 2008-12-02 Autodesk, Inc. Mixed-media data encoding
US20020198748A1 (en) * 2001-05-25 2002-12-26 Eden Thomas M. System and method for implementing an employee-rights-sensitive drug free workplace policy
US7359517B1 (en) 2001-10-09 2008-04-15 Adobe Systems Incorporated Nestable skeleton decryption keys for digital rights management
US20030074482A1 (en) 2001-10-16 2003-04-17 Christensen Erik B. Composable messaging protocol
US8059815B2 (en) 2001-12-13 2011-11-15 Digimarc Corporation Transforming data files into logical storage units for auxiliary data through reversible watermarks
US7137553B2 (en) 2001-12-31 2006-11-21 Digital Data Research Company Security clearance card, system and method of reading a security clearance card
US7487365B2 (en) 2002-04-17 2009-02-03 Microsoft Corporation Saving and retrieving data based on symmetric key encryption
US7890771B2 (en) * 2002-04-17 2011-02-15 Microsoft Corporation Saving and retrieving data based on public key encryption
JP4111923B2 (ja) 2003-01-22 2008-07-02 株式会社リコー データ形式可逆変換方法、画像処理装置、データ形式可逆変換用プログラム及び記憶媒体
US7181016B2 (en) 2003-01-27 2007-02-20 Microsoft Corporation Deriving a symmetric key from an asymmetric key for file encryption or decryption
US7197512B2 (en) 2003-03-26 2007-03-27 Microsoft Corporation Type bridges
US7653876B2 (en) 2003-04-07 2010-01-26 Adobe Systems Incorporated Reversible document format
US20070277036A1 (en) * 2003-05-23 2007-11-29 Washington University, A Corporation Of The State Of Missouri Intelligent data storage and processing using fpga devices
US7389529B1 (en) 2003-05-30 2008-06-17 Cisco Technology, Inc. Method and apparatus for generating and using nested encapsulation data
US7480382B2 (en) 2003-09-30 2009-01-20 Microsoft Corporation Image file container
US7421741B2 (en) 2003-10-20 2008-09-02 Phillips Ii Eugene B Securing digital content system and method
US7243157B2 (en) 2004-02-20 2007-07-10 Microsoft Corporation Dynamic protocol construction
JP2005259015A (ja) 2004-03-15 2005-09-22 Ricoh Co Ltd 文書開示装置、文書開示システム、プログラム及び記憶媒体
US20050213511A1 (en) * 2004-03-29 2005-09-29 Merlin Mobile Media System and method to track wireless device and communications usage
JP2005341316A (ja) 2004-05-27 2005-12-08 Sony Corp 情報処理システムおよび方法、情報処理装置および方法、並びにプログラム
JP5057519B2 (ja) * 2004-06-01 2012-10-24 レッド・ベンド・リミテツド 記憶装置に記憶されたコンテンツをインプレース更新するための方法およびシステム
US8306920B1 (en) 2004-07-28 2012-11-06 Ebay Inc. Method and system to securely store customer data in a network-based commerce system
US7715565B2 (en) 2004-07-29 2010-05-11 Infoassure, Inc. Information-centric security
IL164571A0 (en) * 2004-10-14 2005-12-18 Yuval Broshy A system and method for authenticating and validating the validating the linkage between input filesand output files in a computational process
US7454021B2 (en) * 2004-10-29 2008-11-18 Hewlett-Packard Development Company, L.P. Off-loading data re-encryption in encrypted data management systems
US7441185B2 (en) 2005-01-25 2008-10-21 Microsoft Corporation Method and system for binary serialization of documents
EP1870821A4 (en) 2005-03-30 2013-04-03 Fujitsu Ltd IMPLEMENTATION PROCEDURES FOR STRUCTURED DATA
US8694788B1 (en) 2005-04-29 2014-04-08 Progressive Casualty Insurance Company Security system
US8832047B2 (en) 2005-07-27 2014-09-09 Adobe Systems Incorporated Distributed document version control
US7945784B1 (en) 2005-08-19 2011-05-17 Adobe Systems Incorporated Method and system to perform secret sharing
US20070078684A1 (en) * 2005-09-30 2007-04-05 International Business Machines Corporation Models for sustaining and facilitating participation in health record data banks
JP2007142591A (ja) 2005-11-15 2007-06-07 Matsushita Electric Ind Co Ltd 暗号管理方法
US7593548B2 (en) 2005-12-15 2009-09-22 Microsoft Corporation Secure and anonymous storage and accessibility for sensitive data
US7814211B2 (en) 2006-01-31 2010-10-12 Microsoft Corporation Varying of message encoding
US8561127B1 (en) 2006-03-01 2013-10-15 Adobe Systems Incorporated Classification of security sensitive information and application of customizable security policies
CA2546148A1 (en) 2006-05-09 2007-11-09 Nikolajs Volkovs Method, system and computer program for polynomial based hashing and message authentication coding with separate generation of spectrums
JP2009543211A (ja) * 2006-07-07 2009-12-03 サンディスク コーポレイション 汎用管理構造を使用するコンテンツ管理システムおよび方法
US20080091606A1 (en) 2006-10-12 2008-04-17 William Grecia Proprietary encapsulated session container with embedded features for a post transferred option for electronic commerce along with a system for distribution and user access
US20080097786A1 (en) * 2006-10-18 2008-04-24 Rohit Sachdeva Digital data security in healthcare enterprise
US20080104146A1 (en) * 2006-10-31 2008-05-01 Rebit, Inc. System for automatically shadowing encrypted data and file directory structures for a plurality of network-connected computers using a network-attached memory with single instance storage
US8219821B2 (en) 2007-03-27 2012-07-10 Netapp, Inc. System and method for signature based data container recognition
US7779139B2 (en) 2007-04-30 2010-08-17 Microsoft Corporation Normalization of binary data
US8656159B1 (en) 2007-10-11 2014-02-18 Adobe Systems Incorporated Versioning of modifiable encrypted documents
US7996672B1 (en) 2007-12-05 2011-08-09 Adobe Systems Incorporated Support for multiple digital rights management systems for same content
JP4818345B2 (ja) * 2007-12-05 2011-11-16 イノヴァティヴ ソニック リミテッド セキュリティーキー変更を処理する方法及び通信装置
US8145794B2 (en) 2008-03-14 2012-03-27 Microsoft Corporation Encoding/decoding while allowing varying message formats per message
US8621222B1 (en) 2008-05-30 2013-12-31 Adobe Systems Incorporated Archiving electronic content having digital signatures
US8826005B1 (en) 2008-08-21 2014-09-02 Adobe Systems Incorporated Security for software in a computing system
US20100174664A1 (en) 2009-01-05 2010-07-08 Blackrock Institutional Trust Company, N.A. ETF Trading in Secondary Market Based on Underlying Basket
US20100173610A1 (en) 2009-01-05 2010-07-08 Qualcomm Incorporated Access stratum security configuration for inter-cell handover
US8978091B2 (en) 2009-01-20 2015-03-10 Microsoft Technology Licensing, Llc Protecting content from third party using client-side security protection
US10169599B2 (en) 2009-08-26 2019-01-01 International Business Machines Corporation Data access control with flexible data disclosure
US8831228B1 (en) 2009-08-28 2014-09-09 Adobe Systems Incorporated System and method for decentralized management of keys and policies
US8468345B2 (en) 2009-11-16 2013-06-18 Microsoft Corporation Containerless data for trustworthy computing and data services
EP2348450B1 (en) 2009-12-18 2013-11-06 CompuGroup Medical AG Database system, computer system, and computer-readable storage medium for decrypting a data record
US8397068B2 (en) 2010-04-28 2013-03-12 Microsoft Corporation Generic file protection format
US9762435B2 (en) 2010-10-04 2017-09-12 Avocent Huntsville, Llc System and method for monitoring and managing data center resources incorporating a common data model repository
KR101528991B1 (ko) * 2011-01-11 2015-06-15 애플 인크. 실시간 또는 준 실시간 스트리밍
HU230908B1 (hu) 2011-03-25 2019-02-28 Tresorit Kft. Eljárás és rendszertechnikai elrendezés csoportmegosztások kezelésére elosztott adattárolási, különösen P2P környezetben
US8181035B1 (en) * 2011-06-22 2012-05-15 Media Patents, S.L. Methods, apparatus and systems to improve security in computer systems
US9077525B2 (en) 2011-06-24 2015-07-07 Microsoft Technology Licensing, Llc User-controlled data encryption with obfuscated policy
US9390228B2 (en) 2011-10-31 2016-07-12 Reid Consulting Group, Inc. System and method for securely storing and sharing information
US9378380B1 (en) 2011-10-31 2016-06-28 Reid Consulting Group System and method for securely storing and sharing information
US9135450B2 (en) * 2011-12-21 2015-09-15 Intel Corporation Systems and methods for protecting symmetric encryption keys
US9152819B2 (en) 2011-12-30 2015-10-06 Intel Corporation Cloud based real time app privacy dashboard
WO2013109932A1 (en) 2012-01-18 2013-07-25 OneID Inc. Methods and systems for secure identity management
KR20150011802A (ko) * 2012-03-20 2015-02-02 크림메니 테크놀로지스, 인크. 프로세스 작업 세트 격리를 위한 방법 및 시스템
US8739308B1 (en) * 2012-03-27 2014-05-27 Amazon Technologies, Inc. Source identification for unauthorized copies of content
US9116906B2 (en) 2012-06-12 2015-08-25 Sap Se Centralized read access logging
US20140025719A1 (en) * 2012-07-02 2014-01-23 Alexander A. Kalinkin Asynchronous distributed computing based system
US9285981B1 (en) 2012-07-16 2016-03-15 Wickr Inc. Discouraging screen capture
US9278249B2 (en) * 2012-07-23 2016-03-08 Icon Health & Fitness, Inc. Exercise cycle with vibration capabilities
US8972750B2 (en) 2012-12-19 2015-03-03 Adobe Systems Incorporated Method and apparatus for securing transfer of secure content to a destination
US9397830B2 (en) 2012-12-30 2016-07-19 Raymond Richard Feliciano Method and apparatus for encrypting and decrypting data
US10769296B2 (en) 2013-12-10 2020-09-08 Early Warning Services, Llc System and method of permission-based data sharing
CN103731272B (zh) 2014-01-06 2017-06-06 飞天诚信科技股份有限公司 一种身份认证方法、系统及设备
US9767317B1 (en) * 2014-03-25 2017-09-19 Amazon Technologies, Inc. System to provide cryptographic functions to a markup language application
CN105207774B (zh) 2014-05-30 2019-03-01 北京奇虎科技有限公司 验证信息的密钥协商方法及装置
GB2513260B (en) * 2014-06-27 2018-06-13 PQ Solutions Ltd System and method for quorum-based data recovery
US20160028735A1 (en) 2014-07-28 2016-01-28 Max Planck Gesellschaft zur Förderung der Wissenschaften e.V. Private analytics with controlled information disclosure
WO2016077219A1 (en) 2014-11-12 2016-05-19 Reid Consulting Group System and method for securely storing and sharing information
US9129095B1 (en) 2014-12-19 2015-09-08 Tresorit, Kft Client-side encryption with DRM
US9871772B1 (en) * 2015-03-17 2018-01-16 The Charles Stark Draper Laboratory, Inc. Cryptographic system for secure command and control of remotely controlled devices
CA2980002A1 (en) 2015-03-20 2016-09-29 Rivetz Corp. Automated attestation of device integrity using the block chain
CN105743958A (zh) * 2015-04-13 2016-07-06 乐视网信息技术（北京）股份有限公司 一种终端之间的通信方法和装置
US10515409B2 (en) 2016-03-23 2019-12-24 Domus Tower, Inc. Distributing work load of high-volume per second transactions recorded to append-only ledgers
US10613938B2 (en) * 2015-07-01 2020-04-07 Actifio, Inc. Data virtualization using copy data tokens
KR101661930B1 (ko) 2015-08-03 2016-10-05 주식회사 코인플러그 블록체인을 기반으로 하는 공인인증서 발급시스템
US10243744B2 (en) * 2016-06-21 2019-03-26 The King Abdulaziz City For Science And Technology Residue message authentication code
CN105930236A (zh) * 2016-07-15 2016-09-07 深圳市沃特玛电池有限公司 一种基于BMS Bootloader升级的应用程序版本回退方法
US11341259B2 (en) 2018-12-12 2022-05-24 Spideroak, Inc. Managing group authority and access to a secured file system in a decentralized environment
US11341261B2 (en) 2019-04-05 2022-05-24 Spideroak, Inc. Integration of a block chain, managing group authority and access in an enterprise environment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080248782A1 (en) * 2006-04-07 2008-10-09 Mobitv, Inc. Providing Devices With Command Functionality in Content Streams
US20140195804A1 (en) * 2012-10-12 2014-07-10 Safelylocked, Llc Techniques for secure data exchange
US20140245025A1 (en) * 2013-02-22 2014-08-28 Spideroak Inc. System and method for storing data securely
US20150347480A1 (en) * 2014-05-30 2015-12-03 Georgetown University Process and Framework For Facilitating Data Sharing Using a Distributed Hypergraph

Also Published As

Publication number Publication date
TWI803291B (zh) 2023-05-21
CN109643285B (zh) 2023-12-08
EA201990315A1 (ru) 2019-08-30
US20210240867A1 (en) 2021-08-05
WO2018052726A1 (en) 2018-03-22
MX2019002385A (es) 2019-06-20
US20180075262A1 (en) 2018-03-15
CA3031531A1 (en) 2018-03-22
US20210240868A1 (en) 2021-08-05
EP3513298A1 (en) 2019-07-24
US11010496B2 (en) 2021-05-18
CR20190075A (es) 2019-06-05
US20180075253A1 (en) 2018-03-15
KR20240038828A (ko) 2024-03-25
JP2022116009A (ja) 2022-08-09
US20200019735A1 (en) 2020-01-16
AU2022200795A1 (en) 2022-02-24
MX2023007718A (es) 2023-07-10
KR102649209B1 (ko) 2024-03-20
US20200226297A1 (en) 2020-07-16
BR112019003128A2 (pt) 2019-05-21
TW202333054A (zh) 2023-08-16
AU2017325928A1 (en) 2019-03-07
CN117692170A (zh) 2024-03-12
EP3513298A4 (en) 2020-05-06
IL274473B (en) 2021-10-31
JP7076819B2 (ja) 2022-05-30
KR20190047687A (ko) 2019-05-08
TWI763710B (zh) 2022-05-11
US10671764B2 (en) 2020-06-02
AU2017325928C1 (en) 2022-04-28
IL274473A (en) 2020-06-30
AU2022200795B2 (en) 2023-04-06
US11720716B2 (en) 2023-08-08
KR102482406B1 (ko) 2022-12-29
US11003802B2 (en) 2021-05-11
US10503933B2 (en) 2019-12-10
TW201814511A (zh) 2018-04-16
AU2017325928B2 (en) 2021-11-11
TW202232312A (zh) 2022-08-16
AU2023204296A1 (en) 2023-07-27
JP2019537769A (ja) 2019-12-26
AU2023204296B2 (en) 2023-12-14
AU2024201130A1 (en) 2024-03-14
US20230315917A1 (en) 2023-10-05
CN109643285A (zh) 2019-04-16

Similar Documents

Publication Publication Date Title
AU2023204296B2 (en) Encrypted userdata transit and storage
US11558192B2 (en) NUTS: flexible hierarchy object graphs
IL310890A (en) Transfer and storage of encrypted user data
IL293412B1 (en) Transfer and storage of encrypted user data
NZ791988A (en) Encrypted userdata transit and storage
EA040905B1 (ru) Зашифрованный транзит и хранение пользовательских данных

Legal Events

Date Code Title Description
A107 Divisional application of patent
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
A107 Divisional application of patent