Proceedings 2002/2003 - IRSE

EURORADIO AND THE RBC 35
communications engineers!) – what happens next?
Basically, the connection request ripples down the
protocol stack, and then the layer connections ripple
back up. So the Safety Layer passes the connection
request to the Transport Layer, which cannot do
anything until there is a Network Layer connection,
then the Data Link Layer, then GSM-R.
It is at this point there can be a problem. The onboard
application knows all about application
addresses – the ETCS-ID which when used with the
ETCS-ID-TYPE is unique in the world, safely – but it
knows and cares little about phone numbers (they
could be different from last week to this). At the
bottom of the stack, GSM-R knows all about phone
numbers, but nothing about application IDs. How is
the translation achieved?
It is possible that the application received the
number along with the ETCS-ID from a balise – the
simplest solution. It may have received it from an
RBC in an application message, but of course it
needs a connection first to do that. Another
possibility is that, as people do, it remembers
associations, in a look-up table in the Transport
layer. But if all else fails, it has the possibility of using
a feature of the network – location-dependent
addressing. As with a ‘999’ call in the UK, the
network is aware of the location of the source of the
call, and can route it to an appropriate local
destination. Similarly, a GSM network is aware of the
source’s cell, and can route the call to a pre-defined
‘most-appropriate RBC’.
So, the Safety layer requests a connection from the
Transport layer, the Transport layer requests a
connection from the Network layer and the Network
layer requests a connection from the Data Link layer
– except that the Data Link layer has no mechanism
to cause GSM to connect. So in fact the Network
layer sends the dial commands to GSM. Once GSM
has connected, the Network layer can request a
connection from the Data Link layer, ie the HDLC
Data Link layer synchronises.
Once the train’s Data Link layer receives an
Unnumbered Acknowledge frame, it can confirm the
connection to the Network layer, which sends
confirmation to the Transport layer, which confirms
the connection to the Safety layer.
4.2 AUTHENTICATION
It is only at this point that the Safety layer, on the
train and in the RBC, can start to authenticate the
end users – but why should it?
It was assumed in the design of EuroRadio that the
data may go over some form of ‘open’ network –
that is, a network where the data is not only subject
to random noise, but could also be the subject of a
malicious human attack from outside or inside the
Railway.
Authentication uses two defences. One is random
data generated at the time of connection set-up. The
other is use of a ‘shared secret’ – the ‘key’ – that only
the correct user will know. But how does the train
know what key to use? Once again, we could use a
look-up table, matching ETCS-ID against phone
number and key. But now, the look-up table must be
much, much larger. If a train does not know the
ETCS-ID or phone number of the next RBC, it can be
given this by the last RBC or a balise – but it cannot
find out the key in the same way. And the same
applies if an RBC does not know the key for a train
arriving in its area.
A process is defined in the Symmetric Key
Management specification (Unisig document
Subset064), but it should really come with a health
warning! It should not be considered a real-time
system, and is best used for a train in operation only
in exceptional conditions, and preferably when the
train is stationary – in fact it is likely to take so long
that the train will be stationary.
It requires the use of a home Key Management
Centre (KMC), which could be a PC in a locked
room. Trains only ever call their home KMC, so
interoperability is not an issue here. Only KMCs talk
directly to other KMCs. So, to take an example,
assume an English train in France does not have the
key for the French RBC:
• the train tries to set up a connection as
described above, only to find it does not have a
working key;
• it disconnects;
• it sets up a connection to its own UK KMC and
requests the key;
• the UK KMC realises the key requested is within
the control of the French KMC, and so sets up a
connection to the French KMC;
• the French KMC generates a key for use by the
train and the RBC;
• the French KMC then encrypts and distributes
the new key to the French RBC;
• when that is confirmed, the French KMC
encrypts and sends the key to the UK KMC;
• the UK KMC encrypts the key, and sends it to
the English train;
• the English train disconnects from the UK KMC,
and sets up the connection to the French RBC
and 20km down the line is the next French
RBC…
It is clear that with five connections being set up, this
is a process best invoked at start-up and in
emergencies. In practice, keys are likely to be
created and downloaded for all RBCs likely to be
encountered by a train.
While on the subject of keys, of course different
strategies are possible. The example above
assumes the ‘normal’ situation where each pair of
entities is allocated a unique key. But it would be
quite possible, in a country or area, if the safety case
allows it, to allocate:
• the same key to all RBCs and trains;
• a key for all trains of a particular type;
• a key for all trains of a particular operator.
This would overcome most of the problems. It really
depends how careless you are – if you keep losing
trains and RBCs, you need a key management
policy that limits the damage to only the stolen
equipment; if equipment is rarely if ever stolen, key