On Sat, Jun 3, 2017 at 11:24 AM, Axel <svenssona...@gmail.com> wrote: > 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.
Peter Todd's https://opentimestamps.org/ seems like a good fit for this purpose. -- 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/CABQWM_BbSKN8ZRuuUd2CJEsuNug0P59JiCr28G4%3DJq-38DDFrw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
