Literature Sources which i found most interesting and authoritative on the subject of Security include

Security Protocol Notation is an ordered sequence of correspondences between Entities

<Sender Entity> --> <intended Recipient Entity> : <contents>
where {X}K means X encrypted with key K
and X, Y, Z means concatenation of X, Y, Z, TS means a timestamp, N means a Nonce

BAN Logic
BAN logic is a formal method for verification of Security Protocols, expressed in Security Protocol Notation. The logic has symbols for representing what Entities see, believe, once said, has jurisdiction over, keys shared and what is encrypted with what keys, and whether information is fresh. Then the logic rules ( message-meaning rule, nonce-verification rule, jurisdiction rule ) can be used to manipulate the symbols producing statements believed to be true.

if a Source who is the authority on some matter, sends an encrypted message about the matter to some Recipient, then as long as the Recipient can verify that the message is “fresh” ( and assumes the encryption is good ), then the Recipient is entitled to believe the matter.

Key Diversification is the practice of generating encryption keys for a particular session or client, so that each session or client has it’s own unique key. This way each Client has it’s own unique Key, K, which if compromised or lost reduces impact.

K = {ClientIdentity}KM
where KM is a master key.

One-Pass Authentication is a simple authentication protocol where a Server is presented with a Token from some Client. The Server makes a trust decision based soley on the Token. The Token identifies the Client. Both Client and Server share knowledge of a symmetric encryption key K.

Client --> Server : ClientIdentity, {ClientIdentity, N}K

Question: does having the ClientIdentity in plain text compromise the security of the key K? My Opinion: It should not. I hope it only depends on the strength of the cypher. Someone trying to brute force guess K and decrypt to get some plaintext containing ClientIdentity is only helped in knowing what to look for in the encrypted text, but not helped in trying to guess K.

The purpose of the nonce N is to prove “Freshness”, ie. the Token is not replayed. Typical Nonce implementations include

  • Random number. Necessary requirement to keep record in theory forever or as long as appropriate. Valet attach => someone has kept old Token copies and replays them after a longer time. Needs to be truly Random. Possible implementation is the encryption of a counter with a key only known to the Nonce generator and only used for that purpose.
  • Counter. Server has a counter value and Client too. Problems with synchronization, not practical.
  • Challenge code, discussed below under Two-Pass Authentication.
  • Timestamp. Requires clock synchronization between Client and Server. Vulnerability to clock setting attack with replay.

Examples:

  • Server can represent a Lock, the Token a “key”. Access control for entry of persons, opening of doors, garage doors, car ignitions.
  • Server can represent a Gas Meter in a home, which has been programmed individually with the ClientIdentity and K. The GasMeter must be tamper resistent because it contains the encryption key, unless it communicates securely back to central office but this is unlikely because otherwise wouldn’t need prepaid Tickets. Kiosk --> GasMeter : ClientIdentity, <amount>, { ClientIdentity, <amount>, N}K

Two Pass Authentication or Challenge Response is an authentication mechanism which involves more than one communication between authenticating parties.
In the basic protocol:

Server-->Client : N
Client-->Server : {ClientIdentity,N}KT

The Client relies on the Serving Entity producing N, which can alleviate some of the nonce problems mentioned in one-pass authentication above. The protocol is succeptible to man-in-the-middle attack when communicated over open channels (ie. radio, internet ).

One-time Pad based encryption schemes are immune to MITM attacks. Require true hardware RNG and xfer of key material to other Entity.

Examples of the protocol can be found in PC Dongles ( not used since PCs themselves are too easy to hack ) and Password Generators for secure(r) login.

Server --> Client : N
Client --> Generator : N, PIN
Generator --> Client : { N, PIN }K
Client--> Server : {N, PIN}K
Simple examples can work with one-way functions instead of reversible encryption. Reflection attack when mutual authentication used, thwarted by including identities in messages and each Entity validate that it is not allowing itself to authenticate itself ( when it’s signal is reflected to itself ).

Key management protocols, enables Entities to communicate securely by distributing a shared symmetric key through communications with a trusted Trusted 3rd Party or TTP (ie. one with which secret keys have been setup apriori).
Example, a Client contacts a TTP indicating that it wants to communicated with a Server. The TTP provides the Client with
two messages, one which the only the Client can decrypt (KC) and the other which only the Server can decrypt (KS). These contain the shared decryption key (KCS) and a Timestamp which acts like a nonce.

Client --> TTP : C, S
TTP --> Client : { C, S, KCS, T}KC, {C, S, KCS, T}KS
where TTP gives Client
Client --> Server : { C, S, KCS, T}KS, { M }KCS
where M is the message the client wants to send to the server, and the Server decrypts the first part to get KAB.

Chicken and Egg Dilema: for generalized key management to work – need apriori key management with someone else.

