Timestamp canaries

[theinnovat...@gmail.com]

I was looking at the canaries, and I liked the idea of a proof of freshness with the latest news headlines. While people can't create canaries ahead of time, it is possible to conspire to modify or backdate one of them after they have been published. To prevent this, we could use a blockchain-based timestamp, where the hashes of each canary are placed within the blockchain of a powerful cryptocurrency. Something similar to these services:

https://opentimestamps.org/
http://originstamp.org/home

This way, if there ever is a interruption of canaries, followed by a court order or something forcing you guys to backdate a falsified canary or modify old ones, we will all be able to check.

[Peter Todd]

The easiest way to do this is to simply use the OpenTimestamps (OTS) git integration.
This blog post explains how:

https://petertodd.org/2016/opentimestamps-git-integration

Addiitionally, while not covered in that blog post, OTS also supports a mode
where it rehashes the git tree in such a way that an efficient, SHA256-based,
timestamp proof can be extracted later for each file. In the next release this
will be done by default, but for now you have to add the --rehash-trees option
where the ots-git-gpg-wrapper command is called.

FWIW, as of this week, Bitcoin Core maintainer Wladimir J. van der Laan started
using OTS to timestamp Bitcoin Core commits and tags.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Related issue:
https://github.com/QubesOS/qubes-issues/issues/2847

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqjSZoACgkQ203TvDlQ
MDDIihAAyu8mH1+bqRR/to4nEzEsVZGP9Y2EMx0JSc2KVN3iZ/nfsoDp1h3vbLDe
r79AZAJZVvjB6VEJCyMgqfa9ZirwT3Ri0g/9ozN9XFn3gdNt1rkz21lsW/nabtpV
P0lLoPOOcCaLWiHHXbRBa3RrntOYp1f3ReFRg0+He9QcmD8aATm43euaPZ+Y/OMb
jhskfSLu9jHh4Ef0R+wXYnjtN7FNwuccy+WuByTzmlT2BbLfjTljo4pahEaDqPKo
mkX330EhVYEXmNfTiV07MmFmYtd2/9zAWB2cZCYsv7S0dh5dc3MyGzQW+pscNyMU
JroXQOtC1JgqctQSkKVPNAiGjzrz5e+RL8K6E+xpCh8tvDNZtPbcCC5S91AsvdOj
N9cxyFFWZiOq7FVO0Wjg0Rvamm67uLFRyLYVPCNj6KeZ6wsPspU32OqCZtXkVTNW
BnGts+Ooo7Z8JW0vsHo/n3kcTYhMp40sBtl4dI1oKMrkoYR8LjM2H98wecdZKl9i
kArYv8WQzgGAFn0631Z3pPRw2g9kVkssH0vrOMuDxYCLiqFg8ImIbx0AhMtPlTEA
pGYsYrL/V2OgvjBGNFcfmtTtprY8SGUFAcIBrVZUcAH4lGntLJW8D2MSmhy+9bpy
8cbbhdqeqHSI5meVyaVahL+7GCx4/gggivvd81WdY0lVkZTjpCE=
=Oc4Y
-----END PGP SIGNATURE-----

[Innovative Inventor]

Sounds good! I was thinking of manually doing each of the canaries for now by using this:
https://github.com/opentimestamps/opentimestamps-client. Git integration can be done later.

I just used the javascript opentimestamps client to stamp all the Qubes PGP keys, Qubes Security Bulletins, Qubes warrant canaries, and Qubes ISO digests along with the signatures at my fork of qubes-secpack: https://github.com/InnovativeInventor/qubes-secpack. Should I submit a pull request with these .ots files included?

[Marek Marczykowski-Górecki]

Is there any sensible way of installing OTS client securely? There is a
chain of dependencies which are not packaged for neither Debian or
Fedora (python-opentimestamps, bitcoinlib, pysha3, ...). And since pip
rely only on https (so, integrity of its infrastructure), the only
alternative is downloading sources manually, verifying its signature
(after finding and verifying what key should really be used for that
particular package), then installing it in /usr/local or such.

And even if I'd do all that (I gave up after two iterations), then I
need to manually track updates for all those packages. Otherwise I risk
exposing my development environment for yet another attack vector. Well,
by installing ots client I do that anyway, but by not updating that
stuff, I make things easier for the attacker, because he/she could use
publicly known, already patched vulnerabilities.

I have better use for my time...

I see two solutions for this problem:
1. Package all the dependencies for Fedora (preferred) and/or Debian.
2. Make a split-gpg-like integration so those possibly
outdated/backdoored (pip install...) packages would run in separate VM
(maybe even DispVM).

I'm not sure about ots client interface, but the second approach may be
not that hard to implement.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Innovative Inventor]

