petriY initial

Views:
 
     
 

Presentation Description

No description available.

Comments

By: jdockal (143 month(s) ago)

I possibilbe to receive presentation "Secure storage" written by Petri Yllo 30.7.2007? Jaroslav Dockal jaroslav.dockal@unob.cz or jdockaldsm@gmail.com

Presentation Transcript

Secure storage: 

Secure storage Papers AES-CBC + Elephant diffuser A Disk Encryption Algorithm for Windows Vista Niels Ferguson, Microsoft, niels@microsoft.com August 2006 How to Manage Persistent State in DRM Systems William Shapiro and Radek Vingralek August 2001 Presentation by Petri Yllö 30.3.2007

Overview, example system model: 

read and write Overview, example system model Confidentiality imple-mented with encryption Integrity options Implicit: meaningful decryption output Explicit: Message Authentication Code (MAC) stored with data records Reply attack detected by comparing counters Hard disk encrypted data MAC copy of counter RAM volatile memory TPM (persistent) one way counter encryption key ROM boot start code encryption application security perimeter attack

BitLocker: 

BitLocker Enterprise and Ultimate editions of Windows Vista Target: protect data on lost laptop’s HD. Protects logical OS volume. Requires another 1,5 GB 'system volume'. Cryptographic keys stored on TPM, USB or PIN TPM is primary option. Easiest for user, but enables hardware-based attacks. OS decryption available, once OS kernel is loaded.

Attack model: 

Attack model The attacker has many known (but not chosen) plaintext/ciphertext pairs for different sectors. The attacker has the ciphertexts for a large number of chosen plaintexts for different sectors. The plaintexts are chosen before the attacker gets access to the laptop. The attacker has access to a slow decryption function for some of the sectors. The attacker gets several ciphertexts of plaintexts for the same sector with a known (but not chosen) difference. The attacker succeeds if he can modify a ciphertext such that the corresponding plaintext change has some non-random property.

Secure boot: 

Secure boot TPM v1.2 PCR’s are used to keep track of the code that runs. Encryption key is sealed against a particular set of PCR values. At power-up the processor starts running the BIOS from ROM (secure code). Extends the BIOS PCR with the entire BIOS code and proceeds with the rest of the BIOS startup. MBR of the hard disk, extends the boot sector PCR with the sector's data, and then executes the code in the boot sector. All newly-loaded code before the switch point is first measured using an extend function before it is executed. At the switch point the TPM unseals the BitLocker volume encryption key. After the switch, all further data is read from the encrypted volume. Any change to the code, requires that the keys be re-sealed to the new PCR values. Switch to using BitLocker encryption at the first opportunity.

Authentication of the data on the disk : 

Authentication of the data on the disk No practical solution to add MAC to each encrypted block. Encryption per sector basis No extra room for additional data Poor-man’s authentication Changes in the ciphertext will crash the machine rather than helping the attacker Second line of defense ignored: digital signatures on executables

The Cipher: AES-CBC + Elephant diffuser: 

The Cipher: AES-CBC + Elephant diffuser Advanced Encryption Standard (AES) was adopted in 2001 as a successor to DES In Cipher Block Chaining (CBC) mode, the plaintext is XORed with an Initial Vector (IV) and then encrypted. By default sector and AES keys 128 bit, 256 bit version also available Diffuser added to make manipulation attacks harder. At least as secure as AES-CBC 30 clock cycles/byte on Pentium 4, faster than peak data rate from disk An option with only AES-CBC is available for those few customers that have formal requirements to only use government-approved encryption algorithms.

The cipher : 

The cipher IVs:= E(KAES, e(s)) Ks := E(Ksec, e(s)) || E(Ksec, e’(s)) Diffuser Decrypt A: for i = 0,1,2,,,,n * Acycles - 1 : di ← di + (di-2 XOR (di-5 andlt;andlt;andlt; R(a)i mod 4)) Encrypt A: for i = n * Acycles – 1,,,,2,1,0 : di ← di - (di-2 XOR (di-5 andlt;andlt;andlt; R(a)i mod 4)) Decrypt B: for i = 0,1,2,,,,n * Bcycles - 1 : di ← di + (di+2 XOR (di+5 andlt;andlt;andlt; R(b)i mod 4)) Encrypt B: for i = n * Bcycles - 1,,,,,2,1,0 : di ← di - (di+2 XOR (di+5 andlt;andlt;andlt; R(b)i mod 4))

DRM Systems: 

DRM Systems Secure binding of digital content to a contract The contract conditionally grants the user the right to access the content and it enforces consequences Typically distributed systems, with content delivered from servers. Persistent data includes The content itself. Certificates used for authentication and authorization in the DRM system. Account balances or usage counters. Start dates used by subscription contracts. Auxiliary data used to support efficient or disconnected operation of clients (such as content decryption keys).

DRM Requirements: 

DRM Requirements Fault tolerance Atomicity, isolation, durability Security Secrecy, tamper-detection, prevent reply attack Performance Resource consumption Scalability

Mechanisms 1: 

Mechanisms 1 Server based data repositories (locker services) Physically secured Accidental corruption reduced Performance penalty No offline content consumption

Mechanisms 2: Secure memories: 

Mechanisms 2: Secure memories Merkle tree – on line tamper detector Tree structure for better performance with limited secure memory

Mechanisms 3: Secure audit logs: 

Mechanisms 3: Secure audit logs Log user transactions in a local secured log Encryption to provide data secrecy Linear chain of hash links to every element in the log provide tamper detection. The hash of the end of the log is periodically sent to a remote server Sequence numbers in the log are used to prevent the replay attack. Truncation entries after last sent to a remote server could go undetected.

Mechanisms 4: Secure file systems: 

Mechanisms 4: Secure file systems Secrecy: encrypted file systems Tamper detection SFS-RO many users access read-only files Uses a tree of hashes to verify the content The root inode, is signed with the private key of the file system Protected File System (PFS) cryptographic hashes over all data and meta-data blocks to detect any tampering no protection against replay attacks. SUNDR no protection against replay attack

Mechanisms 5: Secure database TDB: 

Mechanisms 5: Secure database TDB Log-structured Merkle tree implementation Secrecy by encryption of chunks with a secret key from ROM Tamper-detection by signing the commit chunks with a secret key from ROM Replay attack is prevented by adding the one-way counter to the commit chunk Fine grained recovery based on transactions Transactions committed by adding a commit chunk to the log Location map is updated to stable memory only at a checkpoint

Mechanisms 6: GnatDb: 

Mechanisms 6: GnatDb For small databases simplified store at the cost of performance Location map is an array

DRM Conclusion: 

DRM Conclusion Avoid persistent state requirement in clients Access to named records and transactional semantics for updates Ideally wanted a database system that provided both secrecy and tamper detection Best choice: TDB or GnatDB for small devices Log structured storage benefits tamper-detection atomic updates copy-on-write snapshots for fast backups concentrating all writes in a few blocks traffic analysis harder

authorStream Live Help