Password Hashing is the practice of not storing plaintext passwords or more generally secrets, so as to limit the impact of security compromizing the secrets.
Server has stored Hash{Password}
Client --> Server : ClientIdentity,PasswordAttempt
Server performs Hash{PasswordAttempt} and makes trust decision when Hash{Password} == Hash{PasswordAttempt}

Here the Server does not store the Password in clear text, does not need to know the Password cleartext. So the Hash function does not need to be reversible. It can be a one way function, like SHA1, SHA2, or a key derivation function. If the Servers hashed password storage is compromised, brute force Dictionary attacks and Rainbow Tables can determine valid Password’s. To mitigate this, introduction of Salt for the purpose of “key stretching”.
Server has stored Salt,Hash{Salt,Password}
Server performs Hash{Salt,PasswordAttempt}

This is still not considered good enough since Brute force just got better through using specialized hardware GPUs and cloud computing. NTLM and md5crypt hashing function considered no longer suitable for production use. Current best practice is to use algorithms like PBKDF2, bcrypt, and Scrypt which introduce an algorithmic complexity factor which makes the calculation of the Hash function itself harder to compute so as to render brute force attacks impractical.
Server has stored Salt,Rounds,Hash{Salt,Password}
where the Salt is a fixed length random byte sequence which effectively lengthen the Password
and Rounds is a parameter to determine the "strength" of the hashing.

Using a high effort to compute the hash function introduces the risk that the Server has high effort to compute correct hashes. This opens possibility for DOS attacks if not considered. For the ultimately paranoid and to to reduce this limitation, techniques involving separate hashing hardware can be used.
Unreadable Local Parameter is a technique where separate Hardware is used to perform the hash function and it introduces it’s own privately known Salt. Since no-one except the hashing hardware knows the local parameter, it is considered very safe if the parameter is long enough. The reliance on external hardware like USB is not practical for standard IT deployments like virtual setups and cloud computing environments.
Server has stored Salt,Rounds,Hash{UnreadableLocalParameter,Salt,Password} where the UnreadableLocalParameter is secret to the hardware computing the Hash fn

Problem: Password needs transferring to Server for the authentication decision. This requires transport layer security.

Symetric Cryptography is when the same keys are used at either end of the communication channel ( which can be same place different time) to encrypt and decrypt the plaintext. Different cipher algorithms include substitution, block, stream and otp.

Substitution Cipher – replacing plaintext symbols with ciphertext symbols. easy to break, given probability of letters in plaintext which are substituted. Easily “broken” through frequency analysis of the ciphertext. Encryption made “stronger” by combining larger blocks of plaintext to perform substitution on – resulting in Block ciphers. A “good” algorithm will affects large unpredictable changes in ciphertext, given even tiny changes in plaintext.

Stream Cipher – making ciphertext symbol used to replace plaintext dependent on the position of the plaintext rather than the plaintext’ value. Pseudo random number generators (PRNG) can be used to create a random bit-stream which is xor’ed with the plaintext stream to produce the cipher.

One-time Pad can be considered a stream cipher where the “key” is as long as the plaintext. The OTP offers perfect secrecy because there are as many possible keys as plaintext and every key is equally likely. The OTP offers no message integrity. Quantum cryptography entangled bits at both ends of the communication channel can theoretically solve the key distribution problem.

TODO
Asymetric Cryptography

Information on “best practice” for selecting asymetric key sizes is given Wikipedia article.

NIST recommendation on key generation.

NIST sp800-131A recommends 2048bits currently for RSA encryption. More specific information about RSA is provided in NIST sp800-56B.

Encryption Schemes for Messaging or Storage

Integrated Encryption Scheme is a hybrid mechanism, where a sender uses the receivers public key to encrypt a unique session key for the payload encryption. The scheme is based on DiffieHellman using Eliptic Curve of DiscreteLogarithm for key agreement, and some symetric encryption for the payload. Standardization by IEEE-P1363

At the core of PGP is PublicKey based integrated encryption scheme. Typically a sender uses a receiver’s RSA public key to encrypt a AES symmetric key, and sends both encrypted payload and encrypted message key to the receiver. Only the receiver who has the private key can decrypt the message key.

Identity Based Encryption is an alternative to PublicKey based encryption schemes which have some interesting security properties. The main advantage over PKE is that a public key of an entity can be generated from the identity of the entity ( so doesn’t involve public key distribution ). There are however many “problems” noted in the wikipedia article making it difficult / or potentially usable in niches?

TODO
Digests, Digital Signatures

Oracle supports “SHA256withRSA” digital signature algorithm with Java 7.

OWASP tips regarding Digital Signatures implemented in Java.

