Posts Tagged ‘IEC-61066’


I ended up to the bed with IEC 61066. It is standard for the safety related systems, so I thought it could be nice standard. Oh well – it is nice example of the standard which should definitely not exist. If we have safety related item which has security related quality requirement, it should not conflict with itself. Let’s quote (p109, 14.2.3.5):

In the case where data are not transmitted via a simple electrical data connection from one device to another, for example transmission via a network, it shall not be  possible to modify, delete or add something to these data. In addition, the receiving part of the dosimetry system, for example the computer, shall make sure that the received data are authentic. That means it shall be recognised if the data come from another device than the reader assigned to the dosimetry system.

NOTE One possible technical solution is: All transmitted data are combined in well-defined data sets including date and time of the generation of the data set, a running number, an identification of the transmitting part, for example serial number of the reader, and the relevant data. The whole data set is protected by an electronic signature (CRC, at least CRC-16 with a secret start value). The receiving part, for example computer, checks the contained data by making sure that no running number is missing (or double) and that the identification of the transmitting part is the correct one.

One possible technical solution is in conflict with the requirement. CRC is insecure algorithm for signing the data. It is usable for error detection. First the problem is size. To get the correct CRC-16 value with brute force requires only 2^16 steps, which is 65536. It doesn’t take much time to walk thru all of those. Actually the easier solution is to calculate the secret start value which also takes in worst case those 65536 steps. If that is too many steps, then there is 50% change to find the real start value with only about 256 steps.

The example solution does not honor the spirit of the requirement. With the example solution there isn’t any guarantees that the origin of the data is from the original device. Much better signature algorithms are presented at [1].

I really wonder why that kind of mistake has been made. The error detection algorithm is mixed with the signature. My guess is, that the creators of the standard are professional at embedded systems and communication. They are not security experts. The standard contained cross-domain issues, which would have required also the knowledge of security. The standard creation is too often too closed so the input from different domains is not received when they were needed.

[1] Ferguson N., Schneier B.: Practical cryptography, Wiley Publishing, 2003

Advertisements