Coreboot Is Being Ported To A New Intel Skylake-Y System

[Archi1]

I'm not hinting at anything. It appears that every modern computer comes equipped with a backdoor that the user cannot disable or even firewall from the user's operating system, regardless of whether the user has any need or desire for such a feature.

https://www.google.com/amp/www.netwo...ngine&hl=en-us

This ME was addressed in their update here: https://www.crowdsupply.com/design-s...visible-things
It mitigates more functionalities of ME than any X86 computer.

[Archi1]

This only applies to Intel and their x86. To less degree to AMD and their recent APUs, running some nasty "security" ARM processor. Say on most ARM SBCs one could get quite decent level of control over system and no other code would get in the way.

Check their update here for ME engine mitigation https://www.crowdsupply.com/design-s...visible-things

[Archi1]

Seems Michael has got some obvious idea:


This implies its nowhere close to being "secure". Paying $700 for security snake oil? Hardly best deal ever. I guess it runs Management Engine and so on. So ppl could forget about security whatsoever. If Intel does not releases source, it is likely they've got something to hide. And past experience with proprietary software suggests it tends to be something nasty. IMHO one should be terminally dumb to pay $700 for Intel ME "secure" backdoors.

It seems more secure than the computer you are using. Tamper reaction, two factors, see here https://www.crowdsupply.com/design-s...roller-details
The ME engine is very limited by their custom BIOS and by the secure controler. Check here for more https://www.crowdsupply.com/design-s...visible-things

[SystemCrasher]

Check their update here for ME engine mitigation https://www.crowdsupply.com/design-s...visible-things

This -vvvv does not sounds appealing or satisfactory. Wish to do secure HW is good. Downplaying issues is not.

This ORWL’s proprietary uC is not going to alleviate the problems created by Intel ME in any way. Instead it will only add another ME-like device, controlled by another player. In other words: another actor(s) to worry about.
As far as we know, there is no datasheet for the Intel Management Engine (ME), even under NDA. That’s quite different than the situation with the secure MCU. In fact, the secure MCU actually mitigates some of the concerns around the Intel ME by controlling power to the Intel subsystem, thus guaranteeing the Intel ME is inactive when the Intel subsystem is shutdown. In short, the secure MCU helps reign in the Intel ME and is not nearly as opaque as the Intel ME. In this case, more actors means better behavior all around.

As far as I understand it: they acknowledge an issue. And admit they can't resolve it. Just becaus Intel left no means of doing so. Intel wants to have control. So mumbling about security on x86 is questionable to say the least. Or misnomer at the worst. Furthermore, "secure" MCU from some uncooperative vendor with blob-only firmware does not adds up either.

Say, there was company named Actel. They've advertised their "secure" FPGAs. They've advertised AES encryption of whole firmware, so even dumping flash ROM array using e.g. beam of electrons to read it out would theoretically only yield to encrypted garbage. Sounds pretty secure, eh? Even expensive invasive physical attack is thwarted.

Then there was some curious guy. That guy fed up Actel's FPGA jtag with random fuzz. Eventually it paid for itself. Guy found some fancy undocumented commands. These commands were reading FPGA firmware out of flash ROM. This happened past of decryption hardware. Actel has always been able to read out "protected" firmware. So when someone tells "secure" MCU/FPGA/etc - they have to think twice such part is really demanding for some undocumented backdoor. And unless one could do very advanced part evaluation considering most attack vectors, it is probably not brightest idea ever to stick to things like "secure" MCUs demanding NDA. Well, at least I know ways attackers are using to read out firmwares from "usual MCUs". As well as ways to thwart these attacks at least to some degree. Yet, the truth is: if high-profile attacker gains physical access to system, all you could do is to make attack is more expensive. But at most it would be like $10 000 and could be unreliable so attack attempt destroys device, so it may need several devices in worst case to get key. But either way, one better not to count of physical security. Attackers have way too much ways to try and some could be really unexpected.

p.s. speaking for myself, I'm using some few funny things I call "network guards". Li'l blob-free ARM SBCs, running quite small Linux system. They guard edges of the my network, obviously. No traffic could pass 'em unless I explicitly mark it as requested. Attacker can't physically attach serial wire, and while building OS image I've deliberately "forgot" to put other management options . This way, not even "unfirewallable" ME would pass due to ways I'm doing it. Even "covert signalling" methods are supposed to break, due to fancy ways I'm gating the traffic through. Network guard does not cares if its ME or not. Denial does not depends whether OS on computers behind it is booted and firewall rules are in place, etc. There is no "window of opportunity". Network guard HW built the way it would only pass traffic after it gets conscious and sets everything up. I'm taking control right from boot loader. After carefully analyzing everything I dare to think these are "secure" in sense they provide more or less trusted networking where it is difficult to conduct any unrequested activity and it is enforced by separate HW device, built the right way to do its job. I've got fancy idea OpenHardware computers could use e.g. some improved/polished version of this tech to secure their networking. Even before they've initialized SW firewall. Let's call it HW equvalent of VMs.

