2. Information securityInformation security
Pre computer age
Rugged filing cabinets with combination lock
Computer age
Automated tools for security
Computer security
Collection of tools to protect data
Network security
Internet security
3
3. 3 aspects of information security3 aspects of information security
Security Attack: Any action that compromises
the security of information.
Security Mechanism: A mechanism that is
designed to detect, prevent, or recover from a
security attack.
Security Service: A service that enhances the
security of data processing systems and
information transfers. A security service makes
use of one or more security mechanisms.
4
4. Web Security Considerations
WWW is Client server application over Internet
and TCP/IP intranets
Web is vulnerable to attacks on web servers over
the Internet
The WEB is visible outlet for corporates
Web servers are easy to configure and manage.
Complex software hide many security flaws.
Subverted servers will provide access to intranet
systems
Users are not aware of the risks.
5. Internet security issuesInternet security issues
Requirements
Confidentiality
Authentication
Nonrepudiation
Integrity
Selection of algorithms
Services
Security mechanisms
Creation, distribution and protection of secret keys
Dependence of protocol
Placement of security mechanisms
6
6. OSI security architecture
ITU-T recommendations X.800
Defines a systematic approach
International standard
For managers to provide security
For security products
Focuses on services, mechanisms and
attacks
7
7. Security services
Definition in RFC 2828
A processing or communication service that
is provided by a system to give a specific
kind of protection to system resources
X.800 services
Five categories and 14 specific services
8
10. Specific services
Data integrity
(7) Connection integrity with recovery
(8) Connection integrity without recovery
(9) Selective-field Connection Integrity
(10) Connectionless Integrity
(11) Selective-field Connectionless Integrity
11
11. Specific services
Nonrepudiation
(12) Nonrepudiation, origin
(13) Nonrepudiation, destination
(14) Availability service
Protect to ensure availability
Depends on
- Proper management & control of system resources
12
15. Security AttacksSecurity Attacks
Interruption: This is an attack on
availability
Interception: This is an attack on
confidentiality
Modification: This is an attack on
integrity
Fabrication: This is an attack on
authenticity
16
17. Methods of DefenceMethods of Defence
Encryption
Software Controls (access limitations in
a data base, in operating system protect
each user from other users)
Hardware Controls (smartcard)
Policies (frequent changes of
passwords)
Physical Controls
20
18. Placement of security
mechanisms
Link to link
Hardware device
Application unaware
Distribution of keys a problem
End to end
Application/software aware
Large no of keys involved
21. Need for IPSec
Application level security services
Electronic mail
○ S/MIME, PGP
Client Server
○ Kerberos, X.509
Web access
○ SSL, TLS, SET
Enterprises need security at IP layer
To protect security ignorant applications
Additional security to applications with security
mechanisms
Establish private secure network
24. IP Security Overview
IPSec is not a single protocol.
IPSec provides a set of security
algorithms
IPSec provides a general security
framework for a pair of communicating
entities
Across LAN, Private & Public WANs
Across Internet
25. IP Security Overview
Applications of IPSec
Secure branch office connectivity over the
Internet
Secure remote access over the Internet
Establsihing extranet and intranet
connectivity with partners
Enhancing electronic commerce security
26. IP Security Overview
Benefits of IPSec
Better firewall protection
Transparent to applications (below transport
layer (TCP, UDP)
Provide security for individual users
IPSec can assure that:
A router or neighbor advertisement comes from
an authorized router
A redirect message comes from the router to
which the initial packet was sent
A routing update is not forged
28. IP Security Architectures
Integrated architecture
Supported in IPv6
Difficult to implement in IPv4
Bump in The stack (BITS) for IPv4
Between Data link and IP layers
Bump in The Wire (BITW)
Hardware implementation
29. IPSec RFCs
IPSec documents:
RFC 2401: An overview of security architecture
RFC 2402: Description of a packet
authentication extension to IPv4 and IPv6
RFC 2406: Description of a packet encryption
extension to IPv4 and IPv6
RFC 2408: Specification of key managament
capabilities
30. IPSec Services
Access Control
Connectionless integrity
Data origin authentication
Rejection of replayed packets
Confidentiality (encryption)
Limited traffic flow confidentiallity
32. IPSec modes of operations
Transport
IPSec protects IP payload
IPSec headers added before IP payload
No change in IP header
Tunnel
IPSec protects total IP packet
IPSec headers encapsulates IP packet
New IP header is created
33. Discussion
onTunnel and Transport mode
Tunnel mode header order
New IP hdr->IPsec hdr->old IP hdr->IP payload
BITS or BITW architecture
Choice for VPN
Transport mode header order
IP hdr->IPSec hdr->IP payload
IPSec integrated architecture
End to End security
34. Protocols Transport Mode
SA
Tunnel Mode
SA
AH Authenticates IP payload
and selected portions of
IP header and IPv6
extension headers
Authenticates entire
inner IP packet plus
selected portions of
outer IP header
ESP Encrypts IP payload and
any IPv6 extesion header
Encrypts inner IP
packet
ESP with
authentication
Encrypts IP payload and
any IPv6 extesion
header. Authenticates IP
payload but no IP header
Encrypts inner IP
packet. Authenticates
inner IP packet.
Security services
44. SSL and TLS
SSL was originated by Netscape
TLS working group was formed within
IETF
First version of TLS can be viewed as
an SSLv3.1
45. SSL
Make use of TCP
Provide reliable end to end secure communication
Two layers of protocols
Higher layer
○ Handshake
○ change cipher spec
○ Alert
Lower layer
○ Record
47. SSL connection
A logical client/server link
A peer-to-peer connection with two
network nodes.
Transient.
Every connection associated with one
session.
48. SSL session
An association between a client and a server
Defines a set of parameters such as algorithms used,
session number etc.
An SSL session is created by the Handshake Protocol
that allows parameters to be shared among the
connections made between the server and the client
Sessions are used to avoid negotiation of new parameters
for each connection.
A single session is shared among multiple SSL connections
between the client and the server.
In theory, it may also be possible that multiple sessions are
shared by a single connection, but this feature is not used in
practice.
49. SSL session state
A session state is defined by the following parameters:
session identifier: this is an identifier generated by the server to
identify a session with a chosen client,
Peer certificate: X.509 certificate of the peer,
compression method: a method used to compress data prior to
encryption,
CipherSpec: specifies the bulk data encryption algorithm (for
example DES) and the hash algorithm (for example MD5) used
during the session,
Master secret: 48-byte data being a secret shared between the
client and server
“is resumable”: this is a flag indicating whether the session can
be used to initiate new connections.
50. SSL connection state
The SSL connection state is defined by the following
parameters:
Server and client random: random data generated by both the
client and server for each connection,
Server write MAC secret: the secret key used for data written by
the server,
Client write MAC secret: the secret used for data written by the
client,
Server write key: the bulk cipher key for data encrypted by the
server and decrypted by the client,
Client write key: the bulk cipher key for data encrypted by the
client and decrypted by the server,
Initialisation vectors: for CBC mode of block cipher
Sequence number: sequence numbers maintained separately by
the server for messages transmitted and received during the
data session.
51. Record protocol
Services provided
Confidentiality
○ Encryption of payloads using shared
secret key obtained from handshake
protocol
Message Integrity
○ MAC using shared secret key obtained
from handshake protocol
54. Change cipher spec protocol
Payload of record protocol
Consist of single message
Single byte value = 1
Purpose of message
Cause copy of pending state to current state
Updates cipher suite to be used on the
current connection
55. Alert protocol
Conveys SSL alerts to peer
Payload of record
Consists of two bytes
1st
byte : warning or fatal
2nd
byte: code for specific alerts
57. Handshake Protocol
The most complex part of SSL.
Allows the server and client to
authenticate each other.
Negotiate encryption, MAC algorithm
and cryptographic keys.
Used before any application data are
transmitted.
62. Cryptographic computations
Shared master secret : 48 byte
Creation in 2 stages
Pre-master secret exchanged
○ RSA
○ Diffie Hellman
Master secret calculated at both ends
Use of master secret at client end
Client write MAC secret
Client write key
Client write IV
Use of master secret at client end
Server write MAC secret
Server write key
Client write IV
63. Transport Layer Security
The same record format as the SSL record format.
Defined in RFC 2246.
Similar to SSLv3.
Differences in the:
version number (3.1)
message authentication code (HMAC, TLScomressed.version)
pseudorandom function ( different from SSL)
alert codes ( more in TSL)
cipher suites ( fortezza dropped)
client certificate types ( fortezza schemes not included)
certificate_verify and finished message ( calculation different)
cryptographic computations ( different from SSL)
Padding ( any amount for total length = Xblock length upto max 255 bytes )
68. Secure Electronic Transactions
An open encryption and security
specification.
Protect credit card transaction on the
Internet.
Companies involved:
MasterCard, Visa, IBM, Microsoft,
Netscape, RSA, Terisa and Verisign
Not a payment system.
Set of security protocols and formats.
69. SET Services
Provides a secure communication
channel in a transaction.
Provides tust by the use of X.509v3
digital certificates.
Ensures privacy.
70. SET Overview
Key Features of SET:
Confidentiality of information
Integrity of data
Cardholder account authentication
Merchant authentication
72. SET participants
Cardholder: authorised holder of credit card issued
by issuer. Interacts with merchants over internet
Merchant : Seller of goods over internet
Issuer : Bank which issues credit card to card
holder.
Acquirer : Fin institution which has an account with
a merchant, processes card authorisation and
payments.
Payment gateway: Interfaces between SET and
Payment network
CA: Issues X.509 certificates to All players
73. Sequence of events for
transactions
1. The customer opens an account.
2. The customer receives a certificate.
3. Merchants have their own certificates.
4. The customer places an order.
5. The merchant is verified.
6. The order and payment are sent.
7. The merchant request payment authorization.
8. The merchant confirm the order.
9. The merchant provides the goods or service.
10. The merchant requests payments.
78. Payment Request
Initiate request from card holder
Request certificates to merchant
Incl: Brand of cc, ID req/resp, nonce
Initiate response by merchant
Response signed by Kr of merchant
Incl: Cust nonce, new nonce, trans ID, merchant’s
signature certificate, payment gateways key exchange
certificate
Cardholder
verifies merchant and gateway’s certificates
Generates
○ OI- ref to order
○ PI – card number, value etc
79. Payment Request
Purchase request by card holder
Forwarded to payment gateway
○ Incl: EKs[PI+Dual sig+OIMD], EKUch[Ks]
To merchant
○ OI+dual sig+PIMD, CH certificate
Purchase response by merchant
Incl: Trans ID, response block with order ack
signed by merchant using Kr, merchant’s
signature certificate
Card holder
Verifies merchant’s signature on response block
80. Payment Authorization
Authorization Request to payment gateway from merchant
forwarded
○ PI+dual sig+OIMD+EKUch[Ks]
Generated
○ Auth block: EKms[SignKrm[Trans ID]]
○ EKUpg[EKms]
Certificates
○ Card holder signature key, merchant signature key and merchant key exchange certificates
Payment gateway
Verifies all certificates, obtains EKms, decrypts auth block, verifies merchant’s sign, verifies dual
sign, verifies trans ID, requests and receives an auth from issuer
Authorisation response by payment gateway to merchant
Auth block:
○ EKpgs[SignKrpg[authorisation]]
○ EKUm[EKpgs]
Capture token info:
○ EKpgs[SignKrpg[capture token]]
Certificate
○ Gateway’s signature key certifixcate
81. Payment capture
Capture Request by merchant to payment
gateway
Capture req block
○ Amount+Trand ID+token signed and
encrypted by merchant
This is verified by payment gateway. Req
issuer to release payment
Capture Response by payment gateway
to merchant confirmation of payment