Security

1
Security

• Chapter 8

2
Security

• Security in distributed system can be divided
  into two parts
• A secure channel is a mechanism for ensuring
  communication though authentication, message
  integrity, and confidentiality.
• Authorization deals with ensuring that a process
  gets only those access rights to the resources.

3
Security

• A dependable and trusted system should include
• Availability Accessible and usable upon demand
  for authorized entities
• Reliability Continuity of service delivery
• Safety Very low probability of catastrophes
• Confidentiality No unauthorized disclosure of
  information
• Integrity No accidental or malicious alterations
  of information have been performed (even by
  authorized entities)
• In distributed systems, security is the
  combination of availability, integrity, and
  confidentiality. A dependable distributed system
  is thus fault tolerant and secure.

4
Security Threats

• Four types of security threats
• Interception refers to the situation that an
  unauthorized party has gained access to a service
  or data.
• Interruption refers to the situation in which
  services or data become unavailable, unusable, or
  destroyed.
• Modifications involve unauthorized changing of
  data or tampering with a service.
• Fabrication refers to the situation in which
  additional data or activity are generated that
  would normally not exist.

5
Security Threats

• Examples of security threats
• Interception
• Channel Reading the content of transferred
  messages
• Object Reading the data contained in an object
• Interruption
• Channel Preventing message transfer
• Object Denial of service
• Modification
• Channel Changing message content
• Object Changing an object's encapsulated data
• Fabrication
• Channel Inserting messages
• Object Spoofing an object

6
Security Mechanisms

• A security policy describes precisely which
  actions are allowed and which are prohibited.
• To protect against security threats, we have a
  number of security mechanisms at our disposal
• Encryption Transform data into something that an
  attacker cannot understand (confidentiality). It
  is also used to check whether something has been
  modified (integrity).
• Authentication Verify the claim that a subject
  says it is verifying the identity of a subject.
  
• Authorization Determining whether a subject is
  permitted to make use of certain services.
• Auditing Trace which subjects accessed what, and
  in which way. Useful only if it can help catch an
  attacker.
• Authorization makes sense only if the requesting
  subject has been authenticated.

7
Security Policies

• Policy Prescribes how to use mechanisms to
  protect against attacks. Requires that a model of
  possible attacks is described (i.e., security
  architecture).
• Example Globus security architecture
• There are multiple administrative domains
• Local operations subject to local security
  policies
• Global operations require requester to be
  globally known
• Interdomain operations require mutual
  authentication
• Global authentication replaces local
  authentication
• Users can delegate privileges to processes
• Credentials can be shared between processes in
  the same domain
• Policy statements leads to the introduction of
  mechanisms for crossdomain authentication and
  making users globally known user proxies and
  resource proxies

8
Security Policies

• Globus Example
• Consider a mobile agent in Globus that carries
  out a task by initiating several operations in
  different domains.
• By authenticating an agent and subsequently
  checking its rights, Globus should be able to
  allow an agent to initiate an operation without
  having to contact the agents owner.
• To allow cross-domain authentication and make a
  user known in remote domain, two types of
  representatives are introduced
• A user proxy is a process that is given
  permission to act on behalf of a user.
• A resource proxy is a process running within a
  specific domain that is used to translate global
  operations on a resource into local operations.

9
Security Policies

• The security architecture defines four different
  protocol
• Creation of user proxy
• Allocation of a resource by the user in a remote
  domain
• Allocation of a resource by a process in a remote
  domain
• Making user known in remote domain
• Three design issues are concerned
• Focus of control
• Layering of security mechanisms
• Simplicity

10
Example Globus Security Architecture

• Diagram of Globus security architecture.

11
Design Issue Focus of Control

• Policy What is our focus when talking about
  protection? Three approaches (a) data, (b)
  invalid operations, (c) unauthorized users.
• We generally need all three, but each requires
  different mechanisms.
• At which logical level are we going to implement
  security mechanisms?
