ROS2 DDS Security PKCS#11 URI support #319
Conversation
The DDS-Security specification 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 changes affect to the RMW implementations, as these are filling the DDS security attributes for the participant. However, it also affects the contents of the enclave directories in the keystore. Although the proposed changes are totally backwards compatible (meaning that current RMW implementations will continue working if no PKCS#11 URIS are used), description of the new enclave contents and the expected RMW behavior seems appropriate.
|
@ros2/security_working_group Thoughts about this proposal? |
|
This pull request has been mentioned on ROS Discourse. There might be relevant details there: https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2021-08-19/22008/1 |
|
To give some context, this proposal was discussed an approved on the @ros2/security_working_group on June (minutes here, although with Sid gone, they are still unmerged). |
| 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. |
There was a problem hiding this comment.
one sentence per line, and so is everywhere else. (if i am not mistaken, this is required format for doc.)
| 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. |
There was a problem hiding this comment.
I had been asked to review this PR during a recent RMW WG meeting, and I'm doing so with a bit of delay. Apologies for that.
Anyway, I think the proposal is sound from a technical point of view, and I only had a minor comment on the loading order of the security material.
| 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:`). |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
|
@Quinz @fujitatomoya @asorbini I've open #332 since I don't have write access on the repo of the original contributor. This PR can be closed. |
|
Closing based on the last comment. |
The DDS-Security specification 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
.pemfiles. This is a design proposal to support PKCS#11 URIs.The changes affect to the RMW implementations, as these are filling the DDS security attributes for the participant. However, it also affects the contents of the enclave directories in the keystore. Although the proposed changes are totally backwards compatible (meaning that current RMW implementations will continue working if no PKCS#11 URIS are used), description of the new enclave contents and the expected RMW behavior seems appropriate.