KR20230104877A - 신뢰할 수 없는 환경에서 저장된 데이터 및 메타데이터의 기밀성과 무결성을 보장하는 방법 - Google Patents

신뢰할 수 없는 환경에서 저장된 데이터 및 메타데이터의 기밀성과 무결성을 보장하는 방법 Download PDF

Info

Publication number
KR20230104877A
KR20230104877A KR1020237014825A KR20237014825A KR20230104877A KR 20230104877 A KR20230104877 A KR 20230104877A KR 1020237014825 A KR1020237014825 A KR 1020237014825A KR 20237014825 A KR20237014825 A KR 20237014825A KR 20230104877 A KR20230104877 A KR 20230104877A
Authority
KR
South Korea
Prior art keywords
file
data
sub
files
subfile
Prior art date
Application number
KR1020237014825A
Other languages
English (en)
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 노스롭 그루먼 시스템즈 코포레이션
Publication of KR20230104877A publication Critical patent/KR20230104877A/ko

Links

Images

Classifications

    • 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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G06F16/137—Hash-based
    • 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/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • 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/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • 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/6245—Protecting personal data, e.g. for financial or medical purposes
    • 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Quality & Reliability (AREA)
  • Medical Informatics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

컴퓨터 파일을 저장하고 복구하기 위한 시스템 및 방법. 방법은, 파일의 지문 데이터를 계산하는 단계와, 파일을 각각 동일한 크기를 갖는 복수의 데이터 서브 파일과, 다른 데이터 서브 파일보다 더 작은 크기를 갖는 단일 데이터 서브 파일로 분리하는 단계와, 파일 메타데이터를 단일 데이터 서브 파일에 첨부하거나, 메타데이터 서브 파일로서 첨부하는 단계를 포함한다. 또한, 방법은, 복수의 데이터 서브 파일과 동일한 크기를 갖도록 메타데이터를 포함하는 단일 서브 파일을 패딩하거나, 복수의 데이터 서브 파일과 동일한 크기를 갖도록 메타데이터 서브 파일을 패딩하는 단계와, 각각의 데이터 서브 파일에 서브 파일에 관한 정보를 포함하는 헤더를 추가하는 단계와, 각각의 데이터 서브 파일에 고유 파일 이름을 할당하는 단계와, 각각의 데이터 서브 파일을 암호화하는 단계와, 각각의 데이터 서브 파일을 자신의 고유 파일 이름으로 별도의 파일로서 저장하는 단계를 포함한다.

Description

