? Editing: Post:21.body Save Delete Cancel
Content changed Sign & Publish new content

Insurgo Open Technologies' ZeroBlog

Making reasonably secure hardware a reality for the masses.
Empower yourself.

Follow in NewsfeedFollowing

Latest comments:

New USA made Librem Keys on their way!!!!

on Aug 20, 2019 ·
1 comment

Thanks for all your support and interest!!!! I didn't expect that much interest, questions and suggestions. This is awesome! I'm doing my best to keep up!

A new massive batch of Librem Keys is coming toward me.
I should receive them this week. The price will be adjusted since the costs have been lowered a bit.

Meanwhile, all orders passed after the 16 won't be ready to ship until reception of the keys.

Thanks for your understanding.

Insurgo

Read more

Physical Tamper evidence - Blink comparison of taken pictures

on Aug 09, 2019

Actual work being done

The PrivacyBeast X230 comes with its main screw, attaching the keyboard and palmrest to the case, sealed with Insurgo's sticker and high contrast nail polish applied to its edges. The X230 is built in a way that makes it quite easy to notice if the SPI flash chips have been manually programmed before and if the motherboard has been touched, thanks to the water drain plastic film covering the motherboard and permitting accidental water spills to drain under the laptop.

I can consequently easily notice when I reprogram the SPI chips if i'm the first going there; the plastic film being perfectly flat and solidly glued to the SPI chips. So unless someone with high budget replaced that film to cover his tampering, I know I'm the first one going there. I reprogram the SPI chips, I screw back the case and then apply Insurgo's sticker and nail polish on the sticker edge on that main screw, being the only way to get into the case.

But that nice tamper proofing initiative doesn't help much right now, since I haven't found any good smartphone application applying blink comparison techniques which would permit me to send customers a cropped reference picture of how the laptop was prior to shipping, so they could easily compare with it, whenever in doubt someone could have intruded their laptop to insert a modchip while in transit or while the laptop was left out of sight.

Thanks to the measured boot of Heads, the firmware and boot files are still tamper evident, but if something like spispy PoC was inserted and bypassed TPM measurements and responses, there is still some possibilities left that someone could have inserted a modchip in the laptop that could make it lie about its state.

The idea of tamper evidence stickers, combined with nail polish, isn't new and practical application is quite easy.

Researchers confirm it's the easiest and most efficient way to make intrusions tamper evident.

But no smartphone application facilitates this tamper evident technology accessibility to everyone...yet.

Are you up to the challenge of making such blink comparison prototype available on Android?

