Security

Ogg-Vorbis format, 19Mbytes	MP3, 19Mbytes	WAV format, 210
Ogg-Vorbis format, 40Mbytes	MP3, 40Mbytes	WAV format, 440Mbytes

Security

Security of the organisation affects 100% programs you write
Many more opportunities for security problems in client/server applications
- Unauthorised access
- Disclosure of information
- Modification of information
- Denial of service

Orange Book

D - minimal
C1 - discretionary access control
C2 - controlled access protection
B1 - labelled security protection
B2 - structured protection
B3 - security domains
A1 - verified design

Orange Book

C1
- separation of users and data
- indentification and authentication
- integrity base
- tested controls
C2
- finer grained access control
- login procedures
- auditing of security events
B1
- security policy model
- labelling (e.g. TOP SECRET)
- mandatory access control

Orange Book

B2
- formal security policy model
- device labels
- DAC and MAC (Message Authentication Code) (fancy checksums)
- covert channel control
- more extensive testing
B3
- reference monitor mediates all access
- security administrator support
- system recovery required
- auditing expanded
A1
- formal design and verification

ISO Protocol

ISO Security - Functions and Levels

Peer entity authentication (3, 4, 7)
Data origin authentication (3, 4, 7)
Access control service (3, 4, 7)
Connection confidentiality (1, 2, 3, 4, 6, 7)
Connectionless confidentiality (1, 2, 3, 4, 6, 7)
Selective field confidentiality (6, 7)
Traffic flow confidentiality (1, 3, 7)
Connection integrity with recovery (4, 7)
Connection integrity without recovery (4, 7)
Connection integrity selective field (7)
Connectionless integrity selective field (7)
Non-repudiation at origin (7)
Non-repudiation of receipt (7)

ISO Security - Mechanisms

Peer entity authentication
- encryption
- digital signature
- authentication exchange
Data origin authentication
- encryption
- digital signature
Access control service
- access control lists
- passwords
- capabilities lists
- labels

ISO Security - Mechanisms

Connection confidentiality
- ecryption
- routing control
Connectionless confidelity
- encryption
- routing control
Selective field confidelity
- encryption
Traffic flow confidelity
- encryption
- traffic padding
- routing control

ISO Security - Mechanisms

Connection integrity with recovery
- encryption
- data integrity
Connection integrity without recovery
- encryption
- data integrity
Connection integrity selective field
- encryption
- data integrity
Connectionless integrity
- encryption
- digital signature
- data integrity

ISO Security - Mechanisms

Connectionless integrity selective field
- encryption
- digital signature
- data integrity
Non-repudiation at origin
- digital signature
- data integrity
- notarisation
Non-repudiation of receipt
- digital signature
- data integrity
- notarisation

Security Policies

Anything not explicitly permitted is prohibited
Anything not explicitly prohibited is permitted
These are (or should be) set at the organisation level, and have nothing to do with the convenience of programmers
A policy may be
- vague
- quite detailed, even to the level of which ports are blocked to/from which hosts. As a programmer, you prefer this form

Security Functions Needed

Identification
Authentication - proof of identity
Authorisation - privileges belonging to identity
Integrity - data is not tampered with
Confidentiality - data is not exposed to others
Delegation and administration
Recording
Monitoring

Software Vulnerability

Any piece of software has bugs
The more complex the software, the more bugs
Software dealing with security will have security bugs

Security Locations

Host security
Network security

Host Security

Authentication (e.g. passwords)
Authorisation (e.g. access files)
Physical access

Network Security

Isolate network
Protect behind firewalls
Use proxy servers

Routers

Firewalls

A firewall is a router that controls access as well as routes
Some packets are passed, some are discarded
The firewall controls all access between the network and internet
A "filter" uses rules to decide what passes and what doesn't

Filter Mechanisms

Ethernet packets contain ethernet header information, plus IP data
IP packets contain IP header information, plus TCP/UDP data
So on, upto particular protocol data
The filter can examine the IP header and the TCP/UDP header

IP Header Information

An IP packet has a header containing the following information

IP source address
IP destination address
protocol type (e.g TCP)
options (little used)
packet body

Filtering by IP Header