신뢰할 수 없는 환경에서 저장된 데이터 및 메타데이터의 기밀성과 무결성을 보장하는 방법
본 개시 내용은 일반적으로 저장을 위해 데이터 파일을 암호화하기 위한 시스템 및 방법에 관한 것으로, 더욱 상세하게는, 파일을 동일한 크기의 서브 파일로 분할하고 서브 파일을 고유 파일 이름으로 저장하는 것을 포함하는, 저장을 위해 데이터 파일을 암호화하기 위한 시스템 및 방법에 관한 것이다.
컴퓨터 파일은, 사용되지 않을 때, 일반적으로 드라이브에 저장되며, 예를 들어, 클라우드 또는 네트워크 서버에 업로드되어 나중에 복구된다. 저장된 파일은 일반적으로 다른 사람이 파일의 내용을 보는 것을 방지하도록 보안 목적으로 암호화된다. 일단 파일이 저장되면, 요청 시 파일이 저장되었을 때 그대로 파일을 반환하도록 소유자는 기본 파일 시스템의 계약에 의존한다. 저장된 파일이 공격자(adversary)에 의해 의도적으로 변경되거나, 하드웨어 오류 또는 "비트 부패(bit rot)"를 통해 부주의하게 변경되는 경우, 파일 소유자가 종종 이러한 변경을 검출하거나 수정할 방법은 없다.
개인 기록 파일, 멀티미디어 파일 및 애플리케이션 데이터 파일은 원본 형태로 저장될 때 모두 다르게 보인다. 데이터 파일이 저장될 때, 보안을 위해 파일이 암호화되더라도, 액세스될 수 있는, 메타데이터로 알려진, 파일의 이름과 유형 또는 확장자, 파일의 크기, 파일이 생성되고 마지막으로 수정된 날짜 등과 같은 파일에 관한 정보가 있다. 신뢰할 수 없는 환경에서, 파일에 관한 이러한 소량의 정보는 집계되어 민감한 정보를 유출하거나 공격자에게 특정 파일을 공격하는데 있어서 이점을 제공할 수 있다. 가장 기본적인 레벨에서, 파일 이름은 저장되고 있는 데이터의 유형이나 데이터를 소유하는 비즈니스의 특성에 관한 정보를 제공할 수 있다.
일례로서, 일부 군사 프로그램에서는 특정 플랫폼에서의 특정 장비의 사용에 관한 지식의 "사실"이 기밀로 간주될 수 있다. 이 지식은 다수의 기밀이 아닌 소스로부터 집계될 수 있을 것이다. "(U)_F-123_Public_Release_Notes.docx" 및 "(U)_KG-321_Specification_Sheet.pdf"라는 이름을 갖는 파일을 포함하는 저장 위치를 볼 수 있는 공격자는 F-123 플랫폼이 종합적으로 기밀 정보일 수 있는 KG-321 암호화 장치를 사용한다고 추론할 수 있다. 이것은 이 2개의 파일이 암호화되어 저장될 수 있고 공격자가 파일의 내용을 읽을 수 없다는 사실에도 불구하고 가능하다. 이 경우 공격자는 의도적인 적대자일 필요는 없고, 클라이언트에 의해 저장된 파일에 관한 이름 및 기타 메타데이터를 볼 수 있는 클라우드 서비스 또는 코로케이션(colocation) 제공자의 시스템 관리자일 수 있다.
다른 예로서, 암호화된 파일을 공격하려고 시도하는 공격자는 사용자의 개인 키 또는 암호를 복구하는 희망을 가지고 '.pem' 또는 'passwords.docx'와 같은 이름을 가진 파일을 대상으로 선택할 수 있다. 다수의 이러한 파일이 있는 경우, 공격자는 성공 시 보상을 최대화하기 위해 가장 최근의 수정 날짜 또는 가장 큰 파일 크기를 갖는 파일을 추적할 수 있다. 이러한 파일은 예를 들어 '.mp3' 유형의 파일이나 몇 년 된 파일보다 더 가치 있는 대상으로 간주될 수 있다. 파일 이름과 기타 메타데이터를 숨기는 것은 공격자가 이러한 가치 판단을 내리고 표적화된 공격을 수행하는 것을 방지할 수 있다.
저장된 파일의 메타데이터를 숨기는 2가지 주요 방법이 있다. 구체적으로, 메타데이터가 예를 들어 파일 이름과 날짜를 변경하여 직접 변경될 수 있거나, 파일 시스템의 저장된 메타데이터가 이제 원본 파일이 아닌 캡슐화 파일을 참조하도록 파일이 다른 파일 또는 파일들로 캡슐화될 수 있다. 파일 이름과 확장자를 직접 변경하는 것은 어렵지 않다. 'secret file.docx'라는 이름의 파일은 'abcde.xyz'와 같이 저장 전에 암호화되고 문자열로 변환된 이름을 가질 수 있다. 생성, 수정 및 액세스 날짜 모두에 더미 날짜를 덮어쓸 수 있지만, 프로세스가 가역적이도록 의도되면, 파일 검색 시 원래 날짜를 복구하기 위해 새로운 접근 방식이 필요할 것이다. 파일이 항상 추가 데이터로 패딩(padding)될 수 있지만 일반적으로 짧아질 수는 없기 때문에, 파일 크기는 모호하게 만들기에 가장 어렵다. 공격자를 유의미하게 혼란스럽게 하기 위하여 충분한 추가 데이터로 파일을 패딩하는 것은 저장 용량의 관점에서 극도로 낭비적일 수 있다. 추가적으로, 올바르게 수행하지 않으면, 예를 들어, 00으로만 패딩한다면, 이는 데이터 내용을 보호하는 데 사용되고 있는 암호화 체계에 있어서 약점을 드러낼 수 있으며, 따라서 저장된 데이터의 전반적인 보안을 저하시킨다. 이러한 이유로, 메타데이터의 직접적인 변경은 바람직한 솔루션이 아니다.
더미 파일로의 파일의 캡슐화는 메타데이터를 숨기는 더 나은 접근 방식이다. 가장 기본적인 예로서, 민감한 파일은 저장 전에 암호로 보호된 '.zip' 파일로 아카이브될 수 있어, .zip 안에 있는 파일의 메타데이터가 암호가 없는 사람에게는 숨겨진다. 그러나, 이것은 아카이브 내의 단일 파일에 액세스해야 할 때마다 전체 .zip 파일을 검색하고 아카이브 해제해야 하므로 실용적인 접근 방식은 아니지만, 개념을 보여준다.
파일의 캡슐화에 대한 보다 실용적인 접근 방식은 신뢰할 수 없는 저장 환경에서 여러 개의 큰 바이너리 파일을 생성한 다음 실제 파일 데이터를 그 파일 내부의 오프셋에 저장하는 것일 수 있다. 예를 들어, 공격자는 크기가 각각 1GB인 '1.bin'에서 '10.bin'까지의 이름을 갖는 10개의 큰 파일만 볼 수 있다. 사용자는 '2.bin' 내부의 오프셋 16384에 저장된 'secret file.docx'라는 이름을 갖는 파일을 가지고 있을 수 있다. 이와 같은 기술은 저장된 데이터의 유사한 백색화(whitening)를 달성하여 파일 메타데이터를 보호하고 심지어 높은 무결성을 제공할 수도 있다. 그러나, 이 접근 방식의 주요 단점은 물리적 하드웨어에 직접 액세스가 이용 가능한 로컬 파일 시스템 또는 코로케이션 환경에 더 적합하다는 것이다. 클라우드 스토리지 환경에서는, 제공자에 따라, 파일 내 오프셋에 대한 직접 액세스가 종종 제공되지 않는다. 따라서, 이 예에서, 오프셋 16384에 액세스하고 사용자의 캡슐화된 파일을 검색하기 위하여 전체 1GB의 바이너리 파일이 검색될 필요가 있을 것이다. 그러나, .zip의 예와 마찬가지로, 이것은 대역폭을 극도로 낭비하고 많은 양의 대기 시간을 생성한다.
저장된 데이터 파일의 무결성을 유지하는 것과 관련하여, 오늘날 이 기능을 제공하기 위해 일반적으로 사용되는 많은 방법이 있다. 가장 일반적인 2가지 방법은 sha256sum에 의해 생성된 것과 같이 해시 다이제스트(hash digest)와 함께 파일을 저장하는 것과, 예를 들어 Parchive(.PAR, .PAR2) 파일을 통해 패리티 정보 또는 오류 정정 코드와 함께 파일을 저장하는 것이다. 이 경우 다이제스트를 무결성 메커니즘으로 사용하는 것은 파일을 수정할 수 있는 능력을 갖는 공격자가 파일과 함께 저장된 다이제스트를 수정하거나 교체하는 능력을 가질 가능성이 있기 때문에 상대적으로 낮은 보안 수단이다. 이는 디지털 서명 또는 메시지 인증 코드를 통해 다이제스트를 보호하여 극복될 수 있지만, 그것은 통상적으로 단순한 파일 무결성을 위해 투자되는 것보다 훨씬 더 많은 복잡성을 더한다. 또한, 다이제스트는 원본 파일에 변경이 이루어졌는지 여부만 나타낼 수 있고, 원본 데이터를 복구하기 위한 어떠한 형태의 정정도 제공할 수 없다. 이러한 이유로, 다이제스트는 일반적으로, 디스크로부터 반환된 데이터가 저장된 데이터와 동일한 것을 확인하는 대신, 신뢰할 수 없는 네트워크를 통해 다운로드된 파일이 그대로 수신되는 것을 확인하는 데 사용된다.
Parchive 도구는 전술된 바와 같은 다이제스트에 유사한 기능을 제공하는 인덱스 파일을 생성한다. 그러나, Parchive 도구는 또한 변경이 검출될 때 원본 파일을 재구성하는 데 사용될 수 있는 데이터의 중복 사본(redundant copy)도 제공한다. 이러한 방식으로, 다양한 레벨의 무결성 보호가 제공될 수 있다. 이 접근 방식의 단점은 Parchive 파일이 파일 이름을 통해 보호하고 있는 원본 파일과 구체적으로 연관된다는 것이다.
일례로서, 'secret file.docx'라는 이름의 파일은 전통적으로 'secret file.docx.sha256sum'이라는 이름의 다이제스트 또는 'secret file.PAR2'라는 이름의 Parchive 인덱스와 함께 저장될 것이다. 중복성을 제공하기 위해, Parchive 도구는 'secret file.vol00+10.PAR2' 및 'secret file.vol01+13.PAR2'라는 이름을 갖는 파일들을 생성할 수도 있을 것이다. 중복 데이터가 이름으로 원본 파일과 연관되어 있기 때문에, 공격자는 파일을 함께 대상으로 삼을 수 있다.
다음 논의는 기밀 컴퓨터 파일을 저장하고 복구하기 위한 시스템 및 방법을 개시하고 설명한다. 방법은, 파일의 지문 데이터를 계산하는 단계와, 파일을 각각 동일한 크기를 갖는 복수의 데이터 서브 파일과, 다른 데이터 서브 파일보다 더 작은 크기를 갖는 단일 데이터 서브 파일로 분리하는 단계와, 파일 메타데이터를 단일 데이터 서브 파일에 첨부하거나, 메타데이터 서브 파일로서 첨부하는 단계를 포함한다. 또한, 방법은, 복수의 데이터 서브 파일과 동일한 크기를 갖도록 메타데이터를 포함하는 단일 서브 파일을 패딩하거나, 복수의 데이터 서브 파일과 동일한 크기를 갖도록 메타데이터 서브 파일을 패딩하는 단계와, 각각 복수의 데이터 서브 파일과 동일한 크기를 갖는 복수의 중복(redundancy) 서브 파일을 생성하는 단계를 포함한다. 방법은 각각의 데이터 및 중복 서브 파일에 서브 파일에 관한 정보를 포함하는 헤더를 추가하는 단계와, 각각의 데이터 및 중복 서브 파일에 고유 파일 이름을 할당하는 단계와, 각각의 데이터 및 중복 서브 파일을 암호화하는 더 단계를 포함한다. 그 다음, 방법은 각각의 데이터 및 중복 서브 파일을 자신의 고유 파일 이름으로 별도의 파일로서 저장한다.
파일이 복구될 때, 방법은 파일과 연관된 저장된 데이터 및 중복 서브 파일을 식별하고, 식별된 데이터 및 중복 서브 파일을 복호화하고, 서브 파일 헤더를 이용하여 복호화된 데이터 서브 파일에서 무결성 오류를 검출한다. 그 다음, 방법은, 중복 서브 파일을 사용하여 무결성 오류를 갖는 데이터 서브 파일을 재구축하고, 데이터 서브 파일로부터 헤더 및 패딩을 제거하고, 복호화되고 재구축된 데이터 서브 파일 및 메타데이터를 사용하여 파일을 재구성하고, 지문 데이터를 이용하여 재구성된 상기 파일이 완전한지 판단한다.
본 개시 내용의 추가적인 특징들은 첨부된 도면과 함께 고려되는 이어지는 설명과 첨부된 도면으로부터 명백하게 될 것이다.
도 1은 기밀 데이터 파일을 저장하기 위한 프로세스를 도시하는 컴퓨팅 시스템의 블록도이고;
도 2 내지 7은 기밀 데이터 파일을 저장하기 위한 일련의 단계들을 도시하고; 그리고
도 8 내지 12는 저장된 기밀 데이터 파일을 복구하기 위한 일련의 단계들을 도시한다.
파일을 동일한 크기의 서브 파일로 분할하는 단계와, 동일한 크기의 중복(redundancy) 서브 파일을 추가하는 단계와, 서브 파일을 고유 파일 이름으로 저장하는 단계를 포함하는 저장을 위해 데이터 파일을 암호화하기 위한 시스템 및 방법에 관한 본 개시 내용의 실시예들에 대한 다음의 논의는 본질적으로 단지 예시적일 뿐이며, 본 개시 내용이나 이의 적용례 또는 용도를 어떠한 방식으로도 한정하려고 의도되지 않는다.
도 1은 더 중요한 컴퓨터 파일(12)과 덜 중요한 컴퓨터 파일(14)을 클라우드 스토리지와 같은 저장 장치(16)에 안전하게 저장하기 위한 프로세스를 사용하고, 파일(12, 14)의 데이터 및 메타데이터 모두의 기밀성과 무결성이 저장되는 동안 유지되는 컴퓨팅 시스템(10)의 블록도이다. 파일(12, 14)은 랩탑과 같은 컴퓨터에서 생성되고, 본 명세서에서 논의된 방식으로 암호화되도록 컴퓨터 내의 프로세서(18)에 제공되며, 파일(12, 14)은 파일의 크기, 그것이 생성된 날짜, 그것이 수정된 날짜 등과 같은 특정 메타데이터를 포함할 것이다. 추가적으로, 기밀성 및 무결성의 레벨, 시스템 성능 목표 등과 같은, 박스(20)의 위험 인자 및 선호도 정보가 프로세서(18)에 제공될 수 있어, 특정 파일 또는 파일 그룹이 갖도록 사용자가 원하는 중요도 레벨 및 기타 인자를 식별한다.
아래에서 상세히 논의되는 바와 같이, 프로세서(18)는 파일(12, 14)로부터 다수의 해당하는 서브 파일(22, 24) 및 선호도 정보를 생성하기 위한 다양한 알고리즘을 작동시키며, 각각의 서브 파일(22, 24)은 동일한 크기와 유형을 가지며, 암호화된다. 서브 파일(22, 24)에는 고유 서브 파일 이름이 지정되며, 여기서는 대표하는 목적을 위해 홀수이지만 실제로는 숫자 및 문자와 같은 긴 의사 랜덤 문자열일 수 있다. 서브 파일(22, 24) 중 일부는 음영 표시되지 않았으며 각각 파일(12, 14)에서의 데이터 및 정보를 나타내고, 다른 서브 파일(22, 24)은 음영 표시되어 중복 서브 파일을 나타낸다. 음영 표시된 서브 파일(22, 24)의 개수는 더 중요한 파일의 경우 더 많은 데이터가 중복되어 이러한 파일이 재생성되는 가능성이 증가되도록 미리 결정된 위험 인자 및 선호도에 따라 결정된다. 그러나, 제공되는 중복 데이터가 더 많을수록 더 많은 처리 및 저장 공간이 필요하다. 이 예에서, 파일(12)에 대한 서브 파일(22)은 6개의 중복 서브 파일을 포함하고, 파일(14)에 대한 서브 파일(24)은 1개의 중복 서브 파일을 포함하도록 위험 인자 및 선호도가 설정되었다. 그런 다음, 서브 파일(22, 24)은 장치(16)에 저장되며, 이들이 모두 동일한 크기 및 파일 유형을 가지기 때문에, 권한이 없는 사용자는 임의의 서브 파일(22, 24)에서 어떠한 유용한 메타데이터도 식별할 수 없을 것이다. 사용자가 파일(12 또는 14)을 요청할 때, 알고리즘은 어느 서브 파일(22, 24)이 파일(12, 14)와 연관되는지 알고 있고, 이에 따라 서브 파일(12, 24)를 복호화하여 재구성할 것이다.
도 2 내지 7은 프로세서(18)에서 동작하는 알고리즘 또는 알고리즘들이 예를 들어 중요한 파일(12)을 장치(16)에 기밀로 저장하기 위해 수행하는 일련의 파일 저장 동작을 예시한다. 도 2로 예시된 제1 저장 단계에서, 지문 데이터가 파일(12)에 대해 계산된 다음, 파일(12)은 특정 개수의 동일한 크기의 데이터 청크(chunk)(40)로 분리되며, 그 각각은 음영 표시되지 않은 서브 파일(22) 중 하나의 전개(development)를 나타내며, 마지막 데이터 청크(42)는 파일(12)의 크기와 사용되고 있는 분할 프로세스로 인하여 다른 데이터 청크(40)만큼 길지 않을 수 있다. 예를 들어, 300KB 파일이 64KB 청크로 분리될 수 있으며, 이는 4개의 완전한 64KB 청크와 하나의 44KB 청크를 제공할 것이다.
지문 데이터는 MD5, SHA-256과 같은 암호화 해시 함수 또는 HMAC와 같은 메시지 인증 코드(message authentication code(MAC))를 사용하여 계산된다. 지문 데이터는 CRC(cyclic redundancy check) 또는 유사한 비암호화 알고리즘을 사용하여 계산될 수도 있다. 이 데이터는 공격자에 대한 "보안"을 제공하지 않고, 알고리즘이 어느 정보로 시작하는 지에 대한 고유 지문일 뿐이므로, 알고리즘의 다른 부분만큼 강력할 필요는 없다.
파일(12)을 데이터 청크(40)로 분할하는 것은 박스(20)에서 제공된 성능, 저장 효율 및 보안에 관한 사용자 선호도에 기초하여 수행된다. 값이 "청크 크기"에 대해 식별될 필요가 있으며, 예를 들어, 100kB 파일은 100×1kB 청크(40) 또는 2×50kB 청크(40)로 분할될 수 있다. 청크 크기가 클수록 알고리즘의 성능과 저장 장치(16)로의 서브 파일(22)의 전송 속도를 모두 개선한다. 그러나, 청크 크기가 클수록 저장 용량의 관점에서 덜 효율적이며, 알고리즘은 디스크에서 더 많을 공간을 소비할 것이고 제공될 수 있는 파일 무결성의 양에 있어서 더 적은 입도(granularity)를 제공한다. 예를 들어, 100×1kB 청크의 경우, 제공될 수 있는 최소 레벨의 무결성은 하나의 추가 청크, 즉 총 101kB이다. 더 많은 무결성은 총 102kB에 달하는 제2 청크로 제공될 수 있으며, 매우 많은 양의 무결성은 총 200kB 이상에 달하는 많은 추가 청크로 제공될 수 있다. 2×50kB 청크의 경우, 제공될 수 있는 최소 레벨의 무결성은 총 150kB에 해당하는 하나의 추가 청크이며, 다음 단계는 총 200kB에 해당하는 2개의 청크를 필요로 할 것이다. 사용자가 파일(12)에 대하여 200kB 이하로 소비하는 것을 요구한다면, 큰 청크는 제공된 무결성의 양에 대하여 2개의 옵션만을 제공하는 반면, 작은 청크는 더 많이 제공한다. 더 큰 청크 크기는 저장 효율과 보안 사이의 트레이드 오프를 최적화하는 데 있어서 그렇게 유연하지 않다.
하나의 구현예는 성능, 저장 효율성, 기밀성 및 무결성에 대한 사용자의 선호도가 하나 이상의 가능한 청크 크기를 선택하는 데 사용되는 가변 청크 크기이다. 예를 들어, 더 작은 파일은 64kB 청크로 분할될 수 있고, 더 큰 파일은 1MB 청크로 분할될 수 있다. 기밀성과 무결성보다 성능과 저장 효율성에 가치를 두는 사용자 선호도는 청크 크기에 대해 더 많은 옵션을 허용하는 경향이 있을 것이며, 청크 크기는 평균적으로 더 커질 것이다. 성능 및 효율성보다 보안에 가치를 두는 사용자 선호도는 청크 크기에 대해 더 적은 옵션(잠재적으로 단 하나의 옵션)을 허용할 것이고 청크 크기는 평균적으로 더 작아질 것이다. 알고리즘은 이러한 선호도를 사용자별, 파티션별 또는 파일별로 적용하여 사용자에게 가능한 한 많은 유연성을 제공할 수 있다.
도 3으로 예시된 제2 저장 단계에서, 파일(12)의 메타데이터가 처리되고, 그 다음 마지막 청크(42)가 다른 청크(40)와 동일한 길이가 되도록 추가 비트로 패딩된다. 메타데이터는 마지막 청크(42)에서 메타데이터 섹션(46)으로 표현되고 패딩은 마지막 청크(42)에서 패딩 섹션(48)으로 표현된다. 대안적으로, 마지막 청크(42)에서 메타데이터를 위한 충분한 여유가 없다면, 새로운 청크(50)가 생성되고, 여기에서 섹션(52)은 메타데이터이고 섹션(54)은 새로운 청크(50)를 다른 청크(40)와 동일한 길이로 만들기 위한 패딩이다. 메타데이터와 패딩은 현재 파일 시스템에 상주하는 파일의 일반 및 확장 속성과 제1 저장 단계에서 계산된 지문 데이터로 구성될 것이다. 속성은 단순히 파일 시스템으로부터 판독되어 서브 파일 내에 저장된다. 메타데이터는, 필요한 경우, 공간을 덜 차지하도록 압축되거나 인코딩될 수 있다. 패딩은 여러 가지 방법으로 수행될 수 있으며, 가장 확실하게는, 정확한 길이가 될 때까지 서브 파일(22)의 끝에 0000...0000 또는 1111...1111을 추가하는 것에 의해 수행된다. A5...A5와 같이, 임의의 캐릭터 패턴이 서브 파일(22)을 완성하기 위하여 선택되어 반복될 수 있다. 하나의 접근 방식은 패딩이 추가되기 전에 서브 파일(22)의 원래 길이를 포함하는 약간 더 복잡한 패딩 체계이다. 이러한 접근 방식의 일례는 예는 Merkle-Damg
Figure pct00001
rd 호환 패딩이다.
도 4로 예시된 제3 저장 단계에서, 알고리즘은 계산할 중복 데이터의 양과 그 데이터를 계산하기 위해 사용할 중복 알고리즘을 결정하기 위해 사용자의 선호도를 사용하고, 여기서 서브 파일 중복 청크(60)는 음영 표시된 서브 파일(22)의 전개를 나타낸다. 사용자가 그 데이터에 대한 추가 무결성에 관하여 염려하지 않는 경우, 알고리즘은 제로 추가 중복 서브 파일을 계산할 수 있다. 사용자가 데이터의 무결성에 관해 극도로 염려하는 경우, 모든 서브 파일(22)의 전체 사본이 생성될 수 있다. 분명히, 생성된 중복 데이터는 클라우드 또는 디스크에서 추가 저장 용량을 소비할 것이고, 이는 사용자가 원하는 트레이드 오프의 레벨을 결정하는 이유이다. 도 4는 약 50%의 추가 중복 데이터가 계산되는 중간 접근 방식을 도시한다. 단순 패리티, 해밍 코드, 삭제 코드, 저밀도 패리티 검사 등과 같은 다수의 오류 정정 코드가 사용자 데이터에 대한 다양한 양의 보호를 생성하는 데 사용될 수 있다. 최상의 구현예가 최소한의 가능 추가 스토리지에 대해 최대한의 무결성을 얻기 위해 사용자의 선호도를 최적화하는 데 의존하기 때문에, 선호되는 구현예는 없다.
도 5로 예시된 제4 저장 단계에서, 알고리즘은 요청될 때 정반대로 작용하여 파일(12)을 다시 합치는 데 필요한 정보를 저장한다. 알고리즘은 해당 정보를 각각의 청크(40, 60)에서의 데이터 섹션(64) 앞에 헤더 섹션(62)으로 둔다. 모든 헤더 섹션(62)이 정확히 동일한 정보를 포함해야 하는 것은 아니고 일부 헤더 섹션(62)은 서브 파일(22)을 파일(12)로 적절히 재조립하기 위하여 더 많거나 더 적거나 또는 상이한 유형의 정보를 필요로 할 수 있다는 것에 유의하라. 헤더 섹션(62)에 저장된 정보의 유형은 서브 파일의 이름 및/또는 ID와 파일(12)을 구성하는 서브 파일(22)의 전체 개수, 이 서브 파일(22)이 일부가 되는 파일(12)의 이름 또는 ID, 시퀀스에서의 이후의 서브 파일(들)에 대한 포인터, 헤더 섹션(62) 및/또는 데이터 섹션(64)의 체크섬(checksum)(들), 중복 데이터가 해석되어야 하는 방법에 영향을 미치는 사용자 선호도로부터 도출된 임의의 "시드 값(seed value)"과 어느 중복 알고리즘(들)이 사용되었는지에 관한 정보 및 임의의 암호화 동작에 대한 초기화 벡터 및/또는 논스(nonce)를 포함할 수 있다. 본질적으로, 알고리즘이 서브 파일(22)을 파일(12)로 다시 적절하게 재조립하는 데 필요한 임의의 정보는 헤더 섹션(62)에 저장될 것이다.
도 6으로 예시된 제5 저장 단계에서, 각각의 청크(40, 60)는 암호화되어(어두운 음영으로 표시됨) 서브 파일(22)을 생성하고, 그 다음, 도 7로 예시된 제6 저장 단계에서, 서브 파일(22)은 윈도우(66)에서 숫자 및 문자의 열로 표현되는 고유 이름에 의해 저장 장치(16) 내에 개별 파일로서 저장된다. 이러한 2개의 단계는 본질적으로 본 개시 내용의 이점을 가지지 않고서 사용자에 의해 수행될 수 있는 종래의 "최신 기술"을 구성한다. 전통적인 시스템에서, 사용자는 제1 내지 제4 저장 단계를 건너뛴 다음, 제5 저장 단계에서 파일(12)을 암호화하고 제6 저장 단계에서 이를 장치(16)에 업로드한다. 이것은 암호화된 파일이 저장 장치(16)에 저장되게 한다. 공격자는 파일의 내용을 판독할 수 없지만, 파일의 크기, 파일이 업데이트된 후의 경과 시간 및 파일 이름 또는 유형(.doc)으로부터의 파일이 공격할 만한 가치가 있는 "고가치(high value)" 파일인지 여부를 포함하는 파일에 관한 여러 가지를 알 수 있을 것이다. 설명되고 있는 알고리즘은 제1 내지 제4 저장 단계를 이 프로세스로 추가하여, 저장 장치(16)에서 관찰 가능한 것이 대신에 모두 명백히 랜덤인 파일 이름을 가지며 아니면 서로 구별 가능하지 않은 파일 이름을 갖는 암호화된 서브 파일의 집합인 것을 보장한다. 공격자는 이러한 서브 파일을 검사하여 원본 파일이나 이의 가치에 대해 아무것도 결정할 수 없다.
알고리즘이 해야 할 마지막 일이 하나 있으며, 그것은 제1 내지 제4 저장 단계 중 임의의 단계 동안에 수행될 수 있다. 특히, 알고리즘은 제6 저장 단계에서 장치(16)에 저장할 수 있기 전에 각각의 서브 파일(22)에 대한 고유한 의사 랜덤 파일 이름을 식별할 필요가 있다. 예를 들어, 파일(12)이 3개의 서브 파일(22)로 분할된 경우, 이 서브 파일들에는 다음의 3개의 파일 이름이 할당될 수 있으며, 이는 제6 저장 단계에서 저장 장치(16)에 업로드된다.
30fa9140e9b8679fdcba17c935367c73775bdde0.subfile
6d1cfe7ec4cd1cbaa1bdc4eed8e782548ca66e4f.subfile
a8358b7a52aa79faafba3f4083fb9fce8d8d6548.subfile
이 네이밍(naming) 기능에는 3개의 주요 요건이 있다. 특히, 네이밍 기능은, 사용자가 파일(12) 검색을 요청할 때 알고리즘이 네이밍 기능을 다시 실행하고 3개의 서브 파일(22)이 파일(12)을 재조립하기 위하여 저장 장치(16)로부터 다운로드될 필요가 있다고 결정할 수 있도록, 결정론적이어야 한다.
네이밍 기능은 주어진 파일 시스템에 유효한 캐릭터만을 포함하도록 제한되어야 한다. 본 명세서에서의 모든 파일 이름 예는 16진수 표기법(hexadecimal notation)(0-9 및 a-f)으로 표시되지만, 네이밍 기능은 파일 이름이 더 짧아질 수 있도록 base-64와 같은 다른 인코딩 체계를 사용할 수 있다. 일례로서, 위의 제2 서브 파일 이름(6d1로 시작)은 base-64에서 다음과 같을 수 있다:
bRz+fsTNHLqhvcTu2OeCVIymbk8=.subfile
대부분의 파일 시스템은 \, / 및 !와 같이 파일 이름에 사용될 수 없는 여러 개의 유효하지 않은 캐릭터를 가지며, 따라서 네이밍 기능은 이러한 캐릭터를 이용한 인코딩을 방지해야만 할 것이다. 또한, 네이밍 기능은 주어진 파일 시스템에 대해 유효한 길이의 파일 이름을 생성하도록 제한되어야 한다. 예를 들어, 많은 파일 시스템은 255자를 초과하는 이름을 허용하지 않는다.
이 네이밍 작업을 수행하는 다수의 방식이 있다. 가장 분명한 것은 해시 함수의 이용을 통하는 것일 수 있으며, 예를 들어, MD5 해시 함수를 사용한다:
MD5("Secret File.docx")=406166e3412fb30809931e2a640e12bf
한 가지 간단한 기술은 그 결과를 제1 서브 파일에 대한 파일 이름으로 사용하고, 그 다음, 예를 들어, 제2 서브 파일의 이름을 결정하기 위하여 MD5("406166e3412fb30809931e2a640e12bf")=d8cf286464579a3a7ad2b786e68b731e과 같이 MD5 작업을 다시 연쇄시키는 것 등이다.
이 원시적인 접근 방식에는 2가지 주요 문제가 있다. 공격자가 자신이 찾고 있는 파일의 이름을 알고 있는 경우, 어느 서브 파일이 그 파일을 구성하는지 결정하기 위하여 동일한 네이밍 기능을 실행할 수 있다. 예를 들어, 공격자는 암호화 키 또는 암호 데이터베이스를 포함하는 파일을 찾기 위해 '.pem' 또는 '.kdbx'로 끝나는 파일 이름의 MD5 출력에 대한 무차별 대입(brute force) 검색을 수행할 수 있다. 최신 하드웨어는 초당 수십억 개의 해시 연산을 계산할 수 있으므로, 네이밍 기능이 단순한 해시인 경우, 파일 이름을 "랜덤화"하는 보안 이점의 상당 부분을 무효화시킬 수 있을 것이다.
필연적으로, 네이밍 기능은 파일 이름 충돌의 문제를 처리해야 할 것이다. MD5("Secret File.docx") 및 MD5("Another File.xlsx") 모두 동일한 값을 제공하는 것이 가능하지만, 2개의 다른 서브 파일이 저장 장치(16)에서 동일한 파일 이름을 공유할 수 없으므로, 알고리즘은 그것을 처리해야 할 것이다.
마찬가지로, 위의 MD5("6d1cfe7ec4cd1cbaa1bdc4eed8e782548ca66e4f.subfile")는 MD5("Yet another file.jpg")와 동일한 값을 생성할 수 있다. 저장되는 파일이 많을수록, 더 많은 서브 파일 이름이 생성될 것이고, 파일 이름 충돌에 대한 더 많은 가능성이 존재할 것이다.
첫 번째 문제를 처리하는 것은 간단하다. 해시 함수만 사용하는 대신, 네이밍 기능은 공격자가 추측할 수 없는 방식으로 출력을 변경하기 위해 사용자가 알고 있는 일부 다른 정보를 사용한다. 이는 사용자의 "양념(salt)"을 원본 파일 이름의 해시에 통합하거나, 원본 파일 이름의 키 해시(keyed-hash)(HMAC) 또는 다른 MAC을 계산하거나, 암호화 알고리즘을 해시 함수와 조합하여 파일 이름의 해시의 암호화 또는 파일 이름의 암호화의 해시를 생성하는 것을 포함하는 다수의 방식으로 수행될 수 있다. 바람직한 접근 방식은 암호화 컴포넌트를 포함하는 옵션 중 하나, 다른 말로 하면 "양념(salt)" 옵션이 아닌 것일 수 있다. 그러나, 이러한 접근 방식 중 어느 것도 두 번째 문제인 충돌에 도움이 되지 않는다.
두 번째 문제를 해결하기 위해, 네이밍 기능은 파일 이름이 이미 저장된 파일과 충돌하는 서브 파일에 대한 대체 파일 이름을 계산할 수 있을 필요가 있다. 예를 들어, 윈도우즈 운영 체제를 고려하자. 폴더 내의 파일의 이름이 "Secret File.docx"이고 사용자가 동일한 파일 이름으로 폴더에 제2 파일을 생성하기 원하는 경우, 윈도우즈는 일반적으로 제2 파일을 "Secret File(1).docx"로 네이밍할 것이다. 가장 간단한 레벨에서, 네이밍 기능은 충돌을 피하기 위해 이와 동일한 종류의 작업(파일 이름에 캐릭터를 추가하는 것)을 수행할 수 있다. 네이밍 기능이 이의 거동에 있어서 결정론적인 한, 이것이 알고리즘의 보안에 영향을 미치지 않기 때문에, 대체 파일 이름이 계산되는 방법에 대한 바람직한 접근 방식은 없다.
제4 저장 단계에서 설명된 헤더 섹션(62)은 서브 파일(22)의 정확하고 완전한 세트가 파일(12)을 재조립하기 위해 획득되는 것을 보증하는 데 필요한 모든 정보를 포함해야 한다는 것에 유의하라. 이것은 파일 이름 충돌을 충돌 해제하는데 필요한 정보를 포함할 것이다. MD5("Secret File.docx") 및 MD5("Another File.xlsx")가 모두
406166e3412fb30809931e2a640e12bf.subfile
이라는 이름을 제공하는 충돌이 있다면, 네이밍 기능은 그 중 하나에 대한 대체 파일 이름을 생성할 것이다. 그러나, 사용자가 "Secret File.docx" 또는 "Another File.xlsx"를 검색하려고 시도할 때, 알고리즘은 어느 서브 파일(22)이 파일(12)에 속했는지, 그것이 원본 파일 이름을 갖는 지 또는 대체 파일 이름을 갖는지 결정할 수 있을 필요가 있을 것이다. 이것이 데이터 청크(40)가 먼저 생성될 때 네이밍 기능이 제1 저장 단계 후에 실행되어야 하고, 헤더 정보가 서브 파일(22)에 추가될 때 네이밍 기능이 제4 저장 단계 전이나 제4 저장 단계 동안 실행되어야 하는 이유이다.
도 8 내지 12는 컴퓨터 시스템(10)이 저장 장치(16)로부터 저장된 파일(12)을 복구하기 위해 수행하는 일련의 파일 복구 단계들을 도시한다. 사용자가 파일(12)을 검색하기 원할 때, 알고리즘이 가장 먼저 해야 할 것은 장치(16) 내의 어느 서브 파일(22)이 파일(12)을 구성하는지 결정하기 위하여 네이밍 기능을 반복하는 것이다. 그 다음, 필요한 서브 파일(22)이 다운로드되고 복호화되며, 그것이 포함한 데이터가 알고리즘에 제공된다. 이것은 도 8에 예시된 바와 같이 단순히 전술된 제5 및 제6 저장 단계의 반대 동작인 제1 복구 단계이다.
도 9로 예시된 바와 같은 제2 복구 단계에서, 알고리즘은 파일(12)을 재조립하는 데 필요한 모든 서브 파일(22)을 가지고 있다는 것을 확인한다. 이 단계에서 발생할 수 있는 다수의 "문제 시나리오"가 있으며, 그 일부는 도 9에 표현된다. 이것은 하나 이상의 헤더 섹션(62)에서 데이터 손상이 있을 수 있다는 것, 하나 이상의 데이터 섹션(64)에서 데이터 손상이 있을 수 있다는 것, 메타데이터 섹션(46)에서 데이터 손상이 있을 수 있다는 것 및 패딩 섹션(48)에서 데이터 손상이 있을 수 있다는 것을 포함하며, 손상은 X로 표시된다. 네이밍 기능이 어떻게 구현되는지에 따라 그리고 파일 이름 충돌을 어떻게 처리하는지에 따라, 이 시점에서 다운로드된 서브 파일(22)의 일부는 요청된 파일에 전혀 속하지 않을 수 있다는 것에 또한 유의하라. 이 경우에, 헤더 섹션(62)에 존재하는 정보는 네이밍 기능이 정확한 대체 파일 이름을 결정하고 나머지 필요한 서브 파일(22)을 다운로드하여 복호화할 수 있게 할 수 있다. 이 단계는 모든 데이터 손상 문제가 검출되는 것을 보증하도록 충분한 무결성을 제공해야 한다. 또한, 적절한 무결성 데이터가 헤더 섹션(62)에서 사용 가능하다면, 데이터 손상의 일부 형태는 이 단계에서 정정될 수 있다. 그러나, 이 단계의 주요 작업은 오류를 정정하는 것이 아니라, 단지 모든 필요한 데이터가 존재하는 것을 보장하고 오류가 있는 임의의 데이터를 검출하는 것이다.
도 10으로 예시된 바와 같은 제3 복구 단계에서, 알고리즘은 제2 복구 단계에서 복구된 데이터에서 검출된 모든 오류를 정정하도록 작용한다. 전술된 "문제 시나리오" 외에도, 이 단계에서 정정될 수 있는 더 큰 오류의 예는 하나 이상의 서브 파일(22)이 제2 복구 단계에서 바로 잡기에는 너무 심하게 손상되었다는 것과, 하나 이상의 서브 파일(22)이 완전히 손실되었고 제1 복구 단계에서 다운로드될 수 없다는 것을 포함한다. 이 단계가 정정할 수 있는 오류의 양은 제3 저장 단계에서 사용자 선호도에 따라 수행되었던 파일(12)의 원본 저장 시에 얼마나 많은 중복 데이터가 생성되었는지에 완전히 의존한다. 헤더 섹션(62)에서의 정보는 어느 중복 알고리즘(들)이 사용되었는지와 상이한 종류의 오류를 정정하기 위하여 추가 중복 데이터를 어떻게 해석해야 하는지를 알고리즘에 알려준다.
도 11로 예시된 바와 같은 제4 복구 단계에서, 원본 파일의 데이터 및 메타데이터는 모두 데이터 청크(40)의 형태로 알려져 있다. 원본 파일의 메타데이터와 함께 유지된 제1 저장 단계로부터의 원본 파일의 지문은 도 11에 도시되지 않는다. 본질적으로, 이 단계에서 수행되는 모든 것은 서브 파일 헤더 섹션(62)과 패딩 섹션(48)이 더 이상 필요하지 않으므로 이를 버리는 것이다.
도 12로 예시된 바와 같은 제5 복구 단계에서, 원래의 요청된 파일의 이름을 사용하여 파일(12)이 사용자의 로컬 파일 시스템에 생성된다. 데이터 청크(40) 내의 데이터는 순차적으로 파일(12)에 저장되고, 메타데이터 정보는 파일 시스템에 적절한 방식으로 파일 속성에 재적용된다. 이 단계와 인터넷에서 파일을 다운로드하는 보통의 프로세스 사이의 유일한 차이점은 알고리즘이 선택적으로 사용자의 선호도에 따라 파일 속성과 메타데이터를 복원한다는 것이다. 달리 말해서, 파일(12)이 저장 장치(16)로부터 정상적으로 다운로드될 때, 다운로드된 파일은 오늘 날짜에 그것이 다운로드된 시간에 생성되고 수정되었다고 말할 것이다. 다운로드된 파일이 재조립된 후 알고리즘을 사용하면, 알고리즘은, 해당 메타데이터가 청크(40)와 함께 저장되기 때문에, 원하는 경우, 해당 속성을 원래 생성 및 수정 날짜로 구성할 수 있다.
마지막으로 해야 할 것은 사용자가 시작한 원본 파일(12)과 지문 데이터를 재계산하여 이제 재조립된 파일 사이에 차이가 없다는 것을 100% 확실하게 하고, 이를 제4 복구 단계 또는 제1 저장 단계로부터 획득된 것과 비교하는 것이다. 이것은 제1 저장 단계에서 수행된 동일한 무결성 기능을 반복하고, 결과가 일치하는 것을 확실하게 한다. 지문이 일치하면, 알고리즘이 시작했던 파일(12)과 알고리즘이 사용자에게 다시 제공한 파일(12)이 100% 동일하다는 것이 보증된다.
전술한 논의는 단지 본 개시 내용의 예시적인 실시예들을 개시하고 설명한다. 당해 업계에서의 통상의 기술자는 이러한 논의로부터 그리고 첨부된 도면과 청구범위로부터 다양한 변경, 수정 및 변동이 이어지는 청구범위에서 정의된 본 개시 내용의 사상과 범위로부터 벗어나지 않으면서 이루어질 수 있다는 것을 쉽게 인식할 것이다.

