DOCSLIB.ORG

Protection and Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Leaking information Stealing 26.5 million veteran’s data Protection and Security Data on laptop stolen from employee’s home (5/06) Ø Veterans’ names Ø Social Security numbers How to be a paranoid Ø Dates of birth or just think like one Exposure to identity theft CardSystems exposes data of 40 million cards (2005) Ø Data on 70,000 cards downloaded from ftp server These are attacks on privacy (confidentiality, anonymity) 1 2 3 The Sony rootkit The Sony rootkit The Problem Types of misuse Ø Accidental Ø Intentional (malicious) Sony’s rootkit enforced DRM but exposed computer Ø CDs recalled Protection and security objective Ø Classified as spyware by anti-virus software Ø Protect against/prevent misuse “Protected” albums included Ø Rootkit removal software distrubuted Ø Billie Holiday Ø Removal software had exposure vulnerability Three key components: Ø Louis Armstrong Ø New removal software distrubuted Ø Authentication: Verify user identity Ø Switchfoot Sony sued by Ø Integrity: Data has not been written by unauthorized entity Ø The Dead 60’s Ø Texas Ø Privacy: Data has not been read by unauthorized entity Ø Flatt & Scruggs, etc. Ø New York Rootkits modify files to infiltrate & hide Ø California Ø System configuration files This is an attack on integrity Ø Drivers (executable files) 4 5 6 Have you used an anonymizing service? What are your security goals? What About Security in Distributed Systems? Authentication Three challenges Ø Authentication 1. Yes, for email Ø User is who s/he says they are. ❖ Verify user identity 2. Yes, for web browsing Ø Example: Certificate authority (verisign) Ø Integrity ❖ Verify that the communication has not been tempered with 3. Yes, for something else Integrity Ø Privacy Ø Adversary can not change contents of message ❖ Protect access to communication across hosts 4. No Ø But not necessarily private (public key) Ø Example: secure checksum Solution: Encryption Ø Achieves all these goals Privacy (confidentiality) Ø Transform data that can easily reversed given the correct key (and Ø Adversary can not read your message hard to reverse without the key) Ø If adversary eventually breaks your system can they decode all stored communication? Ø Example: Anonymous remailer (how to reply?) Authorization, repudiation (or non-repudiation), forward security (crack now, not crack future), backward security (crack now, not cracked past) 7 8 9 Encryption (big idea) Keyed encryption Symmetric Key (Shared Key) Encryption Bob wants to send Alice a message m Most implementations of E() and D() need a secret Basic idea: Ø E(m, k) à cipher text c Does not want Eve to be able to read message key Ø D(c, k) à plain text m Ø Eve can know E() and D() code Somehow, Alice and Bob exchange the key out of band Ø Exercise for the reader ❖ Not many cryptographic algorithms in the world Idea: Need to keep the shared key secret! Ø Alice and Bob just need to pick secret keys Eve doesn’t Bob: E(m) -> c // Sends c over the network to Alice know (and each other may not know) Alice: D(c) -> m ❖ Some mathematical constraints Two types: Function E encrypts plaintext message to ciphertext (c) Ø Symmetric key Function D decrypts ciphertext to plaintext Ø Public/private key Eve can only read c, which looks like garbage 10 11 12 Public Key Encryption Mitigating costs Digital signatures Basic idea: Ø Separate authentication from secrecy Public key crypto is more expensive than shared key Cryptographic hash Ø Hash is a fixed sized byte string which represents arbitrary length Ø Each key is a pair: K-public and K-private Idea: Use public key crypto to exchange a temporary, data. Ø Alice and Bob both have key pairs (Ka and Kb) session key Ø Hard to find two messages with same hash. Example: Ø If m != m’ then H(m) != H(m’) with high probability. H(m) is 256 Ø During a session, exchange messages using shared key bits Ø Alice: E(m, Ka-private, Kb-public) -> c Message integrity with digital signatures Ø Only Bob can decrypt c with: One expensive public key message to set up session Ø For message m: hash m, encrypt the hash (E(H(m)) = s ❖ D(c, Ka-public, Kb-private) -> m Ø All future messages cheap Message is confidential even if Eve knows Ka-public and ❖ With public key crypto Kb-public Ø This is how SSL/TLS and other protocols work Ø Receiver: verify that H(m) == D(s) Ø No out-of-band protocol needed to exchange a shared secret Signature will only verify if: Ø But Alice does have to trust that Kb-public belongs to Bob Ø Hash was encrypted by owner of K-public ❖ Typically managed by some trusted certificate Ø Message did not change authority or key distribution network Also provides non-repudiation ◆ Debian developers meet and sign each others’ keys at conferences 13 14 15 Implementing your security goals Securing HTTP: HTTPS (HTTP+SSL/TLS) When you log into a website using an http URL, which Authentication property are you missing? Ø {I’m Don}^K-private client server CA Integrity hello(client) Ø {SHA-256 hash of message I just send is …}^K-private 1. Authentication Privacy (confidentiality) 2. Integrity certificate Ø Public keys to exchange a secret certificate ok? 3. Privacy Ø Use shared-key cryptography (for speed) Ø Strategy used by ssh 4. Authorization {certificate valid}^CA-private Forward/backward security 5. None Ø Rotate shared keys every hour {send random shared key}^S-public Repudiation Ø Public list of cracked keys switch to encrypted connection using shared key 16 17 18 Authentication Authentication (Cont’d.) When you visit a website using an https URL, which 2. Passwords must be long and obscure property are you missing? Objective: Verify user identity Ø Paradox: v Short passwords are easy to crack Common approach: v Long passwords – users write down to remember è 1. Authentication (server to user) Ø Passwords: shared secret between two parties vulnerable 2. Authentication (user to server) Ø Present password to verify identity Ø Original Unix: v 5 letter, lower case password 3. Integrity 1. How can the system maintain a copy of passwords? v Exhaustive search requires 26^5 = 12 million comparisons 4. Privacy Ø Encryption: Transformation that is difficult to reverse without v Today: < 1us to compare a password è 12 seconds to 5. None right key crack a password Ø Example: Unix /etc/passwd file contains encrypted Ø Choice of passwords passwords v English words: Shakespeare’s vocabulary: 30K words Ø When you type password, system encrypts it and then v All English words, fictional characters, place names, words compared encrypted versions reversed, … still too few words v (Partial) solution: More complex passwords Ø At least 8 characters long, with upper/lower case, numbers, and special characters 19 20 21 Are Long Passwords Sufficient? Are Long Passwords Sufficient? (Cont’d.) Alternatives/enhancements to Passwords Problem: Example: Tenex system (1970s – BBN) Ø Can exploit the interaction with virtual memory to crack passwords! Easier to remember passwords (visual recognition) Ø Considered to be a very secure system Key idea: Two-factor authentication Ø Force page faults at carefully designed times to reveal password Ø Code for password check: Ø Password and some other channel, e.g., physical device Ø Approach with key that changes every minute ❖ Arrange first character in string to be the last character in a page For (i=0, i<8, i++) { ❖ Arrange that the page with the first character is in memory Ø http://www.schneier.com/essay-083.html if (userPasswd[i] != realPasswd[i]) ❖ Rest is on disk (e.g., a|bcdefgh) Report Error; Ø What about a fake bank web site? (man in the middle) ❖ Check how long does a password check take? } ◆ If fast è first character is wrong Ø Local Trojan program records second factor ◆ If slow è first character is right à page fault à one of the later character is wrong Biometrics Ø Looks innocuous – need to try 256^8 (= 1.8E+19) ❖ Try all first characters until the password check takes long Ø Fingerprint, retinal scan combinations to crack a password ❖ Repeat with two characters in memory, … Ø What if I have a cut? What if someone wants my finger? Ø Is this good enough?? Ø Number of checks required = 256 * 8 = 2048 !! Fix: Facial recognition Ø Don’t report error until you have checked all characters! No!!! Ø But, how do you figure this out in advance?? Ø Timing bugs are REALLY hard to avoid 22 23 24 Password security Authorization Authorization § Instead of hashing your password, I will hash your password concatenated with a random salt. Then I Objective: Ø Specify access rights: who can do what? Capability lists (a capability is like a ticket) store the unhashed salt along with the hash. Ø Each process stores information about objects it has § (password . salt)^H salt Access control: formalize all permissions in the permission to touch Ø Processes present capability to objects to access (e.g., file § What attack does this address? system File1 File2 File3 … descriptor) User A RW R -- … Ø Lots of capability-based systems built in the past but idea User B -- RW RW .. out of favor today User C RW RW RW … Problem: 1. Brute force password guessing for all accounts. Ø Potentially huge number of users, objects that dynamically 2. Brute force password guessing for one account. change è impractical Access control lists 3. Trojan horse password value Ø Store permissions for all users with objects 4. Man-in-the-middle attack when user gives Ø Unix approach: three categories of access rights (owner, group, world) password at login prompt.
Recommended publications
  • Topic 3: One-Time Pad and Perfect Secrecy

    Topic 3: One-Time Pad and Perfect Secrecy

    Cryptography CS 555 Topic 3: One-time Pad and Perfect Secrecy CS555 Spring 2012/Topic 3 1 Outline and Readings • Outline • One-time pad • Perfect secrecy • Limitation of perfect secrecy • Usages of one-time pad • Readings: • Katz and Lindell: Chapter 2 CS555 Spring 2012/Topic 3 2 One-Time Pad • Fix the vulnerability of the Vigenere cipher by using very long keys • Key is a random string that is at least as long as the plaintext • Encryption is similar to shift cipher • Invented by Vernam in the 1920s CS555 Spring 2012/Topic 3 3 One-Time Pad Let Zm ={0,1,…,m-1} be the alphabet. Plaintext space = Ciphtertext space = Key space = n (Zm) The key is chosen uniformly randomly Plaintext X = (x1 x2 … xn) Key K = (k1 k2 … kn) Ciphertext Y = (y1 y2 … yn) ek(X) = (x1+k1 x2+k2 … xn+kn) mod m dk(Y) = (y1-k1 y2-k2 … yn-kn) mod m CS555 Spring 2012/Topic 3 4 The Binary Version of One-Time Pad Plaintext space = Ciphtertext space = Keyspace = {0,1}n Key is chosen randomly For example: • Plaintext is 11011011 • Key is 01101001 • Then ciphertext is 10110010 CS555 Spring 2012/Topic 3 5 Bit Operators • Bit AND 0 0 = 0 0 1 = 0 1 0 = 0 1 1 = 1 • Bit OR 0 0 = 0 0 1 = 1 1 0 = 1 1 1 = 1 • Addition mod 2 (also known as Bit XOR) 0 0 = 0 0 1 = 1 1 0 = 1 1 1 = 0 • Can we use operators other than Bit XOR for binary version of One-Time Pad? CS555 Spring 2012/Topic 3 6 How Good is One-Time Pad? • Intuitively, it is secure … – The key is random, so the ciphertext is completely random • How to formalize the confidentiality requirement? – Want to say “certain thing” is not learnable by the adversary (who sees the ciphertext).
  • Applications of SKREM-Like Symmetric Key Ciphers

    Applications of SKREM-Like Symmetric Key Ciphers

    Applications of SKREM-like symmetric key ciphers Mircea-Adrian Digulescu1;2 February 2021 1Individual Researcher, Worldwide 2Formerly: Department of Computer Science, Faculty of Mathematics and Computer Science, University of Bucharest, Romania [email protected], [email protected], [email protected] Abstract In a prior paper we introduced a new symmetric key encryption scheme called Short Key Random Encryption Machine (SKREM), for which we claimed excellent security guarantees. In this paper we present and briey discuss some of its applications outside conventional data encryption. These are Secure Coin Flipping, Cryptographic Hashing, Zero-Leaked-Knowledge Authentication and Autho- rization and a Digital Signature scheme which can be employed on a block-chain. We also briey recap SKREM-like ciphers and the assumptions on which their security are based. The above appli- cations are novel because they do not involve public key cryptography. Furthermore, the security of SKREM-like ciphers is not based on hardness of some algebraic operations, thus not opening them up to specic quantum computing attacks. Keywords: Symmetric Key Encryption, Provable Security, One Time Pad, Zero Knowledge, Cryptographic Commit Protocol, Secure Coin Flipping, Authentication, Authorization, Cryptographic Hash, Digital Signature, Chaos Machine 1 Introduction So far, most encryption schemes able to serve Secure Coin Flipping, Zero-Knowledge Authentication and Digital Signatures, have relied on public key cryptography, which in turn relies on the hardness of prime factorization or some algebraic operation in general. Prime Factorization, in turn, has been shown to be vulnerable to attacks by a quantum computer (see [1]). In [2] we introduced a novel symmetric key encryption scheme, which does not rely on hardness of algebraic operations for its security guarantees.
  • NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Superseded)

    NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Superseded)

    ARCHIVED PUBLICATION The attached publication, NIST Special Publication 800-56 (dated July 2005), has been superseded and is provided here only for historical purposes. For the most current revision of this publication, see: http://csrc.nist.gov/publications/PubsSPs.html#800-56A. NIST Special Publication 800-56 Recommendation for Pair-Wise July 2005 Key Establishment Schemes Using Discrete Logarithm Cryptography Elaine Barker, Don Johnson, and Miles Smid C O M P U T E R S E C U R I T Y NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography DRAFT July 2005 DRAFT Abstract This Recommendation specifies key establishment schemes using discrete logarithm cryptography, based on standards developed by the Accredited Standards Committee (ASC) X9, Inc.: ANS X9.42 (Agreement of Symmetric Keys Using Discrete Logarithm Cryptography) and ANS X9.63 (Key Agreement and Key Transport Using Elliptic Curve Cryptography). Worked examples are provided in Appendix D. KEY WORDS: assurances; Diffie-Hellman; elliptic curve cryptography; finite field cryptography; key agreement; key confirmation; key derivation; key establishment; key management; MQV. 2 NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography DRAFT July 2005 DRAFT Acknowledgements The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates contributions by Rich Davis, Mike Hopper and Laurie Law from the National Security Agency concerning the many security
  • Public Key Infrastructure (PKI)

    Public Key Infrastructure (PKI)

    Public Key Infrastructure Public Key Infrastructure (PKI) Neil F. Johnson [email protected] http://ise.gmu.edu/~csis Assumptions • Understanding of – Fundamentals of Public Key Cryptosystems – Hash codes for message digests and integrity check – Digital Signatures Copyright 1999, Neil F. Johnson 1 Public Key Infrastructure Overview • Public Key Cryptosystems – Quick review – Cryptography – Digital Signatures – Key Management Issues • Certificates – Certificates Information – Certificate Authority – Track Issuing a Certificate • Putting it all together – PKI applications – Pretty Good Privacy (PGP) – Privacy Enhanced Mail (PEM) Public Key Cryptosystems – Quick Review • Key distribution problem of secret key systems – You must share the secret key with another party before you can initiate communication – If you want to communicate with n parties, you require n different keys • Public Key cryptosystems solve the key distribution problem in secret key systems (provided a reliable channel for communication of public keys can be implemented) • Security is based on the unfeasibility of computing B’s private key given the knowledge of – B’s public key, – chosen plaintext, and – maybe chosen ciphertext Copyright 1999, Neil F. Johnson 2 Public Key Infrastructure Key Distribution (n)(n-1) 2 Bob Bob Alice 1 Alice 2 Chris Chris 7 5 8 9 Ellie 3 Ellie 6 David 4 David Secret Key Distribution Directory of Public Keys (certificates) Public Key Cryptosystem INSECURE CHANNEL Plaintext Ciphertext Plaintext Encryption Decryption Algorithm Algorithm Bob’s PUBLIC
  • Introduction, Overview, One Time Pad

    Introduction, Overview, One Time Pad

    University of Illinois, Urbana Champaign LECTURE CS 598DK Special Topics in Cryptography Instructor: Dakshita Khurana Scribe: Joshua Reynolds, Amit Agarwal Date: August 28, 2019 1 Introduction, Overview, One Time Pad 1.1 Introduction This introductory lecture introduces some fundamental goals of cryptography and defines the basic requirement for a useful private key (symmetric) encryption scheme. A basic problem in Cryptography is that of encryption. The encryption problem is that two parties wish to communicate a message without an eavesdropper being able to learn their secret, or even any information about that secret. This problem can be solved with private key (symmetric) encryption under the assumption that both parties already have a shared secret key. This problem can also be solved with public key (asymmetric) key encryption under various other assumptions. These primitives are among the building blocks of more complicated cryptography sys- tems and a useful medium to explore the assumptions made in cryptographic systems. Encryption, in particular, is important because it allows us to communicate secrets safely through an untrusted medium like the Internet. Focusing first on private key encryption, we define the property of correctness. The second necessary property of encryption is security and is covered in part 2 of these lecture notes. 1.2 Notation This set of scribe notes will use the following notation and definitions: • A set will be denoted by a capital letter { M is the set of all possible messages { K is the set of all possible keys { C is the set of all possible ciphertexts • Set subtraction will use the /operator and jSj means the cardinality of set S • An item from a set will be denoted by a lower case letter { m is a message in plaintext (not encrypted) { ct is a ciphertext (encrypted message) { sk is a secret key used as an input in symmetric encryption and decryption • A statistical method of sampling from a set will be denoted with an arrow combined with a description of how the selection is done.
  • Solutions Problem 1. the Ipsec Architecture Documents States That

    Solutions Problem 1. the Ipsec Architecture Documents States That

    Homework 5 - Solutions Problem 1. The IPSec architecture documents states that when two transport mode SA are bundled to allow both AH and ESP protocols on the same end-to-end flow, only one ordering of security protocols seems appropriate: performing the ESP protocol before performing the AH protocol. Why is this approach recommended rather than authentication before encryption? Solution This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Problem 2. Consider the following threats to web security and describe how each is countered by a particular feature of IPSec. a. Brute force cryptoanalitic attack. An exhaustive search of the key space for a conventional encryption algorithm. b. Known plaintext dictionary. Many messages will have predictable plaintext such as HTTP DET command. An attacker can construct a dictionary containing every possible encryption of the known plaintext message. When an encrypted message is intercepted, the attacker takes the portion containing the encrypted known plaintext and looks up the ciphertext in the dictionary. The ciphertext should match against an entry that was encrypted with the same secret key. This attack is especially effective against small key sizes (e.g. 40-bit keys). c. Replay attack. Earlier SSL handshake messages are replayed. d. Man in the middle. An attacker interposes during key exchange, acting as the client to the server and a server to the client.
  • Analysing and Patching SPEKE in ISO/IEC

    Analysing and Patching SPEKE in ISO/IEC

    1 Analysing and Patching SPEKE in ISO/IEC Feng Hao, Roberto Metere, Siamak F. Shahandashti and Changyu Dong Abstract—Simple Password Exponential Key Exchange reported. Over the years, SPEKE has been used in several (SPEKE) is a well-known Password Authenticated Key Ex- commercial applications: for example, the secure messaging change (PAKE) protocol that has been used in Blackberry on Blackberry phones [11] and Entrust’s TruePass end-to- phones for secure messaging and Entrust’s TruePass end-to- end web products. It has also been included into international end web products [16]. SPEKE has also been included into standards such as ISO/IEC 11770-4 and IEEE P1363.2. In the international standards such as IEEE P1363.2 [22] and this paper, we analyse the SPEKE protocol as specified in the ISO/IEC 11770-4 [24]. ISO/IEC and IEEE standards. We identify that the protocol is Given the wide usage of SPEKE in practical applications vulnerable to two new attacks: an impersonation attack that and its inclusion in standards, we believe a thorough allows an attacker to impersonate a user without knowing the password by launching two parallel sessions with the victim, analysis of SPEKE is both necessary and important. In and a key-malleability attack that allows a man-in-the-middle this paper, we revisit SPEKE and its variants specified in (MITM) to manipulate the session key without being detected the original paper [25], the IEEE 1363.2 [22] and ISO/IEC by the end users. Both attacks have been acknowledged by 11770-4 [23] standards.
  • Why Passwords Stink White Paper | Why Passwords Stink

    Why Passwords Stink White Paper | Why Passwords Stink

    WHITE PAPER WHY PASSWORDS STINK WHITE PAPER | WHY PASSWORDS STINK 01 INTRODUCTION 02 PASSWORDS ARE FUNDAMENTALLY INSECURE 03 THE PROBLEM WITH PASSWORDS IS THAT THEY CONTENTS ARE “SHARED SECRETS” 04 CURRENT ALTERNATIVES AREN’T THE ANSWER 05 A SOLUTION TO THE PASSWORD ISSUE 06 INTRODUCING BEYOND IDENTITY 07 CONCLUSION 02 WHITE PAPER | WHY PASSWORDS STINK There are hundreds of billions of passwords in the world today, with more being created every day. In fact, the average business user maintains an astounding average of 191 passwords.1 Unfortunately, these passwords represent a fundamentally weak link in most organizations because INTRODUCTION they will always be insecure. This white paper examines why that is, investigates some alternative solutions, and introduces a new method of authentication using asymmetric keys and certificates to eliminate passwords altogether. 01 1 https://www.securitymagazine.com/articles/88475-average-business-user-has-191-passwords 03 WHITE PAPER | WHY PASSWORDS STINK Let’s face it: Passwords stink! For employees and customers, they cause friction and frustration when logging in – Who can remember the 16-character combination of letters, symbols, and digits that are indicative of strong passwords, much less come up with them in the first place? When PASSWORDS ARE a password gets lost or stolen (and they invariably do), it places a burden on the help desk. In fact, 20-50% of help FUNDAMENTALLY desk calls are for password resets, with the average call costing the organization $70.2 INSECURE For CISOs, passwords represent corporate assets that can be targeted by bad actors. And that’s a problem because they often transit networks in the clear, are stored in databases that can be and often are hacked, are shared 02 among colleagues, and are reused across multiple apps – making them easy targets for malware, phishing attacks, and other credential-stealing schemes.
  • TCP/IP Network Security

    TCP/IP Network Security

    An Intro to Network Crypto Jim Binkley- [email protected] 1 Crypto outline ◆ overview ◆ symmetric crypto (DES ... encryption) ◆ hash/MAC/message digest algorithms ◆ asymmetric crypto (public key technology) ◆ DH - how to start a secure connection ◆ KDC - a little bit on shared secret servers ◆ signatures - authentication with asymmetric keys ◆ certificates - signed public keys ◆ a little bit on authentication 2 overview ◆ there are MANY crypto algorithms and MANY academic network secure protocols ◆ how they are used in network protocols is another matter ◆ traditional IETF RFC said under security considerations (at end of doc) – “not considered here” (another F. Flub) ◆ new IETF POV: must consider here 3 symmetric encryption ◆ both sides know OUT OF BAND shared secret (password, bit string) ◆ encrypt(key, plaintext) -> cybercrud(encrypted) ◆ decrypt(key, cybercrud) -> plaintext ◆ encode/decode use same key (symmetric) – shared secret on both sides ◆ algorithms include: DES, 3DES, IDEA(128), BLOWFISH, SKIPJACK, new AES ◆ ssh uses 128 bit keyed IDEA ◆ DES key 56 bits - 0xdeadbeefdeadbeef 4 DES-CBC ◆ Cipher Block Chaining Mode ◆ DES processes one 64 bit block of data at a time (key is 64 bits (8 bits not important)) ◆ CBC is used so that e.g., two 64 bit blocks in a row that are the same, do NOT produce two 64 encrypted blocks that are the same ◆ C(n) = Ek [C(n-1) xor Plaintext(n)] ◆ requires known IV or initialization vector 5 pros/cons ◆ pros – faster than asymmetric ◆ cons – shared secrets do not scale in general to many users » more people
  • Walking the Bifrost: an Operator's Guide to Heimdal & Kerberos on Macos

    Walking the Bifrost: an Operator's Guide to Heimdal & Kerberos on Macos

    Walking the Bifrost: An Operator's Guide to Heimdal & Kerberos on macOS Cody Thomas Objective By The Sea 3.0 March 2020 WHO AM I? Cody Thomas - @its_a_feature_ ● Operator / Instructor at SpecterOps ● Open Source Developer ○ Apfell – Red Team C2 Framework ○ Bifrost – Kerberos Manipulation ○ Orchard – Open Directory Access ○ GitHub: https://github.com/its-a-feature OVERVIEW ● Brief intro to Kerberos ○ What is it / How does it work / Why do we care? ● Attacking Active Directory Kerberos from macOS ○ Credential Storage / Theft ○ Common Attacks ● Other Kerberos details on macOS ○ LKDC KERBEROS INTRODUCTION A brief overview KERBEROS 101 ● What is Kerberos? ○ Authentication mechanism invented by MIT in 1980s ○ Designed for use on insecure networks ○ Uses math and cryptography to provide strong guarantees ○ Based on a client/server model - stateless ○ Uses ASN.1/DER encoding of data ○ Scoped to ‘realms’ of authentication ● Many implementations ○ Traditional MIT (with plugins) ○ Windows ○ macOS KERBEROS 101 – AUTH STEPS 1. Client and Key Distribution Center (KDC) have shared secret ○ Think of the KDC like an all-knowing PKI management server 2. Client makes a request to the Authentication Server (AS) to be authenticated with the shared secret – i.e. an AS-REQ ○ AS forwards request to the KDC, typically these are the same machine 3. AS responds with a ticket to the krbtgt SPN and encrypts a portion with the krbtgt hash. This ticket is called a Ticket Granting Ticket (TGT). This is an AS-REP. ○ The TGT proves you are who you say you are to the KDC because of the encrypted portion ○ Think of this like a new username/password combination KERBEROS 101 – AUTH STEPS 4.
  • On the (Non)Universality of the One-Time Pad

    On the (Non)Universality of the One-Time Pad

    On the (non)Universality of the One-Time Pad Yevgeniy Dodis Joel Spencer Department of Computer Science Department of Computer Science New York University New York University Email: [email protected] Email: [email protected] Abstract 1 Imperfect Random Sources Randomization is vital in cryptography: secret keys Randomization has proved to be extremely useful and should be randomly generated and most cryptographic fundamental in many areas of computer science, such as primitives (e.g., encryption) must be probabilistic. As a approximation algorithms, counting problems, distributed common abstraction, it is assumed that there is a source of computing, primality testing, as well as cryptographic pro- truly random bits available to all the participants of the sys- tocols (which is the topic of this paper). The common ab- tem. While convenient, this assumption is often highly un- straction used to introduce randomness into computation realistic, and cryptographic systems have to be built based is that the underlying algorithm has access to a stream of on imperfect sources of randomness. Remarkably, this fun- completely unbiased and independent random bits. This ab- damental problem has received little or no attention so far, straction allows one to use randomness in a clean way, sep- despite the fact that a related question of simulating prob- arating out the issue of actually generating such “strong” abilistic (BPP) algorithms with imperfect random sources random bits. Unfortunately, in reality we do not have has a long and rich history. sources that emit perfectly uniform and independent ran- In this work we initiate the quantitative study concerning dom bits.
  • Security Policy Trapeze Networks

    Security Policy Trapeze Networks

    MX-200R-GS/MX-216R-GS Mobility Exchange WLAN Controllers Security Policy Trapeze Networks August 14, 2009 Copyright Trapeze Networks 2007. May be reproduced only in its original entirety [without revision]. Security Policy TABLE OF CONTENTS 1. MODULE OVERVIEW .........................................................................................................................................3 2. SECURITY LEVEL................................................................................................................................................4 3. MODES OF OPERATION.....................................................................................................................................5 4. PORTS AND INTERFACES .................................................................................................................................5 5. IDENTIFICATION AND AUTHENTICATION POLICY................................................................................6 6. ACCESS CONTROL POLICY..............................................................................................................................7 ROLES AND SERVICES................................................................................................................................................7 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS)........................................................................................7 DEFINITION OF CSPS MODES OF ACCESS ..................................................................................................................8