associate professor BME Híradástechnikai Tanszék Lab of Cryptography and System Security (CrySyS)

Transcription

1 Information Security (bmevihim100) Dr. Levente Buttyán associate professor BME Híradástechnikai Tanszék Lab of Cryptography and System Security (CrySyS) Outline Public Key Infrastructures Fair exchange and non-repudiation protocols Electronic payment protocols 2

2 PKI technical issues basic concepts certificate, certification authority, certificate chain (or path), certificate update and revocation PKI components and architectures CA, RA, repository, archive, users; hierarchical, mesh, and bridge architectures life cycle of a certificate application, issuance, distribution and use, revocation, expiration key-pair management issues key-pair generation, private-key protection, management requirements for different key-pair types 3 The need for certificates distribution of public keys confidentiality is not needed authenticity is indispensable public keys can be distributed via secure out-of-band channels physical contact download public key from web site and check its hash value via phone these solutions are not always practical and they don t scale 4

3 Basic idea of public-key certificates concept invented by Kohnfelder in 1978 in his BSc thesis at MIT name and public key is linked together by the digital signature of a trusted entity called certification authority (CA) subject identification information subject public key CA s name generate digital signature CA s private key CA s digital signature in order to verify a certificate you need to have an authentic copy of the public key of the CA advantages: only the CA s public key need to be distributed via out-of-band channels (scales better) certificates can be distributed without any protection (why?) 5 Certificate chains a single CA cannot issue certificates to everyone in the world practically infeasible a single CA wouldn t be trusted by everyone if there are more CA s, then the following may happen: you have a public-key certificate [Alice, K Alice, TrustMe, Sig TrustMe ] you don t have the public key of TrustMe but you may obtain a certificate that contains TrustMe s public key [TrustMe, K TrustMe, SuperTrust, Sig SuperTrust ] a certificate chain is a sequence Cert 1, Cert 2,, Cert k of certificates, such that Cert i = [S i, K, CA S i i, Sig ] (i = 1, 2,, k) CAi S 1 = Alice, S i = CA i-1 (i = 2,, k) the public key of CA k is known 6

4 Certificate chains (cont d) notes: all CAs in the chain must be trusted by the verifier in order to be able to accept the public key of Alice there may be multiple chains leading to Alice some of which may be trusted example: consider two certificate chains leading to A: [A, K A, CA 1 **, Sig CA 1 ] [CA 1, K CA1, CA 2 *, Sig CA2 ] [CA 2, K CA2, CA 3 *, Sig CA 3 ] [A, K A, CA 1 **, Sig CA 1 ] [CA 1, K CA1, CA 4 *, Sig CA4 ] Red has K CA 3, and trusts CA 1, CA 2, and CA 3 Blue has K CA 4, and trusts CA 1, and CA 4 Red accepts the first chain, Blue accepts the second chain 7 Validity periods and revocation for security reasons, key-pairs shouldn t be assumed to be valid forever certificates have a scheduled validity period Cert = [S, K S, valid_from, expires_on, CA, Sig CA ] a certificate shouldn t be used outside its validity period unless it is to reconfirm an earlier action in the same way as it would have occurred within the validity period (e.g., to verify the signature on an old document) if a private key is compromised or suspected to be compromised, then the corresponding certificate needs to be revoked certificate revocation is the dark side of public-key crypto 8

5 PKI components: Certification Authority (CA) collection of hardware, software, and staff (people) main functions: issues certificates for users and other CAs maintains certificate status information and Certificate Revocation Lists (CRLs) publishes currently valid certificates and CRLs maintains archives of status information on expired certificates must comply with strict security requirements related to the protection and usage of its private keys (basis of trust) uses tamper resistant Hardware Security Modules that enforce security policies (access and usage control) defines and publishes its certificate issuing policies complies with laws and regulations is subject to regular control (by national supervising authority) 9 PKI components: Registration Authority (RA) approves certificate applications, but doesn t itself issue certificates (RA is not CA) identifies and authenticates subscribers, provides collected attribute information to CA authorizes requests for key-pair or certificate generation or recovery from back-up authorizes requests for certificate suspension or revocation distributes personal tokens (which contain issued private key) and collects obsolete tokens 10

