cs1.tf.fau.de/research/…

This is interesting.

github.com/TitouanLazard/TEEShift

@forest someone wants to get hired by Google

meh, pdf is unavailable

Oh is it not loading too?

yep

mobile.twitter.com/tanmayg/status/1055870872613842944

wat

>first

you can buy it at dl.acm.org/citation.cfm?doid=3268935.3268938 for 15$ though

DOI:10.1145/3268935.3268938

In case it's no sci-hub or something.

I'm on my work machine right now and this paper does not that interesting that it's worth the trouble :s

or maybe I have not completely grasped the content from reading the abstract

I dunno, it looks pretty neat to me, especially since it requires no recompilation.

@TomK. It's basically a way to put an entire arbitrary function in a trusted environment (SGX or SVM) without needing to specially recompile the program.

yeah okay, I thought so

dunno how impressed I should be

These guys usually come up with neat stuff.

seems like it has the same premise-problem like their other neat stuff though

What premise is that?

so for instance the nomorp hack needed a root priv esc on the phones to run properly

Haven't looked into that one.

so did - iirc - one of the other phone banking related hacks

Oh those are the newer ones right?

Yeah I don't care enough about mobile devices to have read those.

Only know their work on x86 systems.

where you ask your self: if I have root, why do I need a fake banking app?

and it's kind of the the same question here

if I have X why do I need Y?

Because re-writing a program to use TEE is very difficult and not portable.

if I have unlimited containers that are kind of trustworthy, why do I need to put an arbitrary function in another trusted env?

?

The idea is that the program is not already running in a trusted env.

yeah.. but I can always open a new container. a new VM, be it desktop or server

no matter what my host is

That won't run it in a TEE though. That's far different from a trusted VM.

agreed

A trusted VM can still be screwed over by the host. TEE can't.

yeeaeahh, can it though?

I mean sure, there is an attack vector

no question about it

Of course the host can screw over a VM.

It has full access to the VM's memory space.

yeyeyeye, i know i know

but how likely is it?

Very, if the host is compromised and they want to compromise the guest.

I mean it's very easy. Sometimes as easy as a command like vzctl enter, other times it just requires using QEMU's remote control protocol. The hardest thing for the attacker to do would be hook the IDT.

that says nothing about the likeliness

only about the possibility

If an attacker has already gotten to the host, then it is very likely.

my 2 cents: there are use cases for this, sure. but they are extremely rare

and most of the times you will have a trusted or throwaway environment anyway

I'm not sure you get the threat model. It's common enough that Intel and AMD are racing to improve their support of TEE, and that VM vendors are already making use of it, Google especially. With this, not even a ring 0 exploit on the host can pwn the guest (or sensitive function, in the case of this paper).

Intel TXT's DRTM does the same thing, but it requires extensive software support.

(DRTM allows you to verify the state of an existing piece of memory)

this sounded to me like a test environment where you can test binaries with unknown contents

Or an environment where you have, say, a browser executing untrusted code.

With trusted execution, you can ensure a browser exploit, even one that manages to compromise your entire system, will not be able to mess with $process.

Same with VPS services, which want to ensure that a compromised VPS cannot break through and compromise every other VPS running on the system (which it otherwise could). I believe QEMU is trying to integrate SGX to protect from that.

I think I have not understood the threat model of a TEE yet

A TEE is any execution environment where the integrity (and often confidentiality) of the executing code is ensured at such a high level that nothing short of compromise of the TEE enclave can compromise it (not even a ring 0 exploit, logic analyzers in between DIMMs, or JTAG attached to the CPU itself).

Intel SGX and AMD SVM are examples of a TEE. Intel TXT is as well, to a lesser extent.

okay

@TomK. Think of it this way: What if the law of computer security "if an attacker has physical access to your computer, it's not your computer anymore" could end?

I'm not entirely sure what you mean by that (but I think that is a language barrier-thing :> )

ah okay

so you want to extend

ah no, the other way round

What if a server in some untrusted sketchy datacenter could be 100% sure that it's completely safe from any physical attacks, even with an entire corrupt law enforcement agency trying to break in? What if you could give me your laptop with complete confidence that I could not break in, no matter how much I tried? TEE is the solution to "physical access = root access", when implemented properly. This paper is just one step further in that direction.

it doesn't matter what code is executed on my machine, because it always runs in this environment

@TomK. But what if I get physical access to your machine?

Do you still trust that I can't cold boot it, or attach a debugger?

Or what if I plug in a malicious Firewire device or PCIe card and do a DMA attack?

actually I have that level of trust today against most(!) adversaries

Well what if your adversary is RCMP, FBI, or Sledkom?

And what if you are hosting a sensitive server in a datacenter that they break into?

but this point I do not really understand. If the TEE is designed for safe code execution, how does it help against a physical adversary or side channel attacks

