

Ubuntu scores highest in UK Gov security assessment - diggan
http://insights.ubuntu.com/resources/article/ubuntu-scores-highest-in-uk-gov-security-assessment/

======
ronaldx
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...](https://www.gov.uk/government/collections/end-user-devices-
security-guidance--2)

~~~
StavrosK
Care to summarize? Each OS is a different document.

~~~
baxter001
There's not going to be any one line answers but the section
[https://www.gov.uk/government/publications/end-user-
devices-...](https://www.gov.uk/government/publications/end-user-devices-
security-guidance-ubuntu-1204/end-user-devices-security-guidance-
ubuntu-1204#significant-risks) is illuminating.

Not least for recommending the use of TPMs for disk encryption

~~~
eliasmacpherson
Maybe I am a crank but I distrust TPM.

~~~
pgeorgi
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.

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

~~~
pgeorgi
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.

~~~
eliasmacpherson
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.

~~~
pgeorgi
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).

------
theboywho
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.

~~~
jlgaddis
It was apparently written by a Canonical employee, FWIW.

~~~
theboywho
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.

~~~
tych0
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.]

~~~
6d0debc071
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...](http://www.aftenposten.no/nyheter/uriks/Sources-We-were-pressured-to-
weaken-the-mobile-security-in-the-80s-7413285.html)

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

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

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

[http://www.heise.de/tp/artikel/5/5263/1.html](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.

~~~
tych0
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.)

------
baxter001
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.

~~~
profquail
> 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).

~~~
csmithuk
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.

------
jlgaddis
Discussion from five days ago:
[https://news.ycombinator.com/item?id=7130479](https://news.ycombinator.com/item?id=7130479)

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

------
philliphaydon
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.

~~~
pgeorgi
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.