• It depends on the trust a client has in how
  secure the services are in a particular layer.

12
Focus of Control

• Three approaches for protection against security
  threats
• Protection against invalid operations
• Protection against unauthorized invocations
• Protection against unauthorized users

13
Design Issue Layering of Security Mechanisms

• An example such as Switched Multi-megabit Data
  Service (SMDS).
• Security can be provided by placing encryption
  devices at each SMDS router.
• These devices encrypt and decrypt packets but do
  not provide secure communication.
• Secure Socket Layer (SSL) can be used to securely
  send messages across a TCP connection.
• In distributed systems, security mechanisms are
  often placed in the middleware layer.

14
Layering of Security Mechanisms

• The logical organization of a distributed system
  into several layers.

15
Layering of Security Mechanisms

• Several sites connected through a wide-area
  backbone service.

16
Design Issue Layering of Security Mechanism

• Whether security mechanisms are actually used is
  related to the trust a user has in those
  mechanisms. If you do not trust those
  mechanisms, you can implement your own
  mechanisms.
• Dependencies between services regarding trust
  lead to the notion of a Trusted Computing Base
  (TCB). A TCB is the set of mechanisms needed to
  enforce a policy.
• Trusted Computing Base What is the set of
  mechanisms needed to enforce a policy.
• The smaller, the better.
• Where to place mechanisms? Simplicity.

17
Distribution of Security Mechanisms

• The principle of RISSC as applied to secure
  distributed systems.
• (any security-critical server is placed on a
  separate machine)

18
Crypotography

• The original form of the message that is sent is
  called the plaintext (P). The encrypted form is
  referrred to as the ciphertext (C).
• Three types of intruders
• Passive intruder only listens to messages.
• Active intruder can alter messages.
• Active intruder can insert messages.

19
Cryptography

• Intruders and eavesdroppers in communication.

20
Crypotography

• Symmetric (secret-key) system Use a single key
  to (1) encrypt the plaintext and (2) decrypt the
  ciphertext. Requires that sender and receiver
  share the secret key.
• Asymmetric (public-key) system Use different
  keys for encryption and decryption, of which one
  is private, and the other public.
• Hashing system Only encrypt data and produce a
  fixedlength digest. There is no decryption only
  comparison is possible.

21
Cryptographic Functions

• Usually, the encryption method E is made public,
  but let the encryption as a whole be
  parameterized by means of a key k (same for
  decryption).
• Properties of Hash functions
• Oneway function Given some output mout of ES ,
  it is (analytically or) computationally
  infeasible to find min
• Weak collision resistance Given an input m and
  its associated output h H(m) it is
  computationally infeasible to find an m such
  that H(m) H(m).
• Strong collision resistance given only H, it is
  computationally infeasible to find any two
  different inputs m and m such that H(m) H(m).

22
Cryptography
Notation Description
KA, B Secret key shared by A and B
Public key of A
Private key of A

• Notation used in this chapter.

23
Symmetric Cryptosystems

• Substitute Cipher each letter or group of letter
  is replaced by another letter or group of letters
• Caesar cipher rotate the letter (a ? D, b ? E, c
  ? F, z ? C).
• Example attack ? DWWDFN
• Monoalphabetic substitution
• Each letter replaced by different letter
• Plaintext ABCDEFGHIJKLMNOPQRSTUVWXYZ
• Ciphertext QWERTYUIOPASDFGHJKLZXCVBNM
• Disadvantage It does not smooth out frequencies
  in the cipher text.
• Polyalphabatic cipher use multiple cipher
  alphabets.

24
Secret-Key Cryptography

• Transition cipher reorder the letters, but don't
  disguise them.
• select a key MEGABUCK
• 7 4 5 1 2 8 3 6
• p l e a s e t r
• a n s f e r o n
• e h u n d r e d
  
• ? afnsedtoelnhesurndpaeerr
• Plain text ? cipher text

25
Transposition Ciphers

• A transposition cipher.

26
Symmetric Cryptosystems DES

