Re: [qubes-devel] Timestamp canaries
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/ -- 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? -- 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/20180310235827.GI4063%40mail-itl. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-devel] Timestamp canaries
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. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- 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/20180310233950.GA6305%40savin.petertodd.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [qubes-devel] Timestamp canaries
On Saturday, March 10, 2018 at 1:19:28 PM UTC-5, Marek Marczykowski-Górecki wrote: > On Fri, Mar 09, 2018 at 05:12:08PM -0500, Peter Todd wrote: > > On Fri, Mar 09, 2018 at 12:19:47PM -0800, theinnovativeinven...@gmail.com > > 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. > > > > 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. > > 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? 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. -- 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/f05a5171-9b64-42c4-b789-4aa6cd1b317c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Timestamp canaries
On Fri, Mar 09, 2018 at 05:12:08PM -0500, Peter Todd wrote: > On Fri, Mar 09, 2018 at 12:19:47PM -0800, theinnovativeinven...@gmail.com > 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. > > 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. 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? -- 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/20180310181911.GH4063%40mail-itl. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-devel] Timestamp canaries
On Friday, March 9, 2018 at 9:57:47 PM UTC-5, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2018-03-09 16:12, Peter Todd wrote: > > On Fri, Mar 09, 2018 at 12:19:47PM -0800, > > theinnovativeinven...@gmail.com 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. > > > > 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. > > > > 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- 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? -- 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/edcb8b7a-11b6-4d84-9266-2c1e8e2292a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Timestamp canaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-03-09 16:12, Peter Todd wrote: > On Fri, Mar 09, 2018 at 12:19:47PM -0800, > theinnovativeinven...@gmail.com 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. > > 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. > 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- -- 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/298ba99b-eed0-73ec-3e4a-40fa604403aa%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Timestamp canaries
On Fri, Mar 09, 2018 at 12:19:47PM -0800, theinnovativeinven...@gmail.com 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. 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 -- 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/20180309221208.GA4487%40fedora-23-dvm. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[qubes-devel] Timestamp canaries
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. -- 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/f81fd61d-7cb4-42b6-ba99-b55f0734afbb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