[SystemCrasher]

[QUOTE=Archi1;n899319]It seems more secure than the computer you are using.[quote]
I use different computers. My networking is also quite fancy. AFAIK my laptop is old enough to lack ME and only got rudimentary EC. Not to mention it uses non-intel network IC so ME is out of luck that way. Desktop is from pre-DRM ages as well. I believe it one of latest BIOS-based pre-UEFI things. It lacks "secure" AMD stuff to the best of my knowledge. So far I've been most happy with ARMs. They're simple enough so I could get some of them to behave. With virtually no shady blobs in use. That's how I could trust system. Does not addresses physical tamper, sure. But most of time I'm more worried of privacy, networking security and possible covert control channels/backdoors.

If someone physically grabs some computer, next thing is to catch computer's owner. Then "drug him and hit him with this $6 wrench until he tells you password" (c) XKCD. Its something to consider: attackers would usually choose cheapest/most efficient route. Remote attacks are good 'coz they're hard to discover and easy/cheap to conduct.

Tamper reaction,

Maybe not too bad to have, but their implementation looks overengineered/complicated and raises more question than solves. I believe when it comes to security things should be simple and easy to audit. Their implementation is nowhere close to being like that. Since attacker is forewarned such system is in use, they'll use appropriate countermeasures and/or right backdoors.

two factors, see here https://www.crowdsupply.com/design-s...roller-details
The ME engine is very limited by their custom BIOS and by the secure controler. Check here for more https://www.crowdsupply.com/design-s...visible-things

To my taste:
- Using x86 jeopardizes whole idea. Its complicated and can't be truly blob-free, blobs are doing very critical tasks and theoretically could completely overtake system. Say, ME could issue rogue DMA and there is very little OS could do about it AFAIK. So Intel just gets my middle finger when we're up for any security/privacy/trust.
- Way too much wireless stuff == a lot of security and privacy issues. Sure, NFC, BLE and so on are nice buzzwords. And e.g. bluetooth is comlpicated enough to probably use some firmware somewhere. Not to mention it going to fire its MAC into the air and I'm not sure if user would be able to change it == privacy issue. Getting it right could be CHALLENGING task.
- Not sure about NFC but why the hell I need this poorly researched crap in my PC? Especially "high-secure"/trusted? I do not need or want poorly investigated wireless protocols in my computers, to begin with. I've took a look on wi-fi security. While it looks "secure" I could unconditionally disconnect most wi-fi things as long as they hear my TX. Feeling secure, eh? Bluetooth is nowhere close to being researched that good. I guess it would put a lot of nasty surprises. It already did for few times.
- Standards. A nice buzzword. But if we take a look on how e.g. SSL/TLS perform, we'll soon learn it is extremely hard to actually configure TLS the way it secure and there're numerous pitfalls to consider. Maybe it is intentional. Fans of standards are perfectly free to use backdoored Dual EC DRBG, all hail the NIST and their "security" . Most standards are overengineered or have very specific notion of security, just a mere audit whether it actually as secure as claimed is a very huge task. I have no reason to trust some standard "just because banks are usin it". Come on, plenty of public transportation systems are using perfectly hackable Mifare NFC with crappy 48 bit keys. They're known to be hackable, yet cost of reimplementing it exceeds damage caused by few freaks actually capable of doing stuff like that.

So speaking for myself, I do not think I need or want this particular piece of HW. Too much questionable pieces in this puzzle while it does not addresses very basic things like e.g. ME doing DMA and hijacking arbitrary part of system at will. And too much of shady wireless/underdocumented "secure" uCs and so on. I can't call this HW design balanced or trusted. Neither it small/simple enough to reliably audit it quickly nor it is known what going to be uncloaked once all parts of such system are properly audited. One of reasons I like some chinese SoCs is the fact they're simple enough so I could evaluate whole system behavior and more or less answer the very simple security question: "what the worst it could do?"

[starshipeleven]

This implies its nowhere close to being "secure".

Hey hey, it has a microcontroller that erases the SSD if you try to open the casing. That's totally safety there.

Really, this thing sounds more like stuff built to be safe and secure FROM the common people instead of something safe and secure FOR the common people.

[Adarion]

Looks like another Purism/Librem approach. Doomed to fail on the promises more or less. And with intel ME nothing ever is secure by design there, sadly.