DOCSLIB.ORG

System Z Cryptographic Services and Z/OS PKI Services

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
System Z Cryptographic Services and Z/OS PKI Services Front cover System z Cryptographic Services and z/OS PKI Services Hardware cryptography monitoring PKCS#11 support on z/OS Java cryptography Guillaume Hoareau Nikhil V Kapre MuHyun Kim Patrick Kappeler Gerard Laumay Jonathan Barney Joel Porterie Jean Marc Darees Vicente Ranieri, Jr. Pekka Hanninen Dominique Richard Robert Herman Daniel L. Turkenkopf ibm.com/redbooks International Technical Support Organization System z Cryptographic Services and z/OS PKI Services May 2008 SG24-7470-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (May 2008) This edition applies to Version 1, Release 9 of z/OS (product number 5694-A01). © Copyright International Business Machines Corporation 2008. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this book . ix Become a published author . xi Comments welcome. xi Part 1. Using cryptography with advanced technologies . 1 Chapter 1. System z cryptography infrastructure . 3 1.1 Message-security assist . 4 1.2 Cryptographic hardware . 9 1.2.1 CP Assist for Cryptographic Functions (CPACF) . 10 1.2.2 Cryptographic Coprocessor Feature (CCF) . 12 1.2.3 PCI Cryptographic Accelerator (PCICA) . 13 1.2.4 PCI-X Cryptographic Coprocessor (PCIXCC). 14 1.2.5 Crypto Express 2 Feature . 17 1.2.6 Comparison of CPACF, CEX2C, and CEX2A. 19 1.3 IBM Common Cryptographic Architecture. 20 1.3.1 Rationale for the IBM CCA . 20 1.3.2 CCA callable services . 21 1.3.3 DES key management . 24 1.3.4 PKA key management . 30 1.4 ICSF . 34 1.4.1 Audit trails . 38 1.5 Logical partitioning and System z hardware cryptography exploitation. 38 1.6 Monitoring the cryptographic workload on z/OS . 39 1.7 Sysplex and System z hardware cryptography . 40 1.8 Software requirements . 40 Chapter 2. Hardware cryptography activity assessment on System z . 41 2.1 What is exploiting the System z hardware cryptography?. 42 2.1.1 Hardware cryptography exploitation on z/OS . 42 2.1.2 Hardware cryptography exploitation in Linux on System z . 46 2.2 Assessing the use of hardware cryptography on z/OS . 47 2.2.1 Detecting the use of RACF-protected cryptographic resources . 47 2.2.2 z/OS System SSL example. 49 2.2.3 The ICSF component trace. 56 2.3 Assessing the use of hardware cryptography on z/VSE . 58 2.4 Assessing the use of hardware cryptography on Linux on System z . 58 2.4.1 Status of the z90crypt device driver . 59 2.4.2 Collecting information about hardware cryptography activity . 60 2.4.3 Programs that invoke hardware cryptography . 61 2.5 Setting up hardware cryptography configuration of z/VM . 61 2.5.1 Checking the hardware cryptography configuration with z/VM . 63 © Copyright IBM Corp. 2008. All rights reserved. iii Chapter 3. Measuring hardware cryptography activity on z/OS with RMF . 65 3.1 Overview of ICSF cryptographic workload balancing . 66 3.2 SMF reporting of hardware cryptography activity . 66 3.3 Using RMF to measure the z/OS hardware cryptography activity. 68 3.3.1 RMF data collection infrastructure for hardware cryptography . 69 3.4 RMF post-processor reports . 70 3.4.1 Crypto Hardware Activity RMF report . 71 3.4.2 Crypto Hardware Activity report example . 74 3.4.3 Crypto Hardware Activity report without local activity . 75 3.4.4 Workload Activity report . 75 3.4.5 Overview report. 77 Chapter 4. Assessing activity with OMEGAMON XE on z/OS and RMF. 79 4.1 Tivoli OMEGAMON XE on z/OS - Cryptographic coprocessor support . 80 4.2 OMEGAMON XE on z/OS graphical interface . 81 4.3 Measuring activity with RMF and OMEGAMON XE on z/OS . 82 4.3.1 SHA-1 activity (CPACF activity) . 82 4.3.2 CEX2C activity . 85 4.3.3 CEX2A activity . 86 4.4 Using the OMEGAMON XE on z/OS Service Call Performance workspace. 88 Chapter 5. Java cryptography . 91 5.1 Java cryptography. 92 5.1.1 Cryptography overview . 92 5.1.2 Types of encryption algorithms . 95 5.1.3 Key-management challenge . 98 5.1.4 Java cryptography in z/OS . 99 5.2 Cryptography providers on z/OS. 102 5.2.1 How to select a provider (registering a provider in the java.security file) . 103 5.2.2 JCE - Java Cryptography Extension . 103 5.2.3 JCECCA - JCE using CCA hardware cryptographic devices on z/OS . 104 5.2.4 CertPath - Certificate generation and path validation . 104 5.2.5 JSSE - Java Secure Sockets Extension (SSL and TLS). 105 5.2.6 Map the providers and algorithms. 105 5.3 Setting up hardware cryptographic features . 106 5.3.1 Policy files . 107 5.4 Keystore and SAF digital certificates (keyrings) . 107 5.4.1 JCEKS . 108 5.4.2 JCECCAKS. 110 5.4.3 JCERACFKS. 114 5.4.4 JCECCARACFKS . 116 5.5 Tools . 120 5.5.1 Software keytool . ..
Load more

