Abstract

TCP and thus HTTP are clear-text protocols, which make no attempt to hide the data being transmitted. For secure data transfers, it thus is necessary to use additional technologies for providing secure data transfers. This lecture looks briefly into the foundations of cryptographic primitives (such as one-way functions and encryption) and cryptographic protocols. For the Web, the most interesting security feature are secure HTTP interactions, which are provided by HTTP over SSL (HTTPS), a protocol that layers an encryption layer (SSL or TLS) between TCP and HTTP.

Cryptography

• Cryptography is structured into different layers
  • layering is a well-established principle for separation of concerns
• Cryptographic primitives implement very basic functionality
  • changes and advancements in this area are limited to very specialized researchers
  • it is easy to make fatal mistakes which then challenge everything built on top if it
• Cryptographic protocols assemble primitives into application-level solutions
  • primitives solve very basic security problems (fingerprints, encryption, …)
  • protocols combine these into applications (digital signatures, secure communications, …)

Essence of Data

• Hashes (or message digests) are a well-known principle in computer science
  • fast to compute (the goal is to make data handling more efficient)
  • few collisions (there are always collisions because of the smaller size)
  • checksums and Cyclic Redundancy Check (CRC) are popular hashes
• One-way functions are cryptographically safe hashes
  • not just for detecting errors, but also for preventing tampering
  • often referred to as cryptographic hash or digital fingerprint
• One-way functions must satisfy additional criteria
  • it must be very hard to find an input producing a given output
  • it must be very hard to find two inputs producing the same output (collision)

Reducing Data

Plausible Encryption

• Secret-Key is was most people think of when thing of encryption
  • Symmetric cryptography is another popular term
• One key for encryption and decryption
• Losing the key makes encrypted data openly readable
  • there must be a secure channel to transport keys
• Good for long-term relationships with few partners
  • exchange secret keys as part of the initial setup of a relationships
  • adding partners requires a secure channel for key exchange
  • changing keys requires a secure channel for key exchange
• Almost impractical in an environment with many ad-hoc partners

Notice the Arrow

Implausible Encryption

• Public-Key intuitively is hard to accept as a concept
  • Asymmetric cryptography is another popular term
• Key pairs of one public and one secret key
  • key generation is the process of generating these key pairs
• The public key can be made available to the public
  • only the secret key can do the inverse operation of the public key
• Good for short-term relationships with many partners
  • publish your public key so that it can be used worldwide
  • everybody can encrypt data using the public key
  • only the owner of the secret can can decrypt the message and read it
• Computationally expensive and not good for a large amounts of data

No Arrow Here …

And No Arrow Here …

Building Secure Applications

• Cryptographic primitives in most cases are not sufficient
  • they provide basic functionality for fundamental tasks
  • they must by combined to provide solutions for real-world problems
• Typical problem: How to ensure key authenticity
  • with insecure keys, the majority of cryptographic methods is worthless
• Typical problem: How to communicate securely without shared keys
  • secret-key does not work, public-key needs to verify the peer
• Typical problem: How to check authenticity and integrity of data
  • integrity can be done with checksums, but these could be forged
  • authenticity needs a cryptographically secure way of combining identity and data

Encrypted Fingerprints

• Hashes are used to check data integrity
• One-Way Functions are used to check data integrity securely
  • it is not possible to reverse engineer data for a given hash
• Signed hashes can be used to ensure data authenticity
  • if the hash sum is signed, it cannot be changed
  • if the data is changed, its hash will not match the signed hash
• Digital signatures work as long as the hash can be securely signed
  • there must be a trusted public key for checking the hash signature

Creating a Digital Signature

Verifying a Digital Signature

Certificate

• Certificates are digital signatures issued by a trusted party
  • most digital signatures are created with certified public keys
  • this means the digital signature is created based on a digitally signed key
• Who can you trust on the Web?
  • trust can only start to grow from some initial trust
  • many systems come with pre-installed trust (root certificates)
  • certificates from other issuers will cause browsers to complain
• Certificates (like domain names) are a very easy way to make money
  • in theory there are different levels of certificates with different levels of identity checking
  • in practice most sites choose the cheapest one that does not give an error message

Encrypted Keys

• Public-Key cryptography is computationally expensive
  • it is possible to encrypt all traffic using asymmetric key pairs
  • this generates considerably more load on the server side
• Combining public- and secret-key cryptography
  1. check the public key for authenticity (using a Certificate)
  2. generate a key for a secret-key encryption scheme
  3. use the public key to transmit the secret key
  4. use the secret key for securely transmitting the payload
• Combines the advantages of both primitives
  • the better efficiency of secret-key algorithms
  • the ability of secret-key algorithms to work without a secure channel

HTTP and Security

• HTTP sends clear-text messages
  • listening to HTTP traffic is trivial
  • information transferred via simple HTTP is public
  • many Web data transfers (in most cases form data) should be secure
• Making HTTP secure requires additional mechanisms
  • S-HTTP was an attempt to define a secure version of HTTP
  • HTTPS uses a secure communication layer underneath HTTP
• Encryption is done by a layer on top of TCP
  • Secure Sockets Layer (SSL) is the protocol layer invented by Netscape
  • Transport Layer Security (TLS) is the standardized Internet version

HTTPS vs. S-HTTP

• Securing HTTP can be done in two ways
  1. using a secure communications infrastructure
  2. making the protocol itself secure (adding cryptographic features)
• Secure infrastructures are better in terms of layering
  • they can be reused for other applications (email, file transfer, …)
  • they can be evolved independently from the application layer
• Secure protocols can provide better integration of security features
  • signed interactions which can be archived for later retrieval
• Layering is more important than tightly integrated security

HTTP and SSL

Transport Layer Security (TLS)

• SSL is the name of the old Netscape standard
• TLS is the name of the newer IETF standard
• TLS adds more encryption schemes and more flexibility

TLS vs. IPsec

Internet Security

• Certificates are used to guarantee a party's authenticity
• Certificates are digital signatures issued by trusted parties
• One authenticated, public keys can be used to securely communicate
• For efficiency reasons, payload encryption uses secret-key cryptography
• Encryption on the Web is based on HTTPS
• VPN-based encryption can be used to secure all traffic