6 PKI components: repositories and archives repository a directory service for the distribution and management of certificates and certificate status information (e.g., CRLs) typically based on the X.500 directory standard (or a subset, such as the Lightweight Directory Access Protocol (LDAP)) format of directory entries must be generally agreed on (standards) archive long term storage of status information of expired certificates used to check if an old certificate was valid at a given time in the past (e.g., in case of disputes) integrity of the archive must be strongly protected 11 PKI components: users organizations or individuals that use the PKI, but do not issue certificates two types: certificate holders have certificate(s) (own key pairs) can use their own private key(s) (e.g., to sign documents) relying parties relies on certificates (and other components of the PKI) to verify if a public key belongs to a given entity and is valid individuals and organizations may be both certificate holders and relying parties 12

7 PKI architectures: hierarchical CA 0 CA 1 CA 2 CA 3 CA 4 Bob Alice top-down hierarchy certificate chains always start at the root CA every relying party must know the public key of the root CA 13 PKI architectures: mesh CA 0 CA 1 CA 2 Bob CA 3 CA 4 Alice CAs cross certify each other a relying party knows the public key of a CA near itself (usually the one that issued its certificate) a path needs to be found and verified from that CA to the target certificate 14

8 PKI architectures: bridge CA 0 CA 5 CA 4 CA 1 CA 6 CA 2 CA 3 Bob Alice bridge CA connects enterprise PKIs (regardless of their architecture) relying parties need the same information as before (public key of their root or nearest CA) 15 Life cycle of a certificate certificate application certificate expiration and renewal certificate revocation (if needed) validation of application certificate issuance certificate suspension (if needed) distribution and use of certificates acceptance of certificate by subscriber 16

9 Applying for a certificate subscriber registers with the CA establishment of a relationship between the subscriber and the CA general subscriber information is provided to the CA e.g., name, address, subscriber requests a certificate from the CA certificate request contains more specific information regarding the requested certificate e.g., type of certificate, public-key, other specific fields requested for the certificate may not be a conscious action (e.g., employee of a company) in case of a third party CA, a subscriber must always explicitly request the issuance of a certificate and explicitly accept the issued certificate 17 Validation of application the CA needs to verify the identity of the subscriber (subject authentication) that the public-key (if provided) and other subscriber information originates from the subscriber and have not been tampered with in transit (public-key verification) subject authentication method depends on the type of the requested certificate (assurance level) for high assurance level certificates, usually personal presence is required subject presents identification documents CA may obtain further information from third party databases most reliable form of authentication low assurance level certificates may be obtained via an entirely on-line process public-key verification if the CA generates the key-pair, then the problem is trivial if the public key is provided by the subscriber, then a certificate issued by another CA may attest that the given public key really belongs to the given subscriber 18

10 Certificate issuance certificate is signed by a signing device using the CA s private key a copy of the certificate is forwarded to the subscriber a confirmation of acceptance is returned by the subscriber (if needed) a copy of the certificate is sent to the repository (directory service) a copy of the certificate is archived transaction is logged in an audit journal 19 Distribution of certificates via the repository (directory) service individually the signer usually has a copy of her certificate attach the certificate (chain) to the digitally signed document potential disadvantages: waste of bandwidth or storage space, as the verifier may already have a copy of the certificate multiple chains may exist from the verifier to the signer; which one to attach? advantage: easier to archive signed document with the corresponding certificate chain (and certificate status information) other means web DNS 20

