Subject: Re: [T2TRG] [lamps] [EXTERNAL] using/building/standardizing HMS-LMS infrastructure

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Nov 2021 11:34:57 -0500

{I screwed up t2trg, put it at @ietf.org, which is wrong}

Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
    > This is also a concern that I share. (but admit that I'm not familiar with your draft)

    > TL;DR: we've been modelling state re-use as full key compromise. Would
    > love to get that double-checked. Failover and human error are my big
    > concerns.

re-use is full key compromise?  I find that surprising, so I'll go read more.

    > My (admittedly non-expert) understanding is that state reuse means
    > reuse of a one-time signature leaf key, which will allow signature
    > forgery of any bits where the two signed messages differ. If you sign
    > the identical message twice, no biggie; if you sign the bitwise inverse
    > message then you've essentially leaked the entire private key of that
    > leaf node. I don't know the HSS-LMS construction well enough to know if
    > leaf-node (aka state) reuse can even be detected by the verifier. This
    > is a question best answered by @ScottF.

Ah, I see.

    > I share your morbid fear over deployment concerns. Particularly I'm
    > worried about sub-points of your #2:

    > 2a) Multiple copies of your signing infrastructure running in
    > Active-Active mode (ex. multiple IoT manufacturing facilities). Maybe
    > the answer here is that in an LMS / XMSS world, each site needs a
    > dedicated key (aka intermediate CAs, I suppose).

I think that this could make sense.... assuming one uses a CA structure.
If we were using LSS-HMS for IDevIDs, then there would be more of an issue.
I think that a cross-network locking protocol (with human override) is
probably acceptable for firmware signing.   I think that each product line
ought to have it's own key, and I don't think that people sign firmware more
than once a day.... maybe the high-speed DevOps people, but there are other
issues there.

    > 2b) Disaster site failover; your active site gets hit with a tornado
    > and loses power. No worries, your fancy DNS starts re-routing traffic
    > to your DR site within milliseconds. No matter how quick, there is the
    > potential that an object was signed and published in the time between
    > the last HSM sync and the power failure.

Exactly.

    > 2c) Human error on operations like a backup restore, datacentre
    > migration, onboarding new HSM hardware, etc. Datacentre engineers are
    > not cryptographers. Write the SOP in sanguine ink if you want, but I
    > bet someone somewhere will bungle this. Given our assumption that state
    > reuse (if the signature is published) is key compromise, then even
    > running your automated sanity tests after restoring the backup, but
    > before syncing, it could be disastrous.

In particular, if your signing machine is a virtual machine and it's subject to
snapshots, then it's really really easy to take a hardware fault, restore to
snapshot and think it is all well.

    > The only "provable" solution that I've heard about seems to be making
    > your private key so large that you can afford to give each instance its
    > own subtree -- ex. using an ID-prefixed index, for example. It does
    > mean that at keygen time you need to know how many instances you'll
    > ever need.

There is a planning document here.  Is this an IETF job to write it?
ISO17000 series is, apparently, about the audit process for examining
infrastructure like this, but, I'm not really sure... because my eyes glazed
over trying to understand it.  I came across it while trying to find
specifications that proscribed root-key ceremonies for enterprises.

    > Though I suppose this does not address the human error point
    > if you forget to assign it a unique ID. Needless to say, despite many
    > conversations with people who try to convince me otherwise, I remain
    > skeptical about the deployability of stateful hash-based signatures.

I share your concern:  I think that if we can get some good examples out
there, then maybe we can overcome the issues.
Perhaps someone like RIPE, ngi.eu creating a poor-man's HSM.
(air-gapped RPI4 with webcam to read QRcode of thing to sign, eInk to provide
result?  the crypt.tech people have become quiet, but that might be pandemic)

Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
    > Another option which I think is not politically popular (see NSA
    > presentation at LAMPS 112 and following mail list discussion) is to
    > hybrid your LMS / XMSS key with Ed25519; while it does not solve the
    > state-reuse problem, it would buy you time to deal with the
    > consequences of mis-managing your state.

Even if we assume a hybrid key, we still have to manage the LMS part, right?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 11 Nov 2021 17:19:55 +0000

About ID-prefixed state index that would allow safe parallel use of a key, I have not seen any kind of public spec (I thought I had seen the idea in a public paper or mail list, but don't think I'll be able to find it).
Without revealing my sources, I'm aware of some HSM and crypto toolkit type companies that have proprietary versions of this. Your licensing and patent mileage may vary.

---
Mike Ounsworth

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: November 11, 2021 10:35 AM
To: Mike Ounsworth <[email-masked]>; suit <[email-masked]>; LAMPS WG <[email-masked]>; [email-masked]; Scott Fluhrer (sfluhrer) <[email-masked]>
Subject: Re: [lamps] [EXTERNAL] using/building/standardizing HMS-LMS infrastructure

Ah, I see.

ought to have it's own key, and I don't think that people sign firmware more than once a day.... maybe the high-speed DevOps people, but there are other issues there.

Exactly.

    > before syncing, it could be disastrous.

In particular, if your signing machine is a virtual machine and it's subject to snapshots, then it's really really easy to take a hardware fault, restore to snapshot and think it is all well.

There is a planning document here.  Is this an IETF job to write it?
ISO17000 series is, apparently, about the audit process for examining infrastructure like this, but, I'm not really sure... because my eyes glazed over trying to understand it.  I came across it while trying to find specifications that proscribed root-key ceremonies for enterprises.

    > skeptical about the deployability of stateful hash-based signatures.

I share your concern:  I think that if we can get some good examples out there, then maybe we can overcome the issues.
Perhaps someone like RIPE, ngi.eu creating a poor-man's HSM.
(air-gapped RPI4 with webcam to read QRcode of thing to sign, eInk to provide result?  the crypt.tech people have become quiet, but that might be pandemic)

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Thu, 11 Nov 2021 18:07:10 +0000

Hi Michael, 

One answer to 

> I don't know the HSS-LMS construction well enough to know if
> is a question best answered by @ScottF

No unless the verifier has both signatures to detect it. 

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Michael Richardson
Sent: Thursday, November 11, 2021 11:35 AM
To: Mike Ounsworth <Mike.Ounsworth=[email-masked]>; suit <[email-masked]>; LAMPS WG <[email-masked]>; [email-masked]; Scott Fluhrer (sfluhrer) <[email-masked]>
Subject: RE: [EXTERNAL] [lamps] [EXTERNAL] using/building/standardizing HMS-LMS infrastructure

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

Ah, I see.

Exactly.