On Wed, Jan 1, 2020 at 5:43 AM Lorenzo Lamas <lamas9...@gmail.com> wrote:
> Hello Thierry, > > Thanks for all that you are doing for the community. Do you see a > possibility of a Qubes Certified Laptop with an AMD CPU? > There could be others certifying such models, but I won't do certification process for those. Only model that would not have an Intel ME equivalent, doesn't rely on binary blobs etc would be the G505S <https://github.com/osresearch/heads/issues/453> which doesn't have enough SPI flash space to do anything interesting. Intel is affected a lot more than AMD by the sidechannel vulnerabilities in > the last years. The Privacy Beast has a 3rd gen Intel CPU, Intel stopped > providing uCode updates for 1st gen in 2019, so this year is probably the > last year they will support 3rd gen. More CPU vulnerabilities will most > certainly be discovered in the coming years, so there is a need for an AMD > based certified laptop, or at least a newer generation Intel based laptop, > even though that may mean we're stuck with PSP or ME. > My personal path is to try to go away of x86 as fast as possible and try to move actual interest (chicken and egg problem) toward where we should really want to go <https://github.com/QubesOS/qubes-issues/issues/4318#issuecomment-549986749> . I understand all the fuss around those CPU vulnerabilities, but mostly for the server use case, where everything NEEDS to be kept in memory. The concept that needs to be gripped here for workstations is that an information that is not in memory cannot be stolen. Getting the root of this concept, applied to QubesOS, which shuts off smt (HyperThreading) and enforces easy DisposableVMs usage, the user changing some of his habits and compartmentalize accordingly resolves most of the risks. Unsafe browsing? DisposableVM. Done with unsafe browsing? Close unsafe browser, which shuts down DisposableVM and deletes disk changes and memory content. Unsafe attachment? Open in DisposableVM. Often attach untrusted USB device to computer? Create a separate USB sys-usb-unsafe and affect distinct USB controller to it and always attach untrusted USB devices to that port only. Consider USB compartment as being temporary and never trust anything being in memory of that AppVM or its attached storage. Don't give network access to AppVMs not needing it. To say it short, hardware will continue to have vulnerabilities. Those will continue to be really hard to patch. Users will have to change their habits in any case, the sooner the better. Now seems a good moment. The current race for better security enclaves, memory encryption etc won't save the day if closed and behind NDAs for code review and documentation access. The best protection a user can have is against himself. Combined with a root of trust that contains lesser to none untrusted binaries is the best scenario IMOHO, where untrusted binaries are isolated and untrusted at all time. Having ways to make users aware of harware casing tampering would be best. Supply chain not being a problem would be ideal but impossible, targeting and implants always being possible. Race conditions in accessing confidential information in memory is key.... Do you really need those 16 AppVMs opened at all time on older hardware :) Or worst. Have those 20 proprietary software running concurrently on your monolithic operating system disclosing information you don't know on you and other applications running at the same time? Habits. Meanwhile, having a non-monolithic operating system on top of measured firmware containing less to none binary blobs, and verified boot on core components is the best we can have as a root of trust (RoT) perspective for end point devices. It always go down to the simple question: What do you put your trust in? My personal answer is: on hardware that is the most user-controllable as possible. And this is where my interest, time and energies are directed at. The lesser blobs the better. > > On Tuesday, December 31, 2019 at 9:45:18 PM UTC+1, Thierry Laurion wrote: >> >> >> On Wed, Dec 25, 2019 at 6:03 PM <brend...@gmail.com> wrote: >> >>> Insurgo is providing a service. >>> >>> If one can do the steps themselves, that’s fine. >>> >>> If I were advising a somewhat less technical journalist or a potentially >>> targeted human-rights worker or politically targeted activist who just >>> wanted to get stuff done and had the resources, I’d point them to Insurgo. >>> >>> Brendan >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "qubes-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to qubes...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/qubes-users/7a7741f2-6b80-40be-a5a0-0f56b658f9fc%40googlegroups.com >>> . >>> >> >> >> Hello there, Thierry Laurion from Insurgo Open Technologies. >> >> Thanks Brendan. >> >> I feel the need to clarify things a bit once in a while. This reply is >> one of those. This QubesOS community is large, and even if replies were >> done on Reddit and other posts here in the past, the same questions arises >> with the same scattered answers. Here is a combination of those answers. >> >> - Insurgo made grant applications so that actual best trustworthy >> unmaintained hardware becomes mainstreamed under coreboot, and added under >> Heads (extend Heads measured boot support of latest coreboot >> VBOOT+measured >> boot on Sandy/Ivy bridge xx30 and xx20 platforms: t530, t430, x220. >> Thanks >> to obtained NlNet grant for Accessible Security project). >> - Insurgo is attempting to gather developers, device manufacturers >> (RaptorEngineering) and funders around Power9-Power10 hardware based X86 >> alternative platform (PPC64le QubesOS platform support which has a bounty >> offer already but needs commited developers). Let's remember that their >> Blackbird/Talos II platforms recently got RYF certification. >> - The last x86 platform having met RYF criteria is the X200, >> thanks to the Libreboot project, which removed Intel ME. >> - Since then, the x86 platforms have blobs we have to accept/deal >> with to make it trustworthier: >> - Sandy Bridge/Ivy bridge : EC firmware, Intel ME BUP ROMP >> modules. Coreboot doesnt rely on FSP blobs for initialization. ME is >> actually neutered (no kernel nor syslibs as opposed to newer >> platforms, >> just BUP and ROMP) and deactivated (AltMeDisable bit, not HAP bit). >> - More recent hardware requires ME with its kernel and syslibs >> binary blobs present, while ME is asked to be deactivated through >> HAP bit, >> requires Intel FSP and other binary blobs for hardware >> initialization. >> - Insurgo works to bridge the gap to broader QubesOS >> accessibility, so that users in need of remote support can have secured >> remote administration from trusted third parties (new revenue? AccessNow? >> Other third parties?) over hidden tor onion service from additional GUI >> (NlNet grant for Accessible Security project). >> - Insurgo tries its best to support Heads community through GitHub >> opened issues while promoting collaboration. >> - Insurgo tries its best to mainstream CI build systems to produce >> reproducible builds artifacts (this is broken for months and is still not >> resolved). >> - Insurgo tries to raise awareness of researchers and developers on >> the current state of "Open Source Firmware" (currently requiring FSP, ME >> or >> equivalent,not having completely neutered Intel ME while claiming it is >> deactivated, while system libraries and kernel is still there but >> latent...) This implies going to conferences, doing talks, confronting the >> status quo, researching, developing so we have alternatives in the >> future....while also doing the required clerical work. >> - Insurgo made QubesOS preinstallable for the first time on the >> PrivacyBeast X230, thanks to its reownership wizard which takes care of >> GPG >> key generation, internal ROM reflashing, TPM ownership and sealing of >> measurements, signing boot configuration, while enforcing diceware >> passphrases in the provisioning phase. The goal is to generalize it to >> other platforms. Ideally through collaboration... >> - Insurgo made the PrivacyBeast X230 certified by QubesOS, with a lot >> of work done on Heads that is unfortunately not upstreamed yet. Will go >> back at this, while branch is available through Gitlab and GitHub. >> - Insurgo collaborates with other parties to make needed work to have >> fwupd (firmware upgrades), available inside of QubesOS, including Heads >> firmware, thanks to NlNet Privacy and Trust grant, once again. >> - Insurgo tries to push verified boot to measure also the LVM >> containers inside of deployed QubesOS reencrypted disk installation, >> through Heads, so that third party OEMs could also deploy reproducible >> ROMs >> that are measureable, verify their reproducibility, have verified boot and >> known good QubesOS installation with safer defaults to deploy to users by >> themselves (LUKS discards, MAC randomization, sdcard attached to sys-usb >> and others). The user would not have to trust those third parties on the >> RoT. >> - Add internationalization into Heads, so that UK keyboards and other >> keymaps can be selected at first boot and saved into the ROM at ownership. >> - .... Other work required by both QubesOS, Heads and their >> subprojects for more accessible security and usability. >> >> There is something really interesting in the open source world. >> >> Bigger corporation will pay for the development work they require to fit >> their needs and upstream changes. This makes software and accomplished work >> feel like free as in free beer. >> >> Meanwhile, when a small player tries to make important changes for >> everyone in related projects, with really limited resources, people apply >> the same free as in free beer logic since they can buy second hand hardware >> online at lower price and do the reprogramming themselves, not >> understanding even the differences on the model they are buying and the >> changes in costs associated with the model they buy, nor the privilege they >> have to be able to do required technical work themselves nor the knowledge >> privilege they have of knowing that such hardware and free software exist >> with which their hardware can be freed with. >> >> Of course, you can and are encouraged to backup your SPI flash chips, >> unlock the rom, apply me_cleaner, flash ME and Heads back into SPI flash >> chips, replace the wifi card, factory reset your USB security dongle, seal >> secrets for remote attestation and sign boot components, if you are tech >> savvy enough to do it right, yourself. >> >> Meanwhile, Insurgo's goal is to facilitate that DIY, while still making >> money enough to pay itself and others to do the technical required work... >> so that you can do it yourself if you'd like, while organizations needing >> this kind of privacy/confidentiality/security for their users can also do >> the work for their users, without knowing all the technical details. On the >> X230 now, and other platforms in the near future. >> >> Meanwhile, the x230 i7 2.9ghz, with its IPS screen and replaced wifi >> card, maximized 16GB ram and 256GB SSD drive, which makes the PrivacyBeast >> X230 hardware, is the one of the last platform on which open source >> firmware can fully thrive, meeting QubesOS requirements, pushing things the >> farthest possible by truely neutering ME (releasing 5Mb of additional ROM >> space to do more stuff from the boot environment), using its TPM to do the >> measured boot functions, sealing secrets into a QR code that enforces >> remote attestation through TOTP (smartphone based manual validation) or >> HOTP USB security dongles (Librem Key/Nitrokey Pro and Nitrokey Storage >> which visually attests of firmware integrity with a green or red LED), >> while using OpenGPG functions of the smartcard to enforce verified boot on >> QubesOS core system components (/boot), making those root of trust required >> components tamper evident. >> >> Thanks for you time. Equip yourself accordingly. :) >> >> Thierry Laurion >> Insurgo, Open Technologies >> > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/df275a80-4ca6-45f9-b284-1ae34fc41fc4%40googlegroups.com > <https://groups.google.com/d/msgid/qubes-users/df275a80-4ca6-45f9-b284-1ae34fc41fc4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Thierry Laurion -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAAzJznzvEKqWm-TwXMwJLDpUJBmiK2nfxqTx1MmxsrxVMmQmvw%40mail.gmail.com.