Block outward access by discarding all packets with IP destination address external to organisation
Block inward access by discarding all packets with IP source address external to organisation
Fragmentation of IP packets makes it harder to filter on packet data information

TCP and UDP Ports

Services are identified by numbers known as ports

TCP Header Information

A TCP packet has a header containing the following information

TCP source port
TCP destination port
ACK bit
data

Filtering by TCP Header

First packet opening connection has ACK bit unset, later ones have it set
Block inward TCP calls by discarding packets with ACK bit unset and external IP source
All later packets from same source are discarded by recipient as garbage because there was no start packet

UDP Header Information

A UDP packet has a header containing the following information

UDP source port
UDP destination port
data

Filtering by UDP Header

Much harder as there is no ACK bit, so can't tell when an external source is trying to connect
No sequence order or delivery guarantee, so harder to use content

Remote Procedure Call

Portmapper is on port 111
RPC servers use a random port
RPC servers register port and RCP identifier with portmapper
RPC clients ask portmapper for port of RCP server
Clients then establish connection directly with server
Clients may ask portmapper to forward RPC requests directly to server

Spoofing Header Information

Source address not guaranteed
Easier to spoof UDP than TCP

Proxy servers

Client queries local server that can

filter request
answer locally
forward request to remote server

Lessons for Client/Server

Verify IP origin
Use logging
Care with user configurable files
Care with passwords
Use handshaking
Keep security layer simple
Encrypt sensitive data
Design protocol to allow security checks
Ensure your protocol is allowed by security manager if crossing firewalls
More likely to find UDP blocked than TCP

Use Logging

Log all activities, to provide an audit trail
Inspect the audit trail
Failed accesses are the most interesting

IP verification

Using the IP origin, find the IP name
Using the IP name, find the IP address(es)
Verify that the origin address is in these

User Configurable Files

Ensure that users can't compromise security
- accidentally
- deliberately

Passwords

Ordinary passwords should not be sent across insecure network in plain text
rlogin sends them in plain text
telnet uuencodes them before sending (7 bit representation of 8 bit data), but this is not secure
Receiving program should not accept encrypted passwords, in case they are just duplicates
One-shot passwords are secure either in plain text or encrypted

Handshaking

Make the client and server negotiate indentities

Encrypt Data

Sensitive data should not be sent in plain text
Variety of encryption algorithms, with different costs and value

Ciphers

Substitution ciphers are easy (e.g 'a' replaced by 'b', 'b' replaced by 'c', etc)
Substitution ciphers are relatively easy to crack
Vernam ciphers (one-time pad) can be totally secure, but are impractical

Secret Key

Both encryption and decryption use same key
Key must be kept secret from others
Key must be known by at least two people

DES

US Govt standard since 1977
Uses 56-bit key
"Strong" algorithm
Strong algorithms are forbidden exports from the US
The US Govt can probably crack it
Triple-DES more secure. Uses DES 3 times with 2 keys

Public Key

2 keys needed, one to encrypt one to decrypt
Both keys generated at the same time
Both keys needed
One key can't easily be derived from the other

Public Key Encryption

A wants to send a private mesage to B
A has B's public key (so do lots of other people)
A encrypts message using B's public key
B is only person who can decrypt the message using his private key

Digital Signature

A wants to send a message to B
B wants to verify it came untampered from A
A encrypts message using A's private key
B decrypts it using A's public key
If B gets garbage
- message didn't come from A; or
- message was changed in transit
Signature may be detached from text, and sent separately

Secure Verified Data

A signs the message using A's private key
A encrypts the cipher using B's public key
Result can only be decrypted using B's private key (secure)
Can then be verified by A's public key

Session Keys

Public key algorithme are usually slower than private key
Get a secure channel using public key
Use this to exchange a private key
Switch to faster private key encryption

References

W.R. Cheswick and S. M. Bellovin, Firewalls and Internet Security Addison-Wesley, 1994, ISBN 0-201-63357-4
S. Garfinkel, PGP - Pretty Good Privacy O'Reilly and Associates, 1995, ISBN 1-56592-098-8

Jan Newmarch <jan@newmarch.name>

Last modified: Sun Aug 12 20:55:44 EST 2001