CIS307: SECURITY

Read Chapter 7 in Kurose-Ross's book and chapter 8 in Tanenbaum-VanSteen.

Security Threats can occur to data, hardware, software, and communication links. Examples of security threats are interruptions (with loss of data, denial of service), interceptions, modifications, fabrications. Of course we aim for Secure Systems, with properties such as:

• secrecy (privacy, confidentiality, no eavesdropping with consequent information leakage),
• integrity (no data tampering or other form of vandalism),
• authentication (nobody masquerades as somebody else - spoofing if joe@doe signs in as jane@smith - play-back attack if a malicious user eavesdrop a message, say an encrypted password, and plays it back - misrepresentation if www.pinco.com responds to www.ibm.com. A particular kind of masquerading attack is called man-in-the-middle, whereby an interlocutor or principal, places itself between client and server, passing back and forth messages, after registering them and possibly modifying them). Note that authentication usually implies timeliness: not only I want to verify that it is your message, but also I want to be sure it is not the playback of an old message.
• non-repudiation (nobody denies its actions),
• authorization (making sure that a principal is allowed to do what it wants to do, using mechanisms such as Access Control Matrices, capabilities, encryption, filtering, firewalls),
• auditing (audit-trail = analizable history of use; it establishes a basis for accountability), and
• availability, reliability, safety.

In considering security we need to distinguish what are the security policies supported and what are the security mechanisms used to carry out the policies.

Some of the mechanisms involve:

• Cryptography, i.e. encoding information so that only the intended interlocutors understand the transmitted information [Cryptoanalysis is the code breaker science, and Cryptology include both].
• Message Digests, i.e. hash values computed from the message that almost uniquely identify the message.
• Nonces, i.e. large random numbers used to make (very likely) unique an interaction. Think of the problem of sending your encrypted password: if I capture it then I can pass myself as you by using that encrypted password.

• Digital Signatures, i.e. encoded message digests used to authenticate the sender and verify the integrity of messages. A digital signature is specific to a message.
• Certificate Authority(CA), i.e. an organization that creates and administers the distribution and use of Digital certificates.
• Digital Certificates, i.e. data files that act like an online passport for an internet interlocutor (people, web servers, ..). They are issued by a trusted third party, a Certificate Authority, which verifies the identity of the certificate's holder. They cannot be forged. Digital certificates have two purposes: to certificate their holder, and to protect the data exchanged with that holder. A data certificate is specific to a principal, though a principal may have a number of different digital certificates. You may hear these days of support for e-commerce of wallets, that is components that in addition to the information needed for a certificate, they have the information needed for the use of credit cards, plus shipping information, etc.
• Public Key Infrastructure (PKI), i.e. the definition of the technical, operational, and legal aspects of using a public key system to provide authentication, access control, confidentiality, and non-repudiation.
• Trusted Third party (TTP), i.e. a certificate authority, a public key infrastructure, a higher authority that is agreed to and trusted by the communicating parties.
• Internet Messaging Security Mechanisms, i.e. mechanisms such as the Secure Sockets Layer (SSL), a secure extension for MIME, S-Mime, and a secure extension of HTTP, HTTPS. There is also a Secure Electronic Transactions (SET) protocol and infrastructure for bank card payments over the Internet (developed by Visa, MasterCard, etc.).

CRYPTOGRAPHY

	D = E, i.e. same algorithm for encryption and decryption
	Ke is public, so we call it Kp
	Kd is secret, so we call it Ks
	----------------------------------
	Choose two primes p and q, let N = p*q
	We will be able to send only messages whose numeric code is < N
	Choose an integer e relatively prime to (p-1)*(q-1) = Z.
	Find the smallest integer d such that
		(d*e)mod Z = 1
	[thus d is the modular inverse of e].
	Then the public key Kp is [e,N] and the private key Ks is [d,N].
		     e
		C = M   mod N   //This says that the message M must be smaller
                                //than N. If longer, break it up into 
				//chunks smaller than N and encrypt them 
				//individually.
		     d
		M = C   mod N
        Apparently, given N and e, it is computationally hard to compute d,
        if N is sufficiently large [al least 512 bits]. p and q must each
	be more than 200 bits.
	----------------------------------
	Example: p = 13, q = 17, N = 13*17 = 221, Z = (p-1)(q-1) = 192
		 e = 5
		 d = 77
		 The number of bits we can encrypt is 7 since
		 2^7 = 128 < N = 221.
		 So if we want to send a message longer than
		 7 bits we will decompose it in 7 bit fragments
		 and encrypt them individually. 
	----------------------------------




	The RSA algorithm is not good for protecting
	large messages since with it encryption/decryption are fairly
	slow - more that 1000 slower than DES. But it can 
	be used to transmit essential information, such as 
	secret keys and passwords. [Apparently on a 175Mhz Alpha
	RSA encrypts 1kbps, while 56-bit DES encodes over 30Mbps.] 
	In RSA it is normal to use 512-bit and 1024-bit keys. 

                A  -->  E(M, Kp(B))  -->  B

    unsigned char nextPadByte() {
        static int p = 0; 
	static int q = 0;
	p = (p+1)%256;
	q = (q+R[p])%256;
	unsigned char temp = R[p]; R[p] = R[q]; R[q] = temp;
	return R[R[p]+R[q]%256];
    }

