Client/Server: Practical Approaches to Sharing Secure Information

1. Client/Server: Practical Approaches to Sharing Secure Information Dr. Ivor Page, University of Texas at Dallas 1

2. First Generation Security Records Dept. 2

3. Second Generation Security A guard to call the cops if someone breaks in and a dog to bite him if he touches anything. 3

4. Peace at last Modern security www 4

5. The Problem • Student Record Systems are databases. • Increasing number of people (agents) need instant access to student information. • There are many types of transactions and different agents need different capabilities. • The database must authenticate agents and enforce authorization rules on agents. 5

6. More Problems • Some transactions require a “process” in which several agents must concur in a strict sequence before the transaction is “committed” to the database (a grade change) • The agents are geographically distributed. • The system must log all transactions and must be able to undo any subset of them and restore itself to a previous state. 6

7. Even More Problems • Security is a legal requirement and must contend with both accidental and malicious attacks • Agents are humans, some have Ph.Ds, and some are deans • At the time when the database is created we cannot think of all the fields and kinds of analyses on the data that will be needed 7

8. Ease of use/Completeness • Ideally, each agent should be able to access the data within his/her security scope in any authorized fashion, using a query language that is both easy to learn, yet powerful enough for complex analyses, statistical summaries, etc. • It should rarely be necessary to extract data for further analysis in another program. 8

9. Security Again • The main form of personnel authentication comes from login validation. We use the model of the supermarket cash register. The checkout clerk takes the key with her/him when absent, even for a short while. • Unlike the supermarket, the database agent has no physical key; we model the key by login/logout procedures. 9

10. Network Security • The most challenging security problem comes from the need for network access. • Agents are located across campus and communicate with the database via a network. • Messages to and from the database may pass through network nodes that are not part of the student record system. These nodes may be accessible to students, faculty, and others. 10

11. Network Security • Networks comprise a huge variety of software written by many different vendors. • It is rarely possible to redesign an entire network. Our records system must work with existing software that may not be secure. • Typically, our system sits at the highest layer of the network software hierarchy. Our messages are passed through many other layers. 11

12. Network Security • Messages are partitioned into packets with added headers containing the packet types and the network addresses of senders and recipients. • Typically headers are not encrypted. This makes it easy for anyone to capture all packets going to or from a certain network node. • Since we cannot easily prevent adversaries from seeing and collecting our messages, they must be encrypted. 12

13. Network Security • Lap-top computers, PCs, and workstations can be connected to the network. • We must capture and reject false transactions sent by these computers that attempt to imitate (spoof) the transactions of real agents. • Allowing logins to the records system from computers connected via telephone networks greatly increases risk. 13

14. What is a Client/Server System? • Client/Server systems have two program components, a client (replicated at each agent’s site), and a (centralized) server. • The client program calls functions within the server program in order to complete its transactions. • The calls are completed by usingRemote Procedure Calls. 14

15. Local vs. Remote Calling Local Remote Client f(x,y) /* call */ Client stub Network Transport Server f(int x,int y) Server stub Network Transport f(x,y) /* call */ f(int x, int y) { - - - } Network 15

16. Why Client/Server? • Simplicity: The Client/server paradigm enables a very simple and flexible interface between the computational components. • It is simple to add functionality. • With TCP/IP, the RPC interface constitutes a reliable connection-oriented network protocol. 16

17. Why Client/Server? • Security • Having computational power at all agent sites enables a secure communications system in which messages are encrypted. • Clients and server authenticate all messages. • Authentication protocols are easier to design if a reliable client/server interface is assumed (Kerberos). 17

18. Why Client/Server? • Efficiency/scalability: The client/server approach enables some of the computational effort to be carried out in the client. • A balance is possible in which the client and server have different functions and work together to complete each transaction. • The server’s effort can be minimized allowing the size of the network to grow with demand. 18

19. Why Client/Server? • The Client/Server paradigm closely matches the paradigm of Object Oriented Programming in which computation proceeds through inter-object communication. • The OOP paradigm is said to provide a natural partitioning of a program into objects that are self contained and have clean and simple interfaces. This should translate into more reliable programs. 19

20. Authentication and Authorization • Each transaction reaching the server (student records database) must receive two checks: • Is this request from the agent indicated in the transaction? - Authentication. • Is this agent permitted to carry out the requested action? - Authorization. 20

21. Authentication and Secrecy • Digital signatures and encrypted messages are two powerful, but not entirely fail-safe, security techniques. • A digital signature is a (huge) unforgeable password sent with every message that uniquely identifies the sender. • Modern encryption techniques are considered safe for all but the highest levels of security. 21

22. Private Key Encryption Encryption Decryption M M E D C message ke kd message Cyphertext C = Eke(M), M = Dkd(C) = Dkd(Eke(M)) We can make the keys the same: k = ke = kd, so that C = Ek(M), M = Dk(Ek(M)) The algorithms E and D are public, but k is private. 22

23. DES • DES is a private key encryption system. • Messages are split into 64 bit chunks and keys of up to 56-bits are used. • Encryption and decryption involve key-independent transpositions and key-dependent bit substitutions. • A 56 bit number has 17 decimal digits, considered too large to be enumerated. 23

24. Public Key Encryption (RSA) Encryption Decryption M M E D C message kp ks message Cyphertext C = Ekp(M), M = Dks(Ekp(M)) In RSA also, M = Dkp(Eks(M)) (Algorithms are inverses) Algorithms E and D, and the key kp are public, but the key ks is secret. It is impossible to infer ks from knowledge of E, D, and kp. 24

