Download Client/Server - The University of Texas at Dallas

Client/Server: Practical
Approaches to Sharing Secure
Information
Dr. Ivor Page,
University of Texas at Dallas
1
First Generation Security
Records Dept.
2
Second Generation Security
A guard to call the cops
if someone breaks in
and a dog to bite him
if he touches anything.
3
Modern security
www
Peace at last
4
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
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
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
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
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
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
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
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
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
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 using
Remote Procedure Calls.
14
Local vs. Remote Calling
Local
Remote
Client
Server
f(x,y) /* call */
f(int x,int y)
Client stub
Server stub
Network
Transport
Network
Transport
f(x,y) /* call */
f(int x, int y)
{
--}
Network
15
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
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
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
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
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
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
Private Key Encryption
M
message
C = Eke(M),
ke
Encryption
Decryption
E
D
C
Cyphertext
M
kd
message
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
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 keyindependent transpositions and key-dependent
bit substitutions.
– A 56 bit number has 17 decimal digits,
considered too large to be enumerated.
23
Public Key Encryption (RSA)
Encryption
Decryption
E
D
M
message
kp
C
Cyphertext
M
ks
message
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
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
E
kpB
D
B
ksB
25
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
D
B
E
ksA
kpA
26
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.
A
E
ksA
D
B or
anyone
kpA
27
Authentication and Secrecy
 An
agent A can send a message M to server
B using EkpB(EksA(M)),
– A first encrypts M using 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
E1
ksA
E2
To network
kpB
28
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
The Hierarchical Security Model
Registrar
University
Dean
Head
Department
Course
School
School
Department
Department
School
Course
46
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
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
Access List
Subset
Agent x
Agent y
Subset m
Agent z
Read, update
Subset n
Read, set holds
Subset p
Read, update
Read
Read
n
m
p
55
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
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