Using CryptoStick as an HSM

[Trishank Karthik Kuppusamy]

Mozilla maintains a wide range of services which are secured using different solutions.  For internal repositories, our Operations Security team has chosen to use the low-cost, open source and open hardware CryptoStick from the German Privacy Foundation.

https://blog.mozilla.org/security/2013/02/13/using-cryptostick-as-an-hsm/

[Tony Arcieri]

We use Yubikey NEOs and NEO-ns for a similar purpose at Square. I like the Yubikey aesthetics better though ;)

https://www.yubico.com/products/yubikey-hardware/yubikey-neo/

On Sun, Mar 29, 2015 at 11:29 AM, Trishank Karthik Kuppusamy <tris...@nyu.edu> wrote:

Mozilla maintains a wide range of services which are secured using different solutions.  For internal repositories, our Operations Security team has chosen to use the low-cost, open source and open hardware CryptoStick from the German Privacy Foundation.

https://blog.mozilla.org/security/2013/02/13/using-cryptostick-as-an-hsm/

--

Tony Arcieri

[Trishank Karthik Kuppusamy]

On 29 March 2015 at 14:47, Tony Arcieri <bas...@gmail.com> wrote:

We use Yubikey NEOs and NEO-ns for a similar purpose at Square. I like the Yubikey aesthetics better though ;)

https://www.yubico.com/products/yubikey-hardware/yubikey-neo/

Ah, good to know! Some of us here (especially Vlad) have been playing with Yubikeys too. I agree that the Yubikey looks better :)

What has your experience been with these USB sticks? How often do you sign with them?

[Tony Arcieri]

We mostly use them as a second factor right now.

Not many people are using them for signing or encryption but it's something we'd like to do more of

--

Tony Arcieri

[Trishank Karthik Kuppusamy]

On 29 March 2015 at 14:59, Tony Arcieri <bas...@gmail.com> wrote:

We mostly use them as a second factor right now.

Not many people are using them for signing or encryption but it's something we'd like to do more of

Cool, definitely let us know later!

[adam....@motorolasolutions.com]

We are looking into using Yubikey to hold the root key and it would be nice if a dev/release manager could use the Yubikey to sign using a delegated targets file.  I've also been thinking it would be nice to store the targets keys in a cloud HSM where we could run a CI/CD pipeline.

The current issue with a single root key that must be kept offline is that in a development environment where we are creating signed collections frequently, it is not pragmatic to track down somebody with a root key and ask them to sign for you.  It would be preferable to have a hierarchy of root keys with a top level root key used only to sign over an on-line root key, similar to a PKI model with a root CA and issuing CA.  This way developers can have new targets key generated automatically (for example, triggered by creating a new repo in Git).  The offline root could be used to recover from a compromise of the online root key (which should be low risk if on-line root is in HSM) or be used to rotate the online root key.  

Notary is beginning to experiment with such abilities.  It would be great if TUF could do similar in the core spec.

[Justin Cappos]

Why can't the targets role (which is trusted to attest to the correct package content) be used instead?  I do not understand why your CI/CD environment would use the root key.

[Vladimir Diaz]

I think Justin is suggesting that the Targets role should perform a delegation to some role A, where A can be signed with an online/HSM key and the top-level Targets role continues to use an offline key.

--
vladimi...@gmail.com
PGP fingerprint = ACCF 9DCA 73B9 862F 93C5  6608 63F8 90AA 1D25 3935
--

On Wed, Oct 19, 2016 at 2:04 PM, Justin Cappos <jca...@nyu.edu> wrote:

Why can't the targets role (which is trusted to attest to the correct package content) be used instead?  I do not understand why your CI/CD environment would use the root key.

[Nathan McCauley]

Due to TUF not having any native support for private repos, in any scenario where private repos are needed a new TUF root must be created per repository. Thus, whenever a new repo comes around the shared offline root key is needed. In Docker, we share the root key among all of an organization's repos and we allow folks to keep it in hardware in a Yubikey.

It is often the case that there is a new TUF repository per git repository, so any time a new git repo is added to a CI system there is a need to utilize the root key.

[Trishank Karthik Kuppusamy]

On 19 October 2016 at 15:35, 'Nathan McCauley' via The Update Framework (TUF) <theupdate...@googlegroups.com> wrote:

Due to TUF not having any native support for private repos, in any scenario where private repos are needed a new TUF root must be created per repository.

We are planning to introduce support for private repos in TAP 4. Please see the following comment for more details:

https://github.com/theupdateframework/tuf/issues/361#issuecomment-251902688 

[Adam Lewis]

Hi Justin,

It might be more the way Docker implemented Notary than a TUF issue (thought I'm not sure).  But in Docker/Notary there is a targets key PER repository.  So as developers, we are creating micro-services, and each micro-services will be its own image and thus its own Docker repo.  So each time we develop a new micro-service, we'll need a targets key, which requires the root key to be manually brought on-line.  If there could be a subordinate root key, or delegated root key that cloud live online, the the CI/CD pipeline could automatically request a new targets key be generated when a new repo needs to be created for a new micro-service.

Does this make better sense?

tx!
adam

On Wed, Oct 19, 2016 at 1:04 PM, Justin Cappos <jca...@nyu.edu> wrote:

Why can't the targets role (which is trusted to attest to the correct package content) be used instead?  I do not understand why your CI/CD environment would use the root key.

[Justin Cappos]

Okay, this helps me to understand.  This is more an artifact of Notary's implementation / use than TUF itself.  (I spoke with the Docker security team at the Docker Distributed Systems Summit a few weeks ago and we discussed this issue.  I hope we can find a secure solution within TUF's design that meets all of their deployment constraints.)

