PNS- Ra
Sample Answer and Guide to Workshop Task 1
Mengya Li
March 11, 2023
This document contains one sample answer to a task in the workshop (Task 1 on page 13 on the week 8 workshop slides), and a step-by-step guide as to how to give such an answer. Please note: there is more than one possible answer to the task, and more than one way to write it out. You can solve it in other ways. The important skill to learn here, and in your practical assessment, is the method to solve such a task. The aim is to give a technical solution to secure a network transmission and achieve satisfying effects.
Task 1 is: Amy uses CardA to pay for the order, by giving the order and her identity and the card name to the bank B, and putting CardA to a card reader to access the private key saved on it.
To see the other descriptions for the use case, please refer to the workshop slides.
1 Sample Answer
1.1 Assumptions • (A1) CardA has a pair of private/public key, PKCardA and SKCardA, issued by the
Bank, B. CardA has the private key stored on it, and can be accessed through a card reader and read into a computer programme. Bank B holds a copy of the public key, but it has deleted the private key after having generated it. NOTE: this assumption is a rephrase of what is given in the question description. It is not an additional assumption. The purpose of putting this in assumption is to provide more details as this specific design needs, and to give the notation of the keys.
• (A2) Bank B has a pair of public/private key, PKB and SKB, issued by a certificate authority (CA). The certificate for PKB is CertB.
• (A3) The CA is trusted by all entities in the network, i.e., certificates issued by the CA with the CA signature can be verified by any entity in the network.
• (A4) Bank B keeps a record of order number, vendor identity, payer information, payment status and order time. This record is stored with confidentiality protection, such as encrypting it with a key only the bank knows. NOTE: this assumption is made for mitigating replay attack. This is a reasonable assumption to make for this task because protecting information stored inside an entity, i.e., the bank in this case, is out of the scope of the task, which is to protect data in transit in a network.
1.2 Design for Task 1 Task 1 requires the user Amy to send a message to the Bank B, to inform B that she wants to pay for an order with CardA.
1
1.2.1 Security Requirements
To achieve this functional goal, A sends B a message consisting of the order, A’s identity and the card name CardA to B. Because the order has a unique order number, the price to pay, and the time the order is placed, and the order is signed by V using the private key associated to PKV , the bank can know from the order what is the price to be paid, and to whom it is going to be paid. With A’s identity given and the card name given, the bank can know who is supposed to make the payment and which account to use.
In this message, A’s identity, card name CardA and order information are sensitive information. Therefore, this sensitive information should only be known to the intended receiver, and the message should be protected for confidentiality. In addition, the message should have message authentication protection, so that the receiver can obtain the infor- mation the sender intends to send, and it is indeed a message sent by the genuinely CardA with the CardA present (as opposed to sent by someone who knows the name CardA).
NOTE: for the practical assessment, the requirements are already given in the brief. For a full mark, you need to: at least make sure all those requirements are satisfied; and add additional ones based on your message content IF needed.
1.2.2 Design Details
To achieve confidentiality, the message should be encrypted by the public key of the receiver, bank B. This is to ensure that only the owner of the associated private key can decrypt the message correctly and read the content. To achieve message authentication, the encrypted message above should be signed with CardA’s private key.
To send the message, first, A should get the public key of B. This is done by getting B’s certificate, CertB, from CA, and verifying the public key on the certificate is authentic. Then, A encrypts the order, A’s identity and card name CardA with the public key of B, PKB. Then, A generates a signature on this encrypted ciphertext, by signing on it using the private key of CardA, SKCardA. Then A sends the signed message to B.
When the bank B receives the message, it should decrypt the message with its private key, SKB, and find the public key of CardA, PKCardA, in its storage. Then it verifies the signature using PKCardA. If the verification is successful, it checks whether the message is fresh. To do so, it checks the order time is recent enough, and check in the record of all orders to ensure the combination of this order number and this vendor identity is unique and has not been paid yet. NOTE: the combination is used for checking, to deal with the case where two vendors accidentally generated the same order number.
1.2.3 Message Content
The following message is sent from A to B:
pay order request = Sig(SKCardA,Enc(PKB,order||IDA||CardA)), (1)
where SKCardA is the private key of CardA, PKB is the public key of Bank B, IDA is the identity of A, and CardA is the name of the card A is using to pay. Enc(k,m) denotes the encryption of plaintext m using a key k, and Sig(k,m) denotes signing a message m with a private key k. NOTE: Here you should explain the notation you use in the equa- tion. If some notations have been given before in assumptions or design details, you can skip them here. You will not lose marks for explaining them twice; however, you will lose marks if you do not explain a fair number of notations, or if you make contradictory definitions, such as using the same notation for two different things.
2
1.2.4 Justifications
This message can send the necessary payment information, i.e., order information, payer identity and payment card information, to the bank, while achieving confidentiality. This is because the authentic recipient, B, should have the private key needed to decrypt the encryption in the message, and therefore can obtain the plaintext. Only the authentic B should have this key, therefore, only the authentic B is able to obtain the plaintext information.
This message can achieve message authentication, because the signature can only be verified if the private key of CardA is used to generate it on the message, and the message has not been modified after the signing. This key should only be known by CardA, so the signer and sender of the message must be the authentic CardA. The whole encrypted payment information is signed, so none of the information can be modified without being detected. The receiver, B, issued the public key of the signing private key, and keeps an authentic copy of the public key. Therefore, the authentic public key will be used to verify the signature, ensuring the verification is correct.
The message is protected from replay attacks, by using the unique order number and vendor combination for checking for paying twice, and using the order timestamp to check freshness.
1.2.5 Limitations and Future Work
In the design, the message is signed with the private key of CardA. However, the private key is stored on the card, and can be read with a supported device, such as a card reader. This weakens the binding relationship between the card and the card owner, A. That is, whoever can access the private key of CardA may not be the genuine A, but someone who has the card. If an attacker steals CardA from A, knows A’s identity and has a card reader, the attacker will be able to use the card to make payment for themselves, pretending to be A. Therefore, additional measures can be taken, to verify the identity of the person making the payment, before the bank authorises the payment.
2 Steps to break down the task and come up with the design
1. Understand the task: What does the task say you should do? Read the task and find the goal; then find what to send/exchange to achieve the goal.
Task 1 says: ”Amy uses CardA to pay for the order, by giving the order and her identity and the card name to the bank B, and put CardA to a card reader to access the private key saved on it.”
Task goal is to send the order, A’s identity, and card name (CardA) to bank B. In other words, B should know this information by the end of it.
2. Find out the security requirements. What among the things to send needs to be protected, and what is the purpose of the protection? This is the security properties to achieve in this network transmission.
From the task goal we know: A will sends B the order, A’s identity (IDA), and card name CardA to B. The sample answer decides all of this information is sensitive and private, because A may not wish to let everyone know what A is buying, or A is buying something, or A has this card. So, to protect sensitive information from
3
being known to entities A does not want to share the information with, the security property we are looking for is confidentiality.
Then, because the goal is to let Bank B have this information, we want to ensure Bank B gets the correct information as sent by A. This means we need message integrity.
Then, because we do not want anyone who know the name of A and the card name to just use this card to pay for their own order, we would like to ensure that B can verify this message is actually from where CardA is present for the payment. So we would like to have message origin authentication, to ensure this message comes from somewhere CardA is present. (NOTE: compare this to the limitation given above. This origin authentication deals with the situation where an attacker knows A’s identity and CardA’s name. The limitation is considering where the attacker knows A’s identity, CardA’s name and HAS THE CARD.)
So security requirements for this task: confidentiality, and message authentication (integrity and origin authentication).
3. Find out what security measures you can use to satisfy the security requirements.
There is a table given in Chapter 1 of the reference book [1], attached below for easy reference. NOTE: the book uses the term encipherment in a very loose man- ner. Please pay attention in your assignment report and distinguish between encryp- tion, message authentication, and digital signature. Please refer to the slides in the relevant weeks for which term to use for what security properties.
For confidentiality, you need encryption.
For message authentication, you need MAC or signature.
4. How to apply the security measures?
4
For encryption, you already know you want to encrypt the order, A’s identity, and card name. This is the input to your encryption function. Now you need an encryp- tion key. As the purpose of the encryption is for only B to read the plaintext, the key you choose should satisfy: A has the encryption key; Only B has the decryption key; the ciphertext generated with the encryption key can only be decrypted with the decryption key.
Read the task description to see whether there is a key given already. In this case, there is none. So for there to be such a key, one solution is to add an additional assumption, so that you have this key. (Another solution may be you negotiate a key with what you already have; however, this will be more complicated. In your assessment brief, there is a trusted authority for you to use if you need to make such an assumption. So here we make use of the trusted authority given.)
The additional assumption should be reasonable in the scenario. A reasonable ex- ample could be: Bank B has a pair of private/public key, and the public key has a certificate issued by a CA.
With this assumption, we can perform the encryption. The encryption is done in the following steps: (1) A gets B’s certified public key from the certificate; (2) A encrypts the data that need to be confidential with B’s public key.
For message authentication, we look at the task description again. The description has stated that the CardA has a pair of private/public key issued by the bank and the bank knows the authentic public key. This means a signature of CardA can be generated on the message using CardA’s private key, and the message can be verified by B using CardA’s public key. There is no need for additional assumption for this.
Then you write out the design details as above. It should have steps each entity takes to finish the task. The design should state clearly: what operation each entity does on its own, what they send to whom, what they do when they receive something, in what order they do these steps.
5. How to compose the messages?
From above, the design says the message should send order, A’s identity and CardA’s name, encrypted by B’s public key, and signed by CardA’s private key. So the mes- sage should be:
pay order request = Sig(SKCardA,Enc(PKB,order||IDA||CardA)), (2)
where SKCardA is the private key of CardA, PKB is the public key of Bank B, IDA is the identity of A, and CardA is the name of the card A is using to pay. Enc(k,m) denotes the encryption of plaintext m using a key k, and Sig(k,m) denotes signing a message m with a private key k. Here you should explain the notation you use in the equation
6. How to justify? The justification you are making here is the design can achieve the security requirements (and performance requirements, for the assessment). This design for Task 1 should ensure confidentiality of the data A wants to keep secret (order, A’s identity, and card name), and message authentication of all data sent to B.
For confidentiality, this design and the message content show that only the entity with the private key paired with PKB can decrypt the ciphertext and read the en- crypted data. Only B has that private key, so only B can read that message.
5
For message authentication, only the signature generated on the ciphertext using the private key associated to the public key B will use to verify the signature can be validated by B. Only when CardA is present can a user extract the private key from CardA and use it to sign. Therefore, the signature ensures the message is coming from someone in possession of CardA, and the message has not be modified by anyone else after being sent by the sender.
In terms of performance, the design should be examined in terms of computational costs, communication costs, key management costs.
The computation in this design is a public-key encryption and a signature gener- ation, on the user’s end, and public-key decryption and signature verification on the bank’s end. Public-key encryption and signature are more computationally ex- pensive than the symmetric-cipher-based solutions for the same security properties. But because symmetric keys are not available in this task, and only one message ex- change takes place in the task, it is cheaper to directly use public-key cryptography, instead of using public-key cryptography to establish symmetric keys and then us- ing symmetric-cipher-based solutions. NOTE: When a large amount of data is to be exchanged between a pair of entities for a period (a session), it is preferable to use public-key cryptography to establish symmetric session keys, so as to use symmet- ric-cipher-based security measures to protect network transmission in the session. The costs for the extra operations to establish session keys are compensated by the costs saved by using symmetric cryptography instead of asymmetric cryptography in the session. It is also preferable to establish symmetric session keys for a session even if you have long-term symmetric keys in the first place, for reasons we have explained in the workshop about key hierarchy (week 6 workshop).
For communication costs, only one message is sent, and minimum data are added to the message besides the information that has to be sent.
For key management, on the user’s end, only one long-term key has to be kept secret, the CardA private key.
7. Limitation and weakness: Check the protocol against some common threats.
For replay attacks: in the message, there is no timestamp or nonce used. However, the order contains a unique order number, the order time, and the signature of ven- dor. If the bank B saves the order it processes, with the vendor info, order number and order time, and check every new incoming order against the paid ones, B can detect if a certain order has already been paid for.
Impersonation: In the design above, the key used to sign the message is saved in CardA. The signature can prove the genuine CardA is present when the payment request is sent. But this does not prove it is the owner of the card who is making the payment, just someone who has the card at the moment is making the payment. If someone has stolen the card and has the hardware necessary to read the key from the card, they can use this card to pay. Think of the real-world card payment process: you enter card number, name and cvv to a website. All this information is written on the card, so if you steal the card, you can pay from the card, even if you are not the owner of the card. Therefore, this design has a vulnerability, which is someone who has stolen the card from A can make payment pretending to be A.
This is why the exercise set the second task, for the bank to verify A in addition to verifying the card is valid in Task 1.
6
References [1] W. Stallings, Cryptography and Network Security: Principles and Practice. Pearson
Education Limited, 7th ed., 2017.
7
- Sample Answer
- Assumptions
- Design for Task 1
- Security Requirements
- Design Details
- Message Content
- Justifications
- Limitations and Future Work
- Steps to break down the task and come up with the design