Having this bug https://github.com/HelloZeroNet/ZeroBlog/issues/75
Making reasonably secure hardware a reality for the masses.
Having this bug https://github.com/HelloZeroNet/ZeroBlog/issues/75
Time to comment on its content and things that are not clear enough for you!!!!
Give me all the feedback you want!
QubesOS public announce will follow!
A month ago, I tried to do a proof of concept and decided to try to create a Windows 7 Pro OEM (Citrix) QubesOS template and see if it was possible to activate it with Lenovo X230 Product Key on the back of my own, to be QubesOS certified, refurbished PrivacyBeast.
No surprise, the automatic activation failed within the TemplateVM. But interestingly, following the Windows Activation by phone worked!
I find contradicting information online. For both Privacy and Legality.
Some sources say that the image needs to be Sysprep'ed to remove uniquely identifiable Windows installation ID. Some other says that deploying non activated Windows copies (clones) are legally acceptable. I would need a licensing legal GURU advice here.
The other problem would be to not have uniquely identifiable Windows installation ID. Some Windows GURU around here that have some Powershell or other that would be launched on next boot to recreate that identifier? I would need a Windows privacy GURU advice here.
Deploying Windows 7 TemplateVM would facilitate the QubesOS/Linux learning curve by permitting the user to install currently used softwares in the TemplateVM, while creating required compartments that would depend on it, making only "Documents and Settings" prone to user errors while they learn the benefits of QubesOS preventive compartmentalization architecture.
Thanks for your help, guys/gals.
In QubesOS, the TemplateVM is instanciated in read only by the "qube" that used it as a template, discarding changes upon reboot. Installing a software (or malware) in the VM would be installed in an overlay survive that VM boot, but the TemplateVM wouldn't be touched at all and the changes be dismissed at reboot.
Activating a copy of Windows, installing software, updates, or syspreping the image would require to be done in the TemplateVM itself for the state to be kept in across TemplateVM instantiations from VMs and across reboots.
Now, my real question is, for privacy needs: Does the image NEEDS to be sysprep'ed before being cloned to individual physical machines TO NOT SHARE some unique identification, bound to Windows Installation ID?
Since we are talking about a VM, the "hardware" linked to the installation will always be the same across physical deployments, so the drivers being deployed for QubesOS VM<->Xen hypervisor are required to properly support network and disk operations (qvm-copy, XEN drivers, etc). So no need to make that installation generalized, only not indentifiable. Does that change the process or commands implied?
In the last month, I've been working on the e-commence side of my website to make it ready for launch.
This means dealing with Canada taxes, shipping extensions and dealing with shipping carriers... A long adventure I'm looking forward to have behind me.
At first, Stripe was recommended to me for it's simplicity and competitive costs.
But then, after doing tests, my designer and I went clueless on a glitch that was present on stripe embedded code on my website. It was impossible to enter credit card numbers... After a lot of searching, we come on this post which basically says that people behind a proxy (or Tor... sharing a same IP) may have problems using the payment gateway...
And then today, I used Paypal to pay for something, which I haven't done for a long time and realized how their automatic system might be problematic for people behind a proxy/VPN/Tor. After having erased old phone numbers in my account, 2FA linked my new phone number and configured TOTP, I came on the same error even after validating my identity through a SMS sent to my phone to login. Paypal was "unable to verify my identity" when trying to pay, even though my identity was verified at login.
Called them. They resetted their system and said to me that I could go forward with my payment in 4 hours. 4 hours later I was on the phone again with them and... Basically, the non-dumb guy said to me "You have to reset your password from an IP that is not shared for the process to work and reset your precedent login locations..."
So my question to you guys is this: which payment gateway is Tor/VPN/proxy friendly and doesn't require geolocalization?
From a security perspective (not to be confounded with surveillance), nothing justifies that a user, which proves his identity by his password(something he knows) and confirms a 2FA on his phone (something he owns) should be required to disclose his geolocalization to pay for a service or a product.
Yet again. The billing address is linked to the credit card and home address, while the shipping address doesn't need to be the same as the billing address. But I'm curious. Is there something better to make a statement and force such system usage for the masses?
Back in March 2019, a sad news touched the privacy conscious people around the world: LineageOS dropped support of all 14.1 supported devices. Understandable but still a really sad news.
That included the freedom defenders loved Galaxy S3 (I9300(GSM)/I905(LTE) and the Note 2 (N7100) devices, consequently also dropped from microG for LineageOS, the project which permits to use Android without depending on Google's services to have a usable phone without completely compromising user's choices of application choices. EG: permitting the user to use Signal (dependent on Google's Cloud Messaging [push notifications])
Why is it a big deal?
Because fully open source powered phones, permitting full user control over hardware, are rare. Replicant dropped support of Android maintenance on those devices a while ago. Even though the chipset of those phones were to be even more liberated, with the promise of being completely freed devices from the ground up, as opposed to be tracking devices by default, as all other currently manufactured phones with binary-blob initialized components and spywares installed without users knowing or having a possibility to know.
AND THEN! Got pointed simultaneously by two different sources to Replicant being funded to port LineageOS up to 16.1 for those devices, working on upstreaming it back and include fourkbomb's work!
Keep a genuinely curious eye on that!
Currently doing last tests before sending E-mail to QubesOS for code review!
You own a Lenovo X230, a InPlace SPI programmer and a Librem Key/NitroKey Pro/NitroKey Storage?
Time to make your X230 the most trustworthy laptop available and pair to what is to be the PrivacyBeast X230, to be certified by QubesOS!!!!
The additions to Heads in this PR are broad. But mainly aims to ease OEM deploy QubesOS preinstalled in a secured way, making the firmware and QubesOS installation tamper evident, so you are sure that the package you receive by mail is in the same state it was in when it left Insurgo's facility.
That addition easily transfers ownership from OEM to the user by replacing secrets first thing upon reception of hardware. Even if the OEM was asked to reveal those secrets, the user would know that the firmware and/or the /boot partition has been tampered with, making it untrustworthy.
Take a peak here!
This is a repost from Insurgo's Facebook Page.
#x86 processors/CPUs (#Intel, #AMD) need to be replaced by open source hardware alternatives.
The x86 architecture is rotten to its roots with deep #DesignFlaws, for which vulnerabilities are discovered at an increasing pace since December 2017/January 2018 with MeltDown/Spectre speculative flaws. And now with #ZombieLoad .
ZombieLoad is the invasive newcomer, exploiting the theoretical design flaws in really practical ways, see linked demo. But it can be mitigated. Reactively and preventively.
Reactively by applying microcode updates, those corrective patches applied at runtime by your Operating System, directly to your CPU software (yes, there is software in your processor, as everywhere else), instructing it to compute stuff differently from when it left the manufacture. And through Operating system updates, who will take advantage of the microcode fixes... Until a new vulnerability is exposed from known design flaws.
On the preventive side, Xen, a virtualization platform, used in QubesOS to compartmentalize your digital life to fit your needs, isolates your needed daily applications in different isolated compartments. QubesOS "virtualises" those environments in HVM(Hardware isolated Virtual Machines), taking also advantage of the microcode update, while limiting the reach of those continuously discovered vulnerabilities to the sole realm of that compromised "insecure" compartment, preventing it from easily stealing secrets from your "ClientX", "Work E-Mail" or "Social Media" compartments, running applications concurrently on your physical machine.
Your "Accounting", "ClientZ" and "vault" compartments, unpowered at the moment, don't expose any of their secrets, simply because they are not active; not in memory. In simple words, QubesOS empowers you with multiple virtual machines inside of a single physical computer, letting you launch only required applications inside of them and only when you need them. You can seemlessly have 3 different Firefox, running distinctively from different compartments, filling different needs, without them stealing easily information from each other. You compartiment your life. What is personal stays personal. What is professional stays professional. What is untrusted stays untrusted and can even be deleted as needed. You get the picture.
Otherwise, Windows, MacOSX or Linux, which are monolithic by design, run everything in the same "realm", possibly exposing the content (memory) of your concurrent applications, consequently to discovered CPU vulnerabilities. That's right: your recently typed password, your deleted browsing history, your recently sent encrypted e-mail (plain text) content, your (not so) private messages, your encryption key and its passphrase... All of those can be accessed by a malicious application running concurrently, passively monitoring information it's interested in, as you go. Have you watched the demo?
Until user-friendly #compartmentalization technologies like QubesOS become available on x86 open hardware alternatives (like #Power9 or #RISC-V), #QubesOS on x86 is your best friend, while x86's hyperthreading and speculative execution design flaws are filthy traitors who have cheated for too long to arrive first at the finish line... with doped performances, multiple times exposed to the world for everyone to see.
Catch home message: an information that is in memory is an information that can potentially leak; to other applications sharing physical memory on your own machine, to other virtual machines on the same physical machine. Your preferred cloud outsourced server is the same: they are basically and most commonly containers (less #trustworthy then HVMs) running concurrently on the same physical server and sharing even more then virtual machines, potentially leaking each other's applications secrets without any probable oversight.
Be conscious of what you keep in memory. :)
A quick instruction post.
Follow these instruction to install docker inside of a debian-9 or cloned debian-9 template, with additional requirement of sudo apt-get install docker-compose
TODO: find a way to make TemplateVM usermod command above persist inside qube. (Right now, user "user" is not part of docker group for obscure reason.
Datashare qube, created out of debian-9 TemplateVM
Datashare instructions are here
chmod +x datashare.sh
sudo usermod -aG docker user (SHOULD BE PERSISTENT IN TEMPLATEVM)
A lot of questions arised following the new wave of discovered CPU vulnerabilities. Let me be clear on this, the x86 architecture should be considered harmful and we need to transition out of it ASAP.
Meanwhile, read this comprehensive article and watch its attached video to understand why QubesOS is the best we currently have to drive untrusted hardware and software, while some reasonably secure x86 platforms still exist (Asus KGPE-d16, Asus KCMA-D8, Lenovo x230, Lenovo G505S) which meets QubesOS requirements, starts from open source firmware which can attest of root of trust integrity... until alternatives x86 architectures get supported.
Until new architectures (Risc-V, Power9) get proper support from QubesOS, x86 is the only user friendly, secure and accessible choice to not completely give up on Windows (but securely isolate its usage, and use it only when required, same applying to insecure software, in different compartments), read transition out of it, while limiting impact of compromising the entire system by daily actions by segregating them properly. See QubesOS security goals. See QubesOS use cases.
QubesOS, a prevention and compartmentalization based security, has preemptively deactivated SMT, or HyperThreading, on Xen boot, which is underlying most of the problems that we saw arising since January 2018 from CPU vulnerabilities, while moving into full virtualization (HVM/PVH) since QubesOS 4, changing its hardware requirements (SLAT, VT-d, VT-x) which unfortunately are not always properly initialized by lazy hardware manufacturers customized BIOSes.
Lately i've been searching for ZeroNet platforms which were used to host/receive massive leaks in a decentralized and anonymous way, but found none fitting required criteria.
Such platforms would empower investigative journalists and leakers.
ZeroNet rassembles the main required features that would permit such system [ Decentralized and distributed publishing/hosting of content through onion hidden sites, censor resistance, IPFS-like file hosting through pinning, strong anonymity, multiple persona switching, accountability while not bound to a real identity, strong and asynchronous collaboration... ].
It feels like ZeroNet could complement SecureDrop into crowdsourcing (pun intended) investigative journalism... if ZeroNet oriented developers wanted to go into that direction.
The platform must be able to host files and corresponding descriptions, should permit discussions/comments on those files and permit private contact of original leaker of material for which ZeroMail already fills the requirements.
If we dream big enough, it could be something like sovereign around disclosed information, empowering experts, civils and investigative journalists into collaborating to ease work around risky wrongdoing reporting, reducing threats for parties involved. See historic panama papers documentary to better understand the need for such decentralized, anonymous cooperative platform, or at the very least, decentralized hosting of leaked files so entities, like WikiLeaks, cannot be blamed for choosing what goes public or not. This would bring some level of chaos at the beginning, just like what WikiLeaks brang at the beginning. But after a little while, everyone became confortable with the idea, until transparency considerations and free electron and personal biases of the organization corrupted the unbiased information source that WikiLeaks could have been, because they filtered and selected the information before it reached journalists. Everyone's free will, combined with ethical and moral ethic prior to leaking information, would, IMOHO, balances itself in time.
Any hints or existing platforms to refer?
I DO NOT INTEND TO TAKE A POLITICAL STANCE HERE.
I'm simply amazed of ZeroNet ecosystem possibilities, which would empower transparency and anonymous collaboration like it was never possible before.
Thanks for participating in the discussion!
I'm asking to review this PR.
This is my personal attempt to bridge the missing gap permitting QubesOS to be preinstalled by OEM, like myself, on reasonably secure hardware, while certifying the best second hand laptop available today, the X230.
What was previously missing to make QubesOS preinstalled was the possibility to reencrypt (cryptsetup-reencrypt) OS installation, but thanks to coreboot linux payload inside of Heads, this out of the box idea resolves the issue in a secured environment.
To have a provable root of trust, the Trusted Platform Module (TPM) needs to be initialized as early as possible and take measurements of the different parts of the firmware. Heads does it. That was the whole goal of the initial project. It did it initially by providing a TOTP tooling that synced with a OTP application on your smartphone. But that is geeky for daily use, and not super user friendly.
Then, Purism brang HOTP to NitroKey and made their Librem Key, turning TOTP manual verification on phone into a backup solution, making it as simple as making a LED flash green if the measurements are valid or red otherwise. That is a total game changer for non geeks, bringing security to the masses. Thanks to them, they made the code open source and transferable to other platforms supported by Heads, with or without a TPM being present.
Before this OEM Reownership Wizard into Heads, the user was obligated to install the OS himself on top of an untrusty proprietary BIOS coming from a untrustable manufacturer, never knowing if a rootkit was ever present or if his computing root of trust was ever really trustworthy. With Heads being reproducible, you know it is. You can validate it. And you can download reproducible rom from a CI, you can build it manually, or you can reproduce the CI yourself and have the same resulting ROM yourself.
With Heads supporting more and more platforms, one tool was missing, giving OEM around the world the possibility to prepare QubesOS preinstalled systems not aimed at geeks. Most right defenders or journalists requiring secured systems are not geeks.
So. This PR permits assisted reownership of root of trust.
Provisioned user secrets permits reencryption of LUKS encrypted device, change its passphrase, factory reset received Librem Key/NitroKey, used on first boot to validate boot and firmware integrity as when it left OEM hands, replacing Admin and User PINs and generating at the same time encryption/signing/authenticating keys on its protected smarcard and public key, which are usable to other means to secure e-mails, encrypt files and authenticate with SSH servers if desired. That generated public key is inserted in the rom to automatically validate that the files checksums are the ones expected at each boot, making it cryptographically validated.
The final steps of the reownership is to sign /boot configuration, reown the TPM and select a LUKS Disk Unlock Key passphrase, different then the Disk Recovery Key passphrase that should stay completely secret. The Disk Unlock Key passphrase is only usable on this computer, preventing prying eyes to be able to type that passphrase on a cloned copy of the disk, the key being bound to TPM measurements of the firmware and the LUKS header, as opposed to the Disk Recovery Key passphrase that if captured, could unlock a cloned copy of the disk.
So voilà. Please review whiptail calls for user understandable prompts. Please review bash code for imperfection. Give as most feedback possible so that this code be usable by other OEM. The end goal being that journalists and right defenders are weaponized to do their jobs, while freedom defenders have the possibility to easily own a secure hardware themselves. And me make a bit of money by making the most trustworthy, powerful enough hardware to empower not geeky users with the most trustworthy, QubesOS certified hardware accessible online to buy.
That code will be frozen for a year and deployed on my PrivacyBeast x230 in the next coming weeks.
This means a lot to me!
Main website, selling the QubesOS certified PrivacyBeast X230 will be up in the next coming days, following joint announcement from QubesOS and Insurgo. Stay tuned!
I'm doing the last improvements on this PR, so that the provisioning of secrets of the reownership process is both secure and the most user-friendly possible. (No, you can't delete files on a SSD, USB Flash Drives by simply overwriting data on it. Full disk encryption is your only friend.)
The last step currently missing is to store provisioning secrets securely on a LUKS encrypted partition on provided USB disk, so the user feeds the secrets once manually to the reownership wizard which stores them in the LUKS encrypted filesystem on provided microSD adapter to reown crucial parts of his future root of turst. The wizard will then factory reset its Librem Key/Nitrokey, reencrypt his LUKS container, change its passphrase and reowns the TPM seemlessly, sign config files and choose a LUKS Disk Unlock Key that he will type at every system startup (bound to TPM measurements), while having a secured backup of those secrets on the USB LUKS container, for both the provisioning and then in case those were forgotten. Better safe then sorry. Reminding oneself of those from another computer being then possible.
The way to proceed properly with this is currently discussed with QubesOS team, will be implemented prior of a final round of tests before going public. The website is also been reviewed and worked on prior to launch.
Meanwhile, i'll work when I have time on my KGPE-D16 to host this zite myself too, which will host anonymous interactions on technical matters. That server didn't received love for a while, now. This is why you, hosting this zite is important to me right now! Else it's being up only when I work, currently!
Don't hesitate to comment! I want this to be a community project, as QubesOS and Heads are! Should I do a forum also? Which one do you suggest?
The instructions have been updated here.
The onion-grater example has been updated here and will soon be updated to Whonix repositories.
Discussion happened here before resolution.
This ZeroBlog is finally alive. Please host.
Insurgo's x230 refurbished reasonably secure laptop is currently being certified! What gives?
The user will finally be able to buy trustworthy cost-effective and durable laptops with QubesOS 4 preinstalled, booting from open source firmware and be reassured it hasn't been tampered with in transit before reowning shipped hardware himself through a user friendly Wizard at first boot!
How is that accomplished? Heads Open Source Firmware does all the required magic!
Behind the scene, Insurgo first backups the two SPI flash chips, neutralizes Intel ME on the 8MB SPI flash and delete most of the potentially harmful rootkit modules. Then, a reproducible x230-flash build of Heads' Open Source Firmware is flashed into the 4MB SPI flash. Then, a full x230 build of Heads is flashed into the combined 12MB flash, empowering the laptop with a full blown and graphical recovery environment.
Insurgo then uses Heads itself to own the laptop's TPM and factory resets a brand new Librem Key/NitroKey Pro V2, with KeepassXC diceware selected user and admin PINs and injects the generated GPG public key into the preflashed rom. That public key will validate /boot signatures, signed in combination with the private key securely stored into the NitroKey/Librem Key, prior to booting Qubes' Xen, initrd and kernel at each boot. The user would be informed of any boot configuration and firmware changes not matching the measured and signed ones.
As a result, Insurgo provides the user all current ownership secrets, including the TPMTOTP QRCode resulting of the TPM firmware measurements, which is scanned by the user through and OTP application on his smartphone, used like any two-factor authentication token. That QRCode can be scanned by the user from Insurgo secured communication following hardware preparation prior to shipping, prior to receiving the hardware. The resulting 6 digits, that changes every 30 seconds, will be shown to the user at first boot and is used to validate that the firmware has not been tampered with. A Disk Unlock Key, different from the Disk Recovery Key password, will be required to boot QubesOS at each machine startup. That Disk Unlock Key is randomly generated and injected in the LUKS header when selecting a boot new boot default. To use it, the user has to enter a selected passphrase, that will unlock the disk only if TPM firmware measurements and LUKS headers are as expected, attesting that the hardware is still trustworthy to use. Otherwise the typed passphrase will fail to boot the installed system and will require the user to type his chosen Disk Recovery Key passphrase.
The Librem Key/NitroKey Pro v2 validates the firmware integrity based on the TPM firmware measurements, but instead of requiring the user to pop his smartphone and check the TOTP changing 6 numbers, the USB key flashes green if the firmware integrity is attested or red otherwise. The USB key will be asked to be inserted at each Heads boot, while the TPMTOTP can be used as a fallback if the key is lost, while waiting for another ordered one to be delivered. Note that the NitroKey/Librem Key also empowers the user to encrypt his files and e-mail communications while securing his private key into the USB card, being tamper-proof and locking out any attacker after 3 bad attempts. This is seriously as best as it can get.
Those two integrity attestation methods provided by measured boot implementation present into Heads Open Source Firmware will guarantee to the user that the hardware is in the state it was when it left Insurgo.
At first boot, a Wizard will take the user by the hand into reowning the shipped hardware. It will first reencrypt the disk content, so Insurgo doesn't know the encryption key anymore and request him to define a new disk recovery disk passphrase. It will then factory reset it's NitroKey/Librem Key and require of him new user and admin PINs of his own. The wizard will then ask to reown the TPM with a new PIN and will finalize the reownership by asking from the user to define a new disk unlock passphrase, bound to TPM measurements, which will be asked of him each time he boots QubesOS.
The KGPE-D16 is the most accessible and owner controllable motherboard available new/used today permitting to build powerful and reasonably secure workstations and servers infrastructures.
The KGPE-D16 coreboot port was funded by Libreboot, (Thanks Leah for the funding and thanks Timothy Pearson for the port!) which permits native hardware initialization of the hardware. Even the remote management engine development was crowdfunded to develop an OpenBMC port, thanks again to Timothy Pearson for all the work that he as done for that motherboard. Note that his Talos II platform brings ownership even further by ditching x86 architecture completely and integrating IBM's Power9 processors, for even more control and openness, while the Power9 architecture is not yet supported by QubesOS.
The present KGPE-D16 beast could at term be remote attested booted through OpenBMC (Measured boot upon reboot), with Heads integrity being remotely verified through TPMTOTP on cellphone when TPM2 is supported with a proper management toolset. To achieve this, the motherboard needs to boot from Head's coreboot firmware, which boots a linux payload that kexec linux compatible kernel (here, it's a multiboot xen + linux environment: QubesOS 4.0) once verified. The QubesOs remote administration of the server could then be achieved by accessing it through an AdminVM, reachable through a tor hidden ssh service. For the moment, dom0 is accessible through /dev/ttyS0 directly from OpenBMC, which is reachable by a dedicated network card.
There are currently some limitations to achieve those goals. This blog post will trace the problems and solutions to permit a transition to reasonably secure computing for the masses.
TPM v2.0 is not implemented in Heads, so measured boot is not yet achieved.