Servers and secure communication

1. Servers and secure communication Jeff Chase Duke University

2. Shell lab • We need to understand a little about: • job states: foreground and background • process states • blocking or sleep states: waiting for an external event • Shell exposes a fundamental problem: • Many programs monitor/control asynchronous activities. • E.g., shell manages children, apps wait for clicks, servers wait for requests, everyone waits for I/O to complete. • How should a program wait for the next event, if there are many possible events to wait for? • Wait for a specific event  may miss others. • Good event handling mechanisms are important.

3. Unix was wrong • Unix was designed around blocking system calls. • read from tty • wait* for child process • listen for arriving server connection • Blocked process makes no progress until event occurs. • signals an afterthought to “kill” a process • Unix got it wrong. • Evolving signal mechanisms for better shells. • Evolving designs for high-performance servers. • Newer systems (and Ux variants) have better event handling mechanisms. • Kqueue, epoll, Android component interfaces

4. Wait (Unix)

5. Wait* Shell waits in read call for next command from tty. dsh fork “echo y” wait exec argv[0]=“echo” argv[1]=“y” argc = 2 If a child is running in the foreground, the parent shell “suspends execution” (blocks or sleeps) until the child changes state (e.g., exits). Child process continues on to execute “echo” program independently of parent.

6. Parent/child interaction dsh fork Child blocks when it receives a STOP signal (e.g., resulting from ctrl-z on keyboard). “echo y” A wait returns when the status of the child changes (e.g., STOP). exec STOP wait wait SIGSTOP “<ctrl-z>” The awakened shell blocks in read to accept the next command. Child wakes up when it receives a CONTINUE signal (e.g., sent by shell). kill SIGCONT “fg” What if a foreground job exits before the parent calls wait? exit EXIT

7. Job states and transitions fg exited exit SIGCONT set-fg ctrl-z (SIGSTP) exit stop bg SIGCONT tty in tty out

8. Monitoring background jobs dsh Parent can use a non-blocking wait to poll the status of a child. fork “echo y&” “jobs” wait exec EXIT How should a parent learn of status changes to a child if it’s busy doing something else and does not poll? “Do you know where your children are?”

9. Monitoring background jobs dsh fork “echo y&” What if a child changes state while the shell is blocked on some other event, e.g., waiting for input, or waiting for a foreground job to complete? coffee…. exec EXIT A “real” shell should notice and inform the user immediately. But dsh will not. Parent is waiting for read to return the next input command. How should parent learn of the child exit event?

10. Shell and children dsh Any of these child jobs/processes could exit or stop at any time. P1A P1B P3A Job 1 Job 3 P2A Job 2

11. Monitoring background jobs dsh A “real” shell receives SIGCHLD signals from the kernel when a child changes state. If the shell is blocked on some other system call (e.g., read), then SIGCHLD interrupts the read. fork “echo y&” coffee…. exec STOP Event notifications SIGCHLD Key point: many programs need to be able to receive and handle multiple event types promptly, regardless of what order they arrive in. Unix has grown some funky mechanisms to deal with that. EXIT SIGCHLD

12. Process states and transitions exit exited running EXIT fg or bg STOP The kernel process/thread scheduler governs these transitions. wait sleep blocked ready wakeup fg or bg wait, STOP, read, write, listen, receive, etc. Sleep and wakeup are internal primitives (later).