11 Certificate revocation sometimes certificates need to be revoked before their expiration time detected or suspected key compromise change of data contained by the certificate (e.g., name, ) change of subject-ca relationship (e.g., employee leaves the company) who can request a revocation? the subscriber is authorized to request the revocation of her own certificate officers of the CA are also authorized to revoke a certificate under well-specified circumstances other people may be authorized (e.g., employer) in any case, the requesting party is authenticated by the CA and a log is generated (RA may have the responsibility to approve revocation requests) 21 Certificate Revocation Lists (CRL) a CRL is a time-stamped list of revoked certificates signed by the CA and made available to certificate users (e.g., published regularly in the directory or on a web site) issuer s name CRL issue time/date certificate serial # revocation time/date certificate serial # revocation time/date digital signature process CA s private key... certificate serial # revocation time/date issuer s signature 22

12 CRLs (cont d) the CA issues CRLs regularly (hourly, daily, or weekly) a new CRL is issued even if no new revocations happened since the last CRL (why?) advantages: CRLs can be distributed in the same way as certificates no need for trusted servers and secure communication links disadvantage: time granularity is limited to CRL issue period key is suspected to be compromised now, but certificate users will be aware of that only when the next periodic CRL is issued issue of CRL i revocation requested issue of CRL i+1 (a) (b) (c) (d) (e) key compromise revocation 23 Immediate revocation the CA can operate a trusted on-line server that can be queried for the revocation status of a given certificate in real-time server s response must be authenticated and its freshness must be ensured server should be highly available to users revocation requests must be quickly processed by the CA example: OCSP Online Certificate Status Protocol (RFC 2560) 24

13 Key-pair generation on the key owner s system possibly in the hardware (smart card) or software module where the private key will be stored later preferable for digital signature keys (easier to ensure nonrepudiation as the private key never leaves the key owner s system) on the CA s system private key should be securely transported to the key owner s system higher quality keys can be generated (more resources, stronger controls) preferable for encryption keys (if private key needs to be backed up or archived) 25 Private-key protection protection of the private-key from unauthorized access is of paramount importance the private key is typically stored in a tamper resistant hardware module or token (e.g., smart card, PCMCIA card, ) an encrypted file within a computer or regular data storage media (e.g., CF card, USB key, ) access to the key needs to be protected via one or more authentication mechanisms typically, passwords and PINs can be used directly in case of hardware tokens encryption keys can be derived from them in case of encrypted files biometric checks 26

14 Key management requirements RSA has the interesting property that the same key pair can be used for both encryption and digital signature however, such double use of key-pairs is not advisable; users should have different key-pairs for different applications the main reason is in the difference in key management requirements digital signature private key should never leave the key owner s system private key doesn t need back up and archive (why?) public key (certificate) needs to be archived encryption private key often needs to be backed up and archived (why?) public key usually doesn t need to be archived the two applications have conflicting requirements 27 Key management requirements more reasons in general, an encryption key pair may not necessarily be used for digital signature (and vice versa) it is better to design a system assuming that different algorithms (and thus key-pairs) will be used for digital signature and encryption implementations that support encryption may be subject to more strict export controls length of encryption key is often limited if the same key is used for digital signature, then the digital signature key is smaller than it could be key escrow private keys used for encryption may be made available for government officials for escrow purposes digital signature keys should not be disclosed in this way 28

15 Outline Public Key Infrastructures Fair exchange and non-repudiation protocols Electronic payment protocols 29 Non-repudiation of transactions in many applications, it is essential to ensure that participants of a transaction cannot deny having participated in the transaction the problem can be traced back to the problem of non-repudiation of message origin and message delivery non-repudiation of message origin (NRO) sender of the message cannot deny that he sent the message non-repudiation of message delivery (reception) (NRR) receiver of a message cannot deny that he received the message ingredients of solutions digital signatures (NRO) fair exchange protocols (NRR) 30

16 The classical exchange problem description desc B of item B description desc A of item A item A swap item B Bob Alice network if Alice has access to item B but Bob does not have access to item A, then Bob has a disadvantage, and vice versa Alice and Bob do not trust each other, they both believe that the other party may try to cheat 31 Fairness (strong) fairness: at the end of the protocol, either A gets item B and B gets item A or none of them get anything useful an alternative, more precise definition: if both parties are rational, then at the end of the protocol, the following conditions hold if A is honest, then B receives item A, only if A receives item B if B is honest, then A receives item B, only if B receives item A 32