Claims (20)

  1. 컴퓨터 파일을 저장하고 복구하기 위한 방법에 있어서,
    상기 파일의 지문 데이터를 계산하는 단계;
    상기 파일을 각각 동일한 크기를 갖는 복수의 데이터 서브 파일과, 다른 데이터 서브 파일보다 더 작은 크기를 갖는 단일 데이터 서브 파일로 분리하는 단계;
    파일 메타데이터를 상기 단일 데이터 서브 파일에 첨부하거나, 메타데이터 서브 파일로서 첨부하는 단계;
    상기 복수의 데이터 서브 파일과 동일한 크기를 갖도록 상기 메타데이터를 포함하는 상기 단일 서브 파일을 패딩하거나, 상기 복수의 데이터 서브 파일과 동일한 크기를 갖도록 상기 메타데이터 서브 파일을 패딩하는 단계;
    각각 상기 복수의 데이터 서브 파일과 동일한 크기를 갖는 복수의 중복(redundancy) 서브 파일을 생성하는 단계;
    각각의 데이터 및 중복 서브 파일에 상기 서브 파일에 관한 정보를 포함하는 헤더를 추가하는 단계;
    각각의 데이터 및 중복 서브 파일에 고유 파일 이름을 할당하는 단계;
    각각의 데이터 및 중복 서브 파일을 암호화하는 단계; 및
    각각의 데이터 및 중복 서브 파일을 자신의 고유 파일 이름으로 별도의 파일로서 저장하는 단계
    를 포함하는, 방법.
  2. 제1항에 있어서,
    상기 파일과 연관된 저장된 상기 데이터 및 중복 서브 파일을 식별하는 단계;
    식별된 상기 데이터 및 중복 서브 파일을 복호화하는 단계;
    상기 서브 파일 헤더를 이용하여 복호화된 상기 데이터 서브 파일에서 무결성 오류를 검출하는 단계;
    상기 중복 파일을 사용하여 무결성 오류를 갖는 상기 데이터 서브 파일을 재구축하는 단계;
    상기 데이터 서브 파일로부터 상기 헤더 및 패딩을 제거하는 단계;
    복호화되고 재구축된 상기 데이터 서브 파일 및 상기 메타데이터를 사용하여 상기 파일을 재구성하는 단계; 및
    상기 지문 데이터를 이용하여 재구성된 상기 파일이 완전한지 판단하는 단계
    를 더 포함하는, 방법.
  3. 제1항에 있어서,
    각각의 서브 파일에 공통 파일 유형을 할당하는 단계를 더 포함하고, 각각의 데이터 및 중복 서브 파일을 저장하는 단계는 각각의 데이터 및 중복 서브 파일을 상기 파일 유형으로 저장하는 단계를 포함하는, 방법.
  4. 제1항에 있어서,
    지문 데이터를 계산하는 단계는, 해시 함수 또는 메시지 인증 코드(message authentication code(MAC))를 사용하는 단계를 포함하는, 방법.
  5. 제1항에 있어서,
    상기 파일을 복수의 데이터 서브 파일로 분리하는 단계는, 성능, 저장 효율성 및 보안에 대한 미리 결정된 사용자 선호도에 기초하여 수행되는, 방법.
  6. 제1항에 있어서,
    헤더를 추가하는 단계는, 상기 서브 파일의 파일 이름 또는 ID, 상기 파일을 구성하는 서브 파일의 전체 개수, 각각의 서브 파일이 일부가 되는 상기 파일의 파일 이름 또는 ID, 서브 파일의 시퀀스에서의 다른 서브 파일에 대한 포인터, 상기 헤더의 기본 체크섬(basic checksum), 상기 지문 데이터, 어느 무결성 알고리즘이 사용되었는지에 관한 정보와 무결성 데이터가 해석되어야 하는 방법에 영향을 미치는 사용자 선호도로부터 도출된 임의의 시드 값(seed value) 및 임의의 암호화 동작에 대한 초기화 벡터 및/또는 논스(nonce) 중 하나 이상을 갖는 헤더를 추가하는 단계를 포함하는, 방법,
  7. 제1항에 있어서,
    각각의 데이터 및 중복 서브 파일에 고유 파일 이름을 할당하는 단계는, 해시 함수 또는 다른 암호화 함수를 사용하는 단계를 포함하는, 방법.
  8. 제1항에 있어서,
    각각의 데이터 및 중복 서브 파일에 고유 파일 이름을 할당하는 단계는, 의사 랜덤 캐릭터 시퀀스를 할당하는 단계를 포함하는, 방법.
  9. 제1항에 있어서,
    각각의 데이터 및 중복 서브 파일에 고유 파일 이름을 할당하는 단계는, 파일 이름 충돌을 방지하는 단계를 포함하는, 방법.
  10. 제1항에 있어서,
    각각의 데이터 및 중복 서브 파일을 저장하는 단계는, 각각의 데이터 및 중복 서브 파일을 클라우드에 저장하거나, 로컬 또는 네트워크 파일 시스템에 저장하는 단계를 포함하는, 방법.
  11. 컴퓨터 파일을 저장하고 복구하기 위한 방법에 있어서,
    상기 파일의 지문 데이터를 계산하는 단계;
    상기 파일을 복수의 데이터 서브 파일로 분리하는 단계;
    파일 메타데이터를 상기 데이터 서브 파일 중 하나에 첨부하거나, 메타데이터 서브 파일로서 첨부하는 단계;
    각각의 데이터 서브 파일에 상기 서브 파일에 관한 정보를 포함하는 헤더를 추가하는 단계;
    각각의 데이터 서브 파일에 고유 파일 이름을 할당하는 단계;
    각각의 데이터 서브 파일을 암호화하는 단계; 및
    각각의 데이터 서브 파일을 자신의 고유 파일 이름으로 별도의 파일로서 저장하는 단계
    를 포함하는, 방법.
  12. 제11항에 있어서,
    상기 파일과 연관된 저장된 상기 데이터 서브 파일을 식별하는 단계;
    식별된 상기 데이터 서브 파일을 복호화하는 단계;
    상기 서브 파일 헤더를 이용하여 복호화된 상기 데이터 서브 파일에서 무결성 오류를 검출하는 단계;
    상기 데이터 서브 파일로부터 상기 헤더를 제거하는 단계;
    복호화된 상기 데이터 서브 파일 및 상기 메타데이터를 사용하여 상기 파일을 재구성하는 단계; 및
    상기 지문 데이터를 이용하여 재구성된 상기 파일이 완전한지 판단하는 단계
    를 더 포함하는, 방법.
  13. 제11항에 있어서,
    각각의 서브 파일에 공통 파일 유형을 할당하는 단계를 더 포함하고, 각각의 데이터 서브 파일을 저장하는 단계는 각각의 데이터 서브 파일을 상기 파일 유형으로 저장하는 단계를 포함하는, 방법.
  14. 제11항에 있어서,
    지문 데이터를 계산하는 단계는, 해시 함수 또는 메시지 인증 코드(message authentication code(MAC))를 사용하는 단계를 포함하는, 방법.
  15. 제11항에 있어서,
    상기 파일을 복수의 데이터 서브 파일로 분리하는 단계는, 성능, 저장 효율성 및 보안에 대한 미리 결정된 사용자 선호도에 기초하여 수행되는, 방법.
  16. 컴퓨터 파일을 저장하고 복구하기 위한 시스템에 있어서,
    상기 파일의 지문 데이터를 계산하는 수단;
    상기 파일을 각각 동일한 크기를 갖는 복수의 데이터 서브 파일과, 다른 데이터 서브 파일보다 더 작은 크기를 갖는 단일 데이터 서브 파일로 분리하는 수단;
    파일 메타데이터를 상기 단일 데이터 서브 파일에 첨부하거나, 메타데이터 서브 파일로서 첨부하는 수단;
    상기 복수의 데이터 서브 파일과 동일한 크기를 갖도록 상기 메타데이터를 포함하는 상기 단일 서브 파일을 패딩하거나, 상기 복수의 데이터 서브 파일과 동일한 크기를 갖도록 상기 메타데이터 서브 파일을 패딩하는 수단;
    각각의 데이터 서브 파일에 상기 서브 파일에 관한 정보를 포함하는 헤더를 추가하는 수단;
    각각의 데이터 서브 파일에 고유 파일 이름을 할당하는 수단;
    각각의 데이터 서브 파일을 암호화하는 수단; 및
    각각의 데이터 서브 파일을 자신의 고유 파일 이름으로 별도의 파일로서 저장하는 수단
    을 포함하는, 시스템.
  17. 제16항에 있어서,
    각각 상기 복수의 데이터 서브 파일과 동일한 크기를 갖는 복수의 중복(redundancy) 서브 파일을 생성하는 수단;
    각각의 중복 서브 파일에 상기 서브 파일에 관한 정보를 포함하는 헤더를 추가하는 수단;
    각각의 중복 서브 파일에 고유 파일 이름을 할당하는 수단;
    각각의 중복 서브 파일을 암호화하는 수단; 및
    각각의 중복 서브 파일을 자신의 고유 파일 이름으로 별도의 파일로 저장하는 수단
    을 더 포함하는, 시스템.
  18. 제16항에 있어서,
    상기 파일과 연관된 저장된 상기 데이터 서브 파일을 식별하는 수단;
    식별된 상기 데이터 서브 파일을 복호화하는 수단;
    상기 데이터 서브 파일로부터 상기 헤더 및 패딩을 제거하는 수단;
    복호화되고 재구축된 상기 데이터 서브 파일 및 상기 메타데이터를 사용하여 상기 파일을 재구성하는 수단; 및
    상기 지문 데이터를 이용하여 재구성된 상기 파일이 완전한지 판단하는 수단
    을 더 포함하는, 시스템.
  19. 제16항에 있어서,
    각각의 서브 파일에 공통 파일 유형을 할당하는 수단을 더 포함하고, 각각의 데이터 서브 파일을 저장하는 것은 각각의 데이터 서브 파일을 상기 파일 유형으로 저장하는 것을 포함하는, 시스템.
  20. 제16항에 있어서,
    상기 파일을 복수의 데이터 서브 파일로 분리하는 수단은, 성능, 저장 효율성 및 보안에 대한 미리 결정된 사용자 선호도룰 사용하는, 시스템.