Recommended publications
  • Horizontal PDF Slides
    1 2 Speed, speed, speed $1000 TCR hashing competition D. J. Bernstein Crowley: “I have a problem where I need to make some University of Illinois at Chicago; cryptography faster, and I’m Ruhr University Bochum setting up a $1000 competition funded from my own pocket for Reporting some recent work towards the solution.” symmetric-speed discussions, Not fast enough: Signing H(M), especially from RWC 2020. where M is a long message. Not included in this talk: “[On a] 900MHz Cortex-A7 NISTLWC. • [SHA-256] takes 28.86 cpb ::: Short inputs. • BLAKE2b is nearly twice as FHE/MPC ciphers. • fast ::: However, this is still a lot slower than I’m happy with.” 1 2 3 Speed, speed, speed $1000 TCR hashing competition Instead choose random R and sign (R; H(R; M)). D. J. Bernstein Crowley: “I have a problem where I need to make some Note that H needs only “TCR”, University of Illinois at Chicago; cryptography faster, and I’m not full collision resistance. Ruhr University Bochum setting up a $1000 competition Does this allow faster H design? funded from my own pocket for TCR breaks how many rounds? Reporting some recent work towards the solution.” symmetric-speed discussions, Not fast enough: Signing H(M), especially from RWC 2020. where M is a long message. Not included in this talk: “[On a] 900MHz Cortex-A7 NISTLWC. • [SHA-256] takes 28.86 cpb ::: Short inputs. • BLAKE2b is nearly twice as FHE/MPC ciphers. • fast ::: However, this is still a lot slower than I’m happy with.” 1 2 3 Speed, speed, speed $1000 TCR hashing competition Instead choose random R and sign (R; H(R; M)).
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 9,514,285 B2 Durham Et Al
    USO09514285B2 (12) United States Patent (10) Patent No.: US 9,514,285 B2 Durham et al. (45) Date of Patent: Dec. 6, 2016 (54) CREATING STACK POSITION DEPENDENT (56) References Cited CRYPTOGRAPHC RETURN ADDRESS TO MTGATE RETURN ORIENTED U.S. PATENT DOCUMENTS PROGRAMMING ATTACKS 7.853,803 B2 * 12/2010 Milliken ................. GO6F 21/52 713, 176 (71) Applicant: Intel Corporation, Santa Clara, CA 2014/0173293 A1* 6/2014 Kaplan ................... G06F 21.54 (US) T13, 190 (72) Inventors: David M. Durham, Beaverton, OR OTHER PUBLICATIONS (US); Baiju V. Patel, Portland, OR “Disk encryption theory,” available at http://en.wikipedia.org/wiki/ (US) XEX-TCB-CTS, accessed Dec. 29, 2014, 6 pages. “The Heartbleed bug, available at http://heartbleed.com/, accessed (73) Assignee: Intel Corporation, Santa Clara, CA Dec. 29, 2014, 7 pages. (US) “OpenSSL.” available at http://en.wikipedia.org/wiki/OpenSSL, accessed Dec. 29, 2014, 13 pages. (*) Notice: Subject to any disclaimer, the term of this “Return-oriented programming,' available at http://en.wikipedia. patent is extended or adjusted under 35 org/wiki/Return-oriented programming, accessed Dec. 29, 2014, 4 pageS. U.S.C. 154(b) by 0 days. “Buffer overflow,” available at http://en.wikipedia.org/wiki/Buf (21) Appl. No.: 14/498,521 fer overflow, accessed Dec. 29, 2014, 12 pages. (22) Filed: Sep. 26, 2014 * cited by examiner Primary Examiner — Jacob Lipman (65) Prior Publication Data (74) Attorney, Agent, or Firm — Barnes & Thornburg US 2016/0094.552 A1 Mar. 31, 2016 LLP (51) Int. C. (57) ABSTRACT G6F 2/54 (2013.01) A computing device includes technologies for securing G06F2L/00 (2013.01) return addresses that are used by a processor to control the (52) U.S.
    [Show full text]
  • Trusted Platform Module Library Part 1: Architecture TCG Public Review
    Trusted Platform Module Library Part 1: Architecture Family “2.0” Level 00 Revision 01.50 September 18, 2018 Committee Draft Contact: [email protected] Work in Progress This document is an intermediate draft for comment only and is subject to change without notice. Readers should not design products based on this document. TCG Public Review Copyright © TCG 2006-2019 TCG Trusted Platform Module Library Part 1: Architecture Licenses and Notices Copyright Licenses: Trusted Computing Group (TCG) grants to the user of the source code in this specification (the “Source Code”) a worldwide, irrevocable, nonexclusive, royalty free, copyright license to reproduce, create derivative works, distribute, display and perform the Source Code and derivative works thereof, and to grant others the rights granted herein. The TCG grants to the user of the other parts of the specification (other than the Source Code) the rights to reproduce, distribute, display, and perform the specification solely for the purpose of developing products based on such documents. Source Code Distribution Conditions: Redistributions of Source Code must retain the above copyright licenses, this list of conditions and the following disclaimers. Redistributions in binary form must reproduce the above copyright licenses, this list of conditions and the following disclaimers in the documentation and/or other materials provided with the distribution. Disclaimers: THE COPYRIGHT LICENSES SET FORTH ABOVE DO NOT REPRESENT ANY FORM OF LICENSE OR WAIVER, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, WITH RESPECT TO PATENT RIGHTS HELD BY TCG MEMBERS (OR OTHER THIRD PARTIES) THAT MAY BE NECESSARY TO IMPLEMENT THIS SPECIFICATION OR OTHERWISE. Contact TCG Administration ([email protected]) for information on specification licensing rights available through TCG membership agreements.
    [Show full text]
  • Reference Manual to Mitigate Potential Terrorist Attacks Against Buildings December 2003
    Risk Management Series Reference Manual to Mitigate Potential Terrorist Attacks Against Buildings December 2003 FEMA FEMA 426 FEMA 426 / December 2003 RISK MANAGEMENT SERIES Reference Manual to Mitigate Potential Terrorist Attacks Against Buildings PROVIDING PROTECTION TO PEOPLE AND BUILDINGS www.fema.gov Any opinions, findings, conclusions, or recommendations expressed in this publication do not necessarily reflect the views of FEMA. Additionally, neither FEMA or any of its employees makes any warrantee, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process included in this publication. Users of information from this publication assume all liability arising from such use. he creation of the Department of Homeland Security (DHS) is one of the most significant transformations in the Federal Government in decades, establishing a department T whose first priority is to protect the nation against terrorist attacks. Within the DHS, the Directorate of Emergency Preparedness and Response (EP&R) is focused on ensuring that our nation is prepared for catastrophes, including both natural disasters and terrorist assaults. Central to this mission is the protection of people and the critical infrastructure of the built environment. This Reference Manual to Mitigate Potential Terrorist Attacks Against Buildings provides guidance to the building science community of architects and engineers, to reduce physical damage to buildings, related infrastructure, and people caused by terrorist assaults. The comprehensive approach to understanding how to improve security in high occupancy buildings will better protect the nation from potential threats by identifying key actions and design criteria to strengthen our buildings from the forces that might be anticipated in a terrorist assault.
    [Show full text]
  • Encryption Block Cipher
    10/29/2007 Encryption Encryption Block Cipher Dr.Talal Alkharobi 2 Block Cipher A symmetric key cipher which operates on fixed-length groups of bits, termed blocks, with an unvarying transformation. When encrypting, a block cipher take n-bit block of plaintext as input, and output a corresponding n-bit block of ciphertext. The exact transformation is controlled using a secret key. Decryption is similar: the decryption algorithm takes n-bit block of ciphertext together with the secret key, and yields the original n-bit block of plaintext. Mode of operation is used to encrypt messages longer than the block size. 1 Dr.Talal Alkharobi 10/29/2007 Encryption 3 Encryption 4 Decryption 2 Dr.Talal Alkharobi 10/29/2007 Encryption 5 Block Cipher Consists of two algorithms, encryption, E, and decryption, D. Both require two inputs: n-bits block of data and key of size k bits, The output is an n-bit block. Decryption is the inverse function of encryption: D(E(B,K),K) = B For each key K, E is a permutation over the set of input blocks. n Each key K selects one permutation from the possible set of 2 !. 6 Block Cipher The block size, n, is typically 64 or 128 bits, although some ciphers have a variable block size. 64 bits was the most common length until the mid-1990s, when new designs began to switch to 128-bit. Padding scheme is used to allow plaintexts of arbitrary lengths to be encrypted. Typical key sizes (k) include 40, 56, 64, 80, 128, 192 and 256 bits.
    [Show full text]
  • Improved Masking for Tweakable Blockciphers with Applications to Authenticated Encryption
    Improved Masking for Tweakable Blockciphers with Applications to Authenticated Encryption Robert Granger1, Philipp Jovanovic2, Bart Mennink3, and Samuel Neves4 1 Laboratory for Cryptologic Algorithms, École polytechnique fédérale de Lausanne, Switzerland, [email protected] 2 Decentralized and Distributed Systems Lab, École polytechnique fédérale de Lausanne, Switzerland, [email protected] 3 Dept. Electrical Engineering, ESAT/COSIC, KU Leuven, and iMinds, Belgium, [email protected] 4 CISUC, Dept. of Informatics Engineering, University of Coimbra, Portugal, [email protected] Abstract. A popular approach to tweakable blockcipher design is via masking, where a certain primitive (a blockcipher or a permutation) is preceded and followed by an easy-to-compute tweak-dependent mask. In this work, we revisit the principle of masking. We do so alongside the introduction of the tweakable Even-Mansour construction MEM. Its masking function combines the advantages of word-oriented LFSR- and powering-up-based methods. We show in particular how recent advancements in computing discrete logarithms over finite fields of characteristic 2 can be exploited in a constructive way to realize highly efficient, constant-time masking functions. If the masking satisfies a set of simple conditions, then MEM is a secure tweakable blockcipher up to the birthday bound. The strengths of MEM are exhibited by the design of fully parallelizable authenticated encryption schemes OPP (nonce-respecting) and MRO (misuse-resistant). If instantiated with a reduced-round BLAKE2b permutation, OPP and MRO achieve speeds up to 0.55 and 1.06 cycles per byte on the Intel Haswell microarchitecture, and are able to significantly outperform their closest competitors.
    [Show full text]
  • Salsa20 and Chacha in Deterministic Authenticated Encryption with No Noncense
    Daence: Salsa20 and ChaCha in Deterministic Authenticated Encryption with no noNCEnse Taylor ‘Riastradh’ Campbell [email protected] November 6, 2020 Abstract We present Daence, a deterministic authenticated cipher based on a pseudorandom function family and a universal hash family, similar to siv [35]. We recommend instances with Salsa20 [14] or ChaCha [15], and Poly1305 [13], for high performance, high security, and easy deployment. 1 Introduction The nonce-based authenticated cipher crypto_secretbox_xsalsa20poly1305 in NaCl [16], and the variant ChaCha/Poly1305 defined by the IETF [33] for TLS [31], are widely available in fast software implementations resistant to timing side channels. The nonce-based authenticated cipher AES-GCM [23] is popular, though only with hardware support is it fast and resistant to timing side channels. These nonce-based ciphers fail catastrophically in the face of nonce reuse. They are best suited to protocols that are designed to support sequential message numbers, such as the record number in TLS. Some applications are unable to keep the state needed to maintain a sequential message number, and although they could use an extended nonce like XSalsa20 [17] chosen randomly, some environments may not have a reliable entropy source. The nonce-misuse-resistant authenticated cipher AES-GCM-SIV [24] was developed to address these use cases, but it carries with it the performance and side channel costs of AES-GCM— and amplifies the performance cost by deriving fresh keys for each distinct nonce, yet has very narrow security margins. We propose a deterministic authenticated cipher Daence built out of the Salsa20 or ChaCha pseudorandom function family and the Poly1305 universal hash family.
    [Show full text]
  • Small Universal Deterministic Authenticated Encryption for the Internet of Things
    Downloaded from orbit.dtu.dk on: Oct 01, 2021 SUNDAE Small universal deterministic authenticated encryption for the internet of things Banik, Subhadeep; Bogdanov, Andrey; Luykx, Atul; Tischhauser, Elmar Published in: Iacr Transactions on Symmetric Cryptology Link to article, DOI: 10.13154/tosc.v2018.i3.1-35 Publication date: 2018 Document Version Publisher's PDF, also known as Version of record Link back to DTU Orbit Citation (APA): Banik, S., Bogdanov, A., Luykx, A., & Tischhauser, E. (2018). SUNDAE: Small universal deterministic authenticated encryption for the internet of things. Iacr Transactions on Symmetric Cryptology, 2018(3), 1-35. https://doi.org/10.13154/tosc.v2018.i3.1-35 General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. SUNDAE: Small Universal Deterministic Authenticated Encryption for the Internet of Things Subhadeep Banik1, Andrey Bogdanov2, Atul Luykx3, Elmar Tischhauser2 1 LASEC, École Polytechnique Fédérale de Lausanne, Switzerland [email protected] 2 Technical University of Denmark, Denmark {anbog,ewti}@dtu.dk 3 Visa Research, USA [email protected] Abstract.
    [Show full text]
  • Security Target
    Bivio 6310-NC Security Target 20-5018-R-0006 Version: 0.8 Nov 25, 2020 Prepared For: Bivio Networks, Inc. 4457 Willow Rd Suite 240 Pleasanton, CA, 94588 Prepared By: Ekta Binwani UL Verification Services Inc. Bivio 6310-NC Security Target Notices: ©2020 Bivio Networks, Inc. All rights reserved. All other brand names are trademarks, registered trademarks, or service marks of their respective companies or organizations It is prohibited to copy, reproduce or retransmit the information contained within this documentation without the express written permission of Bivio Networks, Inc. 4457 Willow Road Suite 200, Pleasanton, CA, 94588. Page 2 of 53 Bivio 6310-NC Security Target Table of Contents 1. Security Target (ST) Introduction.................................................................................... 7 1.1 Security Target Reference ........................................................................................... 7 1.2 Target of Evaluation Reference .................................................................................. 7 1.3 Target of Evaluation Overview .................................................................................... 7 1.3.1 TOE Product Type ................................................................................................. 7 1.3.2 TOE Usage .............................................................................................................. 7 1.3.3 TOE Major Security Features Summary ............................................................ 8 1.3.4 TOE IT environment
    [Show full text]
  • Structural Classification of Authenticated Encryption Schemes
    Structural Classifcation of Authenticated Encryption Schemes 1 2 1 1 Avik Chakraborti , Nilanjan Datta , Ashwin Jha and Mridul Nandi 1 Indian Statistical Institute, Kolkata, India {avikchkrbrti,ashwin.jha1991,mridul.nandi}@gmail.com 2 Institute for Advancing Intelligence, TCG CREST, Kolkata, India [email protected] Abstract. In this short note, we aim to give a structural classifcation of modes of operations for authenticated encryption (AEAD). First, we briefy discuss various features that are desirable in an AEAD mode. Then, we classify AEAD modes according to their structure, understand their target area of applications, discuss their basic design goals and associated features. Finally, we give a brief description of each of the 32 second round candidates in NIST LwC project, distributing them in appropriate class based on their structure. Keywords: Lightweight · AEAD · Feedback · Parallel · SIV · Sponge · Stream Cipher 1 Authenticated Encryption Schemes Authenticated encryption (AE) schemes are symmetric-key primitives that achieve both confdentiality and authenticity. An authenticated encryption scheme A is a tuple (E, D) of two algorithms, the encryption algorithm E and the verifed decryption algorithm D. The working principle of any AE scheme A is as follows: Suppose Alice and Bob are two parties sharing a common secret key K. Whenever Alice wants to send a message M to Bob, she sends (C, T ), where the ciphertext-tag pair (C, T ) is the output of encryption algorithm, i.e., (C, T ) = A.E(K, M). When Bob receives a ciphertext-tag pair (C0,T 0), he runs A.D(K, C0,T 0), and gets some message M 0 in case (C0,T 0) is a valid ciphertext-tag pair, referred as (C0,T 0) authenticates successfully, and an error symbol ? when (C0,T 0) is invalid.
    [Show full text]
  • Linux Journal 33 Reality 2.0: a Linux Journal Podcast 34 News Briefs
    Easier Python Write Secure Free Software, paths with pathlib Shell Scripts Open Science and R Since 1994: The original magazine of the Linux community THE SECURITY ISSUE The Heads Project: a Free Software Solution for Secure Booting YubiKey 5 and Web Authentication The New Purism Librem Key Hardware Token Password Manager Roundup De-mystifying X.509 Certificates ISSUE 295 | FEBRUARY 2019 www.linuxjournal.com FEBRUARY 2019 CONTENTS ISSUE 295 62 DEEP DIVE: Security 63 Password Manager Roundup by Shawn Powers If you can remember all of your passwords, they’re not good passwords. 80 Everyday Security Tips by Michael McCallister Make your computer safer with these guidelines based on the Linux Foundation’s Security Checklist developed for corporate systems. 91 Understanding Public Key Infrastructure and X.509 Certificates by Jeff Woods An introduction to PKI, TLS and X.509, from the ground up. 104 WebAuthn Web Authentication with YubiKey 5 by Todd A. Jacobs A look at the recently released YubiKey 5 hardware authenticator series and how web authentication with the new WebAuthn API leverages devices like the YubiKey for painless website registration and strong user authentication. 122 The Purism Librem Key by Todd A. Jacobs The Librem Key is a new hardware token for improving Linux security by adding a physical authentication factor to booting, login and disk decryption on supported systems. 134 Tamper-Evident Boot with Heads by Kyle Rankin Learn about how the cutting-edge, free software Heads project detects BIOS and kernel tampering, all with keys under your control. 2 | February 2019 | https://www.linuxjournal.com CONTENTS 6 The Security Issue by Bryan Lunduke 10 From the Editor—Doc Searls A Line in the Sand 14 Letters UPFRONT 20 Some (Linux) Bugs Have All the Fun by Bryan Lunduke 24 Astronomy Software by Any Other Name by Joey Bernard 32 Patreon and Linux Journal 33 Reality 2.0: a Linux Journal Podcast 34 News Briefs COLUMNS 38 Reuven M.
    [Show full text]
  • Security of Hard Disk Encryption
    Security of Hard Disk Encryption DHIMAN SARMA KTH Information and Communication Technology Master of Science Thesis Stockholm, Sweden 2012 TRITA-ICT-EX-2012:64 TRITA-ICT-EX-2012:64 www.kth.se Security Of Hard Disk Encryption Abstract| Abstract Encryption is the art of preserving confidentiality of digital information. It is considered to be one of the most ideal solutions for providing data confidentiality and safety of computer hard disk. Many disk encryption software are commercially available with a variety of features. But how much effective security is provided by those software is the ultimate question. Encryption algorithms used by those software are vulnerable to known cryptanalysis. Design and implementation weaknesses critically leave backdoors inside those software themselves. Easy and smart methods are used to defeat the software’s security either by manipulating external hardware or by exploiting user unawareness. This thesis evaluates the potential vulnerabilities of commercial hard disk encryption software that are claimed to provide absolute security of hard disk content. i Security Of Hard Disk Encryption Acknowledgement First and foremost, I pay utmost tribute to almighty God for providing me strength. I offer my sincerest gratitude to Prof. Sead Muftic for supervising this thesis. Thanks to my friends and families for their loves and supports. ii Security Of Hard Disk Encryption Table of Contents| Security of Hard Disk Encryption Chapter 1 Introduction 1.1 Problem Statement 1.2 Goal 1.3 Purpose 1.4 Methodology 1.5 Limitations
    [Show full text]