17 Instances non-repudiation protocols exchange of message and its non-repudiation of origin (NRO) token for non-repudiation of receipt (NRR) token certified electronic mail exchange of mail for acknowledgement of receipt electronic contract signing exchange of signatures on the contract text purchase of network delivered services exchange of electronic payment for services mutual disclosure of identities exchange of identity information 33 More definitions weak fairness: if an honest party does not receive its expected item, while the other party does, then the first party receives a proof of this fact probabilistic fairness: a protocol provides ε-fairness, if it guarantees fairness with probability ε timeliness: all honest parties can reach, in a finite amount of time, a point in the protocol where they can stop the protocol while preserving fairness communication models: unreliable channel: messages can be lost resilient channel: all message are eventually delivered (after a finite, but unknown amount of time) reliable (operational) channel: all messages are delivered within a known, constant amount of time (there s an upper bound on the message delivery delay) 34

18 Types of fair exchange protocols no TTP (Trusted Third Party) main idea: break the exchange up into small steps if one party stops in the middle of the exchange, both parties need approximately the same amount of effort to finish the exchange (compute the other s item) doesn t achieve true fairness, usually needs many messages to exchange impractical in many applications, but theoretically interesting with TTP on-line TTP the TTP is involved in each run of the protocol off-line TTP the TTP is involved only if something goes wrong (a message is not received due to a communication error or some misbehavior) we may assume that, most of the time, there won t be any problems, so the protocol can be optimized (in terms of efficiency) for the faultless case ( also called optimistic protocols) 35 A fair non-repudiation protocol with online TTP protocol: 1. A TTP : E TTP ( A, B, m, sig A (A, B, h(m)) ) 2. TTP B : A, B, h(m), sig TTP (A, B, h(m)) 3. B TTP : E TTP ( sig B (A, B, h(m)) ) 4a. TTP A : sig B (A, B, h(m)) 4b. TTP B : m, sig A (A, B, h(m)) notes: NRO = sig A (A, B, h(m)), NRR = sig B (A, B, h(m)) E TTP ( ) is used to prevent eavesdropping of m and the evidences TTP is trusted for checking signatures and sending messages 4a and 4b simultaneously fairness is based on this simultaneous transmission of 4a and 4b, but there are problems: if channels are resilient, then it is unclear how long the TTP should wait for B s response, and thus, how long A should wait for the TTP s message (timeliness is not guaranteed) the TTP may crash between sending 4a and sending 4b, and leave B in an unfair situation 36

19 Fixing the protocol protocol: 1. A TTP : E TTP ( A, B, m, T, NRO = sig A (A, B, h(m), T) ) 2. TTP B : A, B, h(m), T, sig TTP (A, B, h(m), T) 3. B TTP : E TTP ( NRR = sig B (A, B, h(m), T) ) if TTP receives msg 3 before T: 4. TTP publishes at T: A, B, h(m), T, m, NRO, NRR else: 4. TTP publishes at T: A, B, h(m), T, ABORTED 5a. after T, A checks for the result of the protocol 5b. after T, B checks for the result of the protocol notes: the TTP can publish results by making them available through a server (e.g., through the web) if TTP crashes before step 4, then no result will be available (for some time), but fairness is still preserved in any case, A and B should continue polling the server until they receive some response (their evidences or the abort indication) if channels are resilient, the protocol will end after a finite amount of time 37 A protocol with an off-line TTP main protocol: 1. A B : A, B, id, E K (m), E TTP (K), NRO1 = sig A ( ) 2. B A : A, B, id, NRR = sig B ( A, B, id, E K (m), E TTP (K) ) 3. A B : A, B, id, K, NRO2 = sig A ( ) if B timeouts, then call the recovery protocol NRO = NRO1 + NRO2 recovery protocol (only for B): 1. B TTP : A, B, id, E K (m), E TTP (K), NRO1, NRR 2. TTP B : A, B, id, K, NRO2 = sig TTP ( ) 3. TTP A : A, B, id, NRR NRO = NRO1 + NRO2 notes: if A does not send message 3, then B can invoke the recovery protocol to reestablish fairness B will then get NRO!= NRO B may start recovery without sending message 2 (and hence NRR) that is why B must also provide NRR during recovery, which is then sent to A what if A sends E TTP (K ) in message 1? 38

