Proceedings 2002/2003 - IRSE

More documents

Recommendations

Info

36 EURORADIO AND THE RBC management can be very simple and relatively painless. 4.3 MESSAGE AUTHENTICATION CODE To make it look easy, Figure 3 shows a generic encryption process. PLAINTEXT KEY ENCRYPTION ALGORITHM CIPHERTEXT Figure 3 – Encryption Apart from the terminology, an interesting point is that a single bit change in the plain text should, on average, change half the output ciphertext bits, if the encryption algorithm is a good one. In fact, if you change any or all the input bits, half the output bits should change. So you can find out nothing about the input bits from the output. Which is as it should be, though it does make error-correction a nonstarter. Now it is necessary to introduce the concept of Cipher-Block Chaining (CBC). If the plaintext and the key of Figure 1 are 8 bytes long, the ciphertext out is also 8 bytes. What happens if the message you want to send is longer than 8 bytes? The message can be divided into 8-byte blocks, and each encrypted individually, but input plaintext will always give the same ciphertext. One way of preventing this is to chain the enciphering blocks together, and this is shown in Figure 4. The first plaintext block is encrypted as before, but now the output is fed into the second block, so plaintext 2 is exclusive-OR’d with ciphertext 1 before being encrypted. So now ciphertext 2 depends on all the bits of plaintext 2, and all the bits of plaintext 1. And now it becomes a little clearer how a Message Authentication Code (MAC) works. For encryption, the ciphertext blocks 1 and 2 etc are the output – they are sent to the destination. But to create a MAC the ciphertexts are used only as input to the next PLAINTEXT 1 8 bytes DES CIPHERTEXT 1 8 bytes KEY PLAINTEXT 2 8 bytes DES XOR CIPHERTEXT 2 8 bytes KEY Figure 4 – Cipher Block Chain block; apart from which they can be thrown away. Because what you are left with at the end of this ‘chain of enciphering blocks’ is 8 bytes that depend on every single bit of all the plaintexts 1, 2, etc. The same reasoning applies at the receiver, which performs exactly the same process. That is, the receiver takes the unencrypted plaintext coming in, and calculates a MAC from it and the shared key. If the received and calculated MACs match, then the message received is the same as at the place it was calculated, and the sender must have used the same key. There is one point about this that sometimes causes confusion. What has been described is ‘single DES’. DES, or Data Encryption Standard, describes use of the Data Encryption Algorithm (DEA) which uses a 64 bit key, of which 56 bits are actual random key, and 8 are parity bits. An effective key of 56 bits is rather small considering the increases in processing power, and recently a successful attack has received publicity. However, the attack was a brute-force key search, so it is not true to say that DES has been ‘broken’ in the sense of finding a weakness that bypasses the brute-force approach – it simply demonstrates that any 56 bit key can be discovered in a reasonable time. This was predicted when EuroRadio was first specified, and the actual algorithm used is called ‘single DES with modified optional process’. This is a mechanism for giving the strength of triple-DES without incurring the extra time. What happens is shown in Figure 5. The single-DES approach is used to generate the MAC (B in Figure 5), but then the last block is decrypted with key 2 (C), then encrypted with key 3 (D), ie the last block is triple encrypted. This has the benefit that, if key 2 is the same as key 3, there is compatibility with single DES, but that otherwise a brute-force attack must find all three keys, giving an unexpected effective key length of 112 bits (there are various shortcuts you can take in an attack that mean you do not have to try all three combinations of all keys, making the difficulty the same as that of attacking a single 112-bit key system). Now we have a strong authentication method, we can get on with setting up the connection. Well, not quite! We have a system where a hacker cannot produce false messages or create new ones, because he does not have the key. But what is to stop a hacker recording a message, waiting until the timestamp wraps round, then replaying it into the receiver? Or to stop the network storing the message unintentionally, and then delivering it at some future time? This ‘replay’ attack can be resisted either by having a very, very long timestamp or by using a ‘session key’, and it is this second approach that is specified for EuroRadio. In the authentication handshake messages, random numbers are exchanged. These are used in combination with the shared secret key to produce a shared session key, which is used only until the connection is ended. Next time a connection is needed, different random numbers are generated, producing a different session key.
EURORADIO AND THE RBC 37 PLAINTEXT (N–1) PLAINTEXT (N) DES KEY 1 DES KEY 1 INVERSE DES KEY 2 DES KEY 3 A B C D CIPHERTEXT (N–1) 8 bytes CIPHERTEXT (N) 8 bytes MAC WITH SINGLE DES But we are still trying to set up a connection, so, assuming the right key is available, how is the connection authenticated? The answer is with a three-way handshake – and this is the second difficult part! Note that not all fields are discussed in detail, for example, the ‘direction flag’ which is included to resist a particular form of hacking attack. 4.4 THE HANDSHAKE The train is trying to contact the RBC. It has the key, and all lower protocols have been set up. The first safety message, sent by the train, is catchily entitled the ‘first authentication safety protocol data unit’ (SaPDU), and contains the train’s ETCS-ID, the ID-type (for a train this is “engine”), a Safety Features field specifying DES (to allow for other options in the future), and an 8-byte random number. The RBC replies with – as expected – the ‘second authentication SaPDU’, which contains the RBC’s ETCS-ID, and ID-type (“RBC”), and another 8-byte random number, with a MAC. The train replies to the RBC with the ‘third authentication SaPDU’, which is basically just a MAC. Figure 5 – The Last Block CIPHERTEXT (N) 8 bytes DECRYPTED WITH A SECOND KEY CIPHERTEXT (N) 8 bytes ENCRYPTED WITH A THIRD KEY FINAL MAC So what’s going on, and why? The first message is easy – anyone could create it because it has no MAC. It has the train ID, but not the identity of the RBC, because it may be using the ‘999’ method of connecting. The second message is harder. The RBC constructs the message of Figure 6(a), calculates the MAC, then sends the message of Figure 6(b). Note that the message length, the train’s address, the train’s random number and the padding bits are not transmitted – the train knows or can calculate them to insert into the received message before calculating the MAC and comparing it with the received MAC. The RBC is able to calculate the MAC of course because it knows the key and the two random numbers. The train cannot do this until this message arrives, because it needs the RBC’s random number. But once it receives it, the train is able to reply with the third authentication message, which plays the same trick – it calculates the MAC over the RBC’s address, the two random numbers, the Message Type Identifier and the Direction Flag, but only actually sends the MTI, the DF and the MAC. (a) LENGTH ID RBC TRAIN TRAIN RBC TYPE MTI DF SaF RAND RAND ADDRESS ADDR (engine) NUM NUM TRAIN ADDRESS PADDING BITS Calculates MAC sends: (b) ID TYPE MTI DF RBC ADDR RBC SaF RAND + MAC NUM MTI DF SaF = MESSAGE TYPE IDENTIFIER = DIRECTION FLAG = SAFETY FEATURES Figure 6 – Second Authentication Message from RBC to Train
Page 1 and 2: Proceedings 2002 - 2003
Page 3 and 4: The Institution of Railway Signal E
Page 5 and 6: Contents Contents ……………
Page 7 and 8: 5 PETER STANLEY BSc CEng FIEE FIRSE
Page 9 and 10: OFFICERS AND COUNCIL 7 Photo: Colin
Page 11 and 12: 9 Institution Announcements (The pr
Page 13 and 14: INSTITUTION ANNOUNCEMENTS 11 Head O
Page 15 and 16: 13 Institution Awards PRESIDENT’S
Page 17 and 18: OBITUARIES 15 overseen the conversi
Page 19 and 20: 17 Annual Dinner and Dance The Inst
Page 21 and 22: 19 The Institution of Railway Signa
Page 23 and 24: PRESIDENTIAL ADDRESS 21 in terms of
Page 25 and 26: PRESIDENTIAL ADDRESS 23 technical l
Page 27 and 28: EUROBALISE TRANSMISSION SYSTEM, A T
Page 33 and 34: Company Announcement Bridgen Enterp
Page 35 and 36: EURORADIO AND THE RBC 33 another wh
Page 37: EURORADIO AND THE RBC 35 communicat
Page 41 and 42: EURORADIO AND THE RBC 39 4.7 DISCON
Page 43 and 44: EURORADIO AND THE RBC 41 would be a
Page 45 and 46: EUROCAB AND THE DRIVER MMI - AN INT
Page 51 and 52: 49 Technical Meeting of the Institu
Page 53 and 54: SIGNALLING CONTROL CENTRES TODAY AN
Page 65 and 66: 63 Migration to ERTMS on Existing L
Page 67 and 68: MIGRATION TO ERTMS ON EXISTING LINE
Page 75 and 76: CTRL SIGNALLING AND COMMUNICATIONS
Page 87 and 88: INTERNATIONAL CONVENTION 85 RIC lev
Page 89 and 90:
INTERNATIONAL CONVENTION 87 case se
Page 91 and 92:
INTERNATIONAL CONVENTION 89 the sys
Page 93 and 94:
INTERNATIONAL CONVENTION 91 Connect
Page 95 and 96:
NINETIETH ANNUAL REPORT 93 see the
Page 97 and 98:
NINETIETH ANNUAL REPORT 95 THE INST
Page 99 and 100:
NINETIETH ANNUAL REPORT 97 THE INST
Page 101 and 102:
NINETIETH ANNUAL REPORT 99 Accounts
Page 103 and 104:
NINETIETH ANNUAL REPORT 101 Adminis
Page 105 and 106:
NINETIETH ANNUAL REPORT 103 Vice-Pr
Page 107 and 108:
NINETIETH ANNUAL REPORT 105 There a
Page 109 and 110:
NINETIETH ANNUAL REPORT 107 Fabbian
Page 111 and 112:
NINETIETH ANNUAL GENERAL MEETING 10
Page 114 and 115:
112 Sydney Hosts 2002 Convention Fo
Page 116 and 117:
114 SYDNEY HOSTS 2002 CONVENTION
Page 118 and 119:
116 SYDNEY HOSTS 2002 CONVENTION Co
Page 120 and 121:
118 Much Better Engineer Signal Eng
Page 122 and 123:
120 2002 Examination Results Anothe
Page 124 and 125:
THIS SPACE COULD BE WORKING FOR YOU
Page 126 and 127:
124 AUSTRALASIAN SECTION dangerous
Page 128 and 129:
126 AUSTRALASIAN SECTION to address
Page 130 and 131:
128 CHAIRMAN’S REPORT Midland & N
Page 132 and 133:
130 SCOTTISH SECTION He drew compar
Page 134 and 135:
132 SOUTHERN AFRICAN SECTION at Spo
Page 136 and 137:
134 WESTERN SECTION Scotland. (Atte
Page 138 and 139:
136 YORK SECTION The October meetin
Page 140 and 141:
138 Younger Members’ Section The
Page 142 and 143:
140 The Editor would like to thank
Page 144:
Railway Signalling… A Science or
show all

Proceedings 2002/2003 - IRSE

Create successful ePaper yourself

Delete template?

Save as template?