Vmware's BC-FJA (Bouncy Castle FIPS Java API) Software Version: 1.0.2.1

Total Page:16

File Type:pdf, Size:1020Kb

Vmware's BC-FJA (Bouncy Castle FIPS Java API) Software Version: 1.0.2.1 VMware, Inc. 3401 Hillview Ave Palo Alto, CA 94304, USA Tel: 877-486-9273 Email: info@vmware.com http://www. vmware.com VMware's BC-FJA (Bouncy Castle FIPS Java API) Software Version: 1.0.2.1 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 0.1 Security Policy, Version 0.1 VMware's BC-FJA (Bouncy Castle FIPS Java API) TABLE OF CONTENTS 1 INTRODUCTION ......................................................................................................................................... 4 1.1 Purpose......................................................................................................................................................... 4 1.2 Reference ..................................................................................................................................................... 4 2 VMware’s BC-FJA (Bouncy Castle FIPS Java API) Module ............................................................................ 5 2.1 Introduction .................................................................................................................................................. 5 2.1.1 VMware's BC-FJA (Bouncy Castle FIPS Java API) ...................................................................................... 5 2.2 Module Specification .................................................................................................................................... 5 2.2.1 Physical Cryptographic Boundary ............................................................................................................ 6 2.2.2 Logical Cryptographic Boundary .............................................................................................................. 7 2.2.3 Modes of Operation ................................................................................................................................. 7 2.2.4 Module Configuration .............................................................................................................................. 8 2.3 Roles, Authentication and Services .............................................................................................................. 9 2.3.1 Assumption of Roles ................................................................................................................................ 9 2.3.2 Services .................................................................................................................................................... 9 2.4 Physical Security ......................................................................................................................................... 12 2.5 Operational Environment ........................................................................................................................... 12 2.5.1 Use of External RNG ............................................................................................................................... 14 2.6 Cryptographic Key Management ............................................................................................................... 14 2.6.1 Critical Security Parameters ................................................................................................................... 19 2.6.2 Public Keys ............................................................................................................................................. 21 2.7 Self-Tests .................................................................................................................................................... 21 2.8 Mitigation of Other Attacks Policy ............................................................................................................. 23 3 Secure Operation ...................................................................................................................................... 24 3.1 Basic Enforcement ...................................................................................................................................... 24 3.2 Additional Enforcement with a Java SecurityManager .............................................................................. 24 3.3 Basic Guidance ........................................................................................................................................... 24 3.4 Enforcement and Guidance for GCM IVs .................................................................................................... 25 3.5 Enforcement and Guidance for use of the Approved PBKDF ...................................................................... 25 3.6 Rules for setting the N and the S String in cSHAKE ..................................................................................... 25 3.7 Guidance for the use of DRBGs and Configuring the JVM's Entropy Source .............................................. 26 4 References and Acronyms ......................................................................................................................... 27 April 20, 2021 Page 2 of 30 © 2021 VMware, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.1 VMware's BC-FJA (Bouncy Castle FIPS Java API) LIST OF FIGURES Figure 1 – Hardware Block Diagram ......................................................................................................... 6 Figure 2 – Module’s Logical Cryptographic Boundary ........................................................................... 7 LIST OF TABLES Table 1 – Security Level Per FIPS 140-2 Section ........................................................................................ 5 Table 2 – FIPS 140-2 Logical Interfaces ....................................................................................................... 7 Table 3 – Available Java Permissions .......................................................................................................... 8 Table 4 – Roles Description .......................................................................................................................... 9 Table 5 – Services ........................................................................................................................................ 9 Table 6 – CSP Access Rights within Services ............................................................................................ 11 Table 7 – Tested Configuration ................................................................................................................... 12 Table 8 – Approved and CAVP Validated Cryptographic Functions .......................................................... 15 Table 9 – Approved Cryptographic Functions Tested with Vendor Affirmation .......................................... 17 Table 10 – Non-Approved but Allowed Cryptographic Functions ............................................................... 18 Table 11 – Non-Approved Cryptographic Functions for use in non-FIPS mode only ................................. 18 Table 12 – Critical Security Parameters (CSPs) ......................................................................................... 20 Table 13 – Public Keys ............................................................................................................................... 21 Table 14 – Power Up Self-tests .................................................................................................................. 22 Table 15 – Conditional Self-tests ................................................................................................................ 23 Table 16 – References ................................................................................................................................ 27 Table 17 – Acronyms .................................................................................................................................. 28 April 20, 2021 Page 3 of 30 © 2021 VMware, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.1 VMware's BC-FJA (Bouncy Castle FIPS Java API) 1 INTRODUCTION 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the VMware's BC-FJA (Bouncy Castle FIPS Java API) Module from VMware, Inc. This Security Policy describes how the VMware's BC-FJA (Bouncy Castle FIPS Java API) Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS), a branch of the Communications Security Establishment (CSE), Cryptographic Module Validation Program (CMVP) website at https://csrc.nist.gov/projects/cryptographic-module-validation- program. This document also describes how to run the module in a secure FIPS-Approved mode of operation. The VMware's BC-FJA (Bouncy Castle FIPS Java API) Module is also referred to in this document as “BC-FJA Module”, or “the module”. 1.2 Reference This document deals only with operations and capabilities of the composite module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources:
Recommended publications
  • PHC: Status Quo
    PHC: status quo JP Aumasson @veorq / http://aumasson.jp academic background principal cryptographer at Kudelski Security, .ch applied crypto research and outreach BLAKE, BLAKE2, SipHash, NORX Crypto Coding Standard Password Hashing Competition Open Crypto Audit Project board member do you use passwords? this talk might interest you! Oct 2013 "hash" = 3DES-ECB( static key, password ) users' hint made the guess game easy... (credit Jeremi Gosney / Stricture Group) May 2014; "encrypted passwords" (?) last week that's only the reported/published cases Lesson if Adobe, eBay, and Avast fail to protect their users' passwords, what about others? users using "weak passwords"? ITsec people using "weak defenses"? developers using "weak hashes"? cryptographers, who never bothered? agenda 1. how (not) to protect passwords 2. the Password Hashing Competition (PHC) 3. the 24-2 PHC candidates 4. next steps, and how to contribute WARNING this is NOT about bikeshed topics as: password policies password managers password-strength meters will-technology-X-replace-passwords? 1. how (not) to protect passwords solution of the 60's store "password" or the modern alternative: obviously a bad idea (assuming the server and its DB are compromised) solution of the early 70's store hash("password") "one-way": can't be efficiently inverted vulnerable to: ● efficient dictionary attacks and bruteforce ● time-memory tradeoffs (rainbow tables, etc.) solution of the late 70's store hash("password", salt) "one-way": can't be efficiently inverted immune to time-memory tradeoffs vulnerable to: ● dictionary attacks and bruteforce (but has to be repeated for different hashes) solution of the 2000's store hash("password", salt, cost) "one-way": can't be efficiently inverted immune to time-memory tradeoffs inefficient dictionary attacks and bruteforce main ideas: ● be "slow" ● especially on attackers' hardware (GPU, FPGA) => exploit fast CPU memory access/writes PBKDF2 (Kaliski, 2000) NIST and PKCS standard in Truecrypt, iOS, etc.
    [Show full text]
  • SPHINCS: Practical Stateless Hash-Based Signatures
    SPHINCS: practical stateless hash-based signatures Daniel J. Bernstein1;3, Daira Hopwood2, Andreas Hülsing3, Tanja Lange3, Ruben Niederhagen3, Louiza Papachristodoulou4, Peter Schwabe4, and Zooko Wilcox O'Hearn2 1 Department of Computer Science University of Illinois at Chicago Chicago, IL 606077045, USA djb@cr.yp.to 2 Least Authority 3450 Emerson Ave. Boulder, CO 803056452 USA daira@leastauthority.com,zooko@leastauthority.com 3 Department of Mathematics and Computer Science Technische Universiteit Eindhoven P.O. Box 513, 5600 MB Eindhoven, The Netherlands tanja@hyperelliptic.org, ruben@polycephaly.org, andreas.huelsing@googlemail.com 4 Radboud University Nijmegen Digital Security Group P.O. Box 9010, 6500 GL Nijmegen, The Netherlands louiza@cryptologio.org, peter@cryptojedi.org Abstract. This paper introduces a high-security post-quantum stateless hash-based sig- nature scheme that signs hundreds of messages per second on a modern 4-core 3.5GHz Intel CPU. Signatures are 41 KB, public keys are 1 KB, and private keys are 1 KB. The signature scheme is designed to provide long-term 2128 security even against attackers equipped with quantum computers. Unlike most hash-based designs, this signature scheme is stateless, allowing it to be a drop-in replacement for current signature schemes. Keywords: post-quantum cryptography, one-time signatures, few-time signatures, hyper- trees, vectorized implementation 1 Introduction It is not at all clear how to securely sign operating-system updates, web-site certicates, etc. once an attacker has constructed a large quantum computer: RSA and ECC are perceived today as being small and fast, but they are broken in polynomial time by Shor's algorithm.
    [Show full text]
  • Forgery and Key Recovery Attacks for Calico
    Forgery and Key Recovery Attacks for Calico Christoph Dobraunig, Maria Eichlseder, Florian Mendel, Martin Schl¨affer Institute for Applied Information Processing and Communications Graz University of Technology Inffeldgasse 16a, A-8010 Graz, Austria April 1, 2014 1 Calico v8 Calico [3] is an authenticated encryption design submitted to the CAESAR competition by Christopher Taylor. In Calico v8 in reference mode, ChaCha-14 and SipHash-2-4 work together in an Encrypt-then-MAC scheme. For this purpose, the key is split into a Cipher Key KC and a MAC Key KM . The plaintext is encrypted with ChaCha under the Cipher Key to a ciphertext with the same length as the plaintext. Then, the tag is calculated as the SipHash MAC of the concatenated ciphertext and associated data. The key used for SipHash is generated by xoring the nonce to the (lower, least significant part of the) MAC Key: (C; T ) = EncCalico(KC k KM ; N; A; P ); where k is concatenation, and with ⊕ denoting xor, the ciphertext and tag are calculated vi C = EncChaCha-14(KC ; N; P ) T = MACSipHash-2-4(KM ⊕ N; C k A): Here, A; P; C denote associated data, plaintext and ciphertext, respectively, all of arbitrary length. T is the 64-bit tag, N the 64-bit nonce, and the 384-bit key K is split into a 256-bit encryption and 128-bit authentication part, K = KC k KM . 2 Missing Domain Separation As shown above, the tag is calculated over the concatenation C k A of ciphertext and asso- ciated data. Due to the missing domain separation between ciphertext and associated data in the generation of the tag, the following attack is feasible.
    [Show full text]
  • Differential Cryptanalysis of Siphash
    Differential Cryptanalysis of SipHash Christoph Dobraunig, Florian Mendel, and Martin Schl¨affer IAIK, Graz University of Technology, Austria christoph.dobraunig@iaik.tugraz.at Abstract. SipHash is an ARX based message authentication code de- veloped by Aumasson and Bernstein. SipHash was designed to be fast on short messages. Already, a lot of implementations and applications for SipHash exist, whereas the cryptanalysis of SipHash lacks behind. In this paper, we provide the first published third-party cryptanalysis of SipHash regarding differential cryptanalysis. We use existing auto- matic tools to find differential characteristics for SipHash. To improve the quality of the results, we propose several extensions for these tools to find differential characteristics. For instance, to get a good probabil- ity estimation for differential characteristics in SipHash, we generalize the concepts presented by Mouha et al. and Velichkov et al. to calcu- late the probability of ARX functions. Our results are a characteristic for SipHash-2-4 with a probability of 2−236:3 and a distinguisher for the Finalization of SipHash-2-4 with practical complexity. Even though our results do not pose any threat to the security of SipHash-2-4, they sig- nificantly improve the results of the designers and give new insights in the security of SipHash-2-4. Keywords: message authentication code, MAC, cryptanalysis, differ- ential cryptanalysis, SipHash, S-functions, cyclic S-functions 1 Introduction A message authentication code (MAC) is a cryptographic primitive, which is used to ensure the integrity and the origin of messages. Normally, a MAC takes a secret key K and a message M as input and produces a fixed size tag T .A receiver of such a message-tag-pair verifies the authenticity of the message by simply recalculating the tag T for the message and compare it with the received one.
    [Show full text]
  • Lightweight Macs from Universal Hash Functions
    Lightweight MACs from Universal Hash Functions S´ebastienDuval Ga¨etanLeurent November 13, 2019 REASSURE Introduction Design of MAC611 Benchmarks Conclusion 2 / 21 Authentication I Need for lightweight crypto I Relatively few authentication solutions compared to encryption I Our goal: design a fast MAC, MAC611, for 32-bit micro-controllers Introduction Design of MAC611 Benchmarks Conclusion 3 / 21 MACs Message Authentication Code I Definition: Tag t = Hk (m) I Security: bound on the proba. that an adversary forges a valid tag MAC constructions: I Block-Cipher-based (CBC-MAC, PMAC) I Hash-Function-based (HMAC) I from scratch (Pelican MAC, Chaskey) I from Universal Hash Functions (GMAC, Poly1305-AES) Lightweight MACs Chaskey, SipHash, TuLP, LightMAC, QUARK, SPONGENT Aim for 64-bit security Introduction Design of MAC611 Benchmarks Conclusion 3 / 21 MACs Message Authentication Code I Definition: Tag t = Hk (m) I Security: bound on the proba. that an adversary forges a valid tag MAC constructions: I Block-Cipher-based (CBC-MAC, PMAC) I Hash-Function-based (HMAC) I from scratch (Pelican MAC, Chaskey) I from Universal Hash Functions (GMAC, Poly1305-AES) Lightweight MACs Chaskey, SipHash, TuLP, LightMAC, QUARK, SPONGENT Aim for 64-bit security Introduction Design of MAC611 Benchmarks Conclusion 4 / 21 [Almost] Universal Hash Functions A family H : A B is: ! "-almost universal ("-AU) m = m0 A; h H : h(m) = h(m0) " H 8 6 2 jf 2 gj ≤ j j "-almost XOR universal ("-AXU) m = m0 A; d B; h H : h(m) h(m0) = d " H 8 6 2 8 2 jf 2 ⊕ gj ≤ j j H "-AXU H "-AU,
    [Show full text]
  • Hash Pile Ups: Using Collisions to Identify Unknown Hash Functions
    Hash Pile Ups: Using Collisions to Identify Unknown Hash Functions R. Joshua Tobin David Malone School of Mathematics Hamilton Institute Trinity College Dublin, National University of Ireland, Ireland. Ireland. Email: tobinrj@tcd.ie Email: David.Malone@nuim.ie Abstract—Hash functions are often used to consistently assign 16 Xor Jenkins objects to particular resources, for example to load balancing Pearson in networks. These functions can be randomly selected from a 14 Universal MD5 family, to prevent attackers generating many colliding objects, SHA which usually results in poor performance. We describe a number 12 SHA256 of attacks allowing us to identify which hash function from a family is being used by observing a relatively small number of 10 collisions. This knowledge can then be used to generate a large number of colliding inputs. In particular we detail attacks against (us) 8 CPU Time small families of hashes, Pearson-like hash functions and linear 6 hashes, such as the Toeplitz hash used in Microsoft’s Receive Side Scaling. 4 I. INTRODUCTION 2 Hash functions are often used to spread load across several 0 resources. For example, in the common case of a hash table, a Geode Core 2 Duo Athlon 64 Xeon Atom 500MHz 2.66GHz 2.6GHz 3GHz 1.6GHz hash function is used to give a consistent assignment of objects to linked lists. In modern networking, similar techniques are used by high-end network cards to assign packets to CPUs [1], Fig. 1. The average cost of hashing an IPv6 flow record with different algorithms on a selection of CPUs.
    [Show full text]
  • Research Intuitions of Hashing Crypto System
    Published by : International Journal of Engineering Research & Technology (IJERT) http://www.ijert.org ISSN: 2278-0181 Vol. 9 Issue 12, December-2020 Research Intuitions of Hashing Crypto System 1Rojasree. V, 2Gnana Jayanthi. J, 3Christy Sujatha. D PG & Research Department of Computer Science, Rajah Serfoji Govt. College(A), (Affiliated to Bharathidasan University), Thanjavur-613005, Tamilnadu, India. Abstract—Data transition over the internet has become there is no correlation between input and output bits; and no inevitable. Most data transmitted in the form of multimedia. correlation between output bits, etc. The data transmission must be less complex and user friendly To ensure about the originator of the message, Message at the same time with more security. Message authentication Authentication Code (MAC) is used which can be and integrity is one of the major issues in security data implemented using either symmetric Stream cipher Transmission. There are plenty of methods used to ensure the integrity of data when it is send from the receiver and before it cryptography or Hashing cryptography techniques. reaches the corresponding receiver. If these messages are However, MAC is limited with (i) Establishment of Shared tampered in the midst, it should be intimated to the receiver Secret and (ii) Inability to Provide Non-Repudiation. Even and discarded. Hash algorithms are supposed to provide the some kind of attacks is found like Content modification, integrity but almost all the algorithms have confirmed Sequence modification, Timing modification etc. breakable or less secure. In this review, the performances of This paper is aimed to discuss the several security various hash functions are studied with an analysis from the algorithms based on hash functions in cryptography to point of view of various researchers.
    [Show full text]
  • Security Policy: Java Crypto Module
    FIPS 140-2 Non-Proprietary Security Policy: Java Crypto Module FIPS 140-2 Non-Proprietary Security Policy Trend Micro Java Crypto Module Software Version 1.0 Document Version 1.2 August 30, 2018 Prepared For: Prepared By: Trend Micro Inc. SafeLogic Inc. 225 E. John Carpenter Freeway, Suite 1500 530 Lytton Ave, Suite 200 Irving, Texas 75062 Palo Alto, CA 94301 www.trendmicro.com www.safelogic.com Document Version 1.1 © Trend Micro Page 1 of 34 FIPS 140-2 Non-Proprietary Security Policy: Java Crypto Module Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for the Trend Micro Java Crypto Module. Document Version 1.1 © Trend Micro Page 2 of 34 FIPS 140-2 Non-Proprietary Security Policy: Java Crypto Module Table of Contents 1 Introduction .............................................................................................................................................. 5 1.1 About FIPS 140 ............................................................................................................................................. 5 1.2 About this Document .................................................................................................................................... 5 1.3 External Resources ....................................................................................................................................... 5 1.4 Notices .........................................................................................................................................................
    [Show full text]
  • Two Provably Secure Password Hashing Algorithms
    Pleco and Plectron – Two Provably Secure Password Hashing Algorithms Bo Zhu, Xinxin Fan, and Guang Gong Department of Electrical and Computer Engineering, University of Waterloo, Canada {bo.zhu,x5fan,ggong}@uwaterloo.ca ABSTRACT are two fundamental limitations of password-based authen- Password-based authentication has been widely deployed in tication: 1) Users routinely pick poor passwords which are practice due to its simplicity and efficiency. Storing pass- particularly subject to dictionary attacks or brute-force search; words and deriving cryptographic keys from passwords in and 2) A device or server storing a large number of passwords a secure manner are crucial for many security systems and is consistently a juicy target for attackers, and how to store services. However, choices of well-studied password hashing passwords securely and minimize damages if the device or algorithms are extremely limited, as their security require- server has been breached is non-trivial. As an effective coun- ments and design principles are different from common cryp- termeasure, all passwords should be obscured together with tographic algorithms. In this paper, we propose two practi- user-specific, random and high-entropy salts by applying a cal password hashing algorithms, Pleco and Plectron. one-way function, namely password hashing, before storing They are built upon well-understood cryptographic algo- them in the device or server. During authentication, the rithms, and combine advantages of symmetric and asymmet- user's input is processed in the same way and then the re- ric primitives. By employing the Rabin cryptosystem, we sult is compared with the one stored in the device or server.
    [Show full text]
  • Analyse, Modellierung Und Hashcat-Basierte Implementierung Von Angriffen Auf Passwortgeschutzte¨ Systeme Unter Einbeziehung Des Faktors Mensch
    Analyse, Modellierung und hashcat-basierte Implementierung von Angriffen auf passwortgeschutzte¨ Systeme unter Einbeziehung des Faktors Mensch Bachelorarbeit im Studiengang Medieninformatik zur Erlangung des akademischen Grades Bachelor of Science Fachbereich Medien Hochschule Dusseldorf¨ Lukas Friedrichs Matrikel-Nr.: 526560 Datum: 10. September 2018 Erst- und Zweitprufer¨ Prof. Dr.-Ing. Holger Schmidt Prof. Dr.-Ing. M.Sc. Markus Dahm Eidesstattliche Erkl¨arung Ich erkl¨are hiermit an Eides statt, dass ich die vorliegende Bachelorarbeit selbst¨andig und ohne unzul¨assige fremde Hilfe angefertigt habe. Die verwendeten Quellen sind vollst¨andig zitiert. Diese Arbeit wurde weder in gleicher noch ¨ahnlicher Form einem anderen Prufungsamt¨ vorgelegt oder ver¨offentlicht. Ich erkl¨are mich ausdrucklich¨ da- mit einverstanden, dass diese Arbeit mittels eines Dienstes zur Erkennung von Pla- giaten uberpr¨ uft¨ wird. Ort, Datum Lukas Friedrichs Kontaktinformationen Lukas Friedrichs Rottberger Straße 201 42551 Velbert | lukas.friedrichs@hs-duesseldorf.de i Zusammenfassung Analyse, Modellierung und hashcat-basierte Implementierung von Angriffen auf passwortgeschutzte¨ Systeme unter Einbeziehung des Faktors Mensch Lukas Friedrichs In der vorliegenden Bachelorarbeit geht es um das menschliche Verhalten bei der Pass- worterstellung. Hierbei wird die M¨oglichkeit untersucht dieses menschliche Verhalten uber¨ die Software hashcat nachzubilden, um so Passw¨orter effizienter anzugreifen. Durch die Konzeption und den Test von Passwortangriffsszenarien, deren Fokus auf dem Faktor Mensch liegt, wird versucht aufzuzeigen, dass selbst sichere Passwortver- fahren, durch das individuelle Verhalten von Menschen an Sicherheit verlieren k¨onnen. Zudem werden die Tests der Szenarien Schw¨achen der Software hashcat aufzeigen, die im sp¨ateren Verlauf der Arbeit als Grundlage fur¨ die Entwicklung einer selbst- programmierten Erweiterung von hashcat dienen.
    [Show full text]
  • Fast Keyed Hash/Pseudo-Random Function Using SIMD Multiply and Permute
    Fast keyed hash/pseudo-random function using SIMD multiply and permute J. Alakuijala, B. Cox, and J. Wassenberg Google Research February 7, 2017 Abstract HighwayHash is a new pseudo-random function based on SIMD multiply and permute instructions for thorough and fast hashing. It is 5.2 times as fast as SipHash for 1 KiB inputs. An open-source implementation is available under a permissive license. We discuss design choices and provide statistical analysis, speed measurements and preliminary cryptanalysis. Assuming it withstands further analysis, strengthened variants may also substantially accelerate file checksums and stream ciphers. 1 Introduction Hash functions are widely used for message authentication, efficient searching and `random' decisions. When attackers are able to find collisions (multiple inputs with the same hash result), they can mount denial of service attacks or disturb applications expecting uniformly distributed inputs. So-called `keyed-hash' functions prevent this by using a secret key to ensure the outputs arXiv:1612.06257v3 [cs.CR] 6 Feb 2017 are unpredictable. These functions are constructed such that an attacker who controls the inputs still cannot deduce the key, nor predict future outputs. The authors of SipHash refer to these as `strong pseudo-random functions' [1]. However, existing approaches are too slow for large-scale use. In this paper, we introduce two alternatives that are about 2 and 5 times as fast as SipHash. We are mainly interested in generating random numbers and message authentication, for which 64-bit hashes are sufficient. These are not `collision- resistant' because adversaries willing to spend considerable CPU time could 1 q π 64 find a collision after hashing about 2 2 inputs.
    [Show full text]
  • CHAPTER 19 Android User Enabled Security: Passwords and Gesture
    CHAPTER 19 Android User Enabled Security: Passwords and Gesture Information in This Chapter • Security on Androids • Simple security values • The password lock • Hashcat • The pattern lock (gesture) • Using a rainbow table • SHA-1 exercise Introduction—Security on Androids Since their inception, Android devices (the first being the HTC G1) have provided the user the ability to employ simple security measures. As the operating system versions changed, different types of security also evolved. Today, the consumer can rely on embedded secu- rity features from a specific OS or exclusive settings based on the make and model. There is also an ability to download and install specific applications for the same purpose. Some of the more popular and embedded by OS and/or make and model, include but are not limited to: • PIN • Password • Pattern (gesture) • Fingerprint • Facial recognition • Knock lock It would be unnecessary to dedicate an entire chapter showing each of these security types. Instead, this chapter will primarily address the password and gesture lock. This is continuing to be one of the more popular user enabled security measures employed on Androids. Some Seeking the Truth from Mobile Evidence. http://dx.doi.org/10.1016/B978-0-12-811056-0.00019-4 Copyright © 2018 Elsevier Inc. All rights reserved. 283 284 Chapter 19 of you may be reading this and saying, “My ______ (fill in the blank) unit/machine/utility can get past that security. What do I need to know more about this process?” Yes, in the forensic utility market, many makes and models are supported for bypassing the gesture lock.
    [Show full text]