Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ROS2 DDS Security PKCS#11 URI support #319

Closed
wants to merge 3 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions articles/ros2_dds_security_pkcs11_support.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
---
layout: default
title: ROS2 DDS security PKCS#11 URI support
abstract:
The [DDS-Security specification][dds_security] defines the use of Hardware Security Modules (HSM) and PKCS#11 URIs as an alternative to private keys and certificates stored in the file system. Current implementation only supports these tokens to be directly stored in the file system as `.pem` files. This is a design proposal to support PKCS#11 URIs.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one sentence per line, and so is everywhere else. (if i am not mistaken, this is required format for doc.)

Suggested change
The [DDS-Security specification][dds_security] defines the use of Hardware Security Modules (HSM) and PKCS#11 URIs as an alternative to private keys and certificates stored in the file system. Current implementation only supports these tokens to be directly stored in the file system as `.pem` files. This is a design proposal to support PKCS#11 URIs.
The [DDS-Security specification][dds_security] defines the use of Hardware Security Modules (HSM) and PKCS#11 URIs as an alternative to private keys and certificates stored in the file system.
Current implementation only supports these tokens to be directly stored in the file system as `.pem` files.
This is a design proposal to support PKCS#11 URIs.

author: '[Iker Luengo](https://github.com/IkerLuengo)'
published: false
---

- This will become a table of contents (this text will be scraped).
{:toc}

# {{ page.title }}

<div class="abstract" markdown="1">
{{ page.abstract }}
</div>

Original Author: {{ page.author }}

## Scope

The [DDS-Security specification][dds_security] requires the security documents (private keys, certificates, governance and permissions) to be provided to the DDS implementation within the participant's `properties`. It defines a set of reserved properties, that must hold the URI of the corresponding document. However, it allows different URI schemes to be used. Specifically, in the case of certificates and private keys, it defines the support for:

- file scheme (`file:/keystore/enclaves/foo/key.pem`).
- PKCS#11 scheme (`pkcs11:object=MyParticipantPrivateKey;type=private`).
- data scheme (`data:,-----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEA3HIh...AOBaaqSV37XBUJg== -----END RSA PRIVATE KEY-----`).

Current RCL impementation only support the `file` scheme. Furthermore, it searches these security files in an enclave subdirectory within the reserved `enclaves` subfolder of the root keystore, corresponding to the fully-qualified path of every enclave.
For example, for the `/foo/bar` enclave, the directory structure would look like:

<root>
├── enclaves
│ └── foo
│ └── bar
│ ├── cert.pem
│ ├── key.pem
│ ├── ...
└── public
├── ...


Note that it also requires the names of the files to be the ones expected. Specifically, all certificate and key files must have the `.pem` extension. In order to configure the security properties of a DDS participant, the path of the appropriate file in the enclave directory is added as the `file` URI of the corresponding property. For example, for the private key in the authentication plugin:

dds.sec.auth.private_key = file:<root>/enclaves/foo/bar/key.pem

## Proposal

### Goals

Support PKCS#11 URIs for certificates and key files. `data` URIs are out of scope of this proposal.

### Specification

We want to keep the current keystore structure as much as possible, as this will enable to keep all the current implementation regarding the enclave management and the CLI features that help setting up the keystore. No changes should be needed to systems that do not use the PKCS#11 scheme.

The problem then is how to let the RMW implementation when we want to use a `file` URI and when a `pkcs11` URI; and how to provide the values of these URIs (i.e., the file path in the case of `file` and the token name in the case of `pkcs11`).

This can be solved if we allow for the key and certificate files in the enclave to have `.pem` or `.p11` extensions. Files with `.p11` will contain the PKCS#11 URI instead of the actual document data. Then, the RMW can be aware of the file extension and set the security property accordingly. Taking the private key in the authentication plugin as an example:

1. The RMW will look for a file with name `key.pem` or `key.p11` in the enclave.
1. If there is a `key.pem` file, it keeps the current behavior, and sets the value of the property to the path of the file.
1. Otherwise, if there is a `key.p11` file, it must load the content of the file, and set this content as the value of the property. Some check can be done at this point, e.g., assert that the file contains a PKCS#11 URI (i.e., starts with `pkcs11:`).
Comment on lines +61 to +63

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm misreading the description, but I think that the algorithm should have the key.p11 file have higher priority (i.e. be checked first by the RMW), and then have key.pem be the default, "fallback" selection.

Are there reasons for forcing the use of key.pem over key.p11 if both files are present? Maybe this approach will offer better "backwards compatibility" and avoid introducing sudden changes if the enclave material now contains a .p11 file (since the .p11 file will only be used if the user explicitly deletes key.pem)?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would make sense. I was not on the WG meetings where this was discussed. Perhaps @Quinz or @ruffsl could bring us some light

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I believe the main idea was to keep the "backwards compatibility" for existing enclaves. But on the other hand there wasn't much discussion on the loading order for pem vs p11 files. I agree with @asorbini that it would be more intuitive for me to have p11 have higher priority as it can be considered also as more secure option in most of the configurations.


With this proposal, current RMW implementations do not need to be updated if no support for PKCS#11 URIs is planned. Existing use SROS2 projects that do not use PKCS#11 URIs will continue to work with both the legacy or the updated implementation, New projects that want to use PKCS#11 URIs will fail unless the RMW supports `.p11` extension files as described in this proposal.



[dds_security]: https://www.omg.org/spec/DDS-SECURITY/1.1/PDF