bachelor

Recommendations

Info

8 On Rejsekortet 1. Reader sends a “select” request. 2. Tag replies with its unique ID. 3. Reader sends a directed “select” request, including the tag’s unique ID. This prevents collisions when two tags are within the reach of the reader. 4. Reader tries to authenticate to some sector. 5. Tag picks a challenge nonce and sends it to the reader. 6. Reader sends a challenge nonce, as well as a response to the tag’s challenge. 7. Tag sends a response to the reader’s challenge. Figure 1.2: Authentication protocol of Mifare • Read: Reads the content of the given block. • Write: Writes some given data to the given block. • Increment: Treats the block contents as an integer and increments it by a given value. • Decrement: Like “Increment,” but it decrements. • Copy: Copies the content of a block onto another. This can be used for backup. The incrementation and decrementing functions make Mifare attractable to use for ticketing systems since a purse can be implemented atomically. Note that the access control bytes for the sector dictate whether or not these functions can be used. 1.2.3.4 Ensuring internal card consistency Rejsekortet implements a system that makes card transactions indivisible. This is to ensure that a card does not get corrupted if the user removes it prematurely during a transaction; either an entire transaction is carried out, or no transaction is carried out.
1.2 Technology and card layout 9 The system furthermore differentiates between different kinds of sector types, by defining different application types to them. They define how data redundancy is managed for that specific data field and, and how the data is arranged. Some application types are used only for one data structure on the card, e.g. AT2. AT2 is the type used for storing tickets currently active on the card. There are two data elements “taking turns” in containing the newest version, as well as some number 1 ≤ n ≤ 6 of additional elements, containing a log of old tickets on the card. The card contains a data structure, TCAS 7 , that keeps the ID of the last transaction, as well as the status of all the sectors. The sector status variable defines which of the two redundancy elements is the current, depending on the application type of the sector. This is important, because no current data is ever supposed to be overwritten in Rejsekortet; if some value on the card is going to have a new value, the data will be written to the unused sector first, and then the section status will be changed so as to reflect that the current data is in the “other part” of sector. Ultimately, Rejsekort consistency is ensured by also having two copies of the TCAS field. At each transaction this structure is written twice to the card, in predetermined sectors. This makes the system very robust to connection disturbance, because the card will always be able to use the old TCAS in case of a communications fall-out. There are four phases of a transmission in Rejsekortet: 1. Writing the new data to the unused fields. 2. Writing the new TCAS1 to its designated sector. This value has another sector status for the altered data field, making the just-written data current. 3. Writing the new TCAS2 which is equal to TCAS1. TCAS2, as we shall see, is used if the next transaction falls out and TCAS1 becomes inconsistent. From [6] we have this table over transaction breakdowns and how the system will react (quote): As stated, if TCAS1 is inconsistent, TCAS2 will be used. This leads to the card being temporarily “rolled back” because the TCAS pointed to the non-recent data elements. 7 Travel Card Application Status
Page 1 and 2: Cryptanalysis of Rejsekortet Jens C
Page 3: 3 Abstract. This bachelor thesis an
Page 7: Resumé Denne bachelorafhandling er
Page 10 and 11: vi Glossary Rejsekort(et) Danish fo
Page 12 and 13: viii
Page 14 and 15: x CONTENTS 4.3 Other improvements .
Page 16 and 17: 2 On Rejsekortet Disclaimer: This r
Page 18 and 19: 4 On Rejsekortet are even capable o
Page 20 and 21: 6 On Rejsekortet 1.2.3 Mifare Mifar
Page 24 and 25: 10 On Rejsekortet Time of transacti
Page 26 and 27: 12 On Rejsekortet Figure 1.3: The C
Page 28 and 29: 14 On Rejsekortet 1.3.2.1 CBC-MAC C
Page 30 and 31: 16 On Rejsekortet
Page 32 and 33: 18 Security analysis and threat mod
Page 38 and 39: 24 Attacks on Rejsekortet 3.1 Rollb
Page 40 and 41: 26 Attacks on Rejsekortet 3.2 Attac
Page 42 and 43: 28 Attacks on Rejsekortet and cumbe
Page 44 and 45: 30 Attacks on Rejsekortet hash valu
Page 46 and 47: 32 Attacks on Rejsekortet 3.2.4 Int
Page 48 and 49: 34 Attacks on Rejsekortet 3.2.5 App
Page 50 and 51: 36 Attacks on Rejsekortet 3.2.6.2 T
Page 52 and 53: 38 Attacks on Rejsekortet Language
Page 54 and 55: 40 Attacks on Rejsekortet It is not
Page 56 and 57: 42 Attacks on Rejsekortet specifica
Page 58 and 59: 44 Attacks on Rejsekortet might pro
Page 60 and 61: 46 Attacks on Rejsekortet that the
Page 62 and 63: 48 Attacks on Rejsekortet
Page 64 and 65: 50 Improvements 4.1.1 New MAC algor
Page 66 and 67: 52 Improvements functions tend to b
Page 68 and 69: 54 Improvements
Page 70 and 71: 56 Conclusion of the pre-computatio
Page 72 and 73:
58 Related research Sector 04 - UNK
Page 74 and 75:
60 Mail correspondence enquire abou
Page 76 and 77:
62 Mail correspondence * Kodningspr
Page 78 and 79:
64 Mail correspondence Som ingeniø
Page 80:
66 BIBLIOGRAPHY [9] Philippe Oechsl
show all

bachelor

Create successful ePaper yourself

Delete template?

Save as template?