As Joanna has already noted, qubes-secpack is not advertised as solving all problems related to distribution security, but "the best we can do" currently.
I'd like to suggest a practical improvement of qubes-secpack that I believe can protect against a (rather limited) class of threats including some forced private key hand-over and insider threats. *The scheme:* The idea is to publish hashes of git commits, and maybe also of detached signatures, to the bitcoin blockchain. This will serve as a reasonable secure proof that the information was created *before* a certain point in time. In addition to the proof of freshness, this locks the information into a *narrow time frame*. Taking the canary as an example, the logic of the scheme would be as follows: Axioms: - BnBB: If X is before Y and Y is before Z, then X is before Z. - DB: If X depends on Y, then Y is before X. Assumptions: 1. <Timestamp A> is before <Proof of freshness> 2. <Canary> depends on <Proof of freshness> 3. <Signature> depends on <Canary> 4. <Blockchain transaction> depends on <Signature> 5. <Blockchain transaction> is before <Timestamp B> Argument: 6. <Proof of freshness> is before <Canary> [2, DB] 7. <Canary> is before <Signature> [3, DB] 8. <Signature> is before <Blockchain transaction> [4, DB] 9. <Timestamp A> is before <Canary> [1, 6, BnBB] 10. <Canary> is before <Blockchain transaction> [7, 8, BnBB] 11. <Canary> is before <Timestamp B> [10, 5, BnBB] 12. <Timestamp A> is before <Signature> [9, 7, BnBB] 13. <Signature> is before <Timestamp B> [8, 5, BnBB] 14. *<Timestamp A> is before <Canary>, and <Canary> is before <Timestamp B>* [9, 11, Conjunction] 15. *<Timestamp A> is before <Signature>, and <Signature> is before <Timestamp B>* [12, 13, Conjunction] In other words, under these assumptions it is proven that the canary and its signature was created in the time period between timestamps A and B. When publishing a statement to the blockchain, the statement should include the hash of the latest git commit (and perhaps also hashes of detached signatures if git hashing is not trusted). The bitcoin transaction needs only to publish the hash of this statement. After it is published, the entire statement, its hash, and the identifier of the transaction that published it, should be added to qubes-secpack in a subsequent commit. The purpose of this subsequent commit is only to provide discoverability, and technically needs no signature. Further, the only security assumed to be provided by the publication of such a transaction, is to give reasonable assurance that the statement was produced before a certain point in time. Especially, it does not matter who performs the publication or why. *Suggestion*: The instructions on how to use qubes-secpack, including the blockchain timestamping verification, should be part of qubes-secpack and be signed. *How this scheme mitigates some threats*: Suppose the developers who sign commits and distributions are forced by an outside actor to hand over their private keys. This actor could now for example attempt to sign digests of malicious images of Qubes OS and have them distributed, as well as falsify new canary statements on schedule. So far everything seems lost. Now, suppose further that some indication of this event comes to public knowledge, i.e. users begin to suspect the keys can not be trusted after a certain point in time. With the current system, i.e. without publishing to the blockchain, assumptions 4 and 5 above are not applicable, and we end up not being able to trust anything anymore. However, by adding assumptions 4 and 5, i.e. continually publishing commits to the blockchain, the signatures that were created before the adversarial event *are trustworthy despite a compromised private key*, assuming both the signature and the blockchain transaction are verified. To clarify: If a user trusts that a private key was compromised only after a certain <Timestamp B>, then that user will still be able to trust the contents in qubes-secpack verified by the corresponding <Signature>. Analogously, there may be several other scenarios in which this scheme can help, e.g. in deprecating keys. *Live example*: So I went ahead and did it. -----Begin Statement----- Today is 2017-06-03 Last published git commit of qubes-secpack is 4b1d111457f793cd97524dce2ac98cc694220f88 ---End Statement----- SHA-256 hash of Statement is ec516a47d56b0fb6346404d8e40da1c20a6630d1f02635f9b402eb9b1b69865d Bitcoin transaction 840ea8d6a71ae5415bf0efb84fb25f03cd6a1b0fa2a511133383a3477fe18601 includes as it's first output a script that ends with the hash of the Statement. See https://www.blocktrail.com/BTC/tx/840ea8d6a71ae5415bf0efb84fb25f03cd6a1b0fa2a511133383a3477fe18601 Although this particular publication was made using https://proofofexistence.com it is possible to do the same thing manually for a lower fee. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ccdb91f2-4b31-4d89-a82a-ec5b7054f955%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
