<ekleog>
<pie_> im not a huge fan of 2 factor auth that depends on 3rd party services that force me to tie my phone to it and such <-- github offers OTP 2fa, which can just be a FOSS app running on your phone and never contacting github directly, you just c/p 6 digits by hand at each login :)
<ekleog>
andi-: the problem about closed-source things in embedded device (@yubikey), is that manufacturers of secure elements require you to sign NDAs to get access to a development board, so you don't really have a choice if you want that's actually physically secure :/ (dunno whether yubikey isactually some secure element, though)
<ekleog>
<@gchristensen> the nitrokey and yubikey and related hardware have processors which contain the key material and won't let it out under any circumstances, are resilient to tampering, and will destroy the data if they're mucked with <-- last I checked, nitrokey didn't have a secure element (or at least didn't advertise it, and as it's an important selling point I think they would have) :/
<gchristensen>
ouch
<ekleog>
(yubikey has at least their FIPS series that has seen some validation: 120-2 physical level 3, though I'm familiar with EAL, not with FIPS 140-2 so I don't know what that means)
<gchristensen>
git-crypt is an accident waiting to happen
<ekleog>
about the “protecting from commits maliciously pushed to the repo”, the best I could think of would be to have each commit pushed be signed, and have tools that automate a defcon mode if a non-signed commit is ever pushed (so that it could be reverted asap), but 1/ it'd likely be hard to make all committers follow this practice, as it means eg. no longer using the github UI for merge, but doing a
<ekleog>
signed merge, and 2/ it's likely hard to make it compatible with having ofborg gatewaying merges on successful builds, which is something I think we are more or less working towards :)
<gchristensen>
github does sign commits through the UI
<ekleog>
… wait, what? github has access to private keys? o.O
<gchristensen>
no
<gchristensen>
they sign it with their own key :)
<ekleog>
oh, ok, didn't know! :) though I'm not sure it'd solve the issue, then, as I think we more or less started from a “what defences do we have if an account is compromised?” hardening discussion?
kalbasit has quit [Quit: WeeChat 2.1]
<samueldr>
uh, if the nitrokey doesn't have a secure element
<samueldr>
might as well do something with the tomu I got
<samueldr>
(or get a real u2f one)
<ekleog>
well, I've never heard of a secure element that did not require a NDA to program in C (usually you can program in Java Card even without NDA, but well…) -- didn't manage to find the schematics of the nitrokey, though, to be sure :/
<andi->
ekleog: so the discussion I had with Jan Suhr last December pointed towards: we don't deal with the secure element. We buy smartcards that come with those properties and run our code on them.. I remember programming those during my university time. I certainly did not have to sign an NDA. It was some weird dialect of java back then.
<ekleog>
andi-: it's javacard :)
<adisbladis[m]>
andi-: Javacard :)
<ekleog>
which confirms the message I wrote just above :° (I'm currently working on javacards, fwiw)
<adisbladis[m]>
Good luck getting some NXP chip without an NDA
<andi->
Ahh, I should get s coffee before IRC :(
<ekleog>
more sleep >> coffee (for some definition of >>)
<adisbladis[m]>
Why not both?
<andi->
I define >> as meaning less then the rhs ;)
<ekleog>
so you do less more sleep than you do coffee?
<ekleog>
sounds right :D
<andi->
I don't get the whole NDA thingy.. I have been working with a company writing mainline Linux kernel network drivers and to talk to the developers about the OSS driver... Hardware companies are weird.
<ekleog>
well, for secure elements it sort of “makes sense”: CC evaluation gives bonus points if the source code cannot be found, so it means you need less security otherwise for the same evaluation level
* ekleog
wants to overhaul Common Criteria, but well…
<ekleog>
“Hello ISO, can we change everything you've been doing until now? It's just stupid. Thxbye.”
<andi->
Are those devices powerful to run a few layers of handcrafted intermediate languages for additional obscurity yet?
<ekleog>
not yet afaik
<ekleog>
(but anyway you can't access the binary code, so…)
<andi->
Well that goes more towards wasting >99% of the energy on some garbage in case someone managed to break into the case and tries to read the registers.. But anyway I fear someone might think that's a good idea :/
<ekleog>
tbh, it might be, there are attacks that work by recording the emissions of photons by switching transistors and reverse-engineer from there
<ekleog>
(that conf was awesome)
<andi->
On that level yes but isn't it then just about someone being able to filter through the garbage? Traditionally on software security that would be very bad practice useful to avoid some script kiddies but not sophisticated attackers... On hardware it is probably just good because you can filter through the noise of high volume data?
<ekleog>
hmm I don't really know, tbh, this kind of hardware attacks on secure elements are a bit above my head, and I personally only look at the digit after EAL :° but I'd assume once you get the switching transistors and their time, if you get some obfuscated VM code it's going to make things harder (but never impossible, it's ~ like white-box crypto, that afaik is not really possible to do in a safe way
<ekleog>
but we have schemes that noone managed to break yet)
<pie_>
arguably, you cant do a remote exploit on a smartcard, so as long as you always have physical access to it, dont lose it etc it should be more or less fine?
<pie_>
and if you lose physical control you revoke your creds
<pie_>
i think?
<pie_>
ofc that does require noticing you lost it
<pie_>
and be in a position to revoke
<ekleog>
pie_: the whole point of a smartcard is to be safe even when lost, though :)
<pie_>
sure but if youre talking about physical hardwre attacks it just gives some uestionable amount of time buffer
<pie_>
which if someone has a working exploit is not that much i suppose
<pie_>
but i suppose this is also where economics and breaking the rest of the system comes in
<ekleog>
yeah, basically economics of breaking the smart card is basically “well, we think it's really expensive to break that”, and usually it turns out it is :°
* ekleog
never found an actual evaluation of the price though, but apart from logical attacks (that are still present), physical attacks appeared like they require really expensive stuff nowadays, like electron microscope, high-precision tooling for bypassing the shields, etc.
<andi->
As long as the attack takes longer then it takes on to realize the token is lost there isn't a real threat.
<ekleog>
for things that can be revoked, yes :) for the root DNSSEC keys, or a sss segment of a long-lived private key for an organization, it may be a bit harder to revoke :)
<ekleog>
(for sure the root DNSSEC keys do not base all their security on only a smartcard, thanksfully)
<pie_>
ekleog, if the unversity already has a FIB ¯\_(ツ)_/¯
<ekleog>
pie_: good point, but nowadays smart cards also try to defend against FIB-based attacks (by having smaller transistors than could be attacked, and self-destroying on any “this looks weird” result) :)
<ekleog>
not sure how well they manage it, though
__Sander__ has joined #nixos-security
__Sander__ has quit [Quit: Konversation terminated!]