20 A timeliness problem again A does not know when to stop if message 2 doesn t arrive if she stops, B may start the recovery protocol and obtain NRO (while A will no longer receive NRR) so she should wait, but B may have indeed stopped the protocol, and A will wait forever a potential solution an abort protocol that A can call any time to force termination 39 Fixing the protocol main protocol: 1. A B : A, B, id, E K (m), E TTP (K), NRO1 = sig A ( A, B, id, E K (m), E TTP (K) ) 2. B A : A, B, id, NRR1 = sig B ( A, B, id, E K (m), E TTP (K) ) if A timeouts, then call the abort protocol 3. A B : A, B, id, K, NRO2 = sig A ( A, B, id, K ) if B timeouts, then call the recovery protocol 4. B A : A, B, id, NRR2 = sig B ( A, B, id, K ) if A timeouts, then call the recovery protocol NRO = NRO1 + NRO2; NRR = NRR1 + NRR2 abort protocol (only for A): 1. A TTP : A, B, id, PLEASE ABORT if already aborted or recovered then stop, else aborted = TRUE and 2. TTP A : A, B, id, ABORTED, sig TTP ( ) 3. TTP B : A, B, id, ABORTED, sig TTP ( ) recovery protocol (for X in {A, B}): 1. X TTP : A, B, id, E K (m), E TTP (K), NRO1, NRR1 if already aborted or recovered then stop, else recovered = TRUE and 2. TTP A : A, B, id, K, NRR2 = sig TTP ( ), NRR1 3. TTP B : A, B, id, K, NRO2 = sig TTP ( ) 40

21 Properties fairness: if B feels something is going wrong, then he can invoke the recovery protocol at any time after receiving message 1 (which is the starting point for B) if A feels something is going wrong, then she can invoke the recovery protocol after receiving message 2 before that, she can cancel the transaction by calling the abort protocol abort and recovery are mutually exclusive when A invoked the abort protocol, she shouldn t continue the main protocol (even if B s message arrives later) B may misbehave (e.g., doesn t send message 4), and A cannot call the recovery protocol anymore an abort evidence is not a proof that the transaction didn t take place, because the abort protocol can be called after a successful run of the protocol timeliness at each point in the protocol both parties can force termination either by calling the recovery protocol or the abort protocol TTP is not transparent evidences produced in the protocol when TTP is used are different from those that are produced in the case when no TTP is used 41 Outline Public Key Infrastructures Fair exchange and non-repudiation protocols Electronic payment protocols 42

22 Basic classification pre-paid, pay-now, or pay-later pre-paid: customer pays before the transaction (e.g., she buys electronic tokens, tickets, coins, ) pay-now: the customer s account is checked and debited at the same time when the transaction takes place pay-later (credit-based): customer pays after the transaction on-line or off-line on-line: a third party (the bank) is involved in the transaction (e.g., it checks solvency of the user, double spending of a coin, ) in real-time off-line: the bank is not involved in real-time in the transactions 43 General security requirements authorization a payment must always be authorized by the payer needs payer authentication (physical, PIN, or digital signature) a payment may also need to be authorized by the bank data confidentiality and authenticity transaction data should be intact and authentic external parties should not have access to data some data need to be hidden even from participants of the transaction the merchant does not need to know customer account information the bank doesn t need to know what the customer bought availability and reliability payment infrastructure should always be available centralized systems should be designed with care critical components need replication and higher level of protection 44

