
DARPA's “Unhackable” Computer - deepnotderp
https://www.eetimes.com/document.asp?doc_id=1332764
======
andolanra
I'm not familiar with the MORPHEUS proposal specifically, but I do have a tiny
bit more knowledge of the SSITH program overall, and this has a _terrible_
explanation of what it is. It's effectively about exploring (with working
prototypes in mind) new instruction sets—or, in practice, modifying existing
instruction sets—with mitigations for certain common classes of
vulnerabilities implemented directly in hardware: specifically,
vulnerabilities related to "permissions and privileges, buffer errors,
resource management, information leakage, numeric errors, crypto errors, and
code injection."

The original proposal says nothing about "unhackable", and in fact,
specifically quotes someone as saying that eliminating these hardware
vulnerabilities would, "…effectively close down more than 40% of the software
doors intruders now have available to them"—a far cry from unhackability! It's
pretty typical of both science reporting and marketing bluster to go from
"addressing certain vulnerabilities to reduce intrusion by less than half" and
end up at "unhackable".

The quotes here come from this announcement, from before the proposals were
selected: [https://www.darpa.mil/news-
events/2017-04-10](https://www.darpa.mil/news-events/2017-04-10)

------
Cyph0n
Our research group at Georgia Tech applied for this grant but we were
unfortunately not selected.

As far as I recall, $50m was allocated to the project over a 3 year period.
Unlike NSF, DARPA grants typically require a working prototype by the end of
the funding period. In this case, DARPA needs a fully functional
implementation of the security scheme on a RISC-V processor as well as a
development toolchain that can be used to "secure" generic software and/or
hardware applications.

At a first glance, it sounds like this team is applying instruction set
randomization at the micro-architecture level: as far as I know, this has been
done before at a smaller scale. Our approach was to address each of the CWEs
(vulnerability classes) with a different technique, which I think contributed
to the rejection of our proposal.

Edit: Ignore the title. The goal of SSITH is lofty and likely impossible to
achieve for all cases in practice. But this is how DARPA operates: they come
up with (currently) far-fetched goals with the hope that one of the funded
approaches strikes gold.

~~~
CalChris
I don't think its ISA randomization if the EETimes article is accurate:

> Morpheus works its magic by constantly changing the location of the
> protective firmware with hardware that also constantly scrambles the
> location of stored passwords.

 _Constantly changing the location_ sounds like dynamic ASLR.

I looked at umich to see if there was anything more detailed but all I found
was this press release which is pretty much the same article:

[http://www.eecs.umich.edu/eecs/about/articles/2017/morpheus....](http://www.eecs.umich.edu/eecs/about/articles/2017/morpheus.html)

~~~
deepnotderp
Todd Austin's group has some (old) publications on something close at least.
Looks like they're forcing control flow to not use indirect jumps and branches
somehow and using that to do dynamic ASLR.

------
stevemk14ebr
I'm skeptical. As far as i can tell their 'unhackable' solution is some form
of super advanced ASLR that moves 'some' kind of software around and decrypts
and re-encrypts it on the fly. By continually encrypting with new keys and
such they are betting that an attacker won't have the time to find
vulnerabilities. However, this all assumes the 'advanced ASLR' itself isn't
vulnerable, and moreover they are not building software that has no bugs, but
rather just throwing all the bugs behind a pretty big locked door.

Sure it's a cool idea, but lets not call it unhackable.

~~~
GuB-42
The "unhackable" name probably just comes from a sales pitch or an
overenthousiastic journalist.

The Titanic wasn't called unsinkable by people who knew what they were talking
about. Same thing for that exploit mitigation hardware.

------
admax88q
Are we seriously trying to fix buffer overflows in hardware instead of just
moving on from C?

~~~
drew-y
I feel like that $3.6 Million in funding go a lot further if spent on projects
like the Rust Language.

~~~
nickpsecurity
Rust's safety was partly inspired from such spending on Cyclone, a safe
version of C. The NSF and other organizations fund tons of work on clean-slate
languages, type systems, formal methods, etc. The academic incentives usually
lead to quickly thrown together prototypes that arent production ready. Even
the good ones rarely get used by programmers in general. Ocaml was one of the
exceptions. What gets adoption is normally a language/platform with a knock-
off of their efforts pushed by a big company or used in a "killer app."
Bandwagons in other words.

The consistently-low adoption of clean-slate tech along with lock-in effecta
means the opposite is true: massive investment should go into making most
common tech more correct, secure, and recoverable as simple as possible for
users. If clean-slate, it should stay close as possible to what people already
know with clean integrations. We can also continue to invest in ground-
breaking stuff for niches that use them (eg SPARK Ada for aerospace) and/or
new bandwagons that might build on them (eg Rust ecosystem).

~~~
nickelbox
I had forgotten Cyclone's name, thanks for the reminder. I've always felt
kinda sad some of the small features like int@ didn't make their way back into
C. I'm glad at least C++ has non-null pointers via references (but with
stricter semantics and potentially undesirable syntactic sugar) and fat
pointers via span<T>, but it's useless when I have to write in C for legacy
reasons.

~~~
nickpsecurity
Trevor Jim revived it a bit with virtualization for those wanting to play with
it:

[http://trevorjim.com/unfrozen-cyclone/](http://trevorjim.com/unfrozen-
cyclone/)

~~~
nickelbox
Oh, that looks interesting, thanks for the link!

------
tehchromic
It sounds like an oxymoron. Given the meaning of hacking today it seems a
computer by definition is hackable - if you can't hack it what's the point?
There's surely some mathematical way to prove that the usefulness of a
computing system declines in proportion to it's hackability, such that the
least hackable system resembles more or less a rock.

~~~
fao_
Eh? It's about ensuring that a program running on the computer cannot be
altered or compromised in order to run unintended code.

~~~
otakucode
Wouldn't abandoning the von Neumann architecture do this immediately? Store
the code and data in separate memories. I'd think that would take out most all
exploits in one strike, no?

~~~
goldenkey
It appears that they don't want any sacrifices..just a system to run existing
code on top of. But yes, you are correct.

------
mintplant
I find it difficult to parse out what's really going on here from the
hodgepodge of attempted layman's explanations.

~~~
subway
Not to mention the weird inaccuracies, like tying vpro (amt) to Xeon.

Also no mention of TrustZone or similar existing techs for ensuring
application integrity.

------
nicolashahn
Labelling something "unhackable" is the quickest way to get some random
person/group on the internet to hack it.

~~~
wolfgke
> Labelling something "unhackable" is the quickest way to get some random
> person/group on the internet to hack it.

Perhaps doing such penetration testing is actually what they (secretly) want
people to do?

------
lololwuuut
I actuallyed laughed out loud at this sentence:

> Austin likens Morpheus’ defenses to requiring a would-be attacker to solve a
> new Rubik’s Cube every second to crack the chip’s security.

Hopefully that is a gross simplfication for the bendfit of less tech savvy
folks. A _physical_ rubiks cube can be solved nowadays in 600ms.

~~~
Giroflex
To be fair, 600ms is a long time for what I assume is an analogy for a hashing
algorithm.

Maybe it would be a fun idea to have sensitive data encrypted in such a way
that a part of the hashing algorithm involves solving a physical Rubik's cube.

~~~
Outpox
I would say that 600ms is just a _mechanical_ limitation.

------
icc97
I don't know enough about computer security, but I think the talk from Joanna
Rutkowska about 'Towards (reasonably) trustworthy x86 laptops' [0] is
basically pushing for 'hack resistance' from a different angle, with a
stateless laptop. I guess that's focussing more on verifying the lack of hacks
rather than making it unhackable.

[0]:
[https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...](https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops)

------
pleasecalllater
Yep. And Enigma is unbreakable, that's why it's totally safe.

------
paulgdp
What about the Mill architecture?
[https://millcomputing.com/docs/security/](https://millcomputing.com/docs/security/)

------
erikj
Something as simple as tagged memory becoming a standard feature of the
dominant CPU architectures would be a huge step forward for computer security.

------
samirm
what a load of shit. as if hardware bugs don't exist

------
mhh__
I can't help but feel that the only "unhackable" computer is one without
powers that's been recently introduced to a sledgehammer.

Besides, if you wanted to hack some sort of computer system: Wouldn't you just
take someone's children and do unspeakable things to them until someone
cracks, that seems less more straightforward - certainly more reliable than
depending on the intellect of an engineer ("hacker").

~~~
knodi123
> Wouldn't you just take someone's children and do unspeakable things to them
> until someone cracks,

Eek. No need to get ghoulishly creative! We just call that
[https://en.wikipedia.org/wiki/Rubber-
hose_cryptanalysis](https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis)
:-)

