Subject: [Secdispatch] Relevant to software lifecycle assurance

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Mar 2022 15:08:55 -0400

Let me be clear, a reputation attack is still a serious attack even if
those who are knowledgeable understand it to be false. I have not had time
to look into whether the latest purported attack is real or not. But given
that the hacker group in question specializes in insider threat (bribing
employees) and it appears likely they are a nation state actor, I won't
rule out of hand.

So allegedly Microsoft code signing keys were breached:

Soufiane Tahiri on Twitter: "Just successfully signed an assembly using one
of the #Microsoft's certificates from the #Lapsus leak.
https://t.co/EWtbpGhE6v" / Twitter
<https://twitter.com/S0ufi4n3/status/1506325204787679237>

Maybe what we need here is not a BOF after all. Maybe what we need is for
the IAB to arrange a workshop on the topic possibly jointly with other
relevant groups and for that to trigger work on multiple fronts.

Supply chain is a chain. And there is a need for improvement at multiple
points along that chain. But in many cases, the tools required are self
contained. Fixing git to provide improved traceability in the
code-development and provenance area is needed, so are better code-signing
approaches. But those are two independent tools.

On the topic of code signing, there are again two separable concerns. The
first is the nature of the assurance provided. In the 1990s, we were fully
aware of Haber Stornetta hash chains and Merkle Trees and that they were
the right approach. Their use was also encumbered by an IPR holder that was
too greedy. As a result AuthenticCode and others of its generation sign the
ZIP file containing the distribution package. Today we should be signing a
manifest of the actual code so that malware scanners can continuously
verify the integrity of the executables after installation.

A second change that is needed is to make use of threshold signatures to
perform the signatures for public consumption. Here, the work in CFRG on
FROST is required reading.

Production environments should provide audit and accountability. If Alice,
Bob and Carol are each authorized to sign a production release, it should
be possible for the software provider to determine which of them signed a
particular release even if this is not visible to the end users.

I do have fully specified, running code that is relevant to these concerns.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Mar 2022 20:52:58 +0000

*   Maybe what we need here is not a BOF after all. Maybe what we need is for the IAB to arrange a workshop on the topic possibly jointly with other relevant groups and for that to trigger work on multiple fronts.

That is a VERY worthwhile idea. Some pointers (sorry, Akamai PR’s [press release] where all I had on hand):

US Government recently had a meeting to talk about open source security, and SBOM came up a lot:
    https://www.ir.akamai.com/news-releases/news-release-details/akamai-comments-national-security-council-and-white-house-open

Also the financial industry created a group:
    https://www.ir.akamai.com/news-releases/news-release-details/fs-isac-launches-program-bolster-financial-sectors-supply-chain

One I was at is the regular CERT Vendor Meeting.  Chatham House rules, no easy link or quotes.

Maybe the authors could start thinking about that?