23 Further requirements atomicity of transactions all or nothing principle: either the whole transaction is executed successfully or the state of the system doesn t change in practice, transactions can be interrupted (e.g., due to communication failure) it must be possible to detect and recover from interruptions (e.g., to undo already executed steps) privacy (anonymity and untraceability) customers should be able to control how their personal data is used by the other parties sometimes, the best way to ensure that personal data will not be misused is to hide it anonymity means that the customer hides her identity from the merchant untraceability means that not even the bank can keep track of which transactions the customer is engaged in 45 Credit-card based systems motivation and concept: credit cards are very popular today use existing infrastructure deployed for handling credit-card payments as much as possible enable secure transfer of credit-card numbers via the Internet examples: MOTO (non-internet based scheme) First Virtual and CARI (non-cryptographic schemes) SSL (general secure transport) ikp (specific proposal from IBM) SET (standard supported by industry including VISA, MasterCard, IBM, Microsoft, VeriSign, and many others) 46

24 Credit-card payment with TLS/SSL the user visits the merchant s web site and selects goods/services to buy state information may be encoded in cookies or in specially constructed URLs or state information may be stored at the merchant and referenced by cookies or specially constructed URLs the user fills out a form with his credit card details the form data is sent to the merchant s server via a TLS connection the merchant s server is authenticated transmitted data is encrypted the merchant checks the solvency of the user if satisfied, it ships the goods/services to the user clearing happens later using the existing infrastructure deployed for credit-card based payments 47 Pros and cons of TLS/SSL advantages: TLS is already part of every browser and web server no need to install any further software users are used to it this payment method can be used as of today disadvantages: eavesdropping credit card numbers is not the only risk another risk is that credit card numbers are stolen from the merchant s computer 48

25 SET Secure Electronic Transactions a protocol designed to protect credit card transactions on the Internet initiated and promoted by MasterCard and Visa MasterCard (and IBM) had SEPP (Secure E-Payment Protocol) VISA (and Microsoft) had STT (Secure Transaction Technology) the two proposals converged into SET many companies were involved in the development of the specifications (IBM, Microsoft, Netscape, RSA, VeriSign, ) the SET specification is available on the web ( Google) it consists of three books: 1. Business Description 2. Programmer s Guide 3. Formal Protocol Definition (around 1000 pages all together) 49 SET participants cardholder wants to buy something from a merchant on the Internet authorized holder of payment card issued by an issuer (bank) merchant sells goods/services via a Web site or by has a relationship with an acquirer (bank) issuer issues payment cards responsible for the payment of the dept of the cardholders acquirer maintains accounts for merchants processes payment card authorizations and payments transfers money to the merchant account, reimbursed by the issuer payment gateway interface between the Internet and the existing credit-card payment network CAs 50

26 SET services cardholder account authentication merchant can verify that the client is a legitimate user of the card based on X.509 certificates merchant authentication client can authenticate the merchant and check if it is authorized to accept payment cards based on X.509 certificates confidentiality cardholder account and payment information (i.e., her credit card number) is protected while it travels across the network credit card number is hidden from the merchant too! integrity messages cannot be altered in transit in an undetectable way based on digital signatures 51 Dual signature basic concept goal: link two messages that are intended for two different recipients (e.g., order info and payment instructions in SET) link may need to be proven in case of disputes data1 hash hash K -1 X hash hash sign sign data2 hash hash data1 data2 52

27 Dual signatures in SET goal: same as in the basic case, but the two messages have the same signature data1 hash hash K -1 X hash hash sign sign data2 hash hash + data1 data2 53 Overview of message flows cardholder order info + payment instruction ack + services merchant Internet authorization request authorization response + capture token capture request capture response authorization processing capture processing payment network payment gateway issuer money transfer acquirer 54

