suggest storing osdp keys securely

[rsgmodelworks]

It would be nice if this used some secure mechanism (like Windows provides) to store the OSDP secure channel keys it distributes to PD's. Perhaps dotnet capabilities can provide this?

[bytedreamer]

Agreed, I'm thinking through how to securely store credentials and keys. I'll send my thoughts to you regarding my implementation ideas when I'm ready.

[jraynes]

@bytedreamer My $.02:

Since OSDP doesn't do native X.509 between the readers and the panel (that would be neat though) the only way I think you could do this is to encrypt the reader keys with a master key that only the panel has and decrypt them on startup.

Windows has a nice certificate store feature where you can create an RSA keypair with a private key that can never be exported or extracted. Encrypt/Decrypt operations using the .NET managed key object are easy enough. And you can limit key object access to the specific user account running the panel service. But this may not work well with unix platforms.

Maybe you could use the TPM library from Microsoft to store the keys in hardware somehow?

[mistial-dev]

Since OSDP doesn't do native X.509 between the readers and the panel (that would be neat though) the only way I think you could do this is to encrypt the reader keys with a master key that only the panel has and decrypt them on startup.

Maybe you could use the TPM library from Microsoft to store the keys in hardware somehow?

TPMs are good for things like key diversification, where the root (master) key is stored in the TPM and can't leave, but keys for readers can be generated. The downside to this approach is that it's still possible to do an Oracle attack, where a piece of software sends the TPM the data and gets all the diversified keys.

If that limitation is acceptable, then a nice cross-platform way to handle this would be to use PC/SC and a sim cut smart card. The card would essentially have a command to store a secret, and then a command to derive keys.

[mistial-dev]

The "meat", so to speak, of a diversion applet would look something like this:

public class DemoApplet extends Applet implements MultiSelectable
{
    public DemoApplet(byte[] buffer, short offset, byte length)
    {
        // ...
        key = new GPKey (KeyBuilder.TYPE_AES, KeyBuilder.LENGTH_AES_128);

        key.setKey (testKey, GPKey.KEY_SOURCE_DEFAULT);
        register();
    }

    public void process(APDU apdu)
    {
        // ...

        switch(apInstruction & 0x00ff) {
            case INS_GET_NEW_KEY:
                // ...
                Signature cmac = new AESCMAC128();
                short signatureLength = key.sign(cmac, apduBuffer, recvLength);
                apdu.setOutgoingAndSend (ISO7816.OFFSET_CDATA, length);
                break;

            case INS_SET_DIVERSIFICATION_KEY:
                // ...
        }
    }
}

[rsgmodelworks]

@bytedreamer My $.02:

Since OSDP doesn't do native X.509 between the readers and the panel (that would be neat though) the only way I think you could do this is to encrypt the reader keys with a master key that only the panel has and decrypt them on startup.

Windows has a nice certificate store feature where you can create an RSA keypair with a private key that can never be exported or extracted. Encrypt/Decrypt operations using the .NET managed key object are easy enough. And you can limit key object access to the specific user account running the panel service. But this may not work well with unix platforms.

Maybe you could use the TPM library from Microsoft to store the keys in hardware somehow?

[rsgmodelworks]

different topics here.

1. store the scbk securely locally to the ACU. do whatever, use CNG or something.
2. providing identities via certs or something. OSDP over TLS already specifies this. There is no concept in the 485 world of the ACU providing it's identity to the PD. You could ask a PD to talk a PIV card (i.e. support challenge/response) but in any event that's an identity management question.

[mistial-dev]

If the panel is hacked, the reader keys themselves being compromised is a lesser concern.

That being said, the ATECC608A secure element would make sense to use in terms of a relatively open way to handle cryptographic material. It's included (for example) in the Iono Pi Max.

It can store up to 16 keys. While that's not enough to store everything one might want, the device does have ECDH, as well as multiple KDFs. It's not the fastest, but it can be used to (for example) unwrap or re-derive secure channel base keys, leaving them encrypted at rest.

This should work fine with PDs, as the PD can be identified prior to running secure channel.

[mistial-dev]

One option that might make sense would be to use PKCS11 for key management operations. It's designed to talk to tokens, and it opens a lot of flexibility.

For example, ykcs11 allows a yubikey to be used. CryptoAuthLib (used for the ATECC608A) can also be configured to provide pkcs11 services.

http://ww1.microchip.com/downloads/en/Appnotes/Getting-Started-with-AWS-Greengrass-on-SAMA5D2-Application-Note-DS00003170A.pdf

OpenSC also has their pkcs11 driver, and it supports https://github.com/philipWendland/IsoApplet , allowing a javacard to easily become PKCS11 compatible. They support Mac and Windows.

If someone wanted to use a higher-end HSM (like something made by thales), they will support that interface as well.

The PKCS11interop library is permissively licensed and handles a lot of the abstraction necessary to use the interface.

https://pkcs11interop.net/

"is compatible with .NET Framework 2.0 and higher, .NET Core, Mono and Xamarin is supported on Windows, Linux, Mac OS X, Android and iOS is supported on both 32-bit and 64-bit platforms is open source and completely free for commercial use is used in production by several information security and financial organizations uses 100% managed and fully documented code"

[mistial-dev]

One of the other nice advantages to using pkcs11 is the capability to retain unit testing functionality in a reproducible manner.

SoftHSM is a well-maintained codebase, and supports using sqlite3 as an underlying database store. This makes it possible to export and import data, allowing for "destructive" cryptographic operations to be unit tested, and operations to be pre-calculated with known keys and (if appropriate) IVs for comparison, then distributed for testing by other individuals. https://github.com/opendnssec/SoftHSMv2

[rsgmodelworks]

OSDP offload would need to offload AES 128 operations. If the pkcs11 solution does that then sure. PKCS11 solutions that only work with dual-key cryptography (RSA, ECC) won't work.

I agree some sort of offload mechanism, possibly PKCS-11 based, would be useful.

[rsgmodelworks]

The ATECC608A does not seem to do AES-128-CBC. It appears to do AES-128-GCM, which is nice, but OSDP does not at this time use it (it has been suggested, using a new set of SCS headers. )

[mistial-dev]

It’s too slow to do offload, but it can do kdfs and wrapping just fine.