Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A Critical Command Filter Based on Critical Command Certificates

IP.com Disclosure Number: IPCOM000213634D
Publication Date: 2011-Dec-23

Publishing Venue

The IP.com Prior Art Database


A Critical Command Filter Based on Critical Command Certificates

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 01 of 10


A Critical Command Filter

Based on Critical Command Certificates


1.1 Background

Authentication is one important security objective that is important to achieve in securing industrial control systems. One way to guarantee the authenticity of actors (e.g. a device, a server or a human user) is by binding a digital certificate to them and using that certificate to sign messages. Lately, the use of this type of authenticity is even becoming popular, e.g. it is used in the IEC 62351 standard. However, the digital certificate of a device or user needs to be authenticated itself. Digital certificate standards such as X.509 do this by a chain of signatures from certificate authorities. A receiving actor must have a common trusted root for this chain in order to be able to validate a certificate. This is done by providing a so-called root certificates. Whoever knows the public key from such a root certificate will be able to validate the authenticity of the given certificates.

Upcoming standards require the use of such certificates for human-to-device communication and device-to-device communication including predefined, standardized roles, again an example is the IEC 62351 standard. This ensures that no intruder can send commands to devices or read data from them. In order to check whether a message that has been received by a certain device A is indeed sent from a trusted device B, A has to perform the following actions:

x Validate the certificate by

o Get the public certificate of B (e.g. from the message or from a directory) and checking that it is really issued to B

o Check whether the certificate of B was signed by a certificate authority chain that is rooted in a trusted root certificate

x Check that the signature of the message is still intact by

o computing the hash of the message

o decrypting the hash sent in the signature using the public key from B's certificate

o comparing the two hashes

Besides authentication (i.e. ensuring the actor is who he claims to be), certificates can also be used for authorization (i.e. determining which permissions the actor has in a given system). The standard IEC62351 is again an example. It specifies standardized "roles" for devices and humans. For each standard role, a standard set of permissions is associated. This has the advantage that a user only needs one set of certificates identifying himself and defining his role (and thus his permissions) in a given system. An actor may have an identity certificate for authentication and one or more attribute certificates for other information (e.g. roles assigned

Page 02 of 10


to him) or all of this may be combined in one certificate. Again, IEC 62351 is an example using this technology and allows for either option. This invention applies to either alternative. Also, this invention is independent of whether or not a hierarchy of intermediate certificate authorities is used.

1.2 Problem statement

The problem of using certificates in devic...