28 Overview of message protection cardholder (C) merchant (M) acquirer (via payment gtw) PReq OI C PI C K A Auth.Req. PI C K A M K M K A Auth.Res. Cap.Token A PRes M K A A K M M signature Cap.Req. Cap.Token A K A M C dual signature K A K A digital envelop Cap.Res. A K M 55 Why did SET fail? less benefits than expected merchants like to collect credit card numbers (they use it as indexes in marketing databases) optionally, SET allows the merchant to get the credit card number from the acquirer security improvements of SET are negated too high costs SET requires a PKI no advantages for the customer! the idea was that SET transactions would be handled as cardholder present transactions (due to the digital signature) customers prefer MOTO-like systems where they can freely undo a transaction if they are unhappy (not only in case of fraud) customers were much worse off SET requires the download and installation of a special software, and obtaining a public-key certificate 56

29 Electronic cash motivation and concept: people like cash (75-95% of all transactions in the world are paid in cash) design electronic payment systems that have cash-like characteristics it is possible to ensure untraceability of transactions (an important property of real-world cash) examples: DigiCash (on-line) CAFE (off-line) 57 E-cash a naïve approach electronic coins: (value, Sig bank (value)) problem 1: double spending a solution to problem 1: coins can have a serial number: (sn, val, Sig bank ( sn, val )) the bank maintains a database of spent serial numbers merchants deposit received coins before providing any service or goods only coins that have never been deposited before are accepted by the bank problem 2: ever increasing database at the bank a solution to problem 2: coins have an expiration time: ( sn, val, exp, Sig bank ( sn, val, exp )) bank needs to store deposited coins until their expiration time only 58

30 E-cash a naïve approach (cont d) problem 3: traceability user merchant spend coin sn withdraw coin sn (user is identified in order to debit her account) deposit coin sn (merchant is identified in order to credit his account) bank bank can link the withdrawal (identity of the user) and the deposit (identity of the merchant) via the serial number sn a solution to problem 3: DigiCash 59 The main idea of DigiCash blind RSA signatures the bank s public RSA key is (e, m), its private RSA key is d user U generates a coin (sn, exp, val) and computes its hash value h = H(sn, exp, val) user U generates a random number r (blinding factor), computes h r e, and sends it to her bank the bank signs the blinded coin by computing (h r e ) d = h d r when U receives the blindly signed coin, it removes the blinding: h d r r -1 = h d U obtained a digital signature of the bank on the coin the bank cannot link h d r and h d together (r is random) problem 4: How much should the user be charged? the bank signs the blinded coin it does not know the value of the coin a solution to problem 4: the bank can use different signing keys for different denominations 60

31 Micropayment schemes motivation and concept: many transactions have a very low value (e.g., paying for one second of a phone call, for one article in a newspaper, for one song from a CD, for 10 minutes of a TV program, etc.) transaction costs of credit-card, check, and cash based payments may be higher than the value of the transaction need solutions optimized for very low value transactions (perhaps by sacrificing some security) examples: Millicent PayWord MicroMint probabilistic micro-payment schemes the truth: micropayment schemes are not very successful so far people are used to get these kind of things for free if they have to pay, they prefer the subscription model 61 PayWord designed by Rivest and Shamir in 1996 representative member of the big family of hash-chain based micropayment schemes check-like, credit based (pay later) system payment tokens are redeemed off-line uses public key crypto, but very efficiently (in case of many consecutive payments to the same vendor) the user signs a single message at the beginning this authenticates all the micropayments to the same vendor that will follow 62

32 PayWord model players: user (U) vendor (V) broker (B) phases: registration (done only once) payment redemption user PayWord commitment micropayment tokens vendor... account information (e.g., credit-card number) PayWord certificate commitment + last received token broker 63 Registration phase U provides B with account information in a real bank (e.g., her credit card number) shipping address public key B issues a certificate for U Cert U = { B, U, addr U, K U, exp, more_info } K B -1 more_info: serial number, credit limit, contact information of B, broker terms and conditions, the certificate is a statement by B to any vendor that B will redeem authentic paywords (micropayment tokens) produced by U turned in before the expiration date 64