KR1020237014825A 2020-11-10 2021-08-19 신뢰할 수 없는 환경에서 저장된 데이터 및 메타데이터의 기밀성과 무결성을 보장하는 방법 KR20230104877A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/093,818 US11580091B2 (en) 2020-11-10 2020-11-10 Method of ensuring confidentiality and integrity of stored data and metadata in an untrusted environment
US17/093,818 2020-11-10
PCT/US2021/046620 WO2022103463A1 (en) 2020-11-10 2021-08-19 Method of ensuring confidentiality and integrity of stored data and metadata in an untrusted environment

Publications (1)

Publication Number Publication Date
KR20230104877A true KR20230104877A (ko) 2023-07-11

Family

ID=77897713

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237014825A KR20230104877A (ko) 2020-11-10 2021-08-19 신뢰할 수 없는 환경에서 저장된 데이터 및 메타데이터의 기밀성과 무결성을 보장하는 방법

Country Status (4)

Country Link
US (1) US11580091B2 (ko)
EP (1) EP4244749A1 (ko)
KR (1) KR20230104877A (ko)
WO (1) WO2022103463A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115757300A (zh) * 2022-12-22 2023-03-07 北京航星永志科技有限公司 电子文件封装方法以及电子文件解封读取方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1596276A3 (en) * 2000-04-05 2005-11-23 Seiko Epson Corporation Methods for creating printing data and for transferring printing data
US7448077B2 (en) 2002-05-23 2008-11-04 International Business Machines Corporation File level security for a metadata controller in a storage area network
US7454406B2 (en) 2005-04-29 2008-11-18 Adaptec, Inc. System and method of handling file metadata
US8099605B1 (en) 2006-06-05 2012-01-17 InventSec AB Intelligent storage device for backup system
US7949693B1 (en) * 2007-08-23 2011-05-24 Osr Open Systems Resources, Inc. Log-structured host data storage
US8589700B2 (en) 2009-03-04 2013-11-19 Apple Inc. Data whitening for writing and reading data to and from a non-volatile memory
CA2795206C (en) 2010-03-31 2014-12-23 Rick L. Orsini Systems and methods for securing data in motion
US20120051657A1 (en) * 2010-08-30 2012-03-01 Microsoft Corporation Containment coefficient for identifying textual subsets
WO2012122175A1 (en) 2011-03-07 2012-09-13 Security First Corp. Secure file sharing method and system
US9268964B1 (en) 2011-04-04 2016-02-23 Symantec Corporation Techniques for multimedia metadata security
US20160239683A1 (en) * 2013-03-15 2016-08-18 Inder-Jeet Singh Gujral System and method for securely storing files
US10452849B2 (en) 2016-03-28 2019-10-22 Brydge Technologies LLC Method and apparatus for isolating an electronic device from external data signals

