RE: Request for Authenticated but not Encrypted Traffic

["Randy Armstrong (OPC)" <[e-mail]>]

Scenario 1) A device with a trusted certificate is compromised and starts probing other devices in the network in ways that make no sense given its role.

Scenario 2) A connection from a device is established using a valid certificate that was not assigned to that device.

Scenario 3) A device is misconfigured and attempts a valid write to a PLC at a time when the configuration of the PLC should not be changing.

Basically when a factory is operational the flows of valid data have known statistical distributions and it is useful to watch for and flag activity that is not expected. This is particularly important since hacks often come from otherwise legitimate devices that have been compromised (i.e. attacks do not come from the internet directly).

One of the features of OT devices which is not that common now but will be common in the future is h/w based key storage. This means it is physically impossible to provide copies of the private keys to any third party. This would prevent any mechanism that depends on having access to all parties private keys from working. In this scenario, the only viable option is to disable encryption.

From: Eliot Lear <[e-mail]>
Sent: Friday, September 30, 2022 6:49 PM
To: Randy Armstrong (OPC) <[e-mail]>
Cc: Phillip Hallam-Baker <[e-mail]>; [e-mail]
Subject: Re: Request for Authenticated but not Encrypted Traffic

Ok. So a bit more detail, please.  For example, people are suggesting that clients report keys to authorized parties. This is a no-code solution from a standards perspective. But does it meet your members’ needs in terms of monitoring, auditing, etc?  If not why not?  For instance, what happens if one end is hacked?  Could it report incorrect keys that would be spotted in a timely fashion?

Eliot


On 30 Sep 2022, at 11:37, Randy Armstrong (OPC) <[e-mail]<mailto:[e-mail]>> wrote:

The requirement is that factory owners need to use tools to monitor network traffic to detect anomalies.

From: Eliot Lear <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 30, 2022 5:44 PM
To: Randy Armstrong (OPC) <[e-mail]<mailto:[e-mail]>>; Phillip Hallam-Baker <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Request for Authenticated but not Encrypted Traffic


Randy,

I'm not discussing backdoors, but requirements.  State your requirements.

Eliot
On 30.09.22 10:38, Randy Armstrong (OPC) wrote:

  1.  I think the key point here is that sometimes observability is a feature and not a bug.  This is particularly important in industrial/critical infrastructure.  That observability can be achieved in many ways.  One question is whether the observability itself should itself be authorized.

Putting backdoors into protocols is not equivalent to letting applications decide to skip encryption.

A backdoor is like giving law enforcement codes to break into a cellphone and hoping that they will never abuse the power or the codes will never fall into the hands of criminals. Letting applications decide is equivalent to an owner of a cellphone choosing not to lock their screen because they decide there is nothing that needs protecting.

IOW, the fact that some users might be willing to live with the risk of a compromised system by allowing for backdoors is not a reason to refuse to allow other users to make a decision send data in clear text when and only when they decide it is safe.