33 Payment phase commitment when U is about to contact a new vendor, she computes a fresh payword chain w n, w n-1 = h(w n ), w n-2 = h(w n-1 ) = h (2) (w n ),, w 0 = h (n) (w n ) where n is chosen by the user w n is picked at random U computes a commitment M = { V, Cert U, w 0, date, more_info } KU -1 the commitment authorizes B to pay V for any of the paywords w 1,, w n that V redeems with B before the given date paywords are vendor specific, they have no value to another vendor 65 Payment phase sending tokens the i-th micropayment from U to V consists of the i-th payword and its index: (w i, i) when V receives w i, it can verify it by checking that it hashes into w i-1 (received earlier, or in the commitment in case of i = 1) since the hash function is one-way (preimage resistant) the next payment w i+1 cannot be computed from w i V needs to store only the last received payword and its index variable size payments can be supported by skipping the appropriate number of paywords let s assume that the value of each payword is 1 cent and the last payword that U sent is (w k, k) if U wants to perform a payment of 10 cents, then she sends (w k+10, k+10) 66

34 Redemption phase at the end of each day, the vendor redeems the paywords for real money at the broker V sends B a redemption message that contains (for each user that contacted V) the commitment and the last received payword w k with its index k B verifies the commitment and checks that iteratively hashing w k k times results in w 0 if satisfied, B pays V k units and charges the account of U with the same amount 67 Efficiency user U needs to generate one signature per session needs to perform as many hash computation as the number of paywords needed (pre-computation of hash chains is possible) needs to store the hash chain and her current position in the chain (time-memory trade-off is possible) vendor V needs to verify one signature per session needs to perform one hash computation per micropayment received needs to store only the last received payword with its index, and the commitment broker B needs to verify signatures and compute lot of hashes but all these are done off-line 68

35 Probabilistic micropayment motivation: in traditional micropayment schemes, the vendor cannot aggregate micropayments of different users if the user spent only a few cents, then the cost of redeeming the micropayment tokens may exceed the value of the payment example: typical value of a payword is 1 cent, whereas processing a creditcard transaction costs about 25 cents main idea: suppose that U wants to pay 1 cent to V U sends to V a lottery ticket that is worth 10$ if it wins, and it wins with probability the expected value of U s payment is exactly 1 cent if V conducts business with many users, then he approximately earns the value of the services/goods provided advantage: only winning lottery tickets are redeemed at the bank number of vendor-bank transactions is greatly reduced value of lottery tickets surely exceeds the transaction cost 69 Micali-Rivest scheme check based, the user simply signs the transaction notation T encoding of the transaction (IDs of user, merchant, bank, transaction time, etc.) F fixed public function that maps an arbitrary bit string to a number between 0 and 1 s fixed selection rate of payable checks setup everyone establishes his own public key and corresponding private key for a digital signature scheme the merchants signature scheme must be deterministic Sig M (x) = Sig M (x ) if x = x 70

36 Micali-Rivest scheme (cont d) payment user U pays by sending C = (T, Sig U (T)) to merchant M M verifies if C is payable by checking if F(Sig M (C)) < s selective deposit M sends only payable checks to the bank for deposit after verification, B credits M s account with 1/s cents and debits U s account with the same amount 71 Some properties Sig M (C) is unpredictable for both U and M practically, F(Sig M (C)) is a random number with close to uniform distribution over [0, 1] the probability that F(Sig M (C)) < s is s expected value of a check is 1 cent the bank essentially processes macropayments of value 1/s e.g., if s = 1/1000, then the value is 10$ potential psychological problem possibility of user s excessive payments (in the short term) e.g., it has a positive probability that the first 10 checks sent by the user are all payable value of the goods/services received by the user is 10 cent but her account is debited 100$ in the long run it will work, but users may not tolerate the risk of short term overpaying 72