25. Public key Encryption, RSA • An agent A with public and secret keys kpA and ksA can send a message M to server B with public and secret keys kpB and ksB using EkpB(M), the public key of the server. • Only B can decrypt this message using ksB A B E D kpB ksB 25

26. Public key Encryption, RSA • B can send a message M to A using EkpA(M), the public key of the agent. • Only A can decrypt this message, using ksA. A B D E ksA kpA 26

27. Authentication with RSA • Agent A can send a message M to server B using EksA(M), the agent’s secret key • Anyone can decrypt the message using A’s public key, but only A could have sent it. • Authentication is obtained, but secrecy is not. B or anyone A E D ksA kpA 27

28. Authentication and Secrecy • An agent A can send a message M to server B using EkpB(EksA(M)), • A first encrypts Musing its secret key, then again using the server’s public key. • An adversary would need to discover ksA to construct such a message and ksB to decrypt it. A To network E1 E2 ksA kpB 28

29. Code breaking • With public-key encryption, code breaking entails factoring a huge integer. • Many of the well-publicized successful encryption breaks have been due to poor selection of the keys. • If the keys are carefully chosen, it should take months if not years to break the code (although we have no formal proof of this). 29

30. Question: • Student records could be valuable to a criminal throughout the students’ lives. Should our security be sufficient to prevent captured student records from ever being decrypted? • If society felt this was so, then current techniques may not be adequate. • However, we don’t have anything better... 30

31. Key server • A key-server is needed to send the public and secret keys to the database server and the clients in highly secure fashion. • The Kerberos System (MIT) is based on the client/server model and uses the DES private key encryption system. • CCITT X.509 is based upon a public key encryption system. It has a security hole. 31

32. What are the threats? • Service Interruption • Service becomes unavailable because of corruption of database or network software, or the injection of false messages that clog-up the system. • Data Interception • Data captured by a “sniffer,” a security hole in a network node, or the theft of a tape... 34

33. What are the threats? • Data Modification • Records are illegally altered • Data Fabrication • Fraudulent records are entered. Since we are moving towards receiving applications via the web, and electronic delivery of transcripts, it is likely that fraudulent applications and transcripts will become a serious problem. 35

34. What are the threats? • Spoofing • An adversary is able to pretend to be a real agent, sending and receiving messages in that agent’s guise. • The adversary imitates the real agent’s login procedure, or sends fraudulent transactions while the real agent is logged in. 36

35. What are the threats? • One simple spoofing technique replays messages from real agents that were obtained by eavesdropping using a sniffer. The hope is that the server will respond as if to the real agent. • Authentication and time stamping should defend against this approach. 37

36. Defense Against Spoofing • Instigate complex login procedures and the associated personnel training and, • make sure all messages are authenticated. • Ideally the agent and the agent’s computer should both be authenticated on every transaction. 38

37. Interception • Interception may be quite easy. “Sniffers’ are devices connected to the network in an attempt to capture messages. They might simply make copies of all packets going to/from a certain network address. • Further lengthy analyses of captured messages may reveal security holes, passwords, keys, etc. 39

38. Interception • It may be possible to guess the nature of an interaction by analyzing the lengths of the packets and/or the time of the interaction. • One adversary asks an agent for some details while another operates a sniffer. • Ideally all packets should be the same length and agent programs should transmit dummy packets to maintain a relatively constant rate. 40

39. What is transported to agents? • An agent may want to view an entire student’s transcript, or a class grade-roll. While these data are at the client computer, a security breach is possible. • It is preferable to have data at the client encrypted. The data in the client’s video buffer and visible data on the screen are not encrypted. This problem requires a hardware solution. 41

40. What is transported to agents? • For statistical summaries, etc., the client computer should do the computations. • If we transport all associated records to the client we cause a security weakness. • Unless essential to the task, the fields identifying the students should not be sent. • Only send the data that are actually needed. 42

41. Authorization: Data Organization • Student data are organized naturally by department and degree level. • There is duplication of data, so consistent update procedures are needed. • Students’ grades appear in the students’ own records, in individual course records, and in summary records. A grade change must affect all copies of the grade in all records. 43

42. The Hierarchical Security Model • Hierarchy: • Agents are organized into levels with differing capabilities at each level • The lowest level agents can see only a restricted subset of the data and cannot change any records, modify holds, etc • The highest level agents can see and modify any record 44

43. The Hierarchical Security Model • This model is simple to maintain, but is probably insufficient on its own. • A dean should not be able to see or alter records of students outside his/her school. • The necessary data structure therefore becomes a tree. • There are some anomalies, double majors... 45

44. The Hierarchical Security Model 46

45. The Hierarchical Security Model • The tree-based hierarchical model may be insufficient. • Some agents may have access needs that do not match the tree structure. For example, honors students may be spread across the departments and courses. The honors program director may need restricted access to the records of just the honors students. 48

46. Access List Security Model • Access Lists: • The database contains a matrix giving, for each agent and subset of the database, the allowed actions. • Any agent can submit any transaction. The authorization check is within the database. 54

47. Access List Subset n Agent x Agent y Agent z Subset m Read, update Subset n Read, set holds Read Read Subset p Read, update m p 55

48. Access List Security Model • Maintenance is again a problem. • The number of agents could be large. • There could be a huge number of subsets. • The access matrix would then be huge. • Agents could be grouped by common access requirements to reduce the size of the matrix. • Changes to the access matrix must be carried out by one or two highly trusted supervisors. 56

49. Overall Security • No matter what security model is used, and no matter whether digital signatures and encrypted messages are employed, if an adversary can discover the login-id and password of a real agent, the data in the scope of that agent are at risk. • This, and physical security, present the biggest threats. 58