Security liability for software vendors, open source on end of support? Great ideas France!

This is a tough slog of a read (167 pages), but there is a proposal from France on cyber security (the parent web page here). I tried a machine-translation to English, but, well, the fonts are embedded as images somehow. Hmm, its like a scan, its a set of pictures. Boo. OCR? What is this, 1990? Plus the font is some sort of comic-sans/cursive script, with accents, I'm not optimistic. So I'll slog on w/ my amateur French.

In a nutshell:

  • Don't lose individual privacy or freedoms while fighting oppressors
  • Private companies cannot fight back
  • Companies can be liable for cyber-vulnerability in their products as long as commercially available
    • And should release source and docs at end of life
  • A hotline (think the red phone from the cold-war) to call other 'actors'
  • Sovereign state can use cyber-offense as part of defense
  • Education of people
  • 249 systematically important organisations

PS, I tried the OCR. Tesseract has a Long-Short-Term-Memory machine-learning approach. The training set is small, which surprises me.

convert -verbose -page a4 -density 300 -quality 00 -flatten 20180206-np-revue-cyber-public-v3.3-publication.pdf revue-cyber-%d.png
tesseract -l fra revue-cyber-2.png

And it output:

DeSs MONACES en éVOUTION emecm emcem ssem m osmme me smme mem emme vamem n eee 11
1.1.1. — lL‘espionnage .c ccc ec ecec rsc rs r rrr rrr rs rs 11
1.1.2. — La CYDEPCTIMÎIMAUTÉ ccce ce sec ose se se se sem eme se se eme se 12
1.1—3, LÀ L SALLOÔTI ssme nsme eme nsem ne ee ee eeme o 13

From this input.

So, i'm not going to spend more time on this. I mean, yeah, its kinda working, and i guess finding and training the font, etc.

So, in the comments... If you are a native cyber-french speaker, what did you find in the doc?

Also, if you are a OCRist-extraordinaire, and want to have a crack, let me know.

Self-signed secure boot, the why, the how, the what to look out for

So I am hoping that all of you have not only an encrypted root disk, but also UEFI secure boot enabled. I am guessing that most of you have enabled that with the default (Microsoft) keys. Here I will outline how I changed methodology on my portable, and some of the challenges I ran into.