I like the second approach. A quicker method (to implement) is to pass the hash by using the javascript version of the opentimestamps client: https://github.com/opentimestamps/javascript-opentimestamps on a different computer/dispVM

"ots-cli.js stamp -H 05c4f616a8e5310d19d938cfd769864d7f4ccdc2ca8b479b10af83564b097af9" That way you don't even need to give the vm access to your files.

[Peter Todd]

On Sat, Mar 10, 2018 at 07:19:11PM +0100, Marek Marczykowski-Górecki wrote:
> Is there any sensible way of installing OTS client securely? There is a
> chain of dependencies which are not packaged for neither Debian or
> Fedora (python-opentimestamps, bitcoinlib, pysha3, ...). And since pip
> rely only on https (so, integrity of its infrastructure), the only
> alternative is downloading sources manually, verifying its signature
> (after finding and verifying what key should really be used for that
> particular package), then installing it in /usr/local or such.

Yup, I agree that the dependencies are still a problem. That said, some of them
I could avoid, e.g. pysha3 is only needed if you want to verify an
ethereum-using timestamp, which is a niche case; I could make that optional.

Even python-bitcoinlib could be made optional I think. There also does exist a
python-bitcoinlib package for Debian buster (testing), although AFAIK not
Fedora.

> And even if I'd do all that (I gave up after two iterations), then I
> need to manually track updates for all those packages. Otherwise I risk
> exposing my development environment for yet another attack vector. Well,
> by installing ots client I do that anyway, but by not updating that
> stuff, I make things easier for the attacker, because he/she could use
> publicly known, already patched vulnerabilities.

Definitely an issue. You also have the problem that timestamping inherently
requires communication with the outside world - a Qubes-specific RPC "firewall"
could be a good idea here, as you suggest below.

> I have better use for my time...
>
> I see two solutions for this problem:
> 1. Package all the dependencies for Fedora (preferred) and/or Debian.
> 2. Make a split-gpg-like integration so those possibly
> outdated/backdoored (pip install...) packages would run in separate VM
> (maybe even DispVM).
>
> I'm not sure about ots client interface, but the second approach may be
> not that hard to implement.

When you say "Fedora", what exact version do you need it for? I have clients
who need RPM packages for this anyway.

Also, what's the best infrastructure to provide for this? Like, on Ubuntu I
could provide packages via Launchpad, but I don't know if there's an equivalent
for Fedora.

[Marek Marczykowski-Górecki]

On Sat, Mar 10, 2018 at 06:39:50PM -0500, Peter Todd wrote:
> On Sat, Mar 10, 2018 at 07:19:11PM +0100, Marek Marczykowski-Górecki wrote:
> > Is there any sensible way of installing OTS client securely? There is a
> > chain of dependencies which are not packaged for neither Debian or
> > Fedora (python-opentimestamps, bitcoinlib, pysha3, ...). And since pip
> > rely only on https (so, integrity of its infrastructure), the only
> > alternative is downloading sources manually, verifying its signature
> > (after finding and verifying what key should really be used for that
> > particular package), then installing it in /usr/local or such.
>
> Yup, I agree that the dependencies are still a problem. That said, some of them
> I could avoid, e.g. pysha3 is only needed if you want to verify an
> ethereum-using timestamp, which is a niche case; I could make that optional.
>
> Even python-bitcoinlib could be made optional I think. There also does exist a
> python-bitcoinlib package for Debian buster (testing), although AFAIK not
> Fedora.

Having those dependencies optional would indeed ease deployment. But
wouldn't that break the common case? AFAIK optional dependencies are not
installed by default. Maybe solvable by an entry in README file...

> > And even if I'd do all that (I gave up after two iterations), then I
> > need to manually track updates for all those packages. Otherwise I risk
> > exposing my development environment for yet another attack vector. Well,
> > by installing ots client I do that anyway, but by not updating that
> > stuff, I make things easier for the attacker, because he/she could use
> > publicly known, already patched vulnerabilities.
>
> Definitely an issue. You also have the problem that timestamping inherently
> requires communication with the outside world

Yes, that's why I mention this problem. If the package wouldn't interact
with the outside world or touch untrusted data, I wouldn't care that
much.

> - a Qubes-specific RPC "firewall"
> could be a good idea here, as you suggest below.

I guess for that, otsclient/git_gpg_wrapper.py needs to be split in
half. Any plans for that?

> > I have better use for my time...
> >
> > I see two solutions for this problem:
> > 1. Package all the dependencies for Fedora (preferred) and/or Debian.
> > 2. Make a split-gpg-like integration so those possibly
> > outdated/backdoored (pip install...) packages would run in separate VM
> > (maybe even DispVM).
> >
> > I'm not sure about ots client interface, but the second approach may be
> > not that hard to implement.
>
> When you say "Fedora", what exact version do you need it for? I have clients
> who need RPM packages for this anyway.