Diffie-Hellman Key Exchange protocol

• A sends to B g^xmod p
• B sends to A g^ymod p

For example p = 23, g = 5; x = 6; then A computes g^xmod p = 5⁶mod 23 = 8. B chooses y = 15 and computes g^ymod 23 = 5¹⁵ mod 23 = 19. Then A computes 19⁶mod 23 = 2 and B computes 8¹⁵mod 23 = 2. A and B have reached the same result!
Diffie-Hellman is vulnerable to man-in-the-middle attack if the identities of the two principals are not authenticated.

Shamir's Sharing a Secret Problem, and Solution

• Compute at random large numbers a₁, a₂, .., a_k-1
• Let y(x) be the polynomial D + a₁ x + a₂ x² + a_k-1 x ^k-1
• Give to person j, for j from 1 to n, the value y(j)
• Since a polynomial of degree k-1 is fully determined when we are given k distinct values of the polynomial, it follows that when k people get together they can determine the polynomial, thus can compute D (the value of y at 0).

DIGITAL SIGNATURES and DIGEST FUNCTIONS (Integrity)

• all receivers R are sure that the document is the unmodified original one (integrity, no tampering),
• it has been sent by A (no impersonation), and
• A cannot deny having sent it (non-repudiation).

Digest Function: a function that, given a document M generates a brief "fingerprint" or "message digest" or "hash value" or "thumbprint" that identifies this document uniquely with almost certainty.
A digest function must be secure, so that we cannot from the digest determine the message that produced it, and must avoid "collisions": it must be computationally unfeasible, given a message, to find another message that generates the same digest.

MD5 (Rivest, 1992): A digest function that generates a 128 bit fingerprint from its text argument. It is much quicker to compute than encrypting with DES [on a 175Mhz Alpha, MD5 digest is computed at over 80Mbps]. Now the most frequently used digest function is SHA-1, which is more secure than MD5 and generates a 160 bit fingerprint from its text argument. For simplicity we use MD5 to refer to a generic hash function.

A sends:

	M + E(MD5(M), Ks(A))    // Ks(A) = Secret key of A

	A  ----> M + E(MD5(M), Ks(A)) ---> B

	A  ----> E(M + E(MD5(M), Ks(A)), Kp(B)) ---> B

We have observed that with a digital signature we also achieve non-repudiation since using public-key cryptography only the sender may have created such a signature. If we had used secret key cryptography that would be lost since now both the sender and the receiver could have created the signature.

Using PGP to send a message

    A --> RSA(K, Kp(B)) + IDEA(M, K) -->  B

Attempts at Authentication

		A  -->  A_id + E(A_id, Ks(A))  -->  B

		A_id + E(A_id + x, Ks(A))

		A  --> A_id --> C  -->  A_id  --> B       
		A  <--  x  <--  C  <--  x  <-- B
	 	A  --> E(A_id + x, Ks(A)) --> C  --> E(A_id + x, Ks(A)) --> B

Direct Authentication and Session Key exchange (using symmetric key)

1. The client sends to the server the message

            clientId
   

2. The server selects at random an integer x [it is random so that likely it was not used before] and sends to the client the message

   	x
   

3. The client uses K(Client) to encode the message received, selects at random a number y, and sends to the server the message

   	E(x, K(client)) + y
   

4. At this point, if x is retrieved, the server is certain of the identity of the client. Now the server sends to the client the message

   	E(y, K(server))
   

5. The client uses K(Client) to decode the message. If y is retrieved, the client is certain of the identity of the server. Mutual authentication has been achieved.

	E(SK, K(server))

As already observed, nonces like x and y are used so that an intruder cannot imitate an interlocutor by just remembering what that interlocutor returned in another occasion (play-back attack).

Access to Protected Pages with HTTP

GET /protected/page.html HTTP/1.1
Host: www.securesite.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
    nonce="754f34bd2a93c53762a73c175e376136"

GET /protected/page.html HTTP/1.1
Host: www.securesite.com
Authorization: Digest
    username="giorgio"
    nonce="754f34bd2a93c53762a73c175e376136"
    response="4e7318ac52a625c148c41c4d525153fa"

Passwords and Logging-In Locally

Passwords and Logging-In Remotely