• Data Data Encryption Standard (DES) was developed
  by IBM and adopted as a US national standard in
  1977.
• The encryption function maps a 64-bit plaintext
  input into a 64-bit encrypted output using a
  56-bit master key.
• The algorithm has 16 key-dependent stages known
  as rounds where each round uses a different
  48-bit key for encryption and was time-consuming.
• The DES algorithm is difficult to break using
  analytical methods ((the rationale behind the
  design has never been clearly explained). Using a
  brute-force attack will do the job because the
  key length is 56 bits. In June 1997, it was
  successfully cracked. Only used for the
  protection of low-value information.

27
Symmetric Cryptosystems DES

1. The principle of DES
2. Outline of one encryption round

28
Symmetric Cryptosystems DES

• Details of per-round key generation in DES.

29
Symmetric Cryptosystems AES

• Triple-DES apply DES three times with another
  two different keys. Give strength against
  brute-force attacks.
• In 1997, the US NIST (National Institute of
  Standards and Technology) issued an invitation
  for Advanced Encryption Standard (AES).
• NIST announced the approval of the Federal
  Information Processing Standard (FIPS) for the
  Advanced Encryption Standard, FIPS-197.
• This standard specifies Rijndael algorithm
  (blocks of 128 bits) as a FIPS-approved symmetric
  encryption algorithm that may be used by U.S.
  Government organizations (and others) to protect
  sensitive information.
• The algorithm has been designed to be fast enough
  so that it can even be implemented on smart
  cards.

30
Public-Key Cryptosystems RSA

• RSA, named after its inventors Rivest, Shamir,
  and Adlemean, a public-key cryptographic
  algorithm.
• The security of RSA comes from the fact that no
  methods are known to efficiently find the prime
  factors to large numbers.
• For example, 2100 can be written as 2100 2 x 2
  x 3 x 5 x 5 x 7 making 2, 3, 5, and 7 the prime
  factors in 2100.
• In RSA, the private and public keys are
  constructed from very large prime numbers. It
  turns out breaking RSA is equivalent to finding
  those two prime numbers.

31
Public-Key Cryptosystems RSA

• Generating the private and public key requires
  four steps
• Choose two very large prime numbers, p and q
• Compute n p x q and z (p 1) x (q 1)
• Choose a number d that is relatively prime to z
  (that is, such that d has no common factors with
  z)
• Compute the number e such that e x d 1 mod z
• Group P into blocks such that CPe (mod n) and
  PCd(mod n) where 0 lt P lt n

32
Public-Key Cryptography

• Example
• p13 q17 ? n 13 x 17 221
• z (13 1) x (17
  1) 192.
  
• let d5 (prime to z)
• e x d 1 mod 192 1, 193, 385, ...
• 385 is divisible by d
• e 385/5 77
• Example
• p3 q11 ? n 3 x 11 33
• z (3 1) x (11
  1) 20.
  
• let d7 (prime to z)
• 7 x e mod 20 1 ? e3
• C P3 (mod 33), P C7 (mod 33)

33
RSA

• An example of the RSA algorithm.

34
Public-Key vs. Secret-Key Cryptosystems

• Compare RSA to DES
• Encrypting message using RSA is much slower than
  DES
• RSA is most used for exchange only shared keys

35
Pretty Good Privacy (PGP)

• Pretty Good Privacy (PGP) is a popular program
  used to encrypt and decrypt e-mail over the
  Internet.
• It can also be used to send an encrypted digital
  signature that lets the receiver verify the
  sender's identity and know that the message was
  not changed en route.
• Available both as freeware and in a low-cost
  commercial version,
• PGP is the most widely used privacy-ensuring
  program by individuals and is also used by many
  corporations. Developed by Philip R. Zimmermann
  in 1991, PGP has become a de facto standard for
  e-mail security.
• PGP can also be used to encrypt files being
  stored so that they are unreadable by other users
  or intruders. .

36
Hash Functions MD5

• MD5 (Message Digest 5) is an algorithm that is
  used to verify data integrity through the
  creation of a 128-bit message digest from data
  input which may be a message of any length.
• MD5, which was developed by Professor Ronald L.
  Rivest of MIT, is intended for use with digital
  signature applications, which require that large
  files must be compressed by a secure method
  before being encrypted with a secret key, under a
  public key cryptosystem.
• MD5 is currently a standard, Internet Engineering
  Task Force (IETF) Request for Comments (RFC) 1321.

37
Hash Functions MD5

• The structure of MD5

38
Hash Functions MD5

• The 16 iterations during the first round in a
  phase in MD5.

39
Secure Channels

• Goal Set up a channel allowing for secure
  communication between two processes.
• They both know who is on the other side
  (authenticated).
• They both know that messages cannot be tampered
  with (integrity).
• They both know messages cannot leak away
  (confidentiality).

40
Authentication versus Integrity

• Note Authentication and data integrity rely on
  each other. Consider an active attack by Trudy on
  the communication from Alice to Bob.
• Authentication without integrity Alice's message
  is authenticated, and intercepted by Trudy, who
  tampers with its content, but leaves the
  authentication part as is. Authentication has
  become meaningless.
• Integrity without authentication Trudy
  intercepts a message from Alice, and then makes
  Bob believe that the content was really sent by
  Trudy. Integrity has become meaningless.
• Question What can we say about confidentiality
  versus authentication and integrity?

41
Authentication Secret Keys

• 1 Alice sends ID to Bob
• 2 Bob sends challenge RB (i.e. a random number)
  to Alice
• 3 Alice encrypts RB with shared key KA,B . Now
  Bob knows he's talking to Alice
• 4 Alice send challenge RA to Bob
• 5 Bob encrypts RA with KA,B . Now Alice knows
  she's talking to Bob
• Note We can improve the protocol by combining
  steps 14, and 23. This costs only the
  correctness.

42
Authentication (1)

• Authentication based on a shared secret key.

43
Authentication (2)

• Authentication based on a shared secret key, but
  using three instead of five messages.

44
Authentication The Reflection Attack

• 1 Chuck sends (A (Alice ID), RC) to Bob.
• 2 Bob sends (RB, , KA,B (RC)) to Chuck.
• 3 Chuck sends (A, RB) to Bob.
• 4 Bob sends (RB2, , KA,B (RB)) to Chuck.
• 5 Chuck KA,B (RB) to Bob.
• 6 Bob thought Chuck is Alice.

45
Authentication (3)

• The reflection attack.

46
The principle of using a KDC

• The problem of using a shared key is scalability.
• Key Distribution Center (KDC) is used for key
  distribution and shares a secret key with each
  host.
• KDC operation
• Alice send (A, B) to the KDC.
• The KDC send KA,KDC ( KA,B ) to Alice and KB,KDC
  ( KA,B ) Bob.
• Drawbacks Alice may want to start setting up a
  new secure channel and KDC is required to get Bob
  into the loop.
• Solution Pass KB,KDC ( KA,B ) to Alice and let
  Alice send it to Bob. The message KB,KDC ( KA,B )
  is known as a ticket.

47
Authentication Using a Key Distribution Center (1)

• The principle of using a KDC.

48
Authentication Using a Key Distribution Center (2)

• Using a ticket and letting Alice set up a
  connection to Bob.

49
Authentication Using a Key Distribution Center

• Figure 8-16 is an example Needham-Schroeder
  authentication protocol.
• The challenge RA1 that Alice sends to the KDC is
  known as nonce. A nonce is a random number that
  is used only once and used to uniquely related
  two messages.

50
Authentication Using a Key Distribution Center (3)

• The Needham-Schroeder authentication protocol.

51
Authentication Using a Key Distribution Center (4)

• Protection against malicious reuse of a
  previously generated session key in the
  Needham-Schroeder protocol.

52
Authentication Using Public-Key Cryptography

• Mutual authentication in a public-key
  cryptosystem.

53
NeedhamSchroeder Subtleties

• Q1 Why does the KDC put Bob into its reply
  message, and Alice into the ticket?
• Q2 The ticket sent back to Alice by the KDC is
  encrypted with Alice's key. Is this necessary?
• Security flaw Suppose Chuck finds out Alice's
  key he can use that key anytime to impersonate
  Alice, even if Alice changes her private key at
  the KDC.
• Reasoning Once Chuck finds out Alice's key, he
  can use it to decrypt a (possibly old) ticket for
  a session with Bob, and convince Bob to talk to
  him using the old session key.
• Solution Have Alice get an encrypted number from
  Bob first, and put that number in the ticket
  provided by the KDC we're now ensuring that every
  session is known at the KDC.

54
Confidentiality

• Compromised keys If a key is compromised, you
  can never use it again. Really bad if all
  communication between Alice and Bob is based on
  the same key over and over again don't use the
  same key for different things
• Temporary keys Untrusted components may play
  along perhaps just once, but you would never want
  them to have knowledge about your really good key
  for all times make keys disposable
• Essence Don't use valuable and expensive keys
  for all communication, but only for
  authentication purposes.
• Solution Introduce a cheap'' session key that
  is used only during one single conversation or
  connection (cheap'' also means efficient in
  encryption and decryption)

55
Confidentiality

• Secret key Use a shared secret key to encrypt
  and decrypt all messages sent between Alice and
  Bob
• Public key If Alice sends a message m to Bob,
  she encrypts it with Bob's public key K
• There are a number of problems with keys
• Keys wear out The more data is encrypted by a
  single key, the easier it becomes to find that
  key don't use keys too often
• Danger of replay Using the same key for
  different communication sessions, permits old
  messages to be inserted in the current session
  don't use keys for different sessions

56
Digital Signatures

• Harder requirements
• Authentication Receiver can verify the claimed
  identity of the sender
• Nonrepudiation The sender can later not deny
  that he/she sent the message
• Integrity The message cannot be maliciously
  altered during, or after receipt
• Solution Let a sender sign all transmitted
  messages, in such a way that (1) the signature
  can be verified and (2) message and signature are
  uniquely associated

57
Digital Signatures (1)

• Digital signing a message using public-key
  cryptography.

58
Message Digests

• Basic idea Don't mix authentication and secrecy.
  Instead, it should also be possible to send a
  message in the clear, but have it signed as well.
  
• Solution take a message digest, and sign that
• Recall Message digests are computed using a hash
  function, which produces a fixedlength message
  from arbitrarylength data.

59
Digital Signatures (2)

• Digitally signing a message using a message
  digest.

60
Secure Group Communication

• Design issue How can you share secret
  information between multiple members without
  losing everything when one member turns bad.
• Confidentiality Follow a simple (hardtoscale)
  approach by maintaining a separate secret key
  between each pair of members.

61
Secure Group Communication

• Replication You also want to provide replication
  transparency. Apply secret sharing
• No process knows the entire secret it can be
  revealed only through joint cooperation
• Assumption at most k out of N processes can
  produce an incorrect answer
• At most c k processes have been corrupted
• Note We are dealing with a k fault tolerant
  process group.

62
Secure Replicated Services

• Sharing a secret signature in a group of
  replicated servers.

63
Authorization versus Authentication

• Authentication Verify the claim that a subject
  says it is verifying the identity of a subject
• Authorization Determining whether a subject is
  permitted certain services from an object
• Note authorization makes sense only if the
  requesting subject has been authenticated

64
General Issues in Access Control

• General model of controlling access to objects.

65
Access Control Matrix

• Essence Maintain an access control matrix in
  which entry contains the permissible operations
  that subject can perform on object
• Implementation (a) Each object maintains an
  access control list (ACL) describing the
  permissible operations per subject (or group of
  subjects)
• Implementation (b) Each subject has a
  capability describing the permissible operations
  per object (or category of objects)

66
Access Control Matrix

• Comparison between ACLs and capabilities for
  protecting objects.
• Using an ACL
• Using capabilities.

67
Protection Domains

• Issue ACLs or capability lists can be very
  large. Reduce information by means of protection
  domains
• Set of (object, access rights) pairs
• Each pair is associated with a protection domain
• For each incoming request the reference monitor
  first looks up the appropriate protection domain
• Common implementation of protection domains
• Groups Users belong to a specific group each
  group has associated access rights
• Roles Don't differentiate between users, but
  only the roles they can play. Your role is
  determined at login time. Role changes are
  allowed.

68
Protection Domains

• The hierarchical organization of protection
  domains as groups of users.

69
Firewalls

• Essence Sometimes it's better to select service
  requests at the lowest level network packets.
  Packets that do not fit certain requirements are
  simply removed from the channel
• Solution Protect your company by a firewall it
  implements access control
• Question What do you think would be the biggest
  breach in firewalls?

70
Firewalls

• A common implementation of a firewall.

71
Secure Mobile Code

• Problem Mobile code is great for balancing
  communication and computation, but is hard to
  implement a generalpurpose mechanism that allows
  different security policies for localresource
  access. In addition, we may need to protect the
  mobile code (e.g., agents) against malicious
  hosts.

72
Protecting a Host

• Observation We need to be able to distinguish
  local from remote code before being able to do
  anything
• Refinement 1 We need to be able to assign a set
  of permissions to mobile code before its
  execution and check operations against those
  permissions at all times
• Refinement 2 We need to be able to assign
  different sets of permissions to different units
  of mobile code authenticate mobile code (e.g.
  through signatures)
• Question What would be a very simple policy to
  follow (Microsoft's approach)?

73
Protecting the Target (1)
8-27

• The organization of a Java sandbox.

74
Protecting the Target (2)
8-28

1. A sandbox
2. A playground

75
Protecting the Target (3)
8-29

• The principle of using Java object references as
  capabilities.

76
Protecting the Target (4)

• The principle of stack introspection.

77
Key Establishment

• Observation We can construct secret keys in a
  safe way without having to trust a third party
  (i.e. a KDC)
• Alice and Bob have to agree on two large numbers,
  n and g. Both numbers may be public.
• Alice chooses large number x, and keeps it to
  herself. Bob does the same, say y.
• Key Establishment
• Alice sends (n, g, gx mod n) to Bob
• Bob sends (gy mod n) to Alice
• Alice computes KA,B (gy mod n)x gxy mod n
• Bob computes KA,B (gx mod n)y gxy mod n

78
Key Establishment

• The principle of Diffie-Hellman key exchange.

79
Key Distribution

• Essence If authentication is based on
  cryptographic protocols, and we need session keys
  to establish secure channels, who's responsible
  for handing out keys?
• Secret keys Alice and Bob will have to get a
  shared key. They can invent their own and use it
  for data exchange. Alternatively, they can trust
  a key distribution center (KDC) and ask it for a
  key.
• Public keys Alice will need Bob's public key to
  decrypt (signed) messages from Bob, or to send
  private messages to Bob. But she'll have to be
  sure about actually having Bob's public key, or
  she may be in big trouble. Use a trusted
  certification authority (CA) to hand out public
  keys.
• A public key is put in a certificate, signed by a
  CA.

80
Key Distribution (1)

• Secret-key distribution

81
Key Distribution (2)

• Public-key distribution (see also menezes.a96).

82
Secure Group Management

• Structure Group uses a key pair K for
  communication with nongroup members. There is a
  separate shared secret key CK G for internal
  communication. Assume process P wants to join the
  group and contacts Q.

83
Secure Group Management

• P generates a onetime reply pad RP, and a secret
  key K P G . It sends a join request to Q, signed
  by itself (notation JR P ), along with a
  certificate containing its public key K P .
• 2 Q authenticates P, checks whether it can be
  allowed as member. It returns the group key CK G
  , encrypted with the onetime pad, as well as the
  group's private key, encrypted as CK G K
• Q authenticates P and sends back K P G N letting
  Q know that it has all the necessary keys.
• Question Why didn't we send KP(CKG) instead of
  using RP?

84
Secure Group Management

• Securely admitting a new group member.

85
Authorization Management

• Issue To avoid that each machine needs to know
  about all users, we use capabilities and
  attribute certificates to express the access
  rights that the holder has.
• In Amoeba, restricted access rights are encoded
  in a capability, along with data for an integrity
  check to protect against tampering.

86
Capabilities and Attribute Certificates (1)
48 bits 24 bits 8 bits 48 bits
Server port Object Rights Check

• A capability in Amoeba.

87
Capabilities and Attribute Certificates (2)

• Generation of a restricted capability from an
  owner capability.

88
Delegation

• Observation A subject sometimes wants to
  delegate its privileges to an object O1 , to
  allow that object to request services from
  another object O2
• Example A client tells the print server to fetch
  a file from the file server to make a hard copy
  the client delegates its read privileges on to
• Nonsolution Simply hand over your attribute
  certificate to a delegate (which may pass it on
  to the next one, etc.)

89
Delegate Privileges

• Problem To what extent can the object trust a
  certificate to have originated at the initiator
  of the service request, without forcing the
  initiator to sign every certificate?
• Solution Ensure that delegation proceeds through
  a secure channel, and let a delegate prove it got
  the certificate through such a path of channels
  originating at the initiator.

90
Delegation (1)

• The general structure of a proxy as used for
  delegation.

91
Delegation (2)

• Using a proxy to delegate and prove ownership of
  access rights.

92
Example Kerberos (1)

• Authentication in Kerberos.

93
Example Kerberos (2)

• Setting up a secure channel in Kerberos.

94
SESAME

• SMIB Database holding shared secret keys, basic
  access rights, and so on
• AS Authenticates a user, and returns a ticket
• PAS Hands out attribute certificates
• KDS Generates session keys for authenticated
  users
• Security Manager Handles setting up and
  communicating over a secure channel
• PVF Validates access rights contained in
  attribute certificates

95
SESAME Components

• Overview of components in SESAME.

96
Privilege Attribute Certificates (PACs)
Field Description
Issuer domain Name the security domain of the issuer
Issuer identity Name the PAS in the issuer's domain
Serial number A unique number for this PAC, generated by the PAS
Creation time UTC time when this PAC was created
Validity Time interval when this PAC is valid
Time periods Additional time periods outside which the PAC is invalid
Algorithm ID Identifier of the algorithm used to sign this PAC
Signature value The signature placed on the PAC
Privileges A list of (attribute, value)-pairs describing privileges
Certificate information Additional information to be used by the PVF
Miscellaneous Currently used for auditing purposes only
Protection methods Fields to control how the PAC i s used

• The organization of a SESAME Privilege Attribute
  Certificate.

97
Electronic Payment Systems (1)

• Payment systems based on direct payment between
  customer and merchant.
• Paying in cash.
• Using a check.
• Using a credit card.

98
Electronic Payment Systems (2)

• Payment systems based on money transfer between
  banks.
• Payment by money order.
• Payment through debit order.

99
Privacy (1)
Merchant Customer Date Amount Item
Merchant Full Partial Full Full Full
Customer Full Full Full Full Full
Bank None None None None None
Observer Full Partial Full Full Full

• Information hiding in a traditional cash payment.

100
Privacy (2)
Information
Merchant Customer Date Amount Item
Merchant Full Full Full Full Full
Customer Full Full Full Full Full
Bank Full Full Full Full None
Observer Full Partial Full Full Full
Party

• Information hiding in a traditional credit-card
  system (see also camp.lj96a)

101
E-cash

• The principle of anonymous electronic cash using
  blind signatures.

102
Secure Electronic Transactions (SET)

• The different steps in SET.