Right now - Fedora 26, hopefully very soon - 27.

> Also, what's the best infrastructure to provide for this? Like, on Ubuntu I
> could provide packages via Launchpad, but I don't know if there's an equivalent
> for Fedora.

I think the equivalent for Fedora is copr[1], but I haven't looked into it.

[1] https://copr.fedorainfracloud.org/

[Innovative Inventor]

Something that I think can also be added to improve the canaries is to add NIST's Randomness Beacon to the proof of freshness by adding the output of https://beacon.nist.gov/rest/record/last.xml. I realize that in most hypothetical scenarios, a government, is the attacker, but it can't hurt to add a government to the list of organizations an attacker would have to attack just to coerce a canary ahead of time. What do you guys think?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I wasn't aware of the NIST Randomness Beacon. Very interesting. Thanks
for bringing it to my attention. As far as I can tell, this looks like a
very good source for the Proof of Freshness. Would you like to submit a
PR that adds it to the script?

https://github.com/QubesOS/qubes-secpack/blob/master/utils/proof_of_freshness_generator.sh

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqt64UACgkQ203TvDlQ
MDD4qQ/9EQrr34iznVASWo801Rv22wQeDOAyPC3td2vUwWg9eQJDww6XV01jTEIf
Eq3Ta+Iy6RDR6GtAhMqy23YubT5uSwQm07lSSTZCF8thXFxlcM2iImLbalZg4942
+jsivcqYtgxxiJ93pJXOnb0ClmH4qIItI+bSoX0T47isy4yHeT/xFgJy7D6sriij
I56bsOVBuBwMUoogRvlRZ+yuHKTNWr7J2E558d+TgNCSM0hWibgHpftwyH/opF26
zbBY3HeGA3KnBMQ6Gog8gm/cIFtKs2oxK7UAoe583fCMCFMIccgKHDZa0pEOs11t
pVmYvN4mb5F/hY3Fx+A0tLSEjbKlwRj75OqfYcXmEu6wcwPiGA4XTSBVGcVQ3hta
zPrvLO6nJBuJ6qdIqV8lLJj307EIi0ZXDTDZgL0c7+WpK/Cry+lq9ma0o68ePU12
Ya8MgiTW/OZOnmkS0TOP0VSkE4LchxdxJ1Zbllba5LbY8qnAYBTLKn2jx5dmSF4t
6n+fu+SxwZ/LEFdGZqyOWdM5+euPw+RnQtBs1Vpy9QzysAsu680yFfyYNdAzq2ks
QtPaTy0e7pHrPiKze/fkP4Eqihdn7Yxsb5ZIVXgdkF6Aft5qRHCYFXGe0KlrQs5N
Q7qhwXqTCAacT3IRMHTq72u/fylPJglUGk47cQxoKIqyemWN1vQ=
=Hx4I
-----END PGP SIGNATURE-----

[Innovative Inventor]

Sure! I've just submitted a pull request. Another thing I was thinking about is adding the nasdaq/some other stock index (preferably worldwide) to the proof of freshness, as being able to predict them is impossible ahead of time and it is hard for a government to control stock prices. While organizations can be infiltrated/hacked, something that combines data from so many companies' performance will be very hard.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Mar 18, 2018 at 04:00:22PM -0700, Innovative Inventor wrote:
> On Sunday, March 18, 2018 at 12:31:13 AM UTC-4, Andrew David Wong wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 2018-03-17 16:34, Innovative Inventor wrote:
> > > On Friday, March 9, 2018 at 3:19:47 PM UTC-5, Innovative Inventor wrote:
> > >> I was looking at the canaries, and I liked the idea of a proof of freshness with the latest news headlines. While people can't create canaries ahead of time, it is possible to conspire to modify or backdate one of them after they have been published. To prevent this, we could use a blockchain-based timestamp, where the hashes of each canary are placed within the blockchain of a powerful cryptocurrency. Something similar to these services:
> > >>
> > >> https://opentimestamps.org/
> > >> http://originstamp.org/home
> > >>
> > >> This way, if there ever is a interruption of canaries, followed by a court order or something forcing you guys to backdate a falsified canary or modify old ones, we will all be able to check.
> > >
> > > Something that I think can also be added to improve the canaries is to add NIST's Randomness Beacon to the proof of freshness by adding the output of https://beacon.nist.gov/rest/record/last.xml. I realize that in most hypothetical scenarios, a government, is the attacker, but it can't hurt to add a government to the list of organizations an attacker would have to attack just to coerce a canary ahead of time. What do you guys think?
> > >
> >
> > I wasn't aware of the NIST Randomness Beacon. Very interesting. Thanks
> > for bringing it to my attention. As far as I can tell, this looks like a
> > very good source for the Proof of Freshness. Would you like to submit a
> > PR that adds it to the script?
> >
> > https://github.com/QubesOS/qubes-secpack/blob/master/utils/proof_of_freshness_generator.sh
> >
>