Certification is the process by which information is endorsed by a trusted entity. Authoritative papers ( see Intrinsic and Extrinsic ). Dr Ed Gerck compares and discusses the different certification methodolgies in Certification Overview where the 3 main methods are stated:

  • Directory – X509
  • Referral -PGP
  • Collaboration – SKIP

The concept of intrinsic certification is quite difficult to understand, considering very little examples are provided. Personally i believe that Intrinsic certification as described by Ed Gerck actually is nothing magic – the process of “cognition” requires communication to with entities outside the communication between subject and relying party. So it is still by my definition “extrinsic” or has extrinsic aspects to a part of the process. Possibly – captcha can be considered as intrinsic certification where the subject is being certified to be human ( but not differentiable from any other human ).

TODO
Kerberos

Transport Layer Security uses cryptography to secure internet communications. SSL is a “synonym” for TLS since SSL is the original name, now insecure and superceeded by TLS. HTTPS builds upon TLS to provide secure communications. TLS1.2 is the latest standard defined 2008, but as of 2013 there is still not good browser ( UserAgent ) support. TLS1.0 seems to be fully supported by all major browsers. There are pitfalls in configuring webservers for strong security. Perfect Forward Security modes of TLS may not be so secure afterall. There are also attacks on TLS’s CBC mode. X.509 Certificate key crypto algorithm choices are complex – see Ron was wrong, Whit is right which gives insight into problems with certificate systems at large scale.

Using TLS/SSL libraries in non browser software is difficult and error prone. Quote from Wikipedia

“A paper presented at the 2012 ACM conference on computer and communications security showed that many applications used several of these SSL libraries incorrectly, leading to vulnerabilities. The authors note that “the root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSL libraries. Instead of expressing high-level security properties of network tunnels such as confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers. As a consequence, developers often use SSL APIs incorrectly, misinterpreting and misunderstanding their manifold parameters, options, side effects, and return values.”

Summarizing this paper, most libraries are difficult to configure to be secure, and configuration mistakes can be effectively disabling validation of the certificate trust chain – as to allow MITM attacks.

Protocol starts with trust relationships defined extrinsically to the dialog between Client and Server.

Client KeyStore( Kc-priv,Kc-pub,Cert-client:=Kc-pub,CA-c), TrustStore( Cert-server or CA-s ), supported TLS version, compression, encryption.
Server KeyStore( Ks-priv,Ks-pub,Cert-server:=Ks-pub,CA-s), TrustStore( CA-c or Cert-client ), allowed TLS version, compression, encryption, client authentication.
Protocol:
Client --> Server : "ClientHello",supported TLS version, compression, cipher, Nrand-c
Server --> Client : "ServerHello",chosen TLS version, compression, cipher,Nrand-s
Server --> Client : "Certificate",Cert-server
[ Server --> Client : "ClientCertificate" ] if client authentication required
Server --> Client : "ServerHelloDone"
[ Client --> Server : "Certificate",Cert-client
Client --> Server : "ClientKeyExchange",{preMasterSecret}Ks-pub
[ Client --> Server : "CertificateVerify"+{msgs}Kc-priv
Client --> Server : ChangeCypherSpec ( server creates K-master := PRF(preMasterSecret, "master secret", Nrand-c+Nrand-s) )
Client --> Server : {Finish}K-master ( where Finish := PRF(masterSecret,"client finished",Hash(msgs)) )
Server --> Client : ChangeCypherSpec ( client creates K-master as Server with known preMasterSecret )
Server --> Client : {Finish}K-master ( where Finish := PRF(masterSecret,"server finished",Hash(msgs)) )

Basically what makes TLS protect against MITM attacker is that the preMasterSecret is encrypted with Ks-pub and sent by the Client to the Server. Only the Server has Ks-priv so to get the preMasterSecret in plain-text. However since Ks-pub is transferred to the Client by potentially a MITM attacker, it boils down to whether Ks-pub is trusted or not. If you trust the MITM’s public key, you’re skrewed!

TODO – relate cipher choices to symetric encryption section.

TODO – relate certification/RSA asymetric encryption section.

OpenVPN is a vertical application based on TLS which allows for secure IP traffic tunneling.

DNS:

some browsers like chrome implemented own cache. And
SQUID is a proxy with DNS cache. Java also has it’s own DNS cache, see NetworkProperties, in particular

-Dnetworkaddress.cache.ttl=7200
-Dnetworkaddress.cache.negative.ttl (default: 10)

DNS behaviour is OS dependent.

linux
OS – setup etc/resolv.conf gives list of nameserver IPs.
standard name querying APIs (getaddrinfo() et al.)
normally no DNS cache by default ( if needed install separate tools: nscd , dnsmasq )

windows – ipconfig /flushdns
OS – setup config via DHCP or in TCP/IP config window

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: