DOCSLIB.ORG

1Password Security Design White Paper

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

1Password Security Design 1Password Memberships [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Key Security Features 1Password offers a number of notable security features, including True end-to-end encryption All cryptographic keys are generated and man- aged by the client on your devices, and all encryption is done locally. Details are in A deeper look at keys. Server ignorance We are never in the position of learning your Master Password or your cryptographic keys. Details are in A modern ap- proach to authentication. Nothing “crackable” is stored Often a server will store the password hash. If captured, this can be used in password cracking attempts. Our two-secret key derivation mixes your locally held Secret Key with your Master Password so that data we store cannot be used in cracking attempts. See Making verifiers uncrackable with 2SKD for details. Thrice encrypted in transport When your already encrypted data travels between your device and our servers, it is encrypted and authenti- cated by Transport Layer Security (TLS) and our own transport en- cryption. Details are in Transport Security. You control sharing Only someone who holds the keys to a vault can share that data with someone else. We do not have those keys, so sharing decisions come from you. See How Vault Items Are Securely Shared for details. Team managed data recovery We do not have the ability to recover your data if you forget your Master Password or lose your Secret Key (since you have end-to-end security). But recovery keys can be shared with team members. Details are in Restoring a User’s Access to a Vault. [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Which controls are cryptographically Contents enforced . 33 Server-enforced controls . 34 Which controls are enforced by server policy . 34 Client-enforced policy . 35 Principles 6 Which controls are enforced by client policy . 35 Master Password and Secret Key 9 Multiple layers of enforcement . 35 Master Password ............... 9 Secret Key ................... 10 Administrator Roles and Powers 37 Emergency Kit . 11 Restoring a User’s Access to a Vault 38 A modern approach to authentication 13 Overview of Groups . 38 What we want from authentication . 13 Recovery Groups . 39 Traditional authentication . 14 Implicit sharing . 39 Password Authenticated Key Exchange 14 Protecting vaults from Recovery Group Making verifiers uncrackable with 2SKD 16 members . 39 Recovery risks . 40 How Vault Items Are Secured 17 Key derivation overview . 18 1Password Connect 43 A first look at Key Set . 18 The Connect Server . 44 Flexible, yet firm . 19 Service account . 44 Local deployment . 45 How Vault Items Are Securely Shared 21 Credential store . 45 Getting the message (to the right people) . 21 The credentials file . 45 A deeper look at keys 23 Encrypted credentials . 46 Key creation . 23 Verifier . 46 Key derivation . 24 Interprocess key . 47 Deriving two keys . 24 Bearer token . 47 Preprocessing the Master Password . 24 Header . 47 Preparing the salt . 26 Payload . 48 Slow hashing . 26 Signature . 49 Combining with the Secret Key . 26 How We Secure Data on Clients 50 Deriving the authentication key . 27 Initial sign-up . 27 Transport Security 51 Protecting email invitations . 28 Data at rest ................... 52 Enrolling a new client . 29 TLS ....................... 52 Normal unlock and sign-in . 31 Our transport security . 53 Client delivery . 53 Revoking Access 32 Server Infrastructure 54 Access control enforcement 33 What the server stores . 54 Cryptographically enforced controls . 33 How is your data stored . 56 How are servers deployed and managed . 57 [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Appendices 57 Changelog 86 [0.3.1] – 2021-04-19 . 86 A Beware of the Leopard 58 Improved . 86 Crypto over HTTPS . 58 [0.3] – 2021-04-13 . 86 Pinning . 59 Improved . 86 Crypto in the browser . 60 New .................... 86 Recovery Group powers . 60 [0.2.10] – 2019-01-12 . 87 No public key verification . 61 Improved . 87 Limited re-encryption secrecy . 61 [0.2.9] – 2018-12-30 . 87 Revocation . 61 Improved . 87 Your mitigations . 62 [0.2.8] – 2018-12-30 . 87 Master Password changes don’t change key- New .................... 87 sets .................... 62 Improved . 87 Your mitigations . 62 [0.2.7] – 2018-09-10 . 87 Clients handling multiple accounts . 62 New .................... 87 Mitigations . 63 Improved . 87 Policy enforcement mechanisms not always [0.2.6] – 2017-04-11 . 88 clear to user . 63 New .................... 88 Malicious client . 64 Improved . 88 Vulnerability of server data . 64 [0.2.5] - 2017-02-20 . 88 Malicious processes on your devices . 64 Improved . 88 Locally exposed Secret Keys . 64 [0.2.4] - 2016-09-28 . 88 Revealing who is registered . 65 New .................... 88 Use of email . 65 Improved . 89 Fixed ................... 89 B Secure Remote Password 66 [0.2.3] - 2015-11-27 . 89 Registration . 66 New .................... 89 Sign-in ................... 67 Fixed ................... 89 With a strong KDF . 67 [0.2.2] - 2015-11-03 . 89 The math of SRP . 68 New .................... 89 Math background . 68 Diffie-Hellman key exchange . 69 Authenticated key exchange . 70 C Strengthening User Master Passwords 71 Some words about strong Master Passwords 71 Slow hashing . 71 D Securing Documents 72 E Verifying public keys 73 Types of defenses . 74 Trust hierarchy . 74 User-to-user verification . 74 The problem remains . 76 [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 List of Stories List of Figures 1 A (bad) day in the life of your data . 10 1 Two-secret Key Derivation . 9 2 A day in the life of an Emergency Kit . 11 2 Master Password ............ 9 3 A day in the life of an item being created 19 3 Secret Key . 10 4 Days in the life of an algorithm upgrade 19 4 Sample Emergency Kit . 11 5 A day in the life of a shared vault . 21 5 Encourage saving Emergency Kit . 12 6 A week in the life of revocation . 32 6 Very traditional authentication . 14 7 A day in the life of read-only data . 34 7 Authentication security properties . 15 8 A day in the life of a concealed password 36 8 Algorithm for creating and populating a 9 Mr. Talk is not a good team player . 61 vault .................... 17 10 A weak primary Master Password un- 9 Structure of a How collections of locks a stronger account . 63 keys and their metadata are organized 11 Mr. Talk is the cat in the middle . 73 within 1Password for Teams . 18 10 Master Unlock Key derivation . 25 11 Sample Master Unlock Key (MUK) . 26 12 Example add link . 29 13 First auth response . 29 List of Asides 14 Personal key set overview . 30 15 Encrypted symmetric key . 30 1 Non-ASCII passwords . 25 16 Public key details . 30 17 Vault recovery . 41 18 Connect server in the middle . 43 19 Connect credentials JSON . 45 20 encCredentials object . 46 List of Tables 21 Decrypted credential structure . 46 1 Authentication schemes . 16 22 Connect server verifier . 46 2 Random number generators . 23 23 Connect server IPC key . 47 3 Symbols . 28 24 JWT header . 47 4 Transport protections . 52 25 JWT payload . 48 B.1 SRP simple KDF . 67 B.2 Sophie Germain . 69 B.3 Diffie-Hellman key exchange . 70 [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Principles 1Password by AgileBits provides powerful administration of 1Password data (login credentials, for example) for teams of individuals. This doc- ument describes how this is done securely. The same approach to security that has driven the design of 1Pass- word prior to offering 1Password accounts has gone into the current design. The first one is that we can best protect your secrets bynot knowing them. Privacy by Design It is impossible to lose, use, or abuse data PRINCIPLE 1 Privacy by Design one doesn’t possess. Therefore we design systems to reduce the amount of sensitive user data we have or can acquire. You will find Principle 1 exemplified throughout our system, from our inability to acquire your Master Password during authentication (through use of Secure Remote Password (SRP) to our use of two-secret key deriva- tion (2SKD) which means that we aren’t in a position to even attempt to crack your Master Password. Likewise, our use of end-to-end encryp- tion protects you and your data from us or someone who gains access to our servers. Our Principle 2 follows directly from the first: Trust the Math Mathematics is more trustworthy than people PRINCIPLE 2 Trust the Math or software. Therefore, when designing a system, prefer security that is enforced by cryptography instead of enforced by software or personnel policy. It is cryptography that prevents one person from seeing the items that they are not entitled to see. Even if an attacker were able to trick our servers (or people) into misbehaving, the mathematics of cryptog- raphy would prevent most attacks. Throughout this document, assume that all access control mechanisms are enforced through cryptography unless explicitly stated otherwise. We also strive to bring the best security architectures to people who are not themselves security experts. This is more than just building a product and system that people will want to use, it is part of the security design itself: [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 1PASSWORD SECURITY DESIGN 7 People are part of the system If the security of a system de- PRINCIPLE 3 People are part of the system pends on people’s behavior, the system must be designed with an understanding of how people behave.
Recommended publications
  • GPU-Based Password Cracking on the Security of Password Hashing Schemes Regarding Advances in Graphics Processing Units

    GPU-Based Password Cracking on the Security of Password Hashing Schemes Regarding Advances in Graphics Processing Units

    Radboud University Nijmegen Faculty of Science Kerckhoffs Institute Master of Science Thesis GPU-based Password Cracking On the Security of Password Hashing Schemes regarding Advances in Graphics Processing Units by Martijn Sprengers [email protected] Supervisors: Dr. L. Batina (Radboud University Nijmegen) Ir. S. Hegt (KPMG IT Advisory) Ir. P. Ceelen (KPMG IT Advisory) Thesis number: 646 Final Version Abstract Since users rely on passwords to authenticate themselves to computer systems, ad- versaries attempt to recover those passwords. To prevent such a recovery, various password hashing schemes can be used to store passwords securely. However, recent advances in the graphics processing unit (GPU) hardware challenge the way we have to look at secure password storage. GPU's have proven to be suitable for crypto- graphic operations and provide a significant speedup in performance compared to traditional central processing units (CPU's). This research focuses on the security requirements and properties of prevalent pass- word hashing schemes. Moreover, we present a proof of concept that launches an exhaustive search attack on the MD5-crypt password hashing scheme using modern GPU's. We show that it is possible to achieve a performance of 880 000 hashes per second, using different optimization techniques. Therefore our implementation, executed on a typical GPU, is more than 30 times faster than equally priced CPU hardware. With this performance increase, `complex' passwords with a length of 8 characters are now becoming feasible to crack. In addition, we show that between 50% and 80% of the passwords in a leaked database could be recovered within 2 months of computation time on one Nvidia GeForce 295 GTX.
  • Medtronic Care Management Services, LLC CC FM TLS/SRTP FIPS 140

    Medtronic Care Management Services, LLC CC FM TLS/SRTP FIPS 140

    Medtronic Care Management Services, LLC CC FM TLS/SRTP FIPS 140‐2 Cryptographic Module Non‐Proprietary Security Policy Version: 1.6 Date: March 16, 2016 Copyright Medtronic Care Management Services 2016 Version 1.6 Page 1 of 14 Medtronic Care Management Services Public Material – May be reproduced only in its original entirety (without revision). Table of Contents 1 Introduction .................................................................................................................... 4 1.1 Cryptographic Boundary ..............................................................................................................5 1.2 Mode of Operation .......................................................................................................................5 2 Cryptographic Functionality ............................................................................................. 6 2.1 Critical Security Parameters .........................................................................................................7 2.2 Public Keys ....................................................................................................................................8 3 Roles, Authentication and Services .................................................................................. 8 3.1 Assumption of Roles .....................................................................................................................8 3.2 Services and CSP Access Rights ....................................................................................................8
  • Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms

    Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms

    Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms Levent Ertaul, Manpreet Kaur, Venkata Arun Kumar R Gudise CSU East Bay, Hayward, CA, USA. [email protected], [email protected], [email protected] Abstract- With the increase in mobile wireless or data lookup. Whereas, Cryptographic hash functions are technologies, security breaches are also increasing. It has used for building blocks for HMACs which provides become critical to safeguard our sensitive information message authentication. They ensure integrity of the data from the wrongdoers. So, having strong password is that is transmitted. Collision free hash function is the one pivotal. As almost every website needs you to login and which can never have same hashes of different output. If a create a password, it’s tempting to use same password and b are inputs such that H (a) =H (b), and a ≠ b. for numerous websites like banks, shopping and social User chosen passwords shall not be used directly as networking websites. This way we are making our cryptographic keys as they have low entropy and information easily accessible to hackers. Hence, we need randomness properties [2].Password is the secret value from a strong application for password security and which the cryptographic key can be generated. Figure 1 management. In this paper, we are going to compare the shows the statics of increasing cybercrime every year. Hence performance of 3 key derivation algorithms, namely, there is a need for strong key generation algorithms which PBKDF2 (Password Based Key Derivation Function), can generate the keys which are nearly impossible for the Bcrypt and Scrypt.
  • Speeding up Linux Disk Encryption Ignat Korchagin @Ignatkn $ Whoami

    Speeding up Linux Disk Encryption Ignat Korchagin @Ignatkn $ Whoami

    Speeding Up Linux Disk Encryption Ignat Korchagin @ignatkn $ whoami ● Performance and security at Cloudflare ● Passionate about security and crypto ● Enjoy low level programming @ignatkn Encrypting data at rest The storage stack applications @ignatkn The storage stack applications filesystems @ignatkn The storage stack applications filesystems block subsystem @ignatkn The storage stack applications filesystems block subsystem storage hardware @ignatkn Encryption at rest layers applications filesystems block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers DBMS, PGP, OpenSSL, Themis applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers Cons: ● no visibility into the implementation ● no auditability ● sometimes poor security https://support.microsoft.com/en-us/help/4516071/windows-10-update-kb4516071 @ignatkn Block
  • No Random, No Ransom: a Key to Stop Cryptographic Ransomware

    No Random, No Ransom: a Key to Stop Cryptographic Ransomware

    No Random, No Ransom: A Key to Stop Cryptographic Ransomware Ziya Alper Genç, Gabriele Lenzini, and Peter Y.A. Ryan Interdisciplinary Centre for Security Reliability and Trust (SnT) University of Luxembourg Abstract. To be effective, ransomware has to implement strong encryp- tion, and strong encryption in turn requires a good source of random numbers. Without access to true randomness, ransomware relies on the pseudo random number generators that modern Operating Systems make available to applications. With this insight, we propose a strategy to miti- gate ransomware attacks that considers pseudo random number generator functions as critical resources, controls accesses on their APIs and stops unauthorized applications that call them. Our strategy, tested against 524 active real-world ransomware samples, stops 94% of them, including WannaCry, Locky, CryptoLocker and CryptoWall. Remarkably, it also nullifies NotPetya, the latest offspring of the family which so far has eluded all defenses. Keywords: ransomware, cryptographic malware, randomness, mitigation. 1 Introduction Ransomware is a malware, a malicious software that blocks access to victim’s data. In contrast to traditional malware, whose break-down is permanent, ransomware’s damage is reversible: access to files can be restored on the payment of a ransom, usually a few hundreds US dollars in virtual coins. Despite being relatively new, this cyber-crime is spreading fast and it is believed to become soon a worldwide pandemic. According to [24], a US Govern- ment’s white paper dated June 2016, on average more than 4,000 ransomware attacks occurred daily in the USA. This is 300-percent increase from the previous year and such important increment is probably due to the cyber-crime’s solid business model: with a small investment there is a considerable pecuniary gain which, thanks to the virtual currency technology, can be collected reliably and in a way that is not traceable by the authorities.
  • Cryptanalysis of the Random Number Generator of the Windows Operating System

    Cryptanalysis of the Random Number Generator of the Windows Operating System

    Cryptanalysis of the Random Number Generator of the Windows Operating System Leo Dorrendorf School of Engineering and Computer Science The Hebrew University of Jerusalem 91904 Jerusalem, Israel [email protected] Zvi Gutterman Benny Pinkas¤ School of Engineering and Computer Science Department of Computer Science The Hebrew University of Jerusalem University of Haifa 91904 Jerusalem, Israel 31905 Haifa, Israel [email protected] [email protected] November 4, 2007 Abstract The pseudo-random number generator (PRNG) used by the Windows operating system is the most commonly used PRNG. The pseudo-randomness of the output of this generator is crucial for the security of almost any application running in Windows. Nevertheless, its exact algorithm was never published. We examined the binary code of a distribution of Windows 2000, which is still the second most popular operating system after Windows XP. (This investigation was done without any help from Microsoft.) We reconstructed, for the ¯rst time, the algorithm used by the pseudo- random number generator (namely, the function CryptGenRandom). We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in O(223) work (this is an attack on the forward-security of the generator, an O(1) attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks. We also analyzed the way in which the generator is run by the operating system, and found that it ampli¯es the e®ect of the attacks: The generator is run in user mode rather than in kernel mode, and therefore it is easy to access its state even without administrator privileges.
  • Forgery and Key Recovery Attacks for Calico

    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.
  • How to Handle Rainbow Tables with External Memory

    How to Handle Rainbow Tables with External Memory

    How to Handle Rainbow Tables with External Memory Gildas Avoine1;2;5, Xavier Carpent3, Barbara Kordy1;5, and Florent Tardif4;5 1 INSA Rennes, France 2 Institut Universitaire de France, France 3 University of California, Irvine, USA 4 University of Rennes 1, France 5 IRISA, UMR 6074, France [email protected] Abstract. A cryptanalytic time-memory trade-off is a technique that aims to reduce the time needed to perform an exhaustive search. Such a technique requires large-scale precomputation that is performed once for all and whose result is stored in a fast-access internal memory. When the considered cryptographic problem is overwhelmingly-sized, using an ex- ternal memory is eventually needed, though. In this paper, we consider the rainbow tables { the most widely spread version of time-memory trade-offs. The objective of our work is to analyze the relevance of storing the precomputed data on an external memory (SSD and HDD) possibly mingled with an internal one (RAM). We provide an analytical evalua- tion of the performance, followed by an experimental validation, and we state that using SSD or HDD is fully suited to practical cases, which are identified. Keywords: time memory trade-off, rainbow tables, external memory 1 Introduction A cryptanalytic time-memory trade-off (TMTO) is a technique introduced by Martin Hellman in 1980 [14] to reduce the time needed to perform an exhaustive search. The key-point of the technique resides in the precomputation of tables that are then used to speed up the attack itself. Given that the precomputation phase is much more expensive than an exhaustive search, a TMTO makes sense in a few scenarios, e.g., when the adversary has plenty of time for preparing the attack while she has a very little time to perform it, the adversary must repeat the attack many times, or the adversary is not powerful enough to carry out an exhaustive search but she can download precomputed tables.
  • Securing Audio Using AES-Based Authenticated Encryption with Python

    Securing Audio Using AES-Based Authenticated Encryption with Python

    Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 9 August 2021 doi:10.20944/preprints202108.0185.v1 Article Securing Audio Using AES-based Authenticated Encryption with Python Jessy Ayala 1 1 New York University, Tandon School of Engineering; [email protected] Featured Application: Securing communication of audio files utilizing symmetric authenticated encryption. Abstract: The focus of this research is to analyze the results of encrypting audio using various au- thenticated encryption algorithms implemented in the Python cryptography library for ensuring authenticity and confidentiality of the original contents. The Advanced Encryption Standard (AES) is used as the underlying cryptographic primitive in conjunction with various modes including Gal- ois Counter Mode (GCM), Counter with Cipher Block Chaining Message Authentication Code (CCM), and Cipher Block Chaining (CBC) with Keyed-Hashing for encrypting a relatively small audio file. The resulting encrypted audio shows similarity in the variance when encrypting using AES-GCM and AES-CCM. There is a noticeable reduction in variance of the performed encodings and an increase in the amount of time it takes to encrypt and decrypt the same audio file using AES- CBC with Keyed-Hashing. In addition, the corresponding encrypted using this mode audio spans a longer duration. As a result, AES should either have GCM or CCM for an efficient and reliable authenticated encryption integration within a workflow. Keywords: AES; Audio analysis; Authenticated encryption; Cryptography; Python 1. Introduction Cryptography is used worldwide for adhering to the security CIA triad: confidenti- ality, integrity, and availability. In an environment where mobile devices have become ubiquitous, voice messages are more common than one may think.
  • Vulnerabilities of the Linux Random Number Generator

    Vulnerabilities of the Linux Random Number Generator

    Black Hat 2006 Open to Attack Vulnerabilities of the Linux Random Number Generator Zvi Gutterman Chief Technology Officer with Benny Pinkas Tzachy Reinman Zvi Gutterman CTO, Safend Previously a chief architect in the IP infrastructure group for ECTEL (NASDAQ:ECTX) and an officer in the Israeli Defense Forces (IDF) Elite Intelligence unit. Master's and Bachelor's degrees in Computer Science from the Israeli Institute of Technology. Ph.D. candidate at the Hebrew University of Jerusalem, focusing on security, network protocols, and software engineering. - Proprietary & Confidential - Safend Safend is a leading provider of innovative endpoint security solutions that protect against corporate data leakage and penetration via physical and wireless ports. Safend Auditor and Safend Protector deliver complete visibility and granular control over all enterprise endpoints. Safend's robust, ultra- secure solutions are intuitive to manage, almost impossible to circumvent, and guarantee connectivity and productivity, without sacrificing security. For more information, visit www.safend.com. - Proprietary & Confidential - Pseudo-Random-Number-Generator (PRNG) Elementary and critical component in many cryptographic protocols Usually: “… Alice picks key K at random …” In practice looks like random.nextBytes(bytes); session_id = digest.digest(bytes); • Which is equal to session_id = md5(get next 16 random bytes) - Proprietary & Confidential - If the PRNG is predictable the cryptosystem is not secure Demonstrated in - Netscape SSL [GoldbergWagner 96] http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Apache session-id’s [GuttermanMalkhi 05] http://www.gutterman.net/publications/2005/02/hold_your_sessions_an_attack_o.html - Proprietary & Confidential - General PRNG Scheme 0 0 01 Stateseed 110 100010 Properties: 1. Pseudo-randomness Output bits are indistinguishable from uniform random stream 2.
  • Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms

    Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms

    66 Int'l Conf. Wireless Networks | ICWN'16 | Implementation and Performance Analysis of PBKDF2, Bcrypt, Scrypt Algorithms Levent Ertaul, Manpreet Kaur, Venkata Arun Kumar R Gudise CSU East Bay, Hayward, CA, USA. [email protected], [email protected], [email protected] Abstract- With the increase in mobile wireless or data lookup. Whereas, Cryptographic hash functions are technologies, security breaches are also increasing. It has used for building blocks for HMACs which provides become critical to safeguard our sensitive information message authentication. They ensure integrity of the data from the wrongdoers. So, having strong password is that is transmitted. Collision free hash function is the one pivotal. As almost every website needs you to login and which can never have same hashes of different output. If a create a password, it’s tempting to use same password and b are inputs such that H (a) =H (b), and a b. for numerous websites like banks, shopping and social User chosen passwords shall not be used directly as networking websites. This way we are making our cryptographic keys as they have low entropy and information easily accessible to hackers. Hence, we need randomness properties [2].Password is the secret value from a strong application for password security and which the cryptographic key can be generated. Figure 1 management. In this paper, we are going to compare the shows the statics of increasing cybercrime every year. Hence performance of 3 key derivation algorithms, namely, there is a need for strong key generation algorithms which PBKDF2 (Password Based Key Derivation Function), can generate the keys which are nearly impossible for the Bcrypt and Scrypt.
  • Wheel of Fortune ANALYZING EMBEDDED OS (CS)PRNGS

    Wheel of Fortune ANALYZING EMBEDDED OS (CS)PRNGS

    Wheel of Fortune ANALYZING EMBEDDED OS (CS)PRNGS JOS WETZELS ALI ABBASI WHOIS • Jos Wetzels1,2 • Researcher, MSc student • samvartaka.github.io • Ali Abbasi1,3 • Ph.D. candidate • http://wwwhome.cs.utwente.nl/~abbasia/ 1Distributed and Embedded System Security (DIES) group, University of Twente, Netherlands 2SEC Group, Eindhoven University of Technology, Netherlands 3SYSSEC Group, Ruhr-University Bochum, Germany ABOUT • Introduction to Embedded OS Random Number Generators • Embedded Challenges Overview • Case Studies • Product of ongoing research EMBEDDED SYSTEMS ARE EVERYWHERE EMBEDDED SYSTEMS ARE BOOMING © DigiReach EMBEDDED RANDOMNESS IS HARD ROADMAP • Why Does This Matter? • OS PRNGs • Embedded Challenges • Case Studies SOME TERMS • Interested in random bits • Cannot predict next bit with Pr. > 0.5 • Entropy (Shannon / Renyi / …) • Measure of information unpredictability • High entropy → very random WHY RANDOMNESS IS IMPORTANT? • Cryptography • Keys, Nonces, Etc. • Exploit Mitigations • ASLR → Randomize address space • Stack Smashing Protection → Randomize canaries • Randomness is critical to security ecosystem • Failure has massive impact TRUE RANDOM NUMBER GENERATORS • Physical (‘true’) entropy source • Radioactive Decay, Shot Noise, Etc. • Two ways to implement it: • External (dedicated device) • Trusted Platform Module (TPM) • Hardware Security Module (HSM) • Integrated • Intel Ivy Bridge RdRand • Certain Smartcards • Downsides • Expensive • Portability issues PSEUDO RANDOM NUMBER GENERATORS • Software based • Deterministic algorithm