First, lets talk about the models of security. Encryption. You want your entire disk (100%) encrypted. This means when you turn the PC on, you must present a password (which is different than your login password, and predates it, it comes up very early). This is before your operating system loads. You want this password to be a) different than your login password, b) strong. It should be 30+ characters in length. Its a passphrase. What full disk encryption ensures is that when (yes when) your PC goes walkabout and ends up on ebay, that there is no change that randoms get access to your Snap archive (you know what i'm talking about).

What is your laptop security strategy

View Results

Loading ... Loading ...

OK, so that is what most of us consider "the big risk". Its enough right? Wrong. What if a bad actor wants access to that disk? They could insert new bad firmware or bootloader in the chain, and then when you enter your password, they are in. Google 'rootkit'. What you really need is to make sure that the system is not tampered with in addition to not being read. And that is where secure boot comes in.

What secure boot does is create a chain of trust. Your machine boots, the bios is signed, it loads some keys from a trusted platform module (tpm). These keys are used to check that the first stage bootloader is not modified, and then it checks the next stage, etc. So each level attests the next level is trusted. Typically these keys are 'default' and managed by Microsoft, allowing you to load the Windows 10 bootloader, and onwards. But what if you don't run Windows? Well, Canonical has a signed-shim (signed by Microsoft, and then it will load grub). And this signed-shim turns out to be not so strong. In fact, well, read the salty twitter stream on the subject, and, weakened the world.

OK, my tinfoil hat is starting to adjust properly, you mean that I have this risk and I should not trust the upstream Microsoft keys (cuz who else has those? Is there maybe some clipper-chip key escrow controversy etc?). Seems up my alley, how hard can it be to create a couple of self-signed certs and some passphrases?

Um, a bit. Since we are using Linux here, we are also using grub. So I need to get a signed copy of grub. And all the modules. And the config. OK, no problem, we can create a grub ramdisk, a sort of initrd, and make a single bundle of grub plus this with all modules, signed. And then we can insert the PK/KEK/db keys into our BIOS.

Fortunately, as you would imagine in the FOSS world, there is a plethora of partial solutions out there, all of which have some troubles 🙂 So I picked one, forked it on Github, and 'fixed' it. Here you go. What this does is 'redirect' update-grub, grub-install so that everytime a new kernel is built/installed, grub is updated and re-signed. The keys are stored in /etc on the full-disk-encryption, so safe.

OK, once this is in place, my PC will only boot my signed code, all the way up. Along the way it will ask for the encryption keys for the disk.

How could someone attack this?

Well, I need a BIOS supervisor password to prevent someone disabling secure boot. So that needs to be strong. If you want to be scared of this, google ALAA4ABA. No really. Did you do it?  Sigh, some sort of 'magic algorithm'. If someone can reset my date to a specific one, they can reset my password. Grr.

How else? Well, my disk now has /efi (vfat, not encrypted, but signed) and /boot (on the encrypted root). But I had to move /boot there, it defaulted to the non-encrypted part. This means someone could tamper with the old kernel there, and maybe trick me into re-signing it on the next run.

So... for those who have already enabled secure boot with your own keys, maybe comment on how you achieved it?

For those who have not enabled secure boot, I would recommend at a minimum enabling the 'default' keys, they work with Linux (at least Ubuntu, not sure on others) and also Windows.

For MAC users? Your immense sense of smugness is your primary (and only) protection. Only the iMac Pro supports security, so I would assume all your bases are belong to us.

For some of you, you will be using Microsoft BitLocker. I don't think this should make you feel very strong.

Let’s Encrypt: huge impact to society, to me, and wildcards coming soon!

OK, there's been a minor delay in wildcard support at Let's Encrypt. But, i'd rather a delay than an insecure cert. So keep up the good work!

Now, I use Let's Encrypt for a variety of purposes here at mi casa. All the public web sites I run from home use a cert (the blog, git, nextcloud, router-web-luci, ...). But to date I've not really been able to use it for internal-only things (e.g. the BMC on my SuperMicro motherboard, those somewhat wretched Hikvision cameras,  etc.). And the reason is, I don't expose them to the Internet, so I cannot (simply) expose them to the Let's Encrypt infrastructure (and some of them use TLS but not for HTTP, e.g. MQTT). Now, I could use a DNS wildcard, have a bastion host pretend to be them, sign, move the certs, ... Perhaps.

But, with the advent of wildcard, I can sign a wildcard for all the miscellany IoT widgets that wander my halls. Its better than 'snake oil inc' self-signed certs, although not infinitely strong (e.g. if I lose that wildcard, all devices go).

I had considered running my own CA internally, which is an approach a lot of companies use. But, running a CA is hard (when doing it right). And then, well, what other devices would I need to trust my CA? Would my Chromecast need it to get to my NAS? But I cannot add a private CA to the Chromecast. So that idea struck out, its left on the dustbin of history.

So, if you are not currently using TLS for something, get on it, the good folks at Let's Encrypt have made it easy and cheap. And, lets all look forward to a great implementation of free wildcards and thus more secure Sous-Vide's!

Bitcoin crypto mining hashing spectrum, breaking mobiles, endangering first responders


Bitcoin. powered by coal, it uses more power than Ireland, and now it is interfering with the mobile network, first responders, and endangering lives.

How so? Well, the rigs that people are building en-masse look like this. Notice any RF shielding? Nope. And, its a lot of high-speed electronics with a lot of wiring. This image looks not too bad, but realise that people are putting tens of thousands of these together. And sometimes they don't take as much care, see the next photo.

All that RF noise is interfering with legitimate radio uses (Television, mobile phones, WiFi, you name it).

And when the spectrum is licensed, the regulator can come calling. As the FCC did in this case. Their letter alleges that this individual caused interference with the T-Mobile 700MHz network in New York City. And the 700MHz band is where your first responders are working, both in Canada, and the US. (Note the interference by these things would be fairly broad-based, so more than just 700MHz will be impacted).

And its causing big problems. First, these setups are catching fire, in residential multi-dwelling units, this is unsafe. Similar to grow-ups, people are stealing power, tapping into the grid (which was ultimately the cause of this fire).

But also, if the RF noise is interfering with the underlying communications network, lives could be at risk. We are not talking about a couple of bad splices in your home-cable-rg59-wiring, nor about one or two PC's you might run with the lid off. We are talking industrial scale, often mega-watt powered, wiring rats nests operating in the microwave range.

Its not a few hobbyists using an idle GPU that will cause this problem, its those doing it at scale. Anyone who has a 'room' for their mining, or a converted garage/shed, open-rack machines full of GPU's.

So, if you know a friend who is dabbling, maybe get them to read the FCC letter, and get some shielding (and maybe an electrical/fire safety inspection). Before someone gets hurt.

The LoRaWAN dragon comes to roost at my house

LoRaWAN. Its a magical network that uses unlicensed spectrum (915MHz for me), runs longish distances with stupidly low power (years of battery life), and is designed to make your things network in internet-styles. And now its in my house.

At right we see a Dragino gateway. Who is Dragino you ask? Well, in their own words: "Dragino dedicates to promote Open Source IoT solution. Our Open Source products are sold world widely and gain good names in the Open Source Internet of Things filed." I think that is pretty clear! They make a gateway (and you don't necessarily need a gateway in LoRa) that runs OpenWRT. And they have a YouTube video with real production values (see end).

Coupled with that I have a pair of ESP32 LoRa micro, powered up, and happily chatting. That was easy!

OK, digging in a bit, this is a single-channel device, it seems it is more of a node than a gateway. Hmm. But, well, the company has done a decent job here, documentation on connecting to The Things Network, on using it with open source, on compiling for it. Its not common for Shenzen-express-type products to have anything other than the box they came in. So kudos for that. Even the ESP32 MCU's came w/ a github repo (and a web site, a lot of electronics that arrive at my house don't have that nicety or even a brand name). Times they are a changing!

The interior? Sure. Click the thumbnails to see the glorious detail.

 

Top