Ubuntu scores highest in UK Gov security assessment | Hacker News Reader

Ubuntu scores highest in UK Gov security assessment

insights.ubuntu.com

41 pointsdiggan25 comments

Warning as potentially misleading: despite the large CESG logo, this is hosted at ubuntu.com.

The PDF summary is written by a Sales Engineer at Canonical Ltd.

The original CESG security guidance has a rather different perspective: https://www.gov.uk/government/collections/end-user-devices-s...

Care to summarize? Each OS is a different document.

There's not going to be any one line answers but the section https://www.gov.uk/government/publications/end-user-devices-... is illuminating.

Not least for recommending the use of TPMs for disk encryption

Maybe I am a crank but I distrust TPM.

Since they're so slow, they're typically only used as "safe" data storage for keys, with all crypto happening in the CPU.

The main appeal of a TPM is then that data stored inside it is "sealed" (bound) to a defined system state (which only protects against the most crude attacks, but still) and somewhat protected from access.

You could just store a password encrypted key in there, like the one created for regular disk crypto. Worst case (TPM fully broken) it's as good as a no-TPM setup. In all other cases, the TPM provides another line of defense.

It's more the implications of accepting TPM and thereby enabling future changes to it that make me uneasy.

The future change so far is that the more complex parts of TPM are emulated in software on the CPU (TPM 2.0 in "firmware TPM" mode).

Vendors can introduce other crypto misfeatures without riding the TPM wave, and they can do so more easily by bypassing the TCG, which standardizes TPM (standardization is expensive).

For example (using Intel names and products as examples, some of these exist in similar fashion in other platforms):

- RDRAND (the in-cpu random number generator you may or may not want to trust)

- AESNI (the in-cpu AES implementation you may or may not want to trust)

- Anchor Cove ("only start the computer with 'correctly' signed firmware" - that is, stop owning your machine, no matter the effort)

- TXT ("run 'trusted' code that can control more of the machine than even your firmware - after you passed through Intel code, which is sometimes faulty and exploitable")

- SGX ("encrypt memory ranges in-CPU, so even the OS or TXT code can't make sense of them anymore" - but maybe Intel can?)

- AMT ("a coprocessor running several megabytes of code, with access to RAM, network, input and output devices" - what could possibly go wrong?)

Many of these ship already, some can't be disabled. Some are in the "won't hurt, won't help" department (eg SGX), some might be actively harmful (eg AMT, TXT, RDRAND). Most features look like Intel was mostly concerned with building the "Protected AV Path" Hollywood longs for so much (and they're usually advertised with that angle, too).

In that light I don't fear the TPM (a passive chip that does nothing unless some code running on the CPU asks it to) whose main issue is that it might be ineffective.

Thanks for your reply. I had heard what is called Anchor Cove and TXT framed as possible implications of TPM catching on, I will have to do some reading on what you say.

TXT uses the TPM to run a system state hash in a special TPM register (that can't be modified from x86 code) - no other relation there.

Anchor Cove can seal (against TPM) or verify (against a hard coded value in the CPU, probably using efuses). Given that choice, I'd prefer the TPM-way - at least that key can be replaced.

The recent spread of TPM is mostly motivated by Windows 8 and its Connected Standby feature. CS requires a TPM 2.0 (by Logo Requirements, ie. "spec", not necessarily by implementation).

This raises a lot of questions about Ubuntu if a government that wants to tap everything has no problem and is "indirectly" recommending it for security.

It was apparently written by a Canonical employee, FWIW.

The article was written by a Canonical employee but not the study. If I were Canonical I would avoid writing/publishing such an article, as anything that the government recommends for security is probably seen by many as potentially backdoored.

Don't be ridiculous. Most crypto algorithms that back major standards today have been approved by the NSA, and to date no backdoors have been found. For example, the change to NSA suggested for DES s-boxes _strengthened_ the standard.

[Disclaimer: I am a Canonical employee, but I had nothing to do with this.]

The A5/1-encryption standard was artificially weakened - short key length with padding of zeros - to make mobile phones easier to eavesdrop on.

http://www.aftenposten.no/nyheter/uriks/Sources-We-were-pres...

Given their past behaviour with respect to weakening security, why ought someone to trust them now?

I don't see where it says NSA weakened the GSM standard in Europe?

It doesn't. If you want NSA stuff, here you go:

http://www.heise.de/tp/artikel/5/5263/1.html

Short version: ADVAPI.DLL contains - or contained - keys, one controls the implementation of crypto to help with US export regs. The NSA looks highly likely to own the second key (MS devs failed to remove the debugging information in NT4 Service Pack 5 and it was labelled as 'NSAKEY'.) The third key was supposedly a surprise to the MS folks.

That said, I'm not sure why you'd want me to respond along those lines given that we're talking about a UK Gov report.

ADVAPI.DLL is a microsoft thing. It's not a crypto standards thing, so my point still stands. (Restated: it is easier to attack implementations than standards.)

I think you might need to distinguish between the old, secretive, possibly creepy NSA and the current slurp the world volcano lair NSA.

I believe the CESG has done this study to see how other goverment and industrial branches can least be tapped, not to see how it can best tap everyon.

Systems under test were:

- Android 4.2

- iOS 6

- OSX 10.8

- Blackberry 10.1

- Google Chrome OS 26

- Ubuntu 12.04

- Windows 7 and 8

- Windows 8 RT

- Windows Phone

So pretty much a statement that a modern open linux can be made the most secure.

> So pretty much a statement that a modern open linux can be made the most secure.

Why didn't they test any other Linux distributions besides Ubuntu (and Android, if you want to include that)?

I also wonder why, if they were really interested in conducting a thorough test, they didn't include any of the BSDs (e.g., FreeBSD, OpenBSD).

If its the government, there is no *BSD experience anywhere. I doubt they'd recommend it. Everything is purchased based on the ability to fill the purchaser's pocket on the side. Yes I have witnessed this - I did contract work for NHS and one of the PCTs had taken on a vendor for a cash back promise.

Discussion from five days ago: https://news.ycombinator.com/item?id=7130479

Also, apparently about mobile phone operating systems and written by a Canonical employee.

Wait what? Secure Boot can be turned off by anyway can it not? It's just it's on by default...

> Ubuntu’s response, from Ubuntu 12.10 onwards is to adopt Grub2 as the default bootloader, with support for Secure Boot, but with anability to turn off secure boot to modify the OS, if required. This is explained in John Melamut’s blog post here [13]. We believe thisgives users and enterprises the best compromise between security and ability to customise after sale.

On x86, Microsoft caved in and mandated (in Windows 8 Logo Requirements) that it must be possible to deactivate Secure Boot. My guess is that they were more concerned with Windows 7 using customers or hardware vendors that didn't want to build two lines of devices, one Windows 7, one Windows 8.

On ARM, the Secure Boot rules are unchanged: mandantory, must not be deactivated.

I somewhat expect Microsoft to switch the x86 side requirements back after Windows 7 support ends.

Since this part of the behaviour isn't specified in UEFI specs but only in Windows Logo requirements, there's also exactly 0 leverage other market participants have over what's going on in that part of the PC platform, except maybe antitrust complaints - that easily take 5-10 years before there are any consequences.

Reply on news.ycombinator.com