One thing you could do is have the targets key serve in the way you want to use the root role.  You could delegate from the (online) target role to your newly created per instance CI/CD key.  To be frank the security benefits here are not huge over using the root key because you still have a key stored online (a targets key) that is trusted to say which images should be installed.  Also, while this works without changes to TUF / Notary, it does make your repository publicly visible.

As Trishank mentioned, we believe that TAP 4 may help to address this issue in a better way.  You can have a separate file that sets separate roots of trust (e.g., to a private repo) for the docker container.  Your new CI/CD instance could have its own separate root files, even while having some parts of your namespace served from public sources.  

This is a good prod for us to talk in more detail with Docker's security team to find a clean resolution. We'd be happy to include others on this thread in the details of how to if they'd like to be pulled into the deep details of how best to make this work...

Thanks,

Justin

P.S., Earlier today we demonstrated a variant of TUF that is being strongly considered as the new standard for how to securely do over-the-air updates for the automotive industry.  Apologies, but I have been distracted with this demo and related travel.  I'll be ready this weekend to rekindle discussions about the pending TAPs, including TAP 4.

[David Lawrence]

One thing to consider may be whether it makes sense to treat a notary/registry repo as containing the suite of micro-services required to deploy some larger server. It’s kind of just the status quo that people put a single image type (i.e. redis) into a repo. It’s not a hard requirement by any means.

On Oct 20, 2016, at 11:33 AM, Diogo Mónica <diogo....@docker.com> wrote:

---------- Forwarded message ----------
From: Justin Cappos <jca...@nyu.edu>
Date: Thu, Oct 20, 2016 at 11:28 AM
Subject: Re: [tuf] Using CryptoStick as an HSM
To: Adam Lewis <adam....@motorolasolutions.com>
Cc: "The Update Framework (TUF)" <theupdate...@googlegroups.com>, Tony Arcieri <bas...@gmail.com>, Diogo Monica <diogo....@docker.com>, Toto Core <toto...@googlegroups.com>

Okay, this helps me to understand.  This is more an artifact of Notary's implementation / use than TUF itself.  (I spoke with the Docker security team at the Docker Distributed Systems Summit a few weeks ago and we discussed this issue.  I hope we can find a secure solution within TUF's design that meets all of their deployment constraints.)

One thing you could do is have the targets key serve in the way you want to use the root role.  You could delegate from the (online) target role to your newly created per instance CI/CD key.  To be frank the security benefits here are not huge over using the root key because you still have a key stored online (a targets key) that is trusted to say which images should be installed.  Also, while this works without changes to TUF / Notary, it does make your repository publicly visible.

As Trishank mentioned, we believe that TAP 4 may help to address this issue in a better way.  You can have a separate file that sets separate roots of trust (e.g., to a private repo) for the docker container.  Your new CI/CD instance could have its own separate root files, even while having some parts of your namespace served from public sources.  

This is a good prod for us to talk in more detail with Docker's security team to find a clean resolution. We'd be happy to include others on this thread in the details of how to if they'd like to be pulled into the deep details of how best to make this work...

Thanks,

Justin

P.S., Earlier today we demonstrated a variant of TUF that is being strongly considered as the new standard for how to securely do over-the-air updates for the automotive industry.  Apologies, but I have been distracted with this demo and related travel.  I'll be ready this weekend to rekindle discussions about the pending TAPs, including TAP 4.

On Wed, Oct 19, 2016 at 6:32 PM, Adam Lewis <adam.lewis@motorolasolutions.com> wrote:

Hi Justin,

It might be more the way Docker implemented Notary than a TUF issue (thought I'm not sure).  But in Docker/Notary there is a targets key PER repository.  So as developers, we are creating micro-services, and each micro-services will be its own image and thus its own Docker repo.  So each time we develop a new micro-service, we'll need a targets key, which requires the root key to be manually brought on-line.  If there could be a subordinate root key, or delegated root key that cloud live online, the the CI/CD pipeline could automatically request a new targets key be generated when a new repo needs to be created for a new micro-service.

Does this make better sense?

tx!
adam

On Wed, Oct 19, 2016 at 1:04 PM, Justin Cappos <jca...@nyu.edu> wrote:

Why can't the targets role (which is trusted to attest to the correct package content) be used instead?  I do not understand why your CI/CD environment would use the root key.

On Wed, Oct 19, 2016 at 1:01 PM, <adam.lewis@motorolasolutions.com> wrote:

We are looking into using Yubikey to hold the root key and it would be nice if a dev/release manager could use the Yubikey to sign using a delegated targets file.  I've also been thinking it would be nice to store the targets keys in a cloud HSM where we could run a CI/CD pipeline.

The current issue with a single root key that must be kept offline is that in a development environment where we are creating signed collections frequently, it is not pragmatic to track down somebody with a root key and ask them to sign for you.  It would be preferable to have a hierarchy of root keys with a top level root key used only to sign over an on-line root key, similar to a PKI model with a root CA and issuing CA.  This way developers can have new targets key generated automatically (for example, triggered by creating a new repo in Git).  The offline root could be used to recover from a compromise of the online root key (which should be low risk if on-line root is in HSM) or be used to rotate the online root key.  

Notary is beginning to experiment with such abilities.  It would be great if TUF could do similar in the core spec.

On Sunday, March 29, 2015 at 2:05:15 PM UTC-5, Trishank Karthik Kuppusamy wrote:

On 29 March 2015 at 14:59, Tony Arcieri <bas...@gmail.com> wrote:

We mostly use them as a second factor right now.

Not many people are using them for signing or encryption but it's something we'd like to do more of

Cool, definitely let us know later!

--

Diogo Mónica

[David Lawrence]

Actually, further to that point, when I released the official notary server and signer images, the official image maintainers actually required me to put both those images in a single repo as they collectively represented the notary service and they thought it would be more confusing to users to break them up.