13. Inside the Shell while (1) { Char *cmd = getcmd(); int retval = fork(); if (retval == 0) { // This is the child process // Setup the child’s process environment here // E.g., where is standard I/O, how to handle signals? exec(cmd); // exec does not return if it succeeds printf(“ERROR: Could not execute %s\n”, cmd); exit(1); } else { // This is the parent process; Wait for child to finish int pid = retval; wait(pid); } }

14. Communication: endpoints and channels endpoint port operations advertise (bind) listen connect (bind) close write/send read/receive channel pipe binding connection data transfer stream flow messages request/reply RPC events If one side advertises a named endpoint, we call it a server. If one side initiates a channel to a named endpoint, we call it a client.

15. Protection systems Every file and every process is labeled/tagged with a user ID. A root process may change its user ID. Alice • Every process (or other entity) has a label that governs its access rights on the system. • The label is a list of named attributes and optional values. • Each system defines the space of attributes and their interpretation. • Some attributes and values represent an identity bound to the process. • E.g.: uid=“alice” log in login fork, setuid(“alice”), exec shell fork/exec tool uid=“alice” A process inherits its userID from its parent process.

16. Android permissions http://source.android.com/tech/security/

17. Services RPC GET (HTTP)

18. Binding to a service (Android) public abstract boolean bindService (Intent service, ServiceConnection conn, int flags) Connect to an application service, creating it if needed. …The given conn will receive the service object when it is created and be told if it dies and restarts. … This function will throw SecurityException if you do not have permission to bind to the given service.

19. Networking endpoint port operations advertise (bind) listen connect (bind) close write/send read/receive channel binding connection node A node B Some IPC mechanisms allow communication across a network. E.g.: sockets using Internet communication protocols (TCP/IP). Each endpoint on a node (host) has a port number. Each node has one or more interfaces, each on at most one network. Each interface may be reachable on its network by one or more names. E.g. an IP address and an (optional) DNS name.

20. Networking and distributed systems endpoint port channel binding connection node A node B Nodes may crash (fail-stop). They may lie, cheat, or steal (“Byzantine” failure) They may run different software. Networks might not be reliable or safe. Issues:

21. Real networks are insecure Mallory attack Bob Alice

22. Crypto primitives Encrypt/Decrypt Use a shared secret key (symmetric) or use a keypair one public, one private (asymmetric) Signing Secure hashing useful for fingerprinting data

23. Cryptography for Busy People • Standard crypto functions parameterized by keys. • Fixed-width “random” value (length matters, e.g., 256-bit) • Symmetric (DES: fast, requires shared key K1 = K2) • Asymmetric (RSA: slow, uses two keys) • “Believed to be computationally infeasible” to break E D M Encrypt K1 Decrypt K2 M [Image: Landon Cox]

24. Symmetric Crypto • “Secret key” or “private key” cryptography. • DES, 3DES, DESX, IDEA, AES • Sender and receiver must possess a shared secret • Shared key K • K = K1 = K2 • Message M, Key K {M}K = Encrypt(M, K) M = Decrypt({M}K , K)

25. Example: Java KeyGenerator class “A key generator is used to generate secret keys for symmetric algorithms.” [oracle.com]

26. Example: Java Cipher class “The Cipher class provides the functionality of a cryptographic cipher used for encryption and decryption. Encryption is the process of taking data (called cleartext) and a key, and producing data (ciphertext) meaningless to a third-party who does not know the key. Decryption is the inverse process: that of taking ciphertext and a key and producing cleartext.” [oracle.com]

27. Simple shared-secret based cryptographic authentication shuque@isc.upenn.edu

28. Add mutual authentication shuque@isc.upenn.edu

29. Two “Key points” • The random challenge is a nonce. • “number used once” • Understand why the protocol uses a nonce. • In order for this protocol to work, Alice and Bob need a shared secret. • How can they establish this shared secret safely?

30. Asymmetric Crypto • Sometimes called “public key” cryptography. • Each subject/principal possesses a keypair: K-1 and K • Decrypt(K, Encrypt(K-1, M)) = M • Each principal keeps one key private. • The inverse key may be public. • Either key can be used to encrypt/decrypt.

31. Example: Java KeyPairGenerator class “The KeyPairGenerator class is an engine class used to generate pairs of public and private keys.” [oracle.com]

32. Asymmetric crypto works both ways Crypt E D A’s private key or A’s public key Crypt A’s public key or A’s private key [Image: Landon Cox]

33. Q • If Alice knows Bob’s public key, how can Alice use it to verify that the party on the other end of a channel is Bob? • What could go wrong? • How is this “better” than symmetric crypto? • How is it “worse”?

34. Cryptographic hashes • Also called a secure hash or one-way hash • E.g., SHA1, MD5 • Result called a hash, checksum, fingerprint, digest • Very efficient SHA1 hash “Hash digest” Arbitrarily large 160 bits [Image: Landon Cox]

35. Properties of Secure Hashing • Collision-resistant • There exist distinct M1 and M2 such that h(M1) == h(M2). • Such collisions are “hard” to find. • One way • Given digest, cannot generate an M with h(M) == digest. • Such collisions are “hard” to find. • Secure • The digest does not help to discover any part of M.

36. Properties of Secure Hashing • Collision-resistant • There exist distinct M1 and M2 such that h(M1) == h(M2). • Such collisions are “hard” to find. • One way • Given digest, cannot generate an M with h(M) == digest. • Such collisions are “hard” to find. • Secure • The digest does not help to discover any part of M. Haven’t SHA-1 and MD5 been broken? Sort of…it turns out collisions are easier to find than thought, at least in some instances.

37. Digital Signature • A hash digest of M encrypted with a private key is called a digital signature • “Proves” that a particular identity sent M. • “Proves” M has not been tampered. • “Unforgeable” • The sender cannot deny sending M. • “non-repudiable” • Can be legally binding in the United States

38. http://pst.libre.lu/mssi-luxmbg/p1/04_auth-art.html

39. Digital signatures with public keys Key point: understand how/why digital signatures use digests and asymmetric crypto together.

40. Two “key points” • Digital signatures are “stronger” than physical signatures, because they are bound to the document contents. • Attacker cannot change the document contents without invalidating the signature. • To verify a signature, the receiver must already know the public key of the signer. • And it must be right. • But how to know for sure?

41. Two Flavors of “Signature” • A digest encrypted with a private asymmetric key is called a digital signature • “Proves” that a particular identity sent the message. • “Proves” the message has not been tampered. • “Unforgeable” • The sender cannot deny sending the message. • “non-repudiable” • Can be legally binding in the United States • A digest encrypted with a shared symmetric key is called a message authentication code (MAC). • faster, but…

42. MAC “Similar to a MessageDigest, a Message Authentication Code (MAC) provides a way to check the integrity of information transmitted over or stored in an unreliable medium, but uses a [symmetric secret] key in the calculation. Only someone with the proper key will be able to verify the received message. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties.” [oracle.com]

43. What happens… • How to authenticate shop.com? • How to assure integrity/privacy of communications? • How to prevent man-in-the-middle attack? • How does shop.com authenticate you? • Answer: Secure Sockets (SSL) or Transport-Layer Security (TLS) https://www.shop.com/shop.html

44. Symmetric and Asymmetric Crypto: Better Together • Use asymmetric crypto to “handshake” and establish a secret session key (slow, but allows for key distribution). • Then use the key to talk with symmetric crypto (fast and cheap) • Example: Secure Sockets Layer (SSL) or Transport-Layer Security (TLS), used in HTTPS (Secure HTTP), SSH, SCP, etc. “SYN, etc.” “My public key is K.” “Let’s establish a session key: {S}K.” Server {M}S Client [encrypted data or content] …

45. What are we missing? • Does C know (believe) that K really is the public key of S? • How to authenticate S?

48. Example: Certificate Certificates allow A to endorse the public key of B. The endorsement can be validated by anyone who knows and trusts A.

49. A Digital Certificate (X.509)

50. Trust management and PKI • An entity A delegates trust to another by endorsing its public key for possession of an attribute or role. • The delegation is a fact written as a logic statement and issued in a certificate that is digitally signed by A. • In a standard x.509 identity certificate (e.g., issued by a PKI CA for web), the attribute is a distinguishing name. • e.g., “Alice” or “amazon.com” • But it could be more… Certificate Term of validity Issuer’s name (or key) A.trusts B Payload: statement A B trusts Signature