Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
OpenXT recently added TPM2 and forward seal (pre-computed PCR) support, currently in release candidate status. This page has links to the relevant source and tickets, in case it's useful. We found some device hardware quirks. Questions/feedback welcome. https://openxt.atlassian.net/wiki/spaces/DC/pages/81035265/Measured+Launch Rich -- 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/9F0378D3-2C38-4F36-9B17-BC6B55E04EE5%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Patrik, > I've opened a pull request [1] to the AEM repository. > > Again, enormous thank you to Rusty Bird for being a wonderful GSoC > mentor and helping me clean up the patches for submission. Thank you for not going crazy from my nitpicking! I encourage all AEM enthusiasts to review the code, and/or build the packages and test them (on Qubes R4.0rc1 or later). And of course post any feedback, either here or on GitHub, even if it's just "it works". Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZnD76XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfn1UP/3F/L5leJMGIUxTa9U7EpQDm 2MOCP0rF5Mrfacq5a/mC1ZC8bInFNTpO85MACSq6pp7TSPZCGsCWLymx05dguuIL UceeW70dZQI350T/wdYuUxtZLQNUfdIgzSm9kRJFEbe7Tt3WM/aSZTWas2WIoEAP 1pm/g41+vWZ5iPQXahcrpX45Of7ldqD4W+pS4/wlnw9mdqFWQfbDPZFWf4QRaMTu f/FhoyE7yH0Z25J7CBlpwbz740r8M1+VYrkh0sEA3Wvp1gev5/BCYlgxatVal+kG ikLzNuMPIcnPbTc6zuyQ/Kr3FmprHPHg6Q2Le/YyQqVwiSrv0OAFGjD9Bw9gtaoJ 6sUfdY0hhBZTX6eTCgyU2fdizgJ9xR0TB+nBjp3PASoo7EzLq1LpgcpXqXbnvREg msKGf5Ex23yw69qHUTHu0EC9Nxu622M4RnSNYv93bJouY7pjSTIcr/q5SfyNmCrY rUtCIL008GFzyHNcnlRv4v/KlZC5E1vgfX03dEnWl4UyA1hLsoXcUX+U8f2VkWLJ DXbOxZfi8v5VMUd2AHRJM7s6yd0wuvTpARPmTb+GqzGpKSett6keQdoA8kN7MpO3 OUD9wn5LoM4oLg2rjP2HZSQVBOpY8DW1t4MgSgf06VUnFv5fC/n5n8Hc4wMO5JHX Cc3rVHxjIxlzIQR5oQT2 =fcPT -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/20170822142602.GA9718%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, I've opened a pull request [1] to the AEM repository. Again, enormous thank you to Rusty Bird for being a wonderful GSoC mentor and helping me clean up the patches for submission. You are awesome! Cheers, Patrik [1] https://github.com/QubesOS/qubes-antievilmaid/pull/20 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZnDJDAAoJEFwecd8DH5rlK5IQAMKSh+6fRkOVjwVGUZoRRagv a7GY/7kJ2T7ZCkMf6Nlv9/PEndhOa6ZGNKXbVvqv4pX1/3z1g8MngOXDTQP73OvL pHS4WDMpZkWkTfjaK07ihpehxbggu/jOfvfUf8wyRFj1PnLn3pdsbM/BqRKdXFcc Pr8boZ/KAE32+MUEaT4I9LcHmGn3mBxAA6hiYUGQlWKqRIiNhBL9912Fj4bjQjRk YWh5kfigbKLx8gU5+UdfknwMMZhLDWWzk5KGZBFGIen8XJJRYPVrFLxiOxweMyxD aTh7jTpTYVlHkdpqrq9mSz9nr//0FC3ImytFjXvZK8MH/gqrfm1y87LyUL0laSj3 QmKBc81s23xTKrLW7oSvul1M+c4M7o2pxn5puJnZJhpWya6bfz8pEu4uCRVAMu9Z jOyIF6IWMkBVocJaaZ2lSGmgNYlCnb1DYJ0wsUQktgtSEgSzxmUdPtqBuAdQn9+g R9zYE1dzbyyY/4od7vekMeMMWRgaGawgHeLJv+qcROi9FYHvVWh1MIX+jaCyjFn+ XE73ewrdWcbtavAP0L+ds2QVw21QFBe+ASbiIZlmvyt1n3evFdvWVdsuDv89feyF negiOWJE1sqpK4ytA53V0oBYKwS41KZlwn8WVgrdjY4qgbvTRcRuiM92Xzd0qDXk jqBslNFhUNybfmtLSKZv =RKId -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/4b9875ee-2b66-c2be-d157-19a6e53043d6%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/16/2017 05:51 PM, Rusty Bird wrote: > Patrik Hagara: >> Rusty: do you think it's ready to be built and pushed into R4 >> testing repos? > > Almost ready IMO. I have some more line comments, can you open a PR > on my qubes-antievilmaid fork? (Just so that I'm able to insert > comments into a flattened view of all commits.) Done. Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZlHFLAAoJEFwecd8DH5rlUZcP/j5pwQP3qz58K7HxmRK8vntr /5XDDSbOPESCB12Li81Cg+OTeL+Ble9G1h+okhA0KFTV7Ho8XteFc8VJq0papG4f Fl8VUjzJHVMbkFNpiW6v3A0sQiCcKIrkWLfB2bCw57qLiJLH9DGiO5utoIJ9/UzB Qiypi+fqoOnxwy5FwS/pZmN+m2WA0vgheqlTBs3u9Bekyy3Ev0usy4DgLBKFBbo4 BIrM5RcMUTvlqFySY/2U9xxrTMOFtrn1v/wxeWSzdEOWJp3eed30c/R5SaWObHhI lvWRBlW/vDUsDOygThaqxi44RlFb44YV1wTnL4t4o9KE3v92MyJNygYBozW6n0RM gPPyX9kzAp8U+u+AfCVIOY0Pat3jmKbtKsIx633Zs6Umpx3ahsXYXy0hjMwjLIm1 dXbAWxMR0xKmiqaGFTFe8mV6Vl7UL2+v61B/qGk8pIg6XVKLwJvbBB9NqpCi0MP6 3pD+OaMsA4xXV9hAXohPO61akJp+oiOaYqeeAyHDQ7CnLd9nWx1u4LrwpPjvV7cn yO1v+FXYQIkvH3qIEtDxNV1rEXRYwU07+IVzuak6KUt4sdqLeFY98Ha5F/N+UpqJ D81nshtPhXNkhmpE0XSMlZv6dwKAVeNCaJngn78YQRsChqFI/SUEnQKAAm6A5yoj zxtAcs5ON9MAKa3K4tUA =dSQp -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/0e409758-fefc-0400-21be-09104717cbeb%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > I've updated the README a bit [1] to (hopefully) make some things > clearer. Also added a section on how to recover from compromises. > > Rusty: do you think it's ready to be built and pushed into R4 testing > repos? Almost ready IMO. I have some more line comments, can you open a PR on my qubes-antievilmaid fork? (Just so that I'm able to insert comments into a flattened view of all commits.) Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZlGn/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf7HAP/AwBCZ8ulOeKusfyxi2euc8w 8XThhrzzPpmzXqi73v8HOrXxrn99Yq+4JQ5w7AVSNFwmkTMkeSTgPk/qPseo1JCX eaVMPwfzRTU6cWviZrsNpIth/5A73hke4eux3UivQqQkJjEzzNggxL4d2j3V/gL4 XcJJ/TS/DA1m3YsyyNdd4iDIujMQoZmikkt+JxHorhPoAWBEZd1CaBPrHgZwWLAa lAf3PIihZtzrigd/aG6m03lhuhdUhfKxJU3vIIlnYVLD0D2LjNDHOvXMjmxsKTn+ sIaMsKYS7tWDlfazHavAo8xZFylh5fYQFhLWkaJwNAzHEenb8YF56A/R30uM5cNH E2tIvBewdyepkDNf/ajVAy1Qs9Fm3fMyOKBMurY/X6H3vCCUOyXJn0lmD6N/cCJK d0caNybEFU3V1QscIxUKAjodmqkeb16hJ1aQeEuBksN88dGQOmCKes0Ugv8HNAd/ hf28Ym4lQSwcI3mzlXpW02Lr1oY+NjWOUrDiJJmr3W3Kr73BiTH4U5iP6WYaWFB+ Ur9+Td9hUvw4MT8nOy3S+R9iLfC0POP/O3vfEe8U//PqJBvd5qrXkpdrg/dCxaq5 Iu2IbzwJrFke5e6563u8pcMxTAGg0ZNzUMPYLGAt3lIodBv3VYl4Gd5PaRcvHjo4 bzuKt1THhtNrnj2mtK7/ =XIQ/ -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/20170816155127.GA18510%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! I've updated the README a bit [1] to (hopefully) make some things clearer. Also added a section on how to recover from compromises. Rusty: do you think it's ready to be built and pushed into R4 testing repos? Cheers, Patrik [1] https://github.com/phagara/qubes-antievilmaid/commit/11f518fce62aa6f962b 894094ef129b86dfbc6ae -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZlEIwAAoJEFwecd8DH5rljAQQAILfYkrbnZKxbsBy3MCMtaL6 cv1ARFZuR0307aMK3HO1Xe62rjQZsgcVSaM9RfjVkqCS8MQgzpAPRgJkeQvwXg4y eMpX/ST9muu9hgkNPcg2/x6BxViOTvS+ZChKH0H6PSxOleWx0ZPWo2C7eno/8Aib 6GRTCEsan88ElyloZLcPbDaTMrbgpo1ytFMwFcMhlgXaAL8S3sgWgKZc9QY6O1qL Mi9Sv027ZEtKgOt11gp8p+ZPqpJpxRGaZ8EPJtLgV4vNAUOkWELieJkuOinWTe9s qm/qJYFka9VYJg4VnODDvius6PMaZ2DzJDgY0vvkRqVqKNiD/8xNpQZHsRLfXJHD bb19s7rGQA3BGTFoUrt747LE6eWiMmOkbOQcB238RFbn1tQLk9tFFa4X17s5yQDt VvFHfWUflCtvcuWZP+cwJE0mZW5YMhP8STmZtxfwIi40wn2bUpgL3EZ2wQnDeHn1 Mw88vyuKRm0EKAFbwaZ3V8KaSQSsM7JUQ+Cx7zS4akBc/JNEYIzfj7+XkEb63yrB 9MPqbkdVGuuELju1K7U8VtwsrCWNxIOCtn22qa2N+XxmvtSHUFAIuWiD98OfnjMH vEaSUL8T/6si2FaTc8thKwyqx+eeWv92Tf8fydWnSoWHtxw3fqyEv328luH9H3Zj WqUPW6lglqGcXfAF0AJO =dwkX -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/e27a1c5f-48c7-f76d-deaf-81ffc6433aa6%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/13/2017 07:28 PM, Rusty Bird wrote: > Patrik Hagara: >> Finally managed to track down why unlocking disk with unsealed >> and decrypted LUKS key file didn't work on a clean Qubes OS >> installation. > >> While starting to develop this feature, I added the key file path >> to my /etc/crypttab and had forgotten about it. Fresh Qubes of >> course didn't have this change. Combined with one weird systemd >> incompatibility (the B point in this [1] forum post), it had >> caused the key file to get completely ignored. > >> There are two ways to work around this issue [2], neither of >> which is perfect [3]. Both solutions' downsides are pretty >> insignificant and most likely not applicable to 99.99% of >> existing Qubes OS installations. > >> For now, I've decided to go with the second option (ignoring >> crypttab even for hostonly dracut setups). > > So, to summarize, rd.luks.key works in both hostonly and > non-hostonly mode now, with this change? And > rd.luks.options=discard (instead of rd.luks.allow-discards) does > too? If so, that seems very reasonable. > > Rusty > Haven't tested the discard option yet as my 4.0 rc1 is on a HDD for now but yes, that should work too. Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZkJdfAAoJEFwecd8DH5rlD8YP/2qug04xgTQzArQ/Hy1Xu9EA Mu/eEscytBWnl19ej9VcmuZwOjfwhrAOo+LPJKJf3nETGB9Nn4TxXOyVmsjk9eod WOaCQ6C/75HXxTD21KiiBhAOCZjiRm8fCSvFeUq7D9T/lx5hRazeWgWiDjD+6TqX QvmPdsSwyJC3G73yDAJexF5Uii8zSj0WI3+8Crpl/xCK+TPGpjXlbeWXfmZZbEAc JXNHel/PYKR3Rk35QmH2iFQeL3RtgzaxtIXPVhFXBhuNC0YU5xSpy8Z6A8BvSEkb s9Ie9De1mDjO3TCdTeJorqBSX1VgsLUXnxAISy/2fq+5VcOG/fYLA2Lw2HflzFJ8 Rwx07Y0VwWHiGQb1jHTSpnPIWEXtDVAxmoSz8rdE4cNOHHyBoLEGfXBGOewsgfjG cQhTsBpqmENDGTMrVn92ojOpS3BrlZg6vdObhZV18FS2WBXxGRxq0fdkVaBPYbZJ eYZrw8SodjlnSMzZaTFoFvh5v8OPh4CAlIVACkS6vgn513phabeghCLVKYqOtHMW cVm3b+JD9/y/+U+aS435U5Cw905yv/s8uclrPAv8pRBMXsC29GtDBjsPTNbrZkvF c76GKAT5uJKho90qNM2e/iUEYxQI2ThiRLeO0tEpSEtSCkbSbzrXYzn94U/72WER tEhlw6gWOc6zIXzPd7cv =Kk4l -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/57d659fc-624e-fdd3-1662-df567d7d3e0f%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > Finally managed to track down why unlocking disk with unsealed and > decrypted LUKS key file didn't work on a clean Qubes OS installation. > > While starting to develop this feature, I added the key file path to > my /etc/crypttab and had forgotten about it. Fresh Qubes of course > didn't have this change. Combined with one weird systemd > incompatibility (the B point in this [1] forum post), it had caused > the key file to get completely ignored. > > There are two ways to work around this issue [2], neither of which is > perfect [3]. Both solutions' downsides are pretty insignificant and > most likely not applicable to 99.99% of existing Qubes OS installations. > > For now, I've decided to go with the second option (ignoring crypttab > even for hostonly dracut setups). So, to summarize, rd.luks.key works in both hostonly and non-hostonly mode now, with this change? And rd.luks.options=discard (instead of rd.luks.allow-discards) does too? If so, that seems very reasonable. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZkIxHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf5RwP/2iVQGV6k44eq6JbpNJjoSMb ViyTqTyJExL66GtDHQ684p36gD8/Pt+MXLLPHWm73sowQm1Sp1A74yr7m04WkW+q 9udraH6f3BWN8j+Jue0pxsPg5iONa/DF81+BDLRz8AitRftoUH9HClDJO0hxhNTd nPgOlLSflZzfQFi5x31r8boXx1bSe9FxTXRy79sRb2WIAZMrkmTbwdk8c8Efe4Nb nZYgd78V3f9Oo/xFfZtrYgo1fVC6r2sGSSFTYDizTwVUPu+cBXfND2NL/EwT9Hc5 gP2xy1FRClbA0OByDlHIf9Bm1NIaf11/IoUEuhXRyqhB5NUWpS3fSte2kjdbwDuf kg/llsqChHa6X320NUsnJal/kd/939dmjsVHMXYp8ErJmk1iaF5ZflyRD9bvoKza wqdY1DpQBfT4n8yZzbQ5kjqqH66GjlrsmjKDBGEf9gmH1jqJVMNs2uadkrtn8gf3 qd50nckperlBpAfHUKtndktnuNm1MgHnO6g8Icv1PNF/McWNEWDAIT32LVALOnfc VQEMG1YLXTE/4bvpInUM7Gk2qkmwsv5Gt6E4j6ol7XGSQ84x5HpnZSQYLcWW5WCH TDpzl6SgUxbxtVVJ23RGZ/kCnEcufd/+NaFAy4SzXnICkwEQOtidoKzJ2fjhFPRl W+dnH3+KbAA3QbBXEu/1 =Fjbf -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/20170813172839.GA1235%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/02/2017 07:05 PM, Patrik Hagara wrote: > On 07/26/2017 03:21 PM, Patrik Hagara wrote: >> On 07/25/2017 08:48 PM, Rusty Bird wrote: >>> Patrik Hagara: Would it be OK if I squashed all the commits so far into a single large one (as there's already quite a lot of reverts and design changes anyway). > >>> Yes, please do. > >> Done, along with some refactoring (plus an implementation of your >> RO/RW manual unplugging suggestion). Feel free to start >> reviewing. :) > > > Just a quick update: code review is in progress (see [1] for > comments), with various small changes and fixes being made [2]. > > > Cheers, Patrik > > > [1] > https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d 4a > > 72ec6696b621fa76e2a95 > [2] https://github.com/phagara/qubes-antievilmaid/commits/master Finally managed to track down why unlocking disk with unsealed and decrypted LUKS key file didn't work on a clean Qubes OS installation. While starting to develop this feature, I added the key file path to my /etc/crypttab and had forgotten about it. Fresh Qubes of course didn't have this change. Combined with one weird systemd incompatibility (the B point in this [1] forum post), it had caused the key file to get completely ignored. There are two ways to work around this issue [2], neither of which is perfect [3]. Both solutions' downsides are pretty insignificant and most likely not applicable to 99.99% of existing Qubes OS installations. For now, I've decided to go with the second option (ignoring crypttab even for hostonly dracut setups). For any brave souls out there trying out Qubes 4.0 rc1 already, able to compile their own packages using the qubes-builder and having Intel TXT on their machines, you're welcome to try the latest commit from my repo [4] and reporting back with any issues or comments (even unclear documentation!). Cheers, Patrik [1] https://fedoraforum.org/forum/showpost.php?p=1681988=43 [2] https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a 72ec6696b621fa76e2a95#commitcomment-23617394 [3] https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a 72ec6696b621fa76e2a95#commitcomment-23617493 [4] https://github.com/phagara/qubes-antievilmaid -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZj2x6AAoJEFwecd8DH5rlJnEQAI8+ouvRkXwzsz0CpN5UgOqB 1qmvua0NgBK1SC15gPeXjuOABXqO8IxJcVpuOoIL3wdZaHvvNgpGmXiKWUu6YTwi h1yhS5w8/2rMhfLRT86AyP6H9SRwdC0DgrjCbBzsQtWZH4kBg8ItOK3q2XWrwhhC 3hckSJ4KbZNgT86q0PABCInLfDrxADiFnI+oOQBvHInq/hWuJRibDBWAnNG4AetA KCkKpMGSSZTBzl6hBfczqtdWc/K7lIhPAO26ht87046ZRN+RjpOl588M2gsw2zYT z3AHDQAY0+m8qAMv89luklyoYJCcg4RiMTOrPrGtBDFuHGB+rylUFDLujI+AaDH1 lLWNaPXBWUXsKBUqaHOWjP7ek+iK3Nl0yotqkngpiDZ+SNvrCCUa4xaG8j6NjVX6 jd8J/OsWzeiSDygzLKY4mitjNIT4d9yoHND4STte3UcWwAeq1vXlb4Ypvn7z7MNJ w9ZDveawLv5Z6ZPLKMUsCml4JrGiLnK74jYi/GSMulB8ZMA2mfJGr9IAgMF8hp9b +Aw2O0kkU3PMp5tTGgIsMAFI3nJcUN2TibiP5OA9898kVO0HXzpYFUfKhQATgjzf g+1PIJwmO2WHvPGO1uYD0SwXyM7joXmg7z5lUEKqo40sU5nW3T/6qrpxymlP+Sy1 1AfgopK/R9mbwGrmvqgs =SBa8 -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/1a5287c1-cd1c-402f-e91a-dd94e258a725%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/25/2017 08:48 PM, Rusty Bird wrote: > Patrik Hagara: >> Would it be OK if I squashed all the commits so far into a >> single large one (as there's already quite a lot of reverts and >> design changes anyway). > > Yes, please do. Done, along with some refactoring (plus an implementation of your RO/RW manual unplugging suggestion). Feel free to start reviewing. :) I also took the liberty to remove Qubes 3.2 compatibility shims (workarounds for old systemd and coreutils pkgs), so scream if you cannot test on 4.0 yet. I'll be installing the 4.0 pre-release on a spare drive over the weekend myself (ie. I haven't tested the current commits yet, might be that some small bug sneaked in while refactoring). Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZeJdtAAoJEFwecd8DH5rlwaEQAK0pHY5lQLVAv3NC8uhuLsq5 1JVD7Dn6vv4z6cYL30LxcwwLkuIacWPWs92Ja+lpqUxTTcoLzByl7DVwo3E2j5d7 aJ6yKpWTnd2MBvGaC7GO/yNMQ3tDEh2uAoSPm4eRhK5aHCdqO7d6KaUnbZba8WjJ fITscsI/whr+YSwDS3ORmVcaikefGZSliHkEw3xogc6wKzAQYCfutFMpiVCsGUAP Qc4w7naMruuO2p3ZnS0vtNI9Blvw8nIRm8Vd9XWaS4og4b+gFCAq/HBLNhTMjcnR hetoB0B+s2O5E6QV6Vsl6km7fMY7WKtRfciIU2Ul0cVBc9weo7cz/sRGgMDYD23K P6HjClS3FHC+zpYm+O3tm/KRq22BLPO1a/djeoz4yPCwKmF1TrW7LiHsEsj7GtxU DD8ThUecScftKnJ82kPQqkBW8lFcOTnkZzzvJ1UuTCvGA/qyrfRcgaIMHlwhSzxH xBIMHn1uiRn+JIuogxmn/WFy7lfU/LW5f5VWmHjwWDYaxcjtPEDsNzs9O7g4TmTn ZDAIqTzbr52/zQRjyeHIMsgduafcWa7xUVq9KQtBPR9AT28GhZtrIWpxCFpOwLFP XFwDwe+Wq9szKz0lZsYB3CtJkV6Ttlz2GMfIxCjS4eh0iF/5jsthxgHiM/g7OFZp z9hUnAWk4wSDKsXCKPA7 =dw/8 -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/e6454350-38c4-a439-f5a4-a33659e800ad%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > Would it be OK if I squashed all the commits so far into a single > large one (as there's already quite a lot of reverts and design > changes anyway). Yes, please do. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZd5J7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfLTkP/RwyStNxTX3jGZiCIu3PjygX rf4NQaBrMJO3kkPGd/iAylMEIxqC+aagiAk+VqfoM4GdVudQNfqD+oXO28ARZbBO ds033AbccgK534fWsda2xrv1aprkfukshLffj4tmugs2CnqeQevkrpwKuAgs+aLr n0odyTab3E448IhR9hC8u7MA725fujq1eKblB/unKRCIuQyAwZF0NPyPKCUTgWvg SZxKpQV3AawPBnxTa/Jf5K/DD+jCJRS4qPa8qgaPyqOV+aP29ujjisVMFK0Pjfpr sWU2tPkknuQ0ZILvU6cJHBHxy5QjBEjrgD3iQNpNAbkbNqXj6BPI8auPpi3WA4ZG N69Ey6VLWjS2feEu2ej/EI1+4x9KhHg5yHiXGlIVL/QgEmOKDl7d1SqNvdPZEfbL 2gCDa1GXOCn165H0YJ07dGWAGyEjlI2jfmw5grvX/ujFI1hyoS809opb3zHSDf1a /SxTLnBOBOwP0/p+D5mJavf4FXRi8bsXi+6YxYzO+12e8UmQemGjhveoFlXCt88r Xo4pqMHEp9jIQTSwX4XebbOQRUjQb+INAYpmxL56Cpih4p1hGrRs2er9G2m/Dnrr JZ+ReL8HYTt0yaTaTwWi+OzcKSQzGgCMeMAX8MRgbGNp/1hBtIihYSwxAgGB4Uv6 roTmLYHvGMb+8vGvOZKO =fVGl -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/20170725184827.GA6414%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/24/2017 04:40 PM, Rusty Bird wrote: > Hi Patrik! > >> Thinking about RO/RW AEM media gave me quite a headache. We want >> to allow creating a RO AEM media that would ignore freshness >> tokens -- but then the attacker can trivially downgrade a seized >> media from RW to RO and thus the freshness token hash in TPM >> NVRAM would never get invalidated if the user doesn't notice (eg. >> attacker flipping the switch on microSD to SD card adapter the >> user leaves in their laptop). > >> Extending a PCR with the media RO/RW status will prevent this >> scenario, but also make it impossible for user to create a legit >> RO AEM media by eg. flipping a physical RO/RW switch on an SD >> card or copying an existing USB stick to a read-only CD... Unless >> there was a way of sealing data to arbitrary PCR values >> regardless of the current state -- and luckily, there is! Will >> need to write a custom tool for that since tpm-tools' >> tpm_sealdata does not support sealing to other than current PCR >> values. > > I was wondering about RW->RO downgrades too (didn't realize you > were already working on this part...), and came up with the > following tweak: Currently, the unseal script will mount the > device, do its work, and unmount. But it could be rearranged to > mount, copy the sealed secrets to /tmp, immediately unmount, do its > work, and at the end, check if the user removed the device. If > that's the case, the unseal script can create a file in /run to > skip -seal.service via "ConditionPathExists=/run/...". > > This would prevent the easy downgrade, and it seems pretty > natural, UX-wise, to remove the device early if you don't want to > reseal. Probably much less code, too? Not sure about how natural it would feel... I'd say the best UX for removal of AEM media would be to _wait_ for the user to decide, ie. print a message and wait either until the device is removed or the user decides not to do so via a key press (_not_ a timeout). Explicit is better than implicit, as the Python saying goes. >> And while we're at it, why not also extend the boot device label >> into a PCR -- what if the attacker covertly changed the label and >> the user then used this AEM media? There's risk of DoS attack by >> filling up the NVRAM freshness token area, or worse, overwriting >> other AEM media's freshness token hash (thus preventing it from >> being used). > > Booting from an attacker-modified AEM device is dangerous anyway, > e.g. there could be exploits against the ext4 filesystem driver. Yes, but while the ext4 exploits are theoretical, the DoS I outlined would be guaranteed to work. > But when extending a PCR with the label is only one or two lines > of code, why not indeed. :) > >> Changes pushed > > Thanks! I'll try them out later this week. No rush, I'm still churning out small fixes. After a code-prettifying pass though, I'd be interested in some code review again. :) Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZdjymAAoJEFwecd8DH5rlnfYQALvJ9KfaCAHc7CCmcouFtWgl K5XLa3h83YL4GiH+JmV6YtxjsvwewpNwZadmSpx/pemAGIK8NVUyD4VH51twNs0D 0Kqamo9y0GVOonILzR2chXRu9woyZSxq/RQhsZb6sfDZxvs6cKFkPDrcFwC9KuRk oWS/yHGEkFxUAqgLbMKcUa+ISCDcN9UEq9XEE8b5wOVB8V+QdCKseZonTjceVvec C952TNBp45rWoygMIM+bDvLFcudsjFpNWteL31An2fWaOyNWNuWMgDZoJF2rqQKw zBQK17JLGQaYZsBYzGXwIjTATzB6q333mL/t9qkLLf2tvsCEszDlhkTUwGHwLSZF DS8nJe+kudIc3KUNBtgq3GzHys2FvY07P+NBDix9IYsTKLcdnxjEwR/A9OUAMcjc 0xUnN5KJoBpwe3ABwd/xp8wj37LxlVtpZTURxglbbQ/QBCzCwrtzFbrNS0JiNi5U PQLIGoX9YLywD3bYyT9K5IL9ZNmbisAFzWyDwHShy+OoB3X1pwhXGJL0Xphqf5oc IuDJglOTvXsPZEfhbrvHszcKBpEhJOTrmrEp+5j8EJIbqJ90UcH8b9btIbmBVBzp dT7OWmQDu0ORkNRtbTwek9wr///+PIM/n13MdogmTv69Cxkvtwf5BVqld7Ox0Smz mj8MKs4dkf/ffMRvYHWg =09sQ -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/dd7692d7-13e6-f2f2-6ee6-b55911d9e7b7%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/20/2017 03:24 AM, Patrik Hagara wrote: > I've got most of the code written already, just need to finish the > -unseal script bits and test it, then I'll push it to my fork -- > should be in the following day or two, depending on how many bugs > I managed to write again. ...or how many more hard-to-solve design issues I find. Thinking about RO/RW AEM media gave me quite a headache. We want to allow creating a RO AEM media that would ignore freshness tokens -- but then the attacker can trivially downgrade a seized media from RW to RO and thus the freshness token hash in TPM NVRAM would never get invalidated if the user doesn't notice (eg. attacker flipping the switch on microSD to SD card adapter the user leaves in their laptop). Extending a PCR with the media RO/RW status will prevent this scenario, but also make it impossible for user to create a legit RO AEM media by eg. flipping a physical RO/RW switch on an SD card or copying an existing USB stick to a read-only CD... Unless there was a way of sealing data to arbitrary PCR values regardless of the current state -- and luckily, there is! Will need to write a custom tool for that since tpm-tools' tpm_sealdata does not support sealing to other than current PCR values. And while we're at it, why not also extend the boot device label into a PCR -- what if the attacker covertly changed the label and the user then used this AEM media? There's risk of DoS attack by filling up the NVRAM freshness token area, or worse, overwriting other AEM media's freshness token hash (thus preventing it from being used). Changes pushed, now to finally finish the unsealing script. Hopefully I don't find any more issues. Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZdeXnAAoJEFwecd8DH5rl6R0P/2QkKp3H0edZYxnylJbqpr7C 5udtkIJgEJh+mLi4sbC8S1T24Sl9CVflK+H9a7UuTkGcV7AcM2YaPmpJzsBpqdp7 65F1MfhoDLtLQkXzg5AgBdNbIaLy1oTrinXCXOYRWoxuHqd2eHe5n0veW5iOvSjQ 2EBUJmv0/wKBYTRIH+nkAmIly1r759zSpJJi8tb0JtlwxARou45SJDYH3U//4jdi TgclSxmx8HnJ5bGVH7dhOpShsSBKWWMLBMFRr/Acwi5rzpIpgVeAz3Wor3lXaJYo veEbklhQnFDTQ2UYJ0FuuLdNLTATrgTOkaDb8GPLGPMbNAQdjqhGly5be/+WumPd 9lsftzJDygNpf2iyla6k+6/HeZVJ3ZeAu6aM5U8Sfawcoa0qBhMJmwP0YxZn5BV5 b2nlns9JSFMt/L6O2S0WrHnYDFQdE6bzmvNhUhS4BIbnnB5w/3BSHi5BKkB3ZEeR 4gb6SQ5ViElgiiFcjlFTEQ3MzaXTZ/ytCCunDCfOUTmXkEuZkBFz45bsKpdFklML GbL5M2i+IrSvv0NS2f4inZn9N5W+fxY9/2852CwxRUPgPpFk3kdSSYQ2WJgm8WdU TtEgOE+g8/eTCaxlDvv7O4UsHMgO3uYM8IfF+7dURhC4AbRLRSt59Baj615ELz6j aL/BAfKgORG1+dqrAgzr =aw1f -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/1bd7dbaa-c005-ff12-9085-425891100332%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! First off, sorry for the delayed report this week! I was doing "drawing board" work almost exclusively for the past ~three weeks trying to wrap my head around all the outstanding issues and figuring out some decent avenues for fixing them, so there was no code committed and I felt like there was simply nothing "real" to report. My mentor, Rusty, has encouraged me to write something up anyway, so here goes. :) First, there's the annoying problem of needing to (preferably non-interactively) reset the TPM dictionary attack lock while having an owner password set to not-well-known value. Although I've been able to find a way of substantially reducing the number of "triggering" TPM calls (by replacing tpm_id's tpm_getpubek call with a custom randomly generated TPM ID stored in NVRAM), there still remain the incorrect SRK password guesses while probing whether SRK password is set or not. While the reduced amount of DA lock trips might work out just fine under normal usage, the backup plan is to store TPM owner password on the encrypted root partition and perform a DA lock reset after each successful boot (eg. from the -seal script, which should now get called every time due to the new "freshness tokens" discussed below). Freshness tokens are the means of preventing an attacker who gains access to a (copy of) AEM boot media _and_ who knows all the required passwords but cannot gain access to the Qubes computer right away for some reason. In such case, the user has a chance to either forcibly invalidate the stolen AEM media and thus preventing attacker from unlocking the encrypted computer (provided the user knows the AEM media was stolen from them/copied); or, if they are not aware of the fact that the attacker possesses a _copy of_ (since a missing primary AEM stick would be pretty obvious) the particular AEM media they use to boot Qubes on a regular basis, they can still (unknowingly) stop the attacker in their tracks by simply rebooting often enough... Another issue is the need of mapping particular AEM media to their respective freshness token hash "slots" stored in the TPM NVRAM. I decided to make this a simple AEM media label suffix to slot index mapping, stored on the encrypted drive. This approach has the advantage of easily replacing lost/destroyed AEM media (or perhaps even read-only but outdated, but I haven't figured that one out yet) - -- simply anti-evil-maid-install to a new media using the same label and answer yes to the prompt warning you of the overwrite (the old media will automagically become unusable). As for storing the actual freshness token hashes in TPM NVRAM, for now I'm planning to make it a fixed 8-slot memory area (much like LUKS key slots) and addressing individual slots using offsets, since I've read [1] that each NVRAM index definition wastes and extra 93 bytes of overhead. Even Chrome OS decided to use just 2 NVRAM indices [2], presumably due to the same reason (since you cannot set different permissions for portions of a single index definition and they needed that for the firmware/kernel spaces). I've got most of the code written already, just need to finish the - -unseal script bits and test it, then I'll push it to my fork -- should be in the following day or two, depending on how many bugs I managed to write again. Cheers, Patrik [1] (p. 37) https://www.cylab.cmu.edu/tiw/slides/challener-TPM.pdf [2] https://www.chromium.org/developers/design-documents/tpm-usage -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZcAZRAAoJEFwecd8DH5rlY3UP/iKmN2zKmYyj4oIfHpbFTUGt HmaEAtGU1PE1OrplB3bE9jTuY/8TvE3uQHMoCN4YaV//Oho79k8a3DtUWOitZwkR bhUXyNjH2kFTX8Ckd+/pUvtNrzubj5Uj05TM1PG8KLIUjk0dgWmm11fk5LxektCq d1KtGg5RrbStB/1/kcllm3SMVzQVhWXu4TgfMt/8HZ2xBqpuTarJQZNcRqfAIQHw AONPtiQX8B15+V7brtJwRJE8WKrR+5NxDjtjaFEoTuM5g1AxLJ1aNj+cunYRR8LM M3eZjVzPRFhbBMu+dvs8ML4seV4PdcWdmU/MkOhYJ6yc+WesliNPZXZ8Bkq4PZeQ Kcfhl8/h+dMXeTzNUvWc7GJCl5tj1ycdJR1mxPbL8k1a7EsP9G+4n3XYpNYAg6XV 5XcenUNDngLUbf6mZWzk58j90DMBqns+DZrrOiVDmSoF2QW9WaiTdtxn5kPAbziL jBAvXN3vvYgIlfB1dq6ZqYgoumHyGmY9dytMrde0En9eI7T4qbouuD8kg1Ve0UIP 3sOAzw//+ebumQdC8lGEA0OUjFI90d4bduqUdvo0EoFJ0OhYGAHySzZ3b7F/tXRB UvuR9T/D/cOqluMbJ1Cqe7eVjdizhJbKo8sQsaUy8elkIBMAYVZED+UeqCsji1Tm ecp6spib2RcvYcDtpZa1 =QM3b -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/c425fb59-48c7-251c-95d8-11756436329c%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Patrik!
> On 07/05/2017 05:30 PM, Rusty Bird wrote:
> > How should portable Qubes installations be handled? We can't save
> > the owner password in the initramfs. But I was thinking, the
> > function to write a 256 bit value to NVRAM (at index n) can be used
> > to store not only the hashed freshness tokens for every AEM device
> > (at index 1, 2, 3, ...), but also a randomly generated TPM
> > identifier (at index 0) that could actually replace all the
> > tpm_getpubek stuff in tpm_id.
>
> Assuming "portable Qubes installation" means sharing a storage media
> containing installed Qubes OS between multiple machines --
Yes, exactly that.
> we could
> store a TPM (UU)ID to {owner,NVRAM} password mapping on the portable
> encrypted root disk instead of a single password; plus per-machine
> (per-TPM, rather) sealed AEM secrets (which in the current
> implementation would get mixed up and overwrite each other if TPM has
> owner password set up, but otherwise works already -- simply replacing
> tpm_id with something not relying on pubEK will fix this, more below).
>
> Neither the owner password nor the NVRAM area password are stored in
> the initramfs, as that would be a security risk. They are stored only
> on the encrypted root partition.
>
> The TPM 1.2 spec mandates at least 512 bytes of NVRAM storage to be
> available
1280 bytes? [1]
> (actual storage is vendor-specific, no upper bound given).
> Assuming 20 bytes per (sha1) hash that's only 25 values in the worst
> case -- and this space is shared between all "applications", so Qubes
> AEM should probably not take up all of it.
>
> So far I've thought about storing a unique 20-byte value as a TPM
> identifier (a randomly generated UUID hashed with sha1)
Or just 'head -c 20 /dev/random' instead of 'uuidgen'.
> and reserving
> a few (say 2 or 4) 20-byte slots for freshness tokens, so that you
> could have MFA-protected backup AEM stick(s). That's just 60-100
> bytes. In principle similar to LUKS key slots stored in its header
> (which has space for 8 keys).
>
> What do you think?
You probably don't even have to define a maximum number of slots in
advance -- the TPM ID / AEM freshness tokens could start from some
constant NVRAM base address and (attempt to) go as high as needed. If
anyone really wants to manage a ridiculous number of AEM devices, why
not let them try. :)
Rusty
1.
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdf
(bottom of page 14)
-BEGIN PGP SIGNATURE-
iQJ8BAEBCgBmBQJZZMuaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfSNEP/jdYH7xcuf3TRxRyJGZuPRaV
Mkk+hHWBvTOlIatFUFZL987HexzSeZNR5QRk5xIUaCtwYVKEHb8/mI5ySPrUJCy5
LFeGGIRURFPsSePym+MwXXElcAzL1fTBbOEkkARtP2vyrfCt4w4OCHeDDF3MvheM
kWCOkZTHD+zzSqPzx+gs7lP80eYhXTNLZIMs/UcqRJA+aFmpxdf5KfcnoL9UjggE
iXBtPdL2gLu3S1M/h9CcHObpJusJ98GSmIQjSAcI44mLQdD5fONfDohpTVuXoG81
uYVdbZFDDCt26+ow2m+J+e1Qc/CsE7W42pRfEoD8We9I2wsGUya1fF8sGR8Nj89K
rAPuJeP+Os/THs+7yf3IsjeSJd8j9QX+4iZO6K5WVqosfakFu4Vk0rOlj6e2KoqM
8kWC251q06bT18+nZ9DwQuJ+Ua7gmX5AE6i9APWeTaOk6bFjp49fZO6TEhIlKv3y
EdJjqk4NTAR2LvmkECkWn0BZYWOPAE8hnIZwVJaf5r1US8O3zzOb7DE5G7MwizpW
ClxJAS82t3JFZLkgw3JuILROqhSe3QFXFY+CR1Q3jyIiX8lvaW5gk4lAICNrMWr6
LK9eA6E/9UQ4/J3bXimrtBhIyM7+hVdtTqLXZkyTSozkwh17kAf+PzE/5hen+SEr
IrhjZxQlOnRq7RpWGcKd
=MPqD
-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/20170711125906.GA20983%40mutt.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/05/2017 05:30 PM, Rusty Bird wrote:
> Patrik Hagara:
>> On 07/04/2017 12:28 AM, Rusty Bird wrote:
>>> Hi Patrik!
OK, let's go with the freshness token then.
>>>
>>> To avoid implementation complexity here: What do you think
>>> about unconditionally requiring the freshness token in all AEM
>>> setups, and (as a stretch goal) skipping the token _update_,
>>> both on the AEM medium and in NVRAM, if the medium is
>>> read-only? IMO it's not crucial to implement this read-only
>>> check in AEM 4.0.
>
>> Hmm, that could work.
>
> How should portable Qubes installations be handled? We can't save
> the owner password in the initramfs. But I was thinking, the
> function to write a 256 bit value to NVRAM (at index n) can be used
> to store not only the hashed freshness tokens for every AEM device
> (at index 1, 2, 3, ...), but also a randomly generated TPM
> identifier (at index 0) that could actually replace all the
> tpm_getpubek stuff in tpm_id.
Assuming "portable Qubes installation" means sharing a storage media
containing installed Qubes OS between multiple machines -- we could
store a TPM (UU)ID to {owner,NVRAM} password mapping on the portable
encrypted root disk instead of a single password; plus per-machine
(per-TPM, rather) sealed AEM secrets (which in the current
implementation would get mixed up and overwrite each other if TPM has
owner password set up, but otherwise works already -- simply replacing
tpm_id with something not relying on pubEK will fix this, more below).
Neither the owner password nor the NVRAM area password are stored in
the initramfs, as that would be a security risk. They are stored only
on the encrypted root partition.
The TPM 1.2 spec mandates at least 512 bytes of NVRAM storage to be
available (actual storage is vendor-specific, no upper bound given).
Assuming 20 bytes per (sha1) hash that's only 25 values in the worst
case -- and this space is shared between all "applications", so Qubes
AEM should probably not take up all of it.
So far I've thought about storing a unique 20-byte value as a TPM
identifier (a randomly generated UUID hashed with sha1) and reserving
a few (say 2 or 4) 20-byte slots for freshness tokens, so that you
could have MFA-protected backup AEM stick(s). That's just 60-100
bytes. In principle similar to LUKS key slots stored in its header
(which has space for 8 keys).
What do you think?
Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJZY5qsAAoJEFwecd8DH5rl6CUQAKuGo5KScXV11eXLJWVmHcf5
1ZO75U/Sx3nLnmbz4Crzr5ci0UpLMbIVnum+Aq82oou93la7NEX4EMhCaTQsILP3
tTVnPPw/hz8OSRptb1zV0RRFU243VvB5zmrVLvT8g/G0lfnTVmFhb448L/+WYB33
dw/V11e+JKfriG2ahnRRuK7yICXYsxz6TOiB7ZULbP0jMMB2b7W7VhC/5Pz51OzE
t0voS9K12NaRaARBjDA9f13XEkjzkbSA/LtA71PG3nzUpE+W8HUKFn6g800HnaE2
bWYf6O6lumRUyrqcHj425jpMu/vGlePH9FSiOTBm3BMuHjLPlHKOUkkVpukPMKUf
feXoVRX+aA2EmDLYFKac8myTz7hu6+k2UEP+zDH6B2RPTgHIe3xvANMi3ZL5cSf0
aLm9mwk/NtCoyibjtqZ3wDlmFGpVfYB/FqNiQNBN/x272OfAcNkInV9tFb7v173b
JYOp445v3/Oq8kvlc3Lrqhueqfv7o4AzFIuMWQsyYDvehiB4uVPbfInGAGWyoqgW
pLbMOo1pT0BJXaN+B9q9UwLmxZm7d1qJ7ZKuH1N/n71EIJ6qis+76V+2rppdPnhV
+7LVMK9pJQDSUw9isbIA5TSmq9WCcUqJLrtlY6zUC0kZqSQQY7pMxm8Mic4bIqqo
OlLYPgAXileuu7S0yp2j
=X/Y8
-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/b0402595-5c15-777e-51a0-53ae255d3fdf%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
0x031F9AE5.asc
Description: application/pgp-keys
0x031F9AE5.asc.sig
Description: PGP signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > On 07/04/2017 12:28 AM, Rusty Bird wrote: > > Hi Patrik! > >> OK, let's go with the freshness token then. > > > > To avoid implementation complexity here: What do you think about > > unconditionally requiring the freshness token in all AEM setups, > > and (as a stretch goal) skipping the token _update_, both on the > > AEM medium and in NVRAM, if the medium is read-only? IMO it's not > > crucial to implement this read-only check in AEM 4.0. > > Hmm, that could work. How should portable Qubes installations be handled? We can't save the owner password in the initramfs. But I was thinking, the function to write a 256 bit value to NVRAM (at index n) can be used to store not only the hashed freshness tokens for every AEM device (at index 1, 2, 3, ...), but also a randomly generated TPM identifier (at index 0) that could actually replace all the tpm_getpubek stuff in tpm_id. > > Inside of the anti-evil-maid-(un)seal.service systemd units, > > /dev/tty is already inaccessible, so 'echo password | tpm_whatever' > > should work. (When the anti-evil-maid-seal script is invoked > > manually, the 'echo password' input will be ignored and > > tpm_whatever will display its own prompt.) See e.g. the > > tpm_sealdata commands in the (un)sealing code. > > Oh, right! Somehow I missed this fact (/dev/tty inaccessible in > services). Still, the workflow outlined right below is IMO better > (perhaps as a stretch goal?). > > >> Reading the TPM 1.2 spec again, I've noticed there's a way to > >> delegate owner's authority for execution of (a specific subset > >> of) owner-only TPM commands (ie. generate a new password that > >> would only be usable for resetting the DA lock and nothing else). > >> While there's no tool for that in tpm-tools package, it should > >> not be that hard to write one using the TSS API provided by > >> TrouSerS. Additionally, this would get rid of the /dev/tty issue > >> and reduce the impact of potential password leak -- only this > >> limited password will be stored on (encrypted) disk, not the > >> full owner pw. Conceptually, it's cleaner for sure. But I don't know if that makes it worth the extra C code. If an attacker can access the encrypted disk contents, the TPM owner password would probably be low on the list of things to worry about? Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZXQYGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk08P/A2F7FlABf7JCjmHmIdYlpfj KNglHY53bt9JVksWmpXCqkeGjH2KVeqRtWAR9tbM9BeQktPDQCYY+PWv+oYSwSnT 8fYh4oHKlcc85adhHMYOFbfo7n4tqlTcsBdk4oFnlp1DDEZkKC+QwwPmIUfM+edz uNvChVsU+V7nwgWBVgY7x1R08AcW/3pPXRUNF+MwjDyeXVCh0TxYI5zYJc5HLMiK 2kjQ8R1TFXriyVvJceC+9IVvJ5Kr/3KqshapCtUiGUG0KybM3RFPLvc5RXuG1aTO hNhrfUs+VKTlrdD8TJAG2Amv0NTP6JGl+x2Evol2sT8/IwCJME6nJIBZfD+5AGm1 bffsApo8/2bxHTpwC8nP7vzT7WqNf1xvIktYzM+0vysdctKhuONoSbs+GYSZuQhp 6d51+fgZz1DX6sXrxsu9D+F6Qp7DFIZSiwzTdigIQ9cydyHNO2sD5iD0KR8Yl1Dn 7f+koFAgU4AOlNS0RBNXD3yHgx/Opr/WhTv3QQLkD88POzfJ9dIpWXo3GGgZ5qe7 AIZaw7tyLN4zTocXghx8ewbxTaE7CgqzceyCckjKcL/ajyEubq0a6LzwUlhVaL7u VxmbQwMiPqaep18SSByhr3CFh/nfUg/4PaHbZDbgA7xQcHAPRRdPPbkGOjICY4Pe D78wH8yzONOmH0k/HUyY =VMqd -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/20170705153014.GA1099%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/04/2017 12:28 AM, Rusty Bird wrote:
> Hi Patrik!
>
> I just noticed that qubes-devel seems to break your PGP/MIME
> signatures. Inline PGP works better on Google Groups based mailing
> lists. (The CCs have all been fine, of course.)
Thanks for letting me know! Hopefully fixed now.
>> On 06/26/2017 05:28 PM, Rusty Bird wrote:
>> I guess your last point is valid, we can seal the actual
>> secrets (txt/png/keyfile) just once and always reseal
>> only the "freshness" token. I'll have to think more about
>> this, but so far I didn't find any obvious flaw with this
>> approach.
>
>> As for the DMA attack mentioned in your later e-mail,
>> shouldn't the IOMMU (which is required for Qubes 4.0)
>> automatically protect against that (as it gets activated
>> by Xen)?
>
> I might totally have the wrong picture here, but can't the
> rogue PCI device (which would not be assigned to any VM)
> access all of dom0's memory? [2] Or are there more
> fine-grained restrictions?
>>>
You're probably right. In which case, encrypting the whole
(not just dom0) RAM would most likely be the only option.
>>>
Considering the ability of DMA to modify memory, unsealing
the "freshness" token before the actual secrets would not
provide any meaningful security and the resulting AEM code
would be pretty similar in size anyway. :(
>>>
>>> Reading memory (with a DMA attack, a cold boot attack on
>>> transplanted RAM modules, or a cold boot attack in the same
>>> system if SCLEAN really doesn't wipe all memory) still seems
>>> like it could sometimes be more straightforward than writing
>>> memory (with a DMA attack). And it's kind of neat to be able to
>>> protect text secrets, in the absence of these memory attacks.
>>>
>>> I don't know. But we can always revisit the whole separate
>>> freshness secret thing later. Maybe somebody will weigh in on
>>> read-only media support in the meantime?
>
>> OK, let's go with the freshness token then.
>
> To avoid implementation complexity here: What do you think about
> unconditionally requiring the freshness token in all AEM setups,
> and (as a stretch goal) skipping the token _update_, both on the
> AEM medium and in NVRAM, if the medium is read-only? IMO it's not
> crucial to implement this read-only check in AEM 4.0.
Hmm, that could work.
One significant issue I've encountered this week is that the
TPM dictionary attack lock actually triggers after a few
reboots (due to tpm_id and tpm_resetdalock calls with
well-known owner secret)...
>>>
>>> Would removing the 'tpm_resetdalock -z' calls in -unseal and
>>> tpm_z_srk improve the situation? Looks like it's
>>> counter-productive in setups with an owner password.
>
>> There's also the tcsd_changer_identify scripts with call to
>> tpm_id which gets executed every time the tcsd service is
>> starting (via ExecStartPre tcsd.service unit drop-in). The
>> tcsd_changer_migrate drop-in will also call tcsd_changer_identify
>> itself if not already migrated. That's one or two tpm_id calls
>> which contribute to dictionary attack lock. And I see no way to
>> get rid of this completely. :-\
>
>> Anyway, why should having a non-zero owner password
>> prevent you, a local user, from reading the TPM's public
>> endorsement key? TCG claims it's due to anonymity concerns (as
>> the pubEK uniquely identifies the TPM), but the same can be done
>> by querying (via /sys or whatever) the serial number of any other
>> HW component (mobo, HDD, battery, ...) or just the specific HW
>> configuration/topology (model numbers, which bus/port the devices
>> are connected to, etc.). It makes sense for remote attestation
>> (and the spec already has a Direct Anonymous Attestation protocol
>> to solve this) but not much for local usage.
>
>>> Also, -seal could avoid the tpm_z_srk call if $CACHE_DIR
>>> exists, and in this case set $Z based on whether
>>> $SRK_PASSWORD_CACHE exists.
>
>> Yeah, I'd rather just call tpm_resetdalock here with a password
>> read from the (now unlocked) disk...
>
> Sounds good.
>
>>> If it turns out to be necessary, TPM utilities can read from
>>> stdin -- but only when /dev/tty is inaccessible (like in a
>>> systemd context):
>>>
>>> # mv /dev/tty{,.bak}; echo password | tpm_whatever; mv
>>> /dev/tty{.bak,}
>
>> That's... not nice.
>
> I forgot to mention that this line is only for testing!
>
> Inside of the anti-evil-maid-(un)seal.service systemd units,
> /dev/tty is already inaccessible, so 'echo password | tpm_whatever'
> should work. (When the anti-evil-maid-seal script is invoked
> manually, the 'echo password' input will be ignored and
> tpm_whatever will display its own prompt.) See e.g. the
> tpm_sealdata commands in the (un)sealing code.
Oh, right! Somehow I missed this fact (/dev/tty inaccessible in
services). Still, the workflow outlined right below is
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Patrik!
I just noticed that qubes-devel seems to break your PGP/MIME
signatures. Inline PGP works better on Google Groups based mailing
lists. (The CCs have all been fine, of course.)
> On 06/26/2017 05:28 PM, Rusty Bird wrote:
> I guess your last point is valid, we can seal the actual secrets
> (txt/png/keyfile) just once and always reseal only the "freshness"
> token. I'll have to think more about this, but so far I didn't find any
> obvious flaw with this approach.
> >>>
> As for the DMA attack mentioned in your later e-mail, shouldn't the
> IOMMU (which is required for Qubes 4.0) automatically protect against
> that (as it gets activated by Xen)?
> >>>
> >>> I might totally have the wrong picture here, but can't the rogue PCI
> >>> device (which would not be assigned to any VM) access all of dom0's
> >>> memory? [2] Or are there more fine-grained restrictions?
> >
> >> You're probably right. In which case, encrypting the whole (not just
> >> dom0) RAM would most likely be the only option.
> >
> >> Considering the ability of DMA to modify memory, unsealing the
> >> "freshness" token before the actual secrets would not provide any
> >> meaningful security and the resulting AEM code would be pretty similar
> >> in size anyway. :(
> >
> > Reading memory (with a DMA attack, a cold boot attack on transplanted
> > RAM modules, or a cold boot attack in the same system if SCLEAN really
> > doesn't wipe all memory) still seems like it could sometimes be more
> > straightforward than writing memory (with a DMA attack). And it's kind
> > of neat to be able to protect text secrets, in the absence of these
> > memory attacks.
> >
> > I don't know. But we can always revisit the whole separate freshness
> > secret thing later. Maybe somebody will weigh in on read-only media
> > support in the meantime?
>
> OK, let's go with the freshness token then.
To avoid implementation complexity here: What do you think about
unconditionally requiring the freshness token in all AEM setups, and
(as a stretch goal) skipping the token _update_, both on the AEM
medium and in NVRAM, if the medium is read-only? IMO it's not crucial
to implement this read-only check in AEM 4.0.
> >> One significant issue I've encountered this week is that the TPM
> >> dictionary attack lock actually triggers after a few reboots (due to
> >> tpm_id and tpm_resetdalock calls with well-known owner secret)...
> >
> > Would removing the 'tpm_resetdalock -z' calls in -unseal and tpm_z_srk
> > improve the situation? Looks like it's counter-productive in setups
> > with an owner password.
>
> There's also the tcsd_changer_identify scripts with call to tpm_id which
> gets executed every time the tcsd service is starting (via ExecStartPre
> tcsd.service unit drop-in). The tcsd_changer_migrate drop-in will also
> call tcsd_changer_identify itself if not already migrated. That's one or
> two tpm_id calls which contribute to dictionary attack lock. And I see
> no way to get rid of this completely. :-\
>
>
> Anyway, why should having a non-zero owner password prevent you, a local
> user, from reading the TPM's public endorsement key? TCG claims it's due
> to anonymity concerns (as the pubEK uniquely identifies the TPM), but
> the same can be done by querying (via /sys or whatever) the serial
> number of any other HW component (mobo, HDD, battery, ...) or just the
> specific HW configuration/topology (model numbers, which bus/port the
> devices are connected to, etc.). It makes sense for remote attestation
> (and the spec already has a Direct Anonymous Attestation protocol to
> solve this) but not much for local usage.
>
>
> > Also, -seal could avoid the tpm_z_srk call if $CACHE_DIR exists, and
> > in this case set $Z based on whether $SRK_PASSWORD_CACHE exists.
>
> Yeah, I'd rather just call tpm_resetdalock here with a password read
> from the (now unlocked) disk...
Sounds good.
> > If it turns out to be necessary, TPM utilities can read from stdin --
> > but only when /dev/tty is inaccessible (like in a systemd context):
> >
> > # mv /dev/tty{,.bak}; echo password | tpm_whatever; mv /dev/tty{.bak,}
>
> That's... not nice.
I forgot to mention that this line is only for testing!
Inside of the anti-evil-maid-(un)seal.service systemd units, /dev/tty
is already inaccessible, so 'echo password | tpm_whatever' should
work. (When the anti-evil-maid-seal script is invoked manually, the
'echo password' input will be ignored and tpm_whatever will display
its own prompt.) See e.g. the tpm_sealdata commands in the (un)sealing
code.
> Reading the TPM 1.2 spec again, I've noticed there's a way to delegate
> owner's authority for execution of (a specific subset of) owner-only TPM
> commands (ie. generate a new password that would only be usable for
> resetting the DA lock and nothing else). While there's no tool for that
> in tpm-tools package, it should not be that hard to
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Patrik, > On 06/19/2017 12:43 PM, Rusty Bird wrote: > > Patrik Hagara: > >> On 06/18/2017 05:51 PM, Rusty Bird wrote: > >>> Rusty Bird: > Patrik Hagara: > > Single-use key file code committed > >>> > Whee, I finally get it... Seeing how it all fits together, it looks > really cool! > >>> > What do you think about making replay protection a self-contained > secret? If we'd change it from a counter (shared between the combined > counter+keyfile secret and NVRAM) to a per-boot random string stored > in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a > hash_ -- then AFAICT the attacker still wouldn't be able to malleate > the secret in any meaningful way, and: > >>> > - secret.fresh.sealed (the first to be unsealed) could be used to > replay-protect all types of AEM secrets, not just keyfiles > >>> > - If secret.fresh.sealed is in fact stale, the keyfile would never > have to be unsealed into memory, where it's susceptible to a cold > boot attack (probably even if the tmpfs file is shredded, due to > buffers) > >>> > - It seems like this approach should simplify the implementation? No > concat/split code, fewer special cases (e.g. all AEM setups would > have the same always-reseal workflow) > >>> > >>> Hmm, replay protection would be incompatible with the use case in > >>> which a backup AEM stick is stashed away somewhere. So it probably > >>> shouldn't be enabled in non-MFA setups after all, or at least not > >>> unconditionally. > > > >> Anti-replay secrets could be compatible even with backup AEM sticks, > >> just by having separate secrets for each AEM device. > > > > Oh, right! NVRAM has enough space. > > > >> However, always resealing would not work for read-only media. > > > > And read-only media could theoretically become more attractive in R4, if > > hypervisor vulnerabilities (=> updates => resealing) are going to affect > > Qubes less frequently. > > > > OTOH, making replay protection _optional_ would complicate the code yet > > again. For example, tagging a particular text secret as "don't display > > if secret.fresh.sealed is missing", similar to the current counter + > > keyfile concatenation. > > > > :/ > > > >> For cold boot attacks, a good solution would be to encrypt the whole > >> memory using eg. TRESOR (storing encryption key in CPU debug registers), > >> with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as > >> most/all Intel processors with VT-d also have AES-NI. Not sure whether > >> encrypting RAM from Linux would be enough or whether we would need to > >> implement the encryption in earlier boot stage (tboot or Xen). > > > > There's an old ticket [1] for TRESOR -- targeting disk encryption keys > > only, but even that is "far in the future"... > > I've read some more about Intel TXT and tboot... and it seems that cold > boot attacks could be ruled out as any abrupt shutdown will trigger a > secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM > module). However, I'm not 100% sure whether whole RAM gets wiped or just > the TXT-related bits -- couldn't find that explicitly stated in neither > TXT nor tboot docs. :-\ > > And since the BIOS ACM is a binary blob, the only way to find out will > be to actually perform a cold boot attack... Yes, it would be interesting to test this on e.g. a popular ThinkPad with 16 GB RAM. There are some bootable memory scrapers [1] if anyone doesn't know what to do with all their liquid nitrogen... > >> I guess your last point is valid, we can seal the actual secrets > >> (txt/png/keyfile) just once and always reseal only the "freshness" > >> token. I'll have to think more about this, but so far I didn't find any > >> obvious flaw with this approach. > > > >> As for the DMA attack mentioned in your later e-mail, shouldn't the > >> IOMMU (which is required for Qubes 4.0) automatically protect against > >> that (as it gets activated by Xen)? > > > > I might totally have the wrong picture here, but can't the rogue PCI > > device (which would not be assigned to any VM) access all of dom0's > > memory? [2] Or are there more fine-grained restrictions? > > You're probably right. In which case, encrypting the whole (not just > dom0) RAM would most likely be the only option. > > Considering the ability of DMA to modify memory, unsealing the > "freshness" token before the actual secrets would not provide any > meaningful security and the resulting AEM code would be pretty similar > in size anyway. :( Reading memory (with a DMA attack, a cold boot attack on transplanted RAM modules, or a cold boot attack in the same system if SCLEAN really doesn't wipe all memory) still seems like it could sometimes be more straightforward than writing memory (with a DMA attack). And it's kind of neat to be able to protect text secrets, in the absence of
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/19/2017 12:43 PM, Rusty Bird wrote: > Patrik Hagara: >> On 06/18/2017 05:51 PM, Rusty Bird wrote: >>> Rusty Bird: Patrik Hagara: > Single-use key file code committed >>> Whee, I finally get it... Seeing how it all fits together, it looks really cool! >>> What do you think about making replay protection a self-contained secret? If we'd change it from a counter (shared between the combined counter+keyfile secret and NVRAM) to a per-boot random string stored in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a hash_ -- then AFAICT the attacker still wouldn't be able to malleate the secret in any meaningful way, and: >>> - secret.fresh.sealed (the first to be unsealed) could be used to replay-protect all types of AEM secrets, not just keyfiles >>> - If secret.fresh.sealed is in fact stale, the keyfile would never have to be unsealed into memory, where it's susceptible to a cold boot attack (probably even if the tmpfs file is shredded, due to buffers) >>> - It seems like this approach should simplify the implementation? No concat/split code, fewer special cases (e.g. all AEM setups would have the same always-reseal workflow) >>> >>> Hmm, replay protection would be incompatible with the use case in >>> which a backup AEM stick is stashed away somewhere. So it probably >>> shouldn't be enabled in non-MFA setups after all, or at least not >>> unconditionally. > >> Anti-replay secrets could be compatible even with backup AEM sticks, >> just by having separate secrets for each AEM device. > > Oh, right! NVRAM has enough space. > >> However, always resealing would not work for read-only media. > > And read-only media could theoretically become more attractive in R4, if > hypervisor vulnerabilities (=> updates => resealing) are going to affect > Qubes less frequently. > > OTOH, making replay protection _optional_ would complicate the code yet > again. For example, tagging a particular text secret as "don't display > if secret.fresh.sealed is missing", similar to the current counter + > keyfile concatenation. > > :/ > >> For cold boot attacks, a good solution would be to encrypt the whole >> memory using eg. TRESOR (storing encryption key in CPU debug registers), >> with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as >> most/all Intel processors with VT-d also have AES-NI. Not sure whether >> encrypting RAM from Linux would be enough or whether we would need to >> implement the encryption in earlier boot stage (tboot or Xen). > > There's an old ticket [1] for TRESOR -- targeting disk encryption keys > only, but even that is "far in the future"... I've read some more about Intel TXT and tboot... and it seems that cold boot attacks could be ruled out as any abrupt shutdown will trigger a secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM module). However, I'm not 100% sure whether whole RAM gets wiped or just the TXT-related bits -- couldn't find that explicitly stated in neither TXT nor tboot docs. :-\ And since the BIOS ACM is a binary blob, the only way to find out will be to actually perform a cold boot attack... >> I guess your last point is valid, we can seal the actual secrets >> (txt/png/keyfile) just once and always reseal only the "freshness" >> token. I'll have to think more about this, but so far I didn't find any >> obvious flaw with this approach. > >> As for the DMA attack mentioned in your later e-mail, shouldn't the >> IOMMU (which is required for Qubes 4.0) automatically protect against >> that (as it gets activated by Xen)? > > I might totally have the wrong picture here, but can't the rogue PCI > device (which would not be assigned to any VM) access all of dom0's > memory? [2] Or are there more fine-grained restrictions? You're probably right. In which case, encrypting the whole (not just dom0) RAM would most likely be the only option. Considering the ability of DMA to modify memory, unsealing the "freshness" token before the actual secrets would not provide any meaningful security and the resulting AEM code would be pretty similar in size anyway. :( One significant issue I've encountered this week is that the TPM dictionary attack lock actually triggers after a few reboots (due to tpm_id and tpm_resetdalock calls with well-known owner secret)... This can be solved by storing the owner password on the encrypted root partition and calling tpm_resetdalock with that on each MFA AEM boot. However, the tpm_resetdalock binary does not support passing the owner password via STDIN or CLI argument -- I'll have to write my own utility just for that (adding it to the tpm-extra package) or get upstream to fix that (as some other binaries in tpm-tools package support that). What are your thoughts on this? The alternative would be for the user to remember to run tpm_resetdalock (manually entering owner pw) before each reboot or
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/18/2017 05:51 PM, Rusty Bird wrote: > Rusty Bird: >> Patrik Hagara: >>> Single-use key file code committed > >> Whee, I finally get it... Seeing how it all fits together, it looks >> really cool! > >> What do you think about making replay protection a self-contained >> secret? If we'd change it from a counter (shared between the combined >> counter+keyfile secret and NVRAM) to a per-boot random string stored >> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a >> hash_ -- then AFAICT the attacker still wouldn't be able to malleate >> the secret in any meaningful way, and: > >> - secret.fresh.sealed (the first to be unsealed) could be used to >> replay-protect all types of AEM secrets, not just keyfiles > >> - If secret.fresh.sealed is in fact stale, the keyfile would never >> have to be unsealed into memory, where it's susceptible to a cold >> boot attack (probably even if the tmpfs file is shredded, due to >> buffers) > >> - It seems like this approach should simplify the implementation? No >> concat/split code, fewer special cases (e.g. all AEM setups would >> have the same always-reseal workflow) > > Hmm, replay protection would be incompatible with the use case in > which a backup AEM stick is stashed away somewhere. So it probably > shouldn't be enabled in non-MFA setups after all, or at least not > unconditionally. Anti-replay secrets could be compatible even with backup AEM sticks, just by having separate secrets for each AEM device. However, always resealing would not work for read-only media. For cold boot attacks, a good solution would be to encrypt the whole memory using eg. TRESOR (storing encryption key in CPU debug registers), with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as most/all Intel processors with VT-d also have AES-NI. Not sure whether encrypting RAM from Linux would be enough or whether we would need to implement the encryption in earlier boot stage (tboot or Xen). I guess your last point is valid, we can seal the actual secrets (txt/png/keyfile) just once and always reseal only the "freshness" token. I'll have to think more about this, but so far I didn't find any obvious flaw with this approach. As for the DMA attack mentioned in your later e-mail, shouldn't the IOMMU (which is required for Qubes 4.0) automatically protect against that (as it gets activated by Xen)? Cheers, Patrik -- 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/18f570e7-10c4-e2f8-bcbd-89aac4834cdf%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > The initramfs would, upon next boot, read both the sealed LUKS key file > (unsealing it, along with stored counter value) and the publicly > readable counter value from TPM -- and, assuming the values match, > continue booting. An attacker cannot circumvent this check -- changing > the code will result in different PCR hash and thus the key file failing > to unseal. One possible attack would be to patch out this check in memory as soon as the kernel has started up, i.e. after SINIT has already measured the initramfs, using DMA from a malicious PCI (ExpressCard, Thunderbolt) device. Similar to TRESOR-HUNT [1], in spirit. But I don't think this invalidates your implementation, which at least requires the attacker to have such a device at hand. Rusty 1. http://old.iseclab.org/papers/acsac2012dma.pdf -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRtO+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJgYP/3KQ3OkTteHGTqMX7Rj7NLhI 8P6s6xHSXOkd2jTK9Ss4bT3aCSsoYPUcOXrUSRf/wYhPCuIqP9OXCpOxyzC2V567 VnTzjCEEt27W/F43skNRygRVIIfkw7OBFNpHPgj9HkeaDprM4csI3mQ0wElIMx7Y cL+f0ymSFTJCL5G4/sfhzixVmL+yjDbZYjDoIaiI8no563t6DVvz2UdjpF5vEpX2 gyj1InqTJ0aiHrGPDTGnVQbZ5SbIFCcAW5gIL50cW7RVbw3xHGo5lgR3hHtx0hn/ 6fvhrFCJIxhJCba1NmDQ5uz6Ybjr1AU2Dx4fr+SQ/TKtkSCaZ1cu6vpg+mCjJxQb v8ZLRsQDkcE8k9diLCXyQcXVkLBKdX+xJMnem0+y2VEdgd86lr8HK45uptrtwsWe aepeyHZlbem4qBZA4pzIdAwHPfbZzH3oQCcGRkdspBpS7Ls2BMUf38HJklM+MVPO fMFVUM2peEpmpzsdumJcS3RlF/VpQT5fzZwbPxhQMRmJnJyvfRvh+9BqRDRus0SC Lifp8k3ldhzh3U+VWcRH5N64wDUaEIpBwbrj+SNuHwVYWggsY1aDFNIwdyFCCJne fbc+ovHRKSrzC2xcWVsXtDQnxieHqX9oXWd7BGh/CfUcddXcHQ/L2o5qi4FTnX5p qfkOdzlliBvDp0UPVQQg =wHwZ -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/20170618192347.GB8291%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rusty Bird: > Patrik Hagara: > > Single-use key file code committed > > Whee, I finally get it... Seeing how it all fits together, it looks > really cool! > > What do you think about making replay protection a self-contained > secret? If we'd change it from a counter (shared between the combined > counter+keyfile secret and NVRAM) to a per-boot random string stored > in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a > hash_ -- then AFAICT the attacker still wouldn't be able to malleate > the secret in any meaningful way, and: > > - secret.fresh.sealed (the first to be unsealed) could be used to > replay-protect all types of AEM secrets, not just keyfiles > > - If secret.fresh.sealed is in fact stale, the keyfile would never > have to be unsealed into memory, where it's susceptible to a cold > boot attack (probably even if the tmpfs file is shredded, due to > buffers) > > - It seems like this approach should simplify the implementation? No > concat/split code, fewer special cases (e.g. all AEM setups would > have the same always-reseal workflow) Hmm, replay protection would be incompatible with the use case in which a backup AEM stick is stashed away somewhere. So it probably shouldn't be enabled in non-MFA setups after all, or at least not unconditionally. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRqF6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrflCQP/i4NBM8yXNzZ9jLrMxpbwiUz nw3zWkm/NrjTEE6lWob7dFS8CN8lMkapt3x7fx90uky0XGcsNVSfghxcF+yjaOuo Ni9wuvkfCAYDfrcTaUHZV2M21sHlxIM+dagmZqMPFlJt9LTu6Ju0P+nExQvZ7C0w ZM7h2MFX7X89g+ESo5j/ZQQwghXh9NTOjpxC4UUTfsWwyCLROmrvmbvpWBwUa7m3 nWAfFL1qUnIENtrlHvq/fKmkIVpVRHmU8Gbhy1u5wH23aTAk5XqGBriw2HM7WdML oS37e15uymf4TxqSl9Ehwc9gHdLHrWVaEgImrIc1buEQZppSl3iQy98YGP3FfpWQ qEwrURqHc45r4gfz2VwRo6XTJ18tgL7dGr+JfQJIY3pwQO4SSdL9ZPSPIITdlR9C zoe33FCqdg1HlcW+PLAVV8MV3KKaSilxI1wGRinhYKQUpKvnOnmUQRjMBZNY2o+9 xqFsLIfglhUzE4u9noE1IREudWSB+hBaFRncAdg7SgZOvV9oEJsVYA+rVdF9reBA 1oUo37qShLMfD9Cilos/hgvO5hJ+41VND3GFyhrhoQ6b/25PmnhVIEAWXLtPWj7V mdaHVqYaHK/p/eDfeHCiPBHMAGrFk+97cnD2wW+Ds7vQGufvxDbiK73zSFK+sMCq VyqfZcTnHUygcP26Dm+U =rDb3 -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/20170618155122.GA7654%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > Single-use key file code committed Whee, I finally get it... Seeing how it all fits together, it looks really cool! What do you think about making replay protection a self-contained secret? If we'd change it from a counter (shared between the combined counter+keyfile secret and NVRAM) to a per-boot random string stored in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a hash_ -- then AFAICT the attacker still wouldn't be able to malleate the secret in any meaningful way, and: - - secret.fresh.sealed (the first to be unsealed) could be used to replay-protect all types of AEM secrets, not just keyfiles - - If secret.fresh.sealed is in fact stale, the keyfile would never have to be unsealed into memory, where it's susceptible to a cold boot attack (probably even if the tmpfs file is shredded, due to buffers) - - It seems like this approach should simplify the implementation? No concat/split code, fewer special cases (e.g. all AEM setups would have the same always-reseal workflow) Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRpsMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfwXMP/3e3eas+5uDtq98w5A+fwW+W A56dVp/e1e8TqsumtHxlmo3rZ2IF6nfvFwjwcKAvQ200KTj0nBvBposXXM5GD2i0 hskpLzEkq2Dapbgnyqd9RWUiQ57ieOWg5qXJmS61q4q9njTgSbIhtnyxgFczqmAb nwc6q/H2eAia4hE0A40aMKOby8T89l4VYo0Czipz8zEZqGtnRRI2yCyhDZLu+eR8 raV9kggH6g/oJjmr+jTnOx1SHUFSVieOns4RfzoaTxV0y86TPknc5QG80/IheP3d AqvEUd6P4MYdngZoL7Txwh0VNE4WwK8qn64bPX27jEJIXZuWxn01P9rQee2dYAJZ SD4JG5/NtYBCopFmZJ2zZ54PjfreO/SoUrlk6CB2ZKF/JLc91qi/2xsrYZIwSPCj Bdr84aUhb3T5I9kBaLM6eX19CZeqFa2bzSfSa1IedS5lqUcGnJddn2zHn3PSjUBp 9g1AVEkF9fhHjPvdBHmHYiyKRMDLW7+FzdCSNNt2vocfGNJu4fyNdGl2AYanuUrk BjhnP+lotYtAUzIwH+l+SX9HhxWF0uBT/7pjj7rFwvs6Ku4LvUXYDFDkEL1DB6ep fDDxuCzSt2iaMNiWKOvTk0YVrotWeuFXi3TAvgKYgozJqPdjeUzOqZPzsWJTxS43 1FSOyp4hlxs8lxu4JIeC =VnBP -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/20170618145811.GA18477%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/16/2017 09:32 PM, Patrik Hagara wrote: > I will push those changes to my fork after > some cleanup and a re-test (most likely tomorrow). Single-use key file code committed [0] and I'm going to check whether clearing the TPM invalidates PCR-sealed data or not. If it does, then generating an extra signing key will not be needed. -- Patrik [0] https://github.com/phagara/qubes-antievilmaid/commit/4b398390b5335222c6d6a9799df3230755fc8d4b -- 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/74a6ff0d-1ce7-f36b-6059-64bcca886bca%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/13/2017 12:45 AM, Patrik Hagara wrote: > Unfortunately, it seems monotonic counters are designed to only be > manipulated (create/increment/destroy) by the OS and thus the TrouSerS > project chose not to provide any APIs to perform those operations. This > trousers-users mailing list thread [0] contains additional information > (details the limitations), posted by the late Hal Finney. > > Given that information and the fact that Linux does not currently make > any use of the available TPM monotonic counter facility and neither does > it expose any TPM-backed virtual counters to the user-space, I've been > thinking whether it would be possible (and secure) to use TPM NVRAM > instead of a proper monotonic counter -- eg. allowing writes to the > NVRAM area (to increment the "counter") only if a correct authorization > key is provided (stored on the LUKS-encrypted root partition), but > otherwise being freely readable (protected only by the optional & in > this threat model useless SRK passphrase). I found out that implementing a secure counter in NVRAM would require having a TPM owner password set -- otherwise an attacker can simply undefine and create a new NVRAM area with chosen counter value -- while the owner password is currently assumed to be well-known (ie. "not used") for dictionary attack lock reset and reading the TPM public endorsement key. This might not be an issue, since the TPM pubEK is used only by the tpm_id script for creating per-TPM directory on AEM media; and the dictionary attack lockdown requires multiple incorrect password entries in a short period of time to trigger (at least for the particular TPM I have available). Still, an attacker with physical access could perform a full TPM reset (without knowing the existing owner password, by using the "physical presence" authorization) and then create a new counter in NVRAM with a chosen value... And since we do not want to prompt the user for TPM owner password during boot (risk of snooping) _and_ the attacker is assumed to possess a full copy of the AEM stick _and_ knows all passwords used during a typical MFA AEM boot, they can successfully unseal, decrypt and use the LUKS key file. :( However, I think an extra signing key can be generated inside the TPM and used to sign the counter value (with the corresponding public key stored on AEM stick _and_ measured into a PCR). This signing key should then get wiped from the TPM if the attacker performs a reset. I already have a PoC for the above (except the signing key pair for TPM reset attack) with a world-readable 4-byte counter stored in NVRAM that requires an authorization password for writes (this pw is stored on the encrypted root partition, counter gets auto-incremented on each AEM boot and key file re-generated). I will push those changes to my fork after some cleanup and a re-test (most likely tomorrow). Should someone figure out any other way to circumvent this, please let me know. :) -- Patrik -- 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/37db3ce0-dc1d-3a4f-be5f-68832158346b%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/10/2017 08:10 PM, Rusty Bird wrote: > Patrik Hagara: >> Any and all code reviews are welcome! The changes I made are stored in >> my fork of AEM repository [1]. > > - Please don't feel obligated to read this on a weekend :) - :) > One thing I noticed is that a comment in anti-evil-maid-unseal > mentions setting up /tmp/keyfile in /etc/crypttab. But adding the > kernel command line parameter "rd.luks.key=/tmp/keyfile" to > /etc/grub.d/19_linux_xen_tboot would have the advantage of working > even if dracut is in no-hostonly mode (e.g. on portable Qubes > installations), where /etc/crypttab is ignored. Yes, this would be the better solution, thanks! Cheers, Patrik -- 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/b3d9442c-42de-ec3e-9f34-133e51eb3020%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > Any and all code reviews are welcome! The changes I made are stored in > my fork of AEM repository [1]. - - Please don't feel obligated to read this on a weekend :) - One thing I noticed is that a comment in anti-evil-maid-unseal mentions setting up /tmp/keyfile in /etc/crypttab. But adding the kernel command line parameter "rd.luks.key=/tmp/keyfile" to /etc/grub.d/19_linux_xen_tboot would have the advantage of working even if dracut is in no-hostonly mode (e.g. on portable Qubes installations), where /etc/crypttab is ignored. There's a bug in systemd < 227, so to test this on R3.2 you'd either have to patch [1] and rebuild systemd-cryptsetup-generator, or use "rd.luks.key=YOUR-LUKS-UUID=/tmp/keyfile", which avoids the buggy code path. But it won't be an issue on R4.0. Rusty 1. https://github.com/systemd/systemd/commit/c802a7306bdc3e82378a87acd9402bbabe9f6b28 -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZPDYoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfyOIP/3Olk10ev81PbGUpBnuCPZkE wN14R+NDAahhukDMH4BAO0X9Po1AfQyyObP3tncZCIXt/rHfn40oqR/25r486TDV pbe6lO2alDlvjCc19cmnlOefcJxJAfdTOdy/aOGlQLcaDhGbksD2rSro2AclefDa irhY6p1cfxRhMvWj753ql7pGJHMlCpU4EFe6HT0JLYAAz6X447KuZbwOvZkp7laB 0gfAHGJXrUCcziTIAbivYUl84TNW7HOjPQmt5/MXrR/aTHycKSUgil6kvJhxM3+a mhcABVKO5Bjs0tYLsv+bC6r/dOr0ECvOV7PC/0C51m9gA9mGeItff73UIoRxmVw/ 1LyZE+zwrOR2yKHih6C4iUzsLJ+hvUOQi1QW6nGnyhKTrMXUEqIyLO+akN4ABVJY BcX4c1cXxba/4RDFy3og0/ZhaWfpSsFGx4jSAY3AKjQYF7x70CJAwGvSXJmMGMG4 eJO9dmvZc4PHqiC/mdZOSUJA2cqOv5VPJk6bfHj4EbFhe+mWOZjb5SJCkF0X6To1 OEAnb7Zl99dRkiTnNtZKQlycEl+pOt4r8uSh9ndOTK+jlRiCZsnRFZSd8AQfcbL9 Gv+Rjfh3Z4behFUgXJjPc9Fr4fQLwLEA034RSbW3fzhLpBC8WTqAL9PRKvvhoLN1 AXIJAmRzzgISwtLl702Z =9qf/ -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/20170610181048.GA1069%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rusty Bird: > Patrik Hagara: > > On 06/09/2017 05:22 AM, Rusty Bird wrote: > > > Rusty Bird: > > >> In the current WIP version, the keyfile is encrypted before sealing > > >> and decrypted after unsealing. (Using scrypt - if we trusted the TPM > > >> to handle the raw keyfile, we could just use SRK password protection > > >> instead.) > > > > > > Sorry, I have to retract the part that says SRK password protection > > > for the keyfile is (in theory) an alternative: The SRK password > > > applies to the unseal operation for the TOTP secret as well, so the > > > user has to enter it before they know that the computer is in a good > > > state. But then the attack Patrik pointed out as the motivation for > > > adding TOTP in the first place would still succeed. > > > > I think using a SRK passphrase is irrelevant in this scenario. > > > > Say the attacker managed to compromise the computer so that it always > > boots attacker-controlled kernel. User gets prompted for the SRk > > passphrase and complies, but the TPM will fail to unseal anything since > > the PCRs wouldn't match -- ie. no correct TOTP code displayed. > > > > The same would be true even if the well-known SKR (ie. no passphrase) > > was used (which is, to my knowledge, already considered secure paired > > with removable AEM devices). And it would have better UX -- one less > > (near-useless, in this case) passphrase to remember/type. > > > > However, it is true that the attacker will have the ability to copy > > contents of the real AEM stick and on subsequent evil maid attack will > > be able to unseal both the TOTP seed and encrypted LUKS key file -- and, > > assuming they also managed to snoop the key file encryption passphrase, > > will gain access to the encrypted drive. > > Oh, I was originally talking about a theoretical setup where SRK > sealing _is_ the only "encryption", with nothing host-side like scrypt > before or afterwards. Where there would be no extra keyfile passphrase > whatsoever. It's a terrible idea... Just to really be clear, my error was to think of the SRK passphrase as a passphrase needed specifically to unseal the keyfile, when in reality it is a passphrase common to first unsealing the TOTP secret and then the keyfile. Eek, I'll stop bumping the thread now. > But yes, a different theoretical seal-then-encrypt setup would not be > vulnerable to an evil maid attack per se, and indeed the SRK password > would be irrelevant (and a nuisance) then, as you say. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZOoucXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfSB4QAIZQFutZ8TK9o3A704uqOsQm YkRirmbgWfq6ToN+sRM8wEPWC7VJNvlqYQkFluKddSCpkZ8xqS2nd82lHlvubI9h qymdVJJvX72oEyaJDx3GDbxNST3FziHRrtxiOHd4CsZH1Xj+bW0VDKuCxA/QzE3i mlzRxzJRgsntYip2bPX3JNIRc1vxHVCtJuHP4qIqljlvIBfhm5i3yiovCAVLwEJT j+mtJXIA9GlV6XqKiOVGD3gwDZZtT6J9MzgvtJ5BAVO4p3Lt5GYaQccwJDwk0Uop BAMgZyD88ydx/je57DZnsdkYJE5V166dFIORkwxDSw0ZXwrVfTQngbKmX4dWD4xQ lV5n4q1f6hxe4MGLzOzZKxYfDS0HpnLrZTHZIvyydSbwI4Mmn15u2pMFdzeB7cUN e50/wA2rvzpnA6fv/oCt3WWBOuH0MQ8QmzvnH55XrEVvzuyzQqc/wM+At6I5UxXv a1ZfDXH+PEfjW8HKYprgvHgW1sK6RYJnt4gICpSBvj2mbSITHIdm1fMAFzwW1LLc bFrrqH1IzH/Eu+bgpWh2dg3oETRHIcioqbd89aa/lJU28fm5JdY45t4JT39dznag 5SQNw3PhuW0buNFk6lY+slhLaaCpbxI/rO05YjRA1UiJURp49MF+ja9na8FENGjf 5EyUfgj0gKIKaN3Hz0Gj =npak -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/20170609115052.GA1157%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/09/2017 05:22 AM, Rusty Bird wrote: > Rusty Bird: >> In the current WIP version, the keyfile is encrypted before sealing >> and decrypted after unsealing. (Using scrypt - if we trusted the TPM >> to handle the raw keyfile, we could just use SRK password protection >> instead.) > > Sorry, I have to retract the part that says SRK password protection > for the keyfile is (in theory) an alternative: The SRK password > applies to the unseal operation for the TOTP secret as well, so the > user has to enter it before they know that the computer is in a good > state. But then the attack Patrik pointed out as the motivation for > adding TOTP in the first place would still succeed. I think using a SRK passphrase is irrelevant in this scenario. Say the attacker managed to compromise the computer so that it always boots attacker-controlled kernel. User gets prompted for the SRk passphrase and complies, but the TPM will fail to unseal anything since the PCRs wouldn't match -- ie. no correct TOTP code displayed. The same would be true even if the well-known SKR (ie. no passphrase) was used (which is, to my knowledge, already considered secure paired with removable AEM devices). And it would have better UX -- one less (near-useless, in this case) passphrase to remember/type. However, it is true that the attacker will have the ability to copy contents of the real AEM stick and on subsequent evil maid attack will be able to unseal both the TOTP seed and encrypted LUKS key file -- and, assuming they also managed to snoop the key file encryption passphrase, will gain access to the encrypted drive. Compared to a scenario in which TOTP is not used, the one described here has one, albeit small, advantage -- if the user is fully confident that nobody has _ever_ had the chance of snooping on their LUKS key file passphrase, they can simply stop using the existing key file and provision a brand new one. I am not sure whether leveraging the TPM's existing monotonic counter can avoid the problem, since there seems to be no TPM facility to unseal a blob if and only if a counter value sealed along with it matches the TPM's internal counter value _and_ unconditionally increment the counter should unsealing succeed -- this would (unless I made a mistake somewhere) fully prevent key file replay attacks and force the attacker to use the captured AEM media contents _immediately_, before the user notices and artificially increments the TPM counter (rendering the captured data useless) or simply performs a normal AEM boot (even if unaware of the ongoing attack). Such feature probably could be implemented in software, since it's code would affect a PCR and thus the sealing key. Hmm... Cheers, Patrik -- 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/5bca42ec-1666-2beb-a4a8-a24a3a755aab%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/08/2017 03:48 PM, Rusty Bird wrote: > Marek Marczykowski-Górecki: >> On Thu, Jun 08, 2017 at 11:19:22AM +0200, Patrik Hagara wrote: >>> How about storing the key file itself inside the TPM? This may (or may >>> not) open some new possibilities while, apparently, not extending the >>> attack surface since the raw LUKS key file already passes through the >>> TPM before being encrypted by the user. > > Wait, what? Does this refer to a hypothetical change to AEM? In the > current WIP version, the keyfile is encrypted before sealing and > decrypted after unsealing. (Using scrypt - if we trusted the TPM to > handle the raw keyfile, we could just use SRK password protection > instead.) Oh right, sorry for the mistake -- the key file is indeed first encrypted and only then passed through TPM for sealing. >> AFAIK there is very little storage inside TPM and it have even more >> limited write count than standard flash memory. Also, for this to work, >> it would require that TPM allow you to access the key only when you boot >> valid OS - so, not only seal (encrypt) the key to PCR values, but also >> make it condition to read some NVRAM part. AFAIR such thing isn't >> supported - you can only protect some parts of NVRAM with SRK. >> So this probably will not work. > >>> Should the TPM not be trusted enough to handle disk encryption key >>> material, then _two_ user encryption passphrases would be required in >>> order to prevent TPM from learning the LUKS key file contents while >>> still attesting the correct machine state by being able to unseal it -- >>> ie. enc(seal(enc(keyfile))). > >> If we don't trust TPM here, the whole AEM makes very little sense... >> Note that malicious TPM may not only steal values sent to it, but also >> lie about PCR values, effectively making you enter valid passphrase into >> superseded password prompt. > > If I understand it right and sending the raw (or brute forcable) > keyfile to the TPM is being considered, IMO we should urgently avoid > that. Of course a malicious or exploitable TPM can be used to mount an > evil maid attack, but trusting the TPM with the keyfile aggravates a > probably much more common threat: For example, any computer acquired > during a regular search and seizure, and then possibly lying around in > an evidence locker for a few years anyway, could be decrypted as soon > as forensics finds a way to peek into the TPM. Yes, that sounds like a realistic threat and should be avoided. Cheers, Patrik -- 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/49fed906-36f0-4ab0-0f00-442caaee5c10%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/08/2017 01:56 PM, Marek Marczykowski-Górecki wrote:>>> - if someone copy AEM stick _before_ observing proper successful boot, >>>he/she can replay it, because copy of AEM will still have "old" OTP >>>valid (a keyfile encrypted with it) > >> This weakness is impossible to prevent in every scenario I have been >> able to think of so far. :( The upside is that the attacker will need to >> posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_ >> gain physical access to the computer -- essentially adding one more >> factor (possessing AEM boot files) compared to the existing implementation. > > _IF_ monotonic counter in TPM can be used also to seal something, then > it should be possible to mitigate this attack too: once you advance such > counter, you will not be able to unseal key sealed to the old one. > But this will only work if such operation is possible with TPM (I don't > know). Yes, the Trusted Computing Group's TPM specification version 1.2 (not 1.1, however) does mandate at least four 32-bit monotonic counter to be available, with enough storage endurance to survive at least 7 years of counter increments every 5 seconds. See the "Part 1 - Design Principles" document [0], section 17 "Monotonic Counter". However, while both the tpm_tis kernel driver and TrouSerS user-space library (along with tpm-tools) claim to support TPM 1.2 spec, I was unable to find any reference to monotonic counters in either (though maybe I just wasn't looking hard enough). >>> Some of it may be possible to improve using monotonic counter from TPM >>> (I assume there is something like this). Maybe some >>> challenge-response could be performed here (after authenticating machine >>> to the user), with usage of TPM monotonic counter, instead of "just" OTP? > >> How about storing the key file itself inside the TPM? This may (or may >> not) open some new possibilities while, apparently, not extending the >> attack surface since the raw LUKS key file already passes through the >> TPM before being encrypted by the user. > > AFAIK there is very little storage inside TPM and it have even more > limited write count than standard flash memory. Also, for this to work, > it would require that TPM allow you to access the key only when you boot > valid OS - so, not only seal (encrypt) the key to PCR values, but also > make it condition to read some NVRAM part. AFAIR such thing isn't > supported - you can only protect some parts of NVRAM with SRK. > So this probably will not work. I'll look into this. >> Should the TPM not be trusted enough to handle disk encryption key >> material, then _two_ user encryption passphrases would be required in >> order to prevent TPM from learning the LUKS key file contents while >> still attesting the correct machine state by being able to unseal it -- >> ie. enc(seal(enc(keyfile))). > > If we don't trust TPM here, the whole AEM makes very little sense... > Note that malicious TPM may not only steal values sent to it, but also > lie about PCR values, effectively making you enter valid passphrase into > superseded password prompt. Of course, you're right. Cheers, Patrik [0] https://trustedcomputinggroup.org/tpm-main-specification/ -- 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/8662acf1-bd37-4202-c7dd-f5399d8f5b1c%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 08, 2017 at 11:19:22AM +0200, Patrik Hagara wrote: > On 06/08/2017 12:45 AM, Marek Marczykowski-Górecki wrote:> I was > thinking for some time about a scheme where user enters > > also something dynamic - OTP (not necessary TOTP) - either in addition > > to normal passphrase or, instead of. But it's tricky how to do it > > properly. > > One idea is to have LUKS keyfile encrypted with the next OTP (in > > addition to other protections like being sealed to PCR values of TPM). > > And after successful user authentication, prepare it for the next boot > > (since you have access to decrypted disk now, you can access OTP key to > > generate next OTP). In practice probably not just one encrypted keyfile, > > but few of them (like 5) using consecutive OTPs to allow some window if > > you accidentally press a button on OTP token (or a button in mobile > > app). > > This idea have at least few weaknesses: > > - each boot require some write on AEM media, which means a) it can't be > >read-only, b) in case of flash it will reduce its lifetime (to make > >password really one-time, already used encrypted keyfiles should be > >wiped - probably using shred or sth like this) > > A few notes regarding this point: > ad a) the boot-time sealing script already expects AEM media to be > writable if secrets fail to unseal, does it not? > ad b) wiping one-time key files might prove problematic with > (unencrypted) flash media due to their wear-leveling algorithms. Good points. > > - if someone copy AEM stick _before_ observing proper successful boot, > >he/she can replay it, because copy of AEM will still have "old" OTP > >valid (a keyfile encrypted with it) > > This weakness is impossible to prevent in every scenario I have been > able to think of so far. :( The upside is that the attacker will need to > posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_ > gain physical access to the computer -- essentially adding one more > factor (possessing AEM boot files) compared to the existing implementation. _IF_ monotonic counter in TPM can be used also to seal something, then it should be possible to mitigate this attack too: once you advance such counter, you will not be able to unseal key sealed to the old one. But this will only work if such operation is possible with TPM (I don't know). > > - similar to the above - it is not resistant against brute-force > >attack; 6 digit code (or even 8) is not so long, even if you force > >reboot every few tries and somehow prevent offline cracking (dumping > >unsealed but still encrypted LUKS keyfile from RAM) > > - the boot procedure more and more rely on security of some additional > >device > > > > Some of it may be possible to improve using monotonic counter from TPM > > (I assume there is something like this). Maybe some > > challenge-response could be performed here (after authenticating machine > > to the user), with usage of TPM monotonic counter, instead of "just" OTP? > > How about storing the key file itself inside the TPM? This may (or may > not) open some new possibilities while, apparently, not extending the > attack surface since the raw LUKS key file already passes through the > TPM before being encrypted by the user. AFAIK there is very little storage inside TPM and it have even more limited write count than standard flash memory. Also, for this to work, it would require that TPM allow you to access the key only when you boot valid OS - so, not only seal (encrypt) the key to PCR values, but also make it condition to read some NVRAM part. AFAIR such thing isn't supported - you can only protect some parts of NVRAM with SRK. So this probably will not work. > Should the TPM not be trusted enough to handle disk encryption key > material, then _two_ user encryption passphrases would be required in > order to prevent TPM from learning the LUKS key file contents while > still attesting the correct machine state by being able to unseal it -- > ie. enc(seal(enc(keyfile))). If we don't trust TPM here, the whole AEM makes very little sense... Note that malicious TPM may not only steal values sent to it, but also lie about PCR values, effectively making you enter valid passphrase into superseded password prompt. - -- 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- Version: GnuPG v2 iQEcBAEBCAAGBQJZOTuBAAoJENuP0xzK19csUrkH/3UFP3fMM5RsbWEKzh5MgD4e x3ShFO/POYtul3FwWv+SehIRYCcjTI5WVVFFkF7tDRMgIMToI1ME/rkcC+0HlOQB oF+ANZxMKHawlPHC9jFZas/GDitTVQdILyUgneiy1/np5hqY4AkzRQiSLgyEYt4n b0bZmRrSJcT1u3Y32Szt4DSqYDkMo72riJ2TX4witGpc2IfrXmal/bWiLlbLkhfP G3PxhcnIKgCe7VnKKjbr0YkUpGL/4DzjtfKSxaGf+UmThLB8USAqwuvypcdWJLlA jxsjymkZfrFHKbYY83lrkRP9ni2tQWnnXE9YJwqeLJBQygYO861x5P3HaO19D8A= =Noq7 -END PGP SIGNATURE-
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/08/2017 12:45 AM, Marek Marczykowski-Górecki wrote:> I was thinking for some time about a scheme where user enters > also something dynamic - OTP (not necessary TOTP) - either in addition > to normal passphrase or, instead of. But it's tricky how to do it > properly. > One idea is to have LUKS keyfile encrypted with the next OTP (in > addition to other protections like being sealed to PCR values of TPM). > And after successful user authentication, prepare it for the next boot > (since you have access to decrypted disk now, you can access OTP key to > generate next OTP). In practice probably not just one encrypted keyfile, > but few of them (like 5) using consecutive OTPs to allow some window if > you accidentally press a button on OTP token (or a button in mobile > app). > This idea have at least few weaknesses: > - each boot require some write on AEM media, which means a) it can't be >read-only, b) in case of flash it will reduce its lifetime (to make >password really one-time, already used encrypted keyfiles should be >wiped - probably using shred or sth like this) A few notes regarding this point: ad a) the boot-time sealing script already expects AEM media to be writable if secrets fail to unseal, does it not? ad b) wiping one-time key files might prove problematic with (unencrypted) flash media due to their wear-leveling algorithms. > - if someone copy AEM stick _before_ observing proper successful boot, >he/she can replay it, because copy of AEM will still have "old" OTP >valid (a keyfile encrypted with it) This weakness is impossible to prevent in every scenario I have been able to think of so far. :( The upside is that the attacker will need to posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_ gain physical access to the computer -- essentially adding one more factor (possessing AEM boot files) compared to the existing implementation. > - similar to the above - it is not resistant against brute-force >attack; 6 digit code (or even 8) is not so long, even if you force >reboot every few tries and somehow prevent offline cracking (dumping >unsealed but still encrypted LUKS keyfile from RAM) > - the boot procedure more and more rely on security of some additional >device > > Some of it may be possible to improve using monotonic counter from TPM > (I assume there is something like this). Maybe some > challenge-response could be performed here (after authenticating machine > to the user), with usage of TPM monotonic counter, instead of "just" OTP? How about storing the key file itself inside the TPM? This may (or may not) open some new possibilities while, apparently, not extending the attack surface since the raw LUKS key file already passes through the TPM before being encrypted by the user. Should the TPM not be trusted enough to handle disk encryption key material, then _two_ user encryption passphrases would be required in order to prevent TPM from learning the LUKS key file contents while still attesting the correct machine state by being able to unseal it -- ie. enc(seal(enc(keyfile))). What are your thoughts on this? Cheers, Patrik -- 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/3e416333-1cd5-b8a1-ecd3-1c20a6de0d2b%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marek Marczykowski-Górecki: > On Wed, Jun 07, 2017 at 10:45:30PM +0200, Patrik Hagara wrote: > > On 06/07/2017 09:45 PM, Rusty Bird wrote: > > > Hi Patrik, > > > > > > Sorry that it took me a while to respond to your first "offical" :) > > > progress report. This email has some general stuff, but I'll post more > > > here or on GitHub later this week. > > > > > >> Right now, I would say the first version of my code changes is almost > > >> finished. > > > > > > I'll summarize part of my mental image of this first version (also for > > > the benefit of casual readers), please correct me if it's wrong. > > > > > > There are now two new AEM setups: Setup A has TOTP and encrypted > > > keyfile secrets on the only AEM stick; setup B has TOTP and fallback > > > text/image secrets on a primary, and the encryted keyfile secret on a > > > secondary AEM stick. > > > > Yes, that is correct. > > > > > > > (Is there any attack where a TOTP secret adds additional security i> > > > setup A? If not, it should only be done for setup B, right?) > > > > One possible attack scenario I thought of is for an evil maid attacker > > to configure the machine to disregard user's AEM boot device and instead > > boot attacker-controlled kernel. This kernel would then pretend to have > > successfully unsealed the LUKS key file -- the user has no way of > > knowing and will thus enter the key file passphrase, which would > > subsequently get captured for the attacker (along with a copy AEM boot > > stick contents). > > > > Now the user would have to immediately and completely destroy their > > computer, even if they are sure nobody has _seen_ them typing the > > passphrase. I would consider this to be a regression from status quo. Hell yeah! Of all the times I've had tunnel vision while trying to keep AEM attacks and defenses straight, this takes the crown. This and ... > > With the additional usage of TOTP, this kind of attack will be apparent > > to the user (wrong TOTP code => do not enter key file passphrase). > > Yes, IMO this case is important - it was exactly the reason why AEM was > developed in the first place - to somehow authenticate machine to the > user, before entering the passphrase. > > > The attacker can still, of course, learn the key file passphrase via an > > observation attack and then seize the AEM stick -- but this is true even > > for both the "setup B" with two sticks (which would always be carried by > > the user together, ie. no added complexity to the seizure process) and > > current "plain" AEM setup. ... the fact that I could have sworn there was a scenario where some sequence of events involving retroactive access to a recording of a passphrase being entered made a difference between setup A and B, but now I can't bring back anything from memory that isn't flawed or completely unrealistic - I'm taking these as signs that it's very good to have someone new working on AEM, and with great attention to detail. Also, that I should make it a habit to write this shit down. > Yes, this attack is possible because all the user enters is a static > secret. I was thinking for some time about a scheme where user enters > also something dynamic - OTP (not necessary TOTP) - either in addition > to normal passphrase or, instead of. But it's tricky how to do it > properly. > One idea is to have LUKS keyfile encrypted with the next OTP (in > addition to other protections like being sealed to PCR values of TPM). > And after successful user authentication, prepare it for the next boot > (since you have access to decrypted disk now, you can access OTP key to > generate next OTP). In practice probably not just one encrypted keyfile, > but few of them (like 5) using consecutive OTPs to allow some window if > you accidentally press a button on OTP token (or a button in mobile > app). > This idea have at least few weaknesses: > - each boot require some write on AEM media, which means a) it can't be >read-only, b) in case of flash it will reduce its lifetime (to make >password really one-time, already used encrypted keyfiles should be >wiped - probably using shred or sth like this) > - if someone copy AEM stick _before_ observing proper successful boot, >he/she can replay it, because copy of AEM will still have "old" OTP >valid (a keyfile encrypted with it) > - similar to the above - it is not resistant against brute-force >attack; 6 digit code (or even 8) is not so long, even if you force >reboot every few tries and somehow prevent offline cracking (dumping >unsealed but still encrypted LUKS keyfile from RAM) > - the boot procedure more and more rely on security of some additional >device > > Some of it may be possible to improve using monotonic counter from TPM > (I assume there is something like this). Maybe some > challenge-response could be performed here (after authenticating machine > to the user), with usage of TPM
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/07/2017 09:45 PM, Rusty Bird wrote: > Hi Patrik, > > Sorry that it took me a while to respond to your first "offical" :) > progress report. This email has some general stuff, but I'll post more > here or on GitHub later this week. > >> Right now, I would say the first version of my code changes is almost >> finished. > > I'll summarize part of my mental image of this first version (also for > the benefit of casual readers), please correct me if it's wrong. > > There are now two new AEM setups: Setup A has TOTP and encrypted > keyfile secrets on the only AEM stick; setup B has TOTP and fallback > text/image secrets on a primary, and the encryted keyfile secret on a > secondary AEM stick. Yes, that is correct. > (Is there any attack where a TOTP secret adds additional security i> setup A? > If not, it should only be done for setup B, right?) One possible attack scenario I thought of is for an evil maid attacker to configure the machine to disregard user's AEM boot device and instead boot attacker-controlled kernel. This kernel would then pretend to have successfully unsealed the LUKS key file -- the user has no way of knowing and will thus enter the key file passphrase, which would subsequently get captured for the attacker (along with a copy AEM boot stick contents). Now the user would have to immediately and completely destroy their computer, even if they are sure nobody has _seen_ them typing the passphrase. I would consider this to be a regression from status quo. With the additional usage of TOTP, this kind of attack will be apparent to the user (wrong TOTP code => do not enter key file passphrase). The attacker can still, of course, learn the key file passphrase via an observation attack and then seize the AEM stick -- but this is true even for both the "setup B" with two sticks (which would always be carried by the user together, ie. no added complexity to the seizure process) and current "plain" AEM setup. > But given setup B's very subtle security benefits [1] and tough UX - > now that its (necessary) complexity of implementation has been proven, > which I severely underestimated, I keep agonising if your original, > simpler proposal would be the better trade-off after all... Somehow I > had focussed too much on the time setup B would take to implement > (which seemed okay as a stretch goal), and not enough on the > substantial increase in tricky code paths that future developers > working on AEM will have to understand. With probably even more to > come, e.g. fallback support when the secondary stick is not at hand, > or other corner cases that tend to turn up in testing. Not to mention > the user-facing things like documentation and usage messages Yes, the code got fairly complex pretty quickly. And there is still number of cases my code does not cover yet (plus a few bugs I found in the meantime). :-\ > I'm mortified to ask you this so late, but what do you think about > scrapping the setup B and TOTP related parts? And considering them > research showing that your original design approach was tasteful and > mine was overly complicated. Or am I too squeamish about the amount of > code? > > (CCing Marek, who ultimately decides what goes into the AEM repo, to > see if he has an opinion on this issue.) Personally, I would be OK with abandoning the two sticks scenario (but keeping TOTP as written above). I would say it was a worthwhile experiment that just fell short on both UX and security (due to code complexity) and, as you stated, would be hard for future developers to understand/maintain. Also, I would imagine users would have a hard time comprehending the resulting lengthy documentation, even if well-written. I am eager to hear Marek's thoughts on this issue you brought up. Thank you for the feedback! :) Cheers, Patrik -- 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/55e683f5-a7c4-3ef4-7585-c477a74350b4%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
Hi! As some of you may already know, I have been accepted into the Google Summer of Code program to work on improving Qubes' Anti Evil Maid suite to provide resistance against shoulder surfing and/or video surveillance. The project proposal I submitted can be found archived on this (qubes-devel) mailing list or in my GitHub repository [0]. It looks like I have managed to just slightly overestimate the time needed to write the code for all the additional features and options for AEM package. :) Right now, I would say the first version of my code changes is almost finished. Small bugs here and there are to be expected, but unless my mentor (Rusty Bird) or anyone else has objections, I would consider the new AEM workflow to be finalized. Any and all code reviews are welcome! The changes I made are stored in my fork of AEM repository [1]. For now, the next steps I am planning are to: * verify all the added features work as intended (lots of reboots) * check for any regressions (even more rebooting) * document the new AEM setup, upgrade and usage procedures Again, I would love to hear feedback -- and not just from my mentor! ;) Cheers, Patrik [0] https://github.com/phagara/gsoc2017-qubes-aem-proposal/releases [1] https://github.com/phagara/qubes-antievilmaid -- 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/42dad15d-58e2-75ce-f8f4-a1cebee32f74%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