> Sure! I've just submitted a pull request. Another thing I was thinking about is adding the nasdaq/some other stock index (preferably worldwide) to the proof of freshness, as being able to predict them is impossible ahead of time and it is hard for a government to control stock prices. While organizations can be infiltrated/hacked, something that combines data from so many companies' performance will be very hard.

To be honest, I don't think we need more proofs of freshness there. We
already have various news headlines (chosen from different countries),
bitcoin blockchain and now NIST Randomness Beacon. What we might need,
is timestamps - proof that canaries (or other files there) were
created at the time included there, not later.

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqoeXIACgkQ24/THMrX
1yz4Wwf+KNAs3X8e/nuKZIuXBPej8dGz8mIx8x2Id+She6tbObmeUAIAYvES0MoV
ZGGVdLDvsYdwwMhCLUgPYd8C8NpMPqlAIQPsjBwvGfWko8RXmlBHVnn6IYIFQKkQ
3sOsxdMBIWYczcRKXVsw9KecdsfvGTcVjzkeq9mivzZ+X9QDPpHWa6qGFjRvNTlQ
entMh9WPo1BVk8TzhhjGE0BueOi11EJjIYQzlKfuvysdk9EF07hOi4K12HY+UR+W
x2wkhBHovkdWCpMldIUyLXId9FphuPXoPfUsYnca/nKaZPGEXAroriS6vBAnZcnn
hIxFgp+n1OPHFa7P79CQuXMRTyFQ5A==
=gke0
-----END PGP SIGNATURE-----

[Andrew Clausen]

Hi Marek,

On 18 March 2018 at 23:12, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

To be honest, I don't think we need more proofs of freshness there. We
already have various news headlines (chosen from different countries),
bitcoin blockchain and now NIST Randomness Beacon. What we might need,
is timestamps - proof that canaries (or other files there) were
created at the time included there, not later.

What about including the hashes of all older canaries in the new one?  That way, anyone trying to counterfeit an old canary would have to somehow hide all of the newer (real) canaries from the victim.

Kind regards,

Andrew

[Innovative Inventor]

I see your point there, Marek. I'm fine if you guys think we don't need another source for the proofs of freshness (we already have plenty). But, I do like the idea of adding the hash of the previous canary (sort of like blockchain) to make it impossible to counterfeit previous canaries. It still doesn't solve the problem of backdating the latest canary, but sounds like a good security feature. It'll allow us to not have to rely on a single cryptocurrency to prevent counterfeiting (what if in a few years Bitcoin is much weaker or a massive vulnerability is discovered).

The primary reason why the warrant canaries exist is to hint at a possibility that a warrant or court order was served to the dev team without breaking any laws. But, let's suppose that eventually a court rules it legal to compel the dev team to counterfeit a canary. The modification of previous canaries shouldn't be of much use to law enforcement, but the creation of fake current canaries is vital for a secret warrant to be carried out. That is why I think that by timestamping canaries, it allows the Qubes dev team to find ways to delay/legally challenge the order long enough that the canary deadline passes. Then, they can cave into the government's demands, thus informing the users and also complying with the government at the same time. This will help a lot if the dev team loses the court case.

[Peter Todd]

On Mon, Mar 19, 2018 at 12:12:13AM +0100, Marek Marczykowski-Górecki wrote:
> > > I wasn't aware of the NIST Randomness Beacon. Very interesting. Thanks
> > > for bringing it to my attention. As far as I can tell, this looks like a
> > > very good source for the Proof of Freshness. Would you like to submit a
> > > PR that adds it to the script?
> > >
> > > https://github.com/QubesOS/qubes-secpack/blob/master/utils/proof_of_freshness_generator.sh
> > >
> >
> > Sure! I've just submitted a pull request. Another thing I was thinking about is adding the nasdaq/some other stock index (preferably worldwide) to the proof of freshness, as being able to predict them is impossible ahead of time and it is hard for a government to control stock prices. While organizations can be infiltrated/hacked, something that combines data from so many companies' performance will be very hard.
>
> To be honest, I don't think we need more proofs of freshness there. We
> already have various news headlines (chosen from different countries),
> bitcoin blockchain and now NIST Randomness Beacon. What we might need,
> is timestamps - proof that canaries (or other files there) were
> created at the time included there, not later.

Not to mention, you can also prove freshness of any source by timestamping that
source and then including a block hash - timestamping makes the block hash
dependent on the freshness source, thus making the timestamp proof a proof of
freshness.

In fact, I've been timestamping the NIST Randomness Beacon output for months
now; if I make that database of timestamps public anyone could use it to prove
freshness against the NIST Randomness Beacon.