Direct exchanges of public keys: Man-in-the-Middle Attack

  Alice --> Alice_id --> Mallory --> Alice_id --> Bob
                         Mallory <-- x <-- Bob
			 Mallory --> E(x, Ks(Mallory)) --> Bob
                         Mallory <-- send me your public key <-- Bob
                         Mallory --> Public_key_of_Mallory --> Bob 
                                       Bob now thinks Mallory is Alice since
				       it can decrypt E(x,Ks(Mallory))
  Alice   <--    x  <--  Mallory
  Alice --> E(x, Ks(Alice)) --> Mallory
  Alice <-- Send me your public key <--  Mallory
  Alice --> Public_key_of_Alice --> Mallory
          Now Alice has authenticated herself to Mallory.
  Alice  <-- Bob_id <-- Mallory
  Alice  --> y -->  Mallory
  Alice  <-- E(y, Ks(Mallory)) <-- Mallory
  Alice --> Send me your public key --> Mallory
  Alice <-- Public_key_of_Mallory <-- Mallory
    Alice now thinks that Mallory is bob since it
    can decrypt E(y,Ks(Mallory))
          When Bob sends data d to Alice it sends
		E(d, Public_key_of_Mallory)
          Mallory decrypts and sends to Alice
		E(d, Public_key_of_Alice)
          and similarly in the opposite direction.

Authentication Server and Distribution of Session Key

1. A sends to S the cleartext message

   	A + B
   

   to mean that A wants to interact with B.
2. S generates a timestamp T, a duration L (Lifetime), and a session key K and sends to A the message:

   	E(T + L + K + B, K(A)) + E(T + L + K + A, K(B))
   

3. Now A uses its key K(A) to obtain the session key K, plus T and L; it then sends to B the message

   	E(T + L + K + A, K(B)) + E(A + T, K)
   

4. B uses K(B) to determine T, L, K and A. The E(A + T, K) part is necessary to authenticate that the message is really from A (only A can have obtained the session key K, as demonstrated by the A+T value) and not from somebody that eavesdropped the conversion between S and A and obtained the E(T + L + K + A, K(B)) part. For this reason the E(A+T,K) part is called an authenticator. Now also B has the session key K, plus T and L, and knows that it can interact with A. It does so by sending to A the message

   	E(T+1, K)
   

   to indicate that B is ready. This authenticates B to A since only B has the session key K, as demonstrated by T+1.

Zero-Knowledge Proofs and Authentication

Here is an example of what we mean by zero knowledge proof. Suppose that Peggy wants to prove to Victor that she knows a magical incantation (say abracadabra) for opening a door but does not want Victor to learn that incantation. That is Peggy wants to prove to Victor that she has some knowledge without Victor learning that knowledge. We can assume the following arrangement:

	+------------+--------------+
	|            | Peggy        |
	|   +--------+----------+   |
        |   |                   |   |
        | A |                   | B |
        |   +-------------------+   |
        |                           |
        +-----------   -------------+
                   Victor

More About Digital Certificates, Certificate Authorities, and SSL

• Name and Digital certificate of the certification authority that issued this certificate
• The name and the public key of the owner of the certificate
• Serial number and expiration date of the certificate.

	M + DigitalSignatureOfM + DigitalCertificateOfSender

  E(M+DigitalSignatureOfM, Public_key_Of_Receiver) +
	DigitalCertificateOfSender

A Certificate Authority, in addition to issuing certificates, will be concerned with renewing (i.e. extend the duration), and revoking (i.e. terminating the validity) existing certificates. A Certificate Authority cannot appear as a single server to which all users make appeal. Instead, as in the case of DSN (Distributed Name Service) one needs a distributed structure of communicating certificate authorities. At present there are a number of competing certificate authority services and a server used in e-commerce will have to keep certificates for the certification services it trusts. Front ends to certificate authorities are often called Registration Authorities.

SSL, the Secure Socket Layer, acts as an intermediate layer between the application protocol, say HTTP, and the transport protocol, say TCP. SSL has two subprotocols. One specifies the format of the messages exchanged. The other specifies the handshakes taking place between clients and servers. The protocol allows the selection of the cryptographic algorithm used. It always requires authentication of the server. Authentication of the client is optional. [Server authentication is almost always crucial - think of client having to give to server its own visa card number - and it is done using certificate. Client authentication is rarer - necessary, for instance, if client asks for bank balance; not necessary if client asks for today's weather. In the case that the client gives a credit card number, the application using SSL will have other methods to make sure that the client is who it claims to be.]

In their SSL interactions interlocutors use digital signatures, digital certificates, and rely on certificate authorities. They use random numbers (nonces) to eliminate the possibility of hostile interlocutors remembering old interactions. Communications between client and server are encrypted. Public key cryptography is used only during session setup: the client, usually a browser, selects a secret symmetric session key, encrypts it with the public key of the server, and sends it to the server. Afterwards client and server communicate with the selected secret session key.
SSL has been modified into an Internet standard, the Transport Layer Security (TLS) protocol, as expressed in RFC 2246

A standard for e-commerce secure transactions is SET. It makes for interesting reading, which, in the case of the business description, is also easy.
The library openssl lets us use cryptographic tools at various levels, defining our own protocols, or relying on SSL.