@TomK. Because the memory in the TEE is encrypted by the CPU, so even someone who can read directly from RAM cannot break into it. The CPU itself also blocks DMA to the TEE region, and for Intel SGX at least, it disables probe mode (debugging mode that's initiated when you plug in a JTAG device) in TEE context.

ah, I was missing that bit of information

It basically ensures that the only way to compromise it would be to physically decap the CPU itself and modify its internals while it is running, which is exceptionally difficult to do (potentially within the capabilities of the NSA but even for them it would be extremely difficult, assuming no backdoors of course).

#encryption

It reduces the root of trust from the root PCIe hub, BIOS, bootloader, disk firmware, disk contents, JTAG ports, DRAM DIMMs, LPC, CPU, and more to only the CPU itself.

And even further than that. It reduces it from the CPU to only the TEE engine, which means even the host kernel cannot compromise it (you can get root or ring 0, yet still can't do anything to a TEE'ed process other than kill it or crash it).

LPE? No problem. RCE? No problem. Kernel driver vuln? No problem. TEE is safe.

okay, then I am able to identify another use case or two

:p

yeah but about RCE for instance

just that last thing

if i get creds and RCE about some weird interface

TEE does me no good, does it?

Weird interface like, a network card that can DMA?

it protects other processes and RAM, okay

It does you good even if you compromise a network card.

nah, I mean something like a webshell

Why wouldn't it protect from that?

well I can still run code, can't I?

as an attacker

Yeah but if it's outside of the TEE, you can't mess with what's inside.

yeah okay

You could have, say, a customer database backend in TEE so even if a webshell is compromised, they couldn't steal any customer information.

> it protects other processes and RAM, okay

It protects your TEE'ed process from other processes (and hardware).

hm... okay...

gotta get to work

aight, ttyl

btw: weirdly my boss is shredding paper since... 9

Lots of evidence he has to get rid of. :D

he's retiring in 2 weeks

heh

so ... yeah.... I guess? :s

ahh.. one fun story a colleague of mine told me yesterday in the smoking section

so you obviously know these certificates for InfoSec like ISO27K and ofc we also have one of these. 6 weeks before the last audit all employees got an email that said: "Please do this training for work environment safety and fire safety and whatnot (it's for the audit, everybody has to have it). and of course: nobody does it besides 50 nerds (and me). Yesterday I met the person who's in charge of the training programs and she told me that miraculously the status for this training..

..for all employees was set to done and passed around the time when the auditor came to our company although 80% of the company has not done the training yet.

O_o

That sounds quite irresponsible.

you think?!?!?!

Something sketchy's going on there lol

yeah.. that was just... wow

I imagine it's one of those cases where, if you bring it up, you find yourself fired for something minor years ago you forgot you even did.

nah, doesn't work like that here

I am more or less unfireable

Fortunate position.

unless I start sleeping or stealing at work

okay.. now I gotta go :P

ttyl :p

Just got the RC4 stream cipher working on an old ZX Spectrum machine.

But doing RC4 drop3072 has a huge impact on performance.

Thinking of creating a loader for encrypted TZX tapes with it.

Not that it'd have any real point of course, just fun.

I know too little about ZX dev to do it for tapes that don't load into memory...

How can I quickly try all desktop envs without actually installing it?

All?

Yes!

I mean I know the common ones are Gnome, KDE, Xfce, and LXDE, but there are more.

There is one more LxQt

@daya How about a live demo CD for a distro that uses it?

Ah yeah I forgot about that one, used it myself for a bit when KDE became... ugly.

There's also some weird ones like CDE (insecure though).

And the old Unity. And of course pure WMs (like a DE without lots of utilities).

@forest Which one?

LXQt.

@forest Never heard about it

Yeah it's an older one from old Unix machines (e.g. Solaris used to use it).

I mean installing is just pain

@daya Most distros have live CDs that you can use to test out the OS.

Without actually installing anything.

@daya Is there anything particular you're looking for in a DE?

Minimalism? Aesthetics? Productivity features? Security?

I remember when I was installing XFCE it took me almost 3 hrs!

@forest Well, most importantly minimalism and Security

After almost one year with GNOME

KDE looked quite fresh and new

But quite resource heavy

@daya How minimalist do you want? If you want minimalist, you should use a WM, not a DE. One popular one is i3 (a tiling window manager, so using it is a bit... different).

KDE and Gnome are the most bloated. LXQt is lighter than KDE but still a bit heavy. Xfce is lighter. LXDE is very light. Pure window managers like DWM, CWM, i3, i3way, etc. are the lightest (and fastest and typically most secure).

KDE is the best for productivity features, but it's also super bloated.

Indeed

@daya If you don't mind learning some configuration syntax, try i3. It's quite minimalist.

i3wm.org/screenshots

Wow looks nice

Tiling window managers like i3 also look 1337 as fuck.

And they are perfectly optimized for screen space.

But because it's a pure window manager, it doesn't come with things like file managers. Those need to be downloaded separately (assuming you want a graphical file manager and not just do it in a terminal). A window manager only manages windows (duh), their layouts, keybinds, etc.

Hm

It looks your desktop

What do you mean?

My personal desktop?

Yeah I thought

But it's not

I just checked above link

And it was from there

My personal desktop uses tmux, which is like a tiling window manager, but only works in a terminal, not an X server (it doesn't display graphical applications).

Tmux looks like this:

Yeah few days ago I read about Tmux

But I have to learn how to use it? Lol

Well you'll have to learn how to use anything new!

Hm

i3 is easier to use tmux anyway, and is similarly pretty.

I suggest you try out i3.

Just to see Tmux quickly I previously I installed it in Termux

And don't know how to exit lol

@forest i would try

It exits when you close the last existing window.

Unless you want to just send it to the background, in which case it's ^b, d

(At least if I remember the original bindings correctly, I have mine customized).

Doing that sends it to the background ("detaches" it), so you can later bring the same session back by running tmux a in a terminal.

@forest But I have to make live usb's of all if I want to use DE. Right?

Well either make it, or download it and run it in a VM.

From their ISOs

But DEs are always going to be more bloated and less secure than pure WMs.

Okay

Xfce and LXDE are probably the best if you really want a DE.

KDE is much more bloated but it's really pretty imho (or at least KDE 4 was).

Gnome is just ugly. I hate Gnome. It's popular though.

And one more thing: If I remember correctly, few months ago, Arminius started a discussion on "password managing approach"

But on that time I didn't really read that

But I really want to go through that whole discussion

How can I read that?

No idea. I don't use any chat rooms here other than a few for main sites.

Discussion was on this chatroom!

And several folks have their opinion

And you also

Ah. Um... Not sure lol. Probably some way to view full chat history.

chat.stackexchange.com/rooms/info/151/the-dmz

Probably something in there.

"Search for messages containing" might be useful.

Thanks

Ttyl

ttyl

dfrws.org/conferences/dfrws-eu-2017/sessions/…

Ooh this is fascinating!

Merry hatmas!

Merry hatmas

thumbs up for tmux btw

@TomK. When you were asking about the risk to choosing specific curves, were you talking about using existing, standardized curves, or choosing a curve (which for ECC means choosing the core parameters to the algorithm, i.e. rolling your own)?

few pieces of that discussion are chat.stackexchange.com/search?room=151&q=U2f

@forest Just to confirm: I am on the right channel you gave me(#twits on irc.netgarage.org) I didn't saw any feeds : thinking

So can you go on that channel and confirm it was the same channel you intended to gave me or other one?

@forest no, choosing a curve from the existing set of curves

I sometimes see comments like ".. and in this product they went for curve XYZ. what a good choice!"

And I always wonder how these comments come about

I probably could've formulated the question better

@forest Really? I always thought they are different

But small bear's name is Tom Leek and Great bear's name is Thomas Pornin

I am pretty confused : thinking

I always thought it was kind of a joke, because Tom Leek is the americanization of his canadian-french name Thomas Pornin. Pornin is not quite poiree, but as Americans were/are when they translated last names they thought "close enough".

@daya Well are there like 30 people in there?

It's not "feeds" you see. An IRC bot dumps tweets from time to time.

@daya I can get in the channel maybe later today or tomorrow.

Not on my IRC box atm.

maybe forest does not care, but most people I know will see it as rather needy or impolite

Have I been completely misunderstanding meet in the middle?

Is this technically correct but omits the insane space complexity, or is it actually wrong?

oh, it looks like reusing nonces with different keys could reduce the space complexity enough to make it feasible?

@forest last time I saw It was like 34 people

@TomK. I know but... :P

@TomK. Sure, But I was just hoping and even If he didn't replied I will not mind :)

After all, it is Internet

@TomK. Thomas -> Tom makes sense to me but Pornin -> Leek ?

No clue

@Androl I think you will have to rephrase your question. I don't understand them as they stand. The meet in the middle part is clear to me

Your other two questions I don't understand

@TomK. I don't really get it either, I might end up asking a question on crypto.se if I can't find anything about it

I know meet in the middle applies to double or triple encryption, but how does it apply to "all block cipher modes"?

I didn't think meet in the middle mattered for AES

tools.ietf.org/html/rfc5084#section-4 makes a similar claim, but it says "any block cipher in counter mode" rather than "all block cipher modes"

at least it gives some references

Ok, I think I get it

If every encryption has a known plaintext block due to some header or something, you can generate a bunch of random keys and encrypt the plaintext with them, storing that in a table. If you snoop on encrypted connections that always use new random keys, eventually one of them will use a key in your table.

so with a table size 2^n you'd need to see around 2^(128-n) connections and do 2^(128-n) table lookups to find one of the keys

So that's why reusing nonces/IVs with different keys could be bad, if you encrypt a known plaintext with 2^64 keys but the same nonce/IV, a precomputation attack could take only around 2^64 time and 2^64 space to find one of the keys

interesting

I learned something today though, so that's cool

@AndrolGenhald cool :>

ask a question and answer it yourself

> You may not be able to prove to the senate subcommittee when you were working out with PJ and Squi? – Peter Vandivier

chuckle

context: security.stackexchange.com/questions/198632/…