lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 26 Mar 2015 15:04:00 +0100 From: Thomas Pornin <pornin@...et.org> To: discussions@...sword-hashing.net Subject: Re: [PHC] Another PHC candidates "mechanical" tests (ROUND2) On Thu, Mar 26, 2015 at 08:11:52AM +0100, Milan Broz wrote: > Or more generic question: what about embedded world? > > PHC seems to be mainly about online services, where you have some big > Intel server hosting behind it but I would like to not forget about > embedded systems. Generically, password hashing is a muscle contest between defender and attacker; we try to design hash functions that are inherently (and in a configurable way) slow to compute, so that brute force attacks are made harder. In any case, if the defender is weak, then the attacker is necessarily strong, relatively speaking. PHC candidates try, within that context, to optimize things for the defender, i.e. to pessimize things for the attacker by relying on the kind of computation that the defender does best, and that the attacker cannot do better than by using the same kind of hardware (which is the best than can be hoped for). Most PHC candidates have used as working assumption that the defender has plenty of RAM that it can access quite efficiently; that assumption maps to authentication servers, but not necessarily to other kinds of systems. Other candidates assume the availability of a GPU, or an access to some big fast-access ROM. Nevertheless, small embedded systems (the kind of hardware that has lately become highly fashionable under the name "Internet of Things") can be adequately described as poor at doing anything, except being cheap. To take an example, we are here talking about ARM7TDMI chips clocked at 30 MHz, with maybe a few dozen kilobytes of RAM. If the defender tries to enter a muscle context while having only that kind of hardware, then prospects for security are grim. So what can be done with such embedded systems ? The first idea is to try to arrange things so that any password hashing happens elsewhere. For instance, if the password (presumably some access code entered by a human bring) is meant to authenticate with a remote server, send it to the server under the cover of some SSL-like protocol(*), so that any expensive hashing happens server-side. This kind of protocol design cannot necessarily be applied, though. Even for authentication with a server, nice password-authenticated key exchange protocols (e.g. SRP) tend to imply that the hashing is done client side. It is my cue, at this point, to remark that my PHC candidate (Makwa) offers a generic method for offloading most of the hashing cost to an external server that needs not be trusted (if we want to offload the work to a trusted server then it can be done with any password hashing function; the hard part is doing it without having to trust that server). If you need to do password hashing on an embedded system that is way too weak to do it properly, and you have some network and online muscle (e.g. cloud-based machines), then Makwa's delegation may be the way to go. Of course, in contexts where there is no network at all (and we were talking full disk encryption, to be unlocked at boot time, before any network may be configured at all), then delegation cannot be applied, and you are back to step 1. Namely, to do things like smart cards do: with hardware shielding, so that secrets may be stored and still not be plundered by attackers with physical access. To sum up: to achieve security with passwords on (small) embedded systems, you will need one of the following: -- a protocol that ensures that whatever password hashing is needed will be done elsewhere, on bigger systems; -- a password hashing function that can delegate the bulk of the computation to an external server (with Makwa, you get the additional benefit that the external server needs not be trusted); -- tamper-resistant hardware that can store secrets safely, thus removing the need for slow password hashing. --Thomas Pornin (*) A 30 MHz ARM7TDMI with 20 kB of RAM and 20 kB of ROM _can_ run a standard-compliant TLS 1.0 client, even including some barebone X.509 certificate validation, and do so fast enough to saturate the bandwidth offered by a 115200 bauds serial line. I've done it a few years ago. In particular, RSA-based key exchange is light on the client side. Thus, SSL/TLS, or any other similar protocol (e.g. IPsec), can be envisioned on such small embedded systems. Of course, raw unprotected communications are even easier to do, if they can be tolerated.
Powered by blists - more mailing lists