First version:

  • Autocropping of borders, making the image the same size for easy human blink comparison (we're naturally good at this). A bit like CamScanner is doing it on Android, but keeping the same size, auto-cropped original picture as a reference, and rapidly switching to taken picture.

More advanced version:

  • Lighting difference cancelation

  • Automatic blink comparison and difference highlightenments

Read more

Sdcard issues while deploying

on Aug 05, 2019 ·
3 comments

Hello, early adopters.

Mea culpa.

I didn't test the PrivacyBeast Re-Ownership process on a lot of sdcards.

Doing all those orders, I realized that sdcard and MMC/SDHCI controller technology was not as stable then I thought. Reencrypting content on them resulted in IO errors which didn't happen inside QubesOS on the same sdcards, leading to search for software causes.

A little bit of patience from you guys is really appreciated. Your orders are prepared, but shipping will be delayed a little.

The Re-Ownership process, requiring reencryption of sdcard content for provisioned secrets, is failing on a lot of sdcards. The old, Linux LTS supported kernel (2017), distributed under Heads, is the culprit.

I'm working on integrating the latest kernel into Heads to fix the issue.

UPDATE: Done. See comments.

Read more

Streamlining OEM/User Heads / Intel ME reprogramming & Re-Ownership activation

on Jul 27, 2019 ·
1 comment

For this post, I take into account that flashrom, me_cleaner and Heads have already been build on fedora 30 (for ifdtool to be present to unlock Intel ME). The flash and boot rom (x230-flash and coreboot.rom) reproducible roms can be downloaded here.

So lets backup SPI roms, clean ME, and flash back roms in SPI flashes. This process is what I'm currently using, but that process will be improved in time and upstreamed into Heads documentation.

Up SPI (4Mb boot ROM):

sudo ~/flashrom/flashrom -r ~/up.rom --programmer ch341a_spi -c "MX25L3273E" && sudo ~/flashrom/flashrom -v ~/up.rom --programmer ch341a_spi -c "MX25L3273E" && sudo ~/flashrom/flashrom -w ~/QubesIncoming/Insurgo/Certified/build/x230-flash/x230-flash.rom --programmer ch341a_spi -c "MX25L3273E" && sudo ~/flashrom/flashrom -v ~/QubesIncoming/Insurgo/Certified/build/x230-flash/x230-flash.rom --programmer ch341a_spi -c "MX25L3273E"

Down SPI (8Mb Intel ME ROM):

sudo ~/flashrom/flashrom -r ~/down.rom --programmer ch341a_spi -c MX25L6405 && sudo ~/flashrom/flashrom -v ~/down.rom --programmer ch341a_spi -c MX25L6405 && ~/heads/build/coreboot-4.8.1/util/ifdtool/ifdtool -u ~/down.rom && python ~/me_cleaner/me_cleaner.py -r -t -d -S -O ~/cleaned_me.rom ~/down.rom.new --extract-me ~/extracted_me.rom && sudo ~/flashrom/flashrom -w ~/cleaned_me.rom --programmer ch341a_spi -c MX25L6405

Then boot the X230 with a USB thumb drive containing extracted artifacts downloaded from latest QubesOS_Certified branch build here. From the recovery console:

mount-usb

flash.sh /media/path/to/coreboot.rom

Voila! You have a PrivacyBeast X230 equivalent that can work on all model variations, requiring you to plug a Librem Key on next boot. The first prompt will require you to inject a public key inside of the rom. If you don't already own one, the menu will propose your to Factory Reset a Librem Key, which will accompany you in the whole process and will inject your public key in the ROM for you.

Once it's done, you can install QubesOS from the USB drive, at the condition of putting both ISO and signing files in the root of the disk:

ISO

Signing file

Or clone the disk image from clonezilla, after having injected your public key in the rom and having signed the ISO image yourself.

Enjoy!

Read more

Experiments on the Note II (N7100 [codename t03g], still maintained LineageOS 14.1 for MicroG by e.foundation!!!

on Jul 27, 2019 ·
4 comments

A couple of months ago, I got really disappointed from LineageOS dropping support on the most secured phones currently available: i9300, i9305, n7100. Understandable choice of theirs because of space constraints of having forever growing number of phones to support (even though now on ipfs...), they decided to drop support of "unmaintained" 14.1 branch phones, including the i9300 that was still the 5th most used phone in their statistics (Android 7.1.2) when they dropped support, even though that branch still received/still receives security fixes from community work. Even though really important work was in the pipeline to free even further the midas platform.

Got excited about the work done by /e/ a couple of months ago, and then forgot their existence for a while, after having suggested them to base themselves on LineageOS for MicroG instead of LineageOS.

Got even more excited when I saw Replicant was restarting their work to support those phones on 16.1 (Android 9), including the work done by forkbomb, referenced above, to push midas platform to become an even more libre platform from the booloader up, while the top down work is currently underway by Replicant. In term, that means that it could be possible to use the same kind of logic present under Heads to sign binaries between OTA upgrades (with a SmartCard) and use kexec to boot them once verified. It also means that HOTP could be used to seal measurements inside of a Librem Key. It opens possibilities to measured boot mechanisms on freer platforms, which radio and CPU are isolated from one another, while Replicant is reversing the radio and even graphic acceleration graphics, which is not even a plan for other projects/initiatives.

My i9300 reached its maximum capacity recently with current needs and threat model. Its memory of 1GB is not bearable anymore. I need to use two Signal accounts (Shelter permits control of Working profile). I need all my traffic (DNS/TCP) forced through Tor (NetGuard permits that, while being a superb pedagogical coach by letting the user know what traffic is being generated by used apps as they are used). I need to use Riot and be reachable at all times. I'm required to talk over Telegram with some cryptocurrentices guys that do not want to move to Signal nor Riot.

The i9300 is not able to fill those needs anymore. But the i9305 (LTE and 2GB) and the N7100 (3G and 2GB phablet with a pen!!!!) do.

The i9305 is the first NL funded Replicant work, attacking the i9305 model first, while the n7100 follows in the pipeline and the i9300 later on.

So long story short, I realized that /e/ is finally a LineageOS for MicroG distribution. Exactly what I was using on my i9300 (which is also supported by them with weekly builds and OTA updates here).

So my experiment on the N7100 so far:

  • The weekly builds are available here for N7100.

  • The latest TWRP doesn't support encrypted partitions properly. 3.2.3 does though, so downgrading is necessary.

  • The data partition needs to be resized inside of TWRP prior to encrypting the phone (done via wipe -> advanced wipe -> repair or change filesystem -> resize filesystem)

  • Default launcher (Bliss) doesn't play well with a work profiles. KISS launcher is just amazing for my needs. Edit: fixed here.

More to follow. Stay tuned!!!

Read more

QubesOS certified and preinstalled on Insurgo PrivacyBeast X230, now available!!!

on Jul 19, 2019 ·
1 comment

Public announcements:

QubesOS Announcement
Twitter
Facebook

For those of you that would want to ask technical questions outside of Facebook/Google/Twitter channels, here would be a good place.

Read more

I Can't comment on my own past blog posts, sorry

on Jul 16, 2019 ·
3 comments

Having this bug https://github.com/HelloZeroNet/ZeroBlog/issues/75

EDIT: fixed now!

Read more

QubesOS Certified. Website ready....

on Jul 16, 2019

Time to comment on its content and things that are not clear enough for you!!!!

https://insurgo.ca

Give me all the feedback you want!
QubesOS public announce will follow!

Read more

Windows OEM Licence clarification needed - Legal advices welcomed prior to deploy Windows 7 QubesOS TemplateVM with the PrivacyBeast

on Jun 12, 2019 ·
6 comments

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!

As a result, I am now questioning myself on the legal/privacy implications of deploying that Windows 7, non-activated, TemplateVM on to be sold PrivacyBeasts.

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.

EDIT:

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?

Insurgo

Read more

Adventures with payment gateways - Advices needed

on Jun 11, 2019 ·
6 comments

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?

Read more

The most libre smartphones will be back!

on Jun 11, 2019 ·
1 comment

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.

I tried to see where the efforts were put to continue to support those back and upstream to LineageOS.

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!

Read more

OEM ReOwnership in Heads' Open Source Firmware - Time for review

on Jun 09, 2019 ·
2 comments

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!

Read more

ZombieLoad

on May 22, 2019

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. :)

Read more

Playing with ICIJ datashare inside QubesOS

on May 18, 2019

A quick instruction post.

Debian-9 TemplateVM
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

wget https://github.com/ICIJ/datashare-installer/releases/download/1.61.2/datashare.sh

exerpt:

chmod +x datashare.sh

sudo usermod -aG docker user (SHOULD BE PERSISTENT IN TEMPLATEVM)

./datashare.sh

Read more

What is QubesOS and why it is important on x86

on May 16, 2019 ·
4 comments

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.

A discussion is happening on ZeroTalk

Insurgo

Read more
Add new post

Title

21 hours ago · 2 min read ·
3 comments
Body
Read more

Not found

Title

21 hours ago · 2 min read

0 Comments:

user_name1 day ago
Reply
Body
This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More