Also Published As

Publication number Publication date
US11580091B2 (en) 2023-02-14
EP4244749A1 (en) 2023-09-20
US20220147508A1 (en) 2022-05-12
WO2022103463A1 (en) 2022-05-19

Similar Documents

Publication Publication Date Title
US11182247B2 (en) Encoding and storage node repairing method for minimum storage regenerating codes for distributed storage systems
US8190662B2 (en) Virtualized data storage vaults on a dispersed data storage network
US7539867B2 (en) On-disk file format for a serverless distributed file system
Curtmola et al. Robust remote data checking
JP4991283B2 (ja) コンテンツベースのアドレシングにおける追加ハッシュ関数
US7895666B1 (en) Data structure representation using hash-based directed acyclic graphs and related method
Storer et al. POTSHARDS: secure long-term storage without encryption
US7478243B2 (en) On-disk file format for serverless distributed file system with signed manifest of file modifications
US8826023B1 (en) System and method for securing access to hash-based storage systems
CN113221155B (zh) 一种多层级与多等级加密的云储存系统
Oprea et al. Integrity Checking in Cryptographic File Systems with Constant Trusted Storage.
Virvilis et al. A cloud provider-agnostic secure storage protocol
KR20230104877A (ko) 신뢰할 수 없는 환경에서 저장된 데이터 및 메타데이터의 기밀성과 무결성을 보장하는 방법
Haubert et al. Tamper-resistant storage techniques for multimedia systems
Jiang et al. An anti-forensic method based on rs coding and distributed storage
Oprea Efficient cryptographic techniques for securing storage systems
Jiang et al. Semi-shadow file system: An anonymous files storage solution
Awale Secure Auditing and Data Deduplication in the Cloud
Chen New directions for remote data integrity checking of cloud storage
Appliance POTSHARDS: Secure Long-Term Storage Without Encryption
Chen et al. Enabling Data Integrity Protection in Regenerating-Coding-Based Cloud Storage: Theory and Implementation (Supplementary File)
Rokade et al. SDDMCSS: Secure and Data De-duplicated Multi-Cloud Storage System
Chondros et al. A distributed Integrity Catalog for digital repositories