
PS4 security article follow up - FiloSottile
https://cturt.github.io/ps4-2.html
======
tptacek
_The reason I didn 't mention encryption in my last article is because trying
to defeat it would be a complete waste of time. The PS4 probably uses AES
(like the PS3 and PS Vita), which is the same type of encryption used by the
U.S. government._

Argh! No! Keep at the encryption!

 _The only exception to this is would be for implementation mistakes such as
the PS3 's infamous use of the constant 4 instead of what should have been a
random number._

 _Whilst it is unlikely that Sony has made another mistake like this in the
core of the PS4 's encryption_...

Argh! No! Look for other stupid mistakes!

~~~
yifanlu
He is misquoting myself and/or other people who've talked about the encryption
before. Sony has their own format they call SELF (secure ELF?) which works as
follows: each ELF segment (not section) has a key/iv generated for it and is
encrypted with AES-CTR (previously same keys were used for different segments,
making it vulnerable to attacks). The keys are placed into the header and
encrypted with AES-CBC. The decryption key for this is the important one,
which if we obtain, allows the decryption of any* SELF. (So an mis-implemented
encryption has happened before and doesn't mean 'oh the military uses AES, so
anything that uses AES is unbreakable')

There's also the signatures which prevent modifying the SELFs even if we got
the decryption keys. The ECDSA random-fail was what happened to the PS3. This
has nothing to do with the encryption though. (There was also no "constant 4"
that was just a simplification in the slide deck of the presenters. It was
meant as a joke.)

But I do understand all the gross simplification CTurt made because the
audience for this article is people who watch the console hacking scene, and
in the console hacking scene, almost nobody knows anything about crypto. I
frequently have to answer why brute forcing 128-bit AES keys is not possible.
Then, inevitably, the asker will declare why we don't just try to guess then.
Once I was informed that computers will become faster, so, in the future, we
can brute force keys "at the speed of light." I asked them how many meters per
second we can crack keys now.

* Okay, technically not any. I haven't gone into NPDRM, which is an additional layer of encryption for purchased games. Different keys are also used for different components (for example, kernel vs. user libraries).

~~~
tptacek
So the whole ELF file is protected by a signature you don't have known flaws
in? Because AES-CTR and/or AES-CBC (actually especially CBC) gives me the
willies without some kind of MAC.

~~~
yifanlu
Yeah, it's unauthenticated encryption, but think about their threat model.
It's not about protecting integrity (the code signing takes care of that),
it's about protecting the code from prying eyes (aka DRM). And the tradeoff
with speed is likely why they choose CTR. That has bitten them in the ass
before with key reuse, but by PS4 they've had about 10 years of experience
with the SELF format now. While I doubt the format is completely secure, it's
likely easier to find a flaw in FreeBSD9 (which is why CTurt tried to say).

~~~
tptacek
It is usually hard to retain confidentiality if you don't also have integrity
protection. My suggestion wasn't that people would be able to exploit the lack
of a MAC to override settings or code in ELF files; it was that they could use
that flaw to decrypt the code.

~~~
yifanlu
No, because that breaks the signature.

~~~
tptacek
Right, that's what I thought. Thanks!

------
floatboth
> our process is running in a FreeBSD jail, which I'm not sure is possible for
> a process running as root

uh... that's, like, the whole point of jails. If you get root in a jail, you
get root. In the jail. You only see the jail's root fs, the jail's processes
and, usually, a very limited set of devices in /dev.

------
Aissen
> As a little side note; with the recent release of LLVM 3.7, if we specify
> -target x86_64-scei-ps4 to clang, we can compile code with the exact same
> options that Sony uses to compile official code for the PS4.

I wonder if this will undermine the opensource strategy of Sony's LLVM/SDK
team. I hope not.

~~~
SXX
Reason why Sony open source their version of LLVM is to make it easier
(cheaper) to maintain it. So it's commercial interest and it's unlikely to
change because it's wouldn't affect how soon it's going to be hacked at that
point anyway.

It's just like with previous "Linux on PS3" that was mainly done by Sony to
decrease taxes as they could pay less if their system can be considered as
general purpose PC and not just gaming console. On the time that feature was
removed this trick just didn't make sense anymore.

~~~
Kristine1975
Essentially this. There was a talk by Sony at the 2013 LLVM Developers'
Meeting:
[http://llvm.org/devmtg/2013-11/#talk8](http://llvm.org/devmtg/2013-11/#talk8)

From the slides:

 _Initial development hampered by secrecy

\- Blanket secrecy policy included compiler project

\- No advice/feedback from the group consciousness

\- Sitting on features and bugs and fixes applicable upstream

Clear value to working openly with upstream

\- File a bug; somebody else might fix it

\- Send a patch; people will review/advise

\- Bigger features can get better design review

\- Putting private changes upstream reduces merge pain_

And:

 _Merging once per upstream release was a nightmare

\- We stuck our fingers in everywhere

\- The 3.0 merge work took three months_

~~~
Aissen
You know that and we know that here. I just feared someone might decide that
making engineers miserable to do the constant porting might be a good security
tradeoff.

