1

I've read a bunch about how one should use bcrypt or PBKDF2 as a good middle ground between tunable workload and acceptable time to make brute force and collision attacks unfeasible.

What if the system is not a stock, off the shelf, general purpose computing system?

I work with an embedded system, that runs on a 200MHZ ARM CPU and over 90% of the CPU time is dedicated to performing the actual job the system is doing, continuously. Everything else is secondary, slow and conservative in terms of memory, CPU time and such.

Currently, access to remote control is protected by a crude challenge-response based on md5; device generates a random string and sends it to the client, client submits md5(password+string). This is to stop script kiddies and overly curious amateurs, but I'm aware this security is rather pathetic.

Now I'd gladly add something better, except I can't really spare much RAM, CPU time, or even disk space to fancy solutions and I'd prefer a valid client to be able to get in within reasonable time. Moreover, the same protocol is to be used to authenticate these devices communicating with each other, so the constraints must apply to all authenticating systems.

How to reasonably solve this? Any algorithms and methods that would allow reasonable security, assuming the constraint that it must not impose a performance penalty of more than 1%?

Improve this question
6
  • Depending on the application, you might be able to let the client do the hashing. It doesn't matter if it is honest, since the only one he can hurt with bad hashing is himself.
    – CodesInChaos
    Dec 21, 2012 at 12:02
  • @CodesInChaos: I'm more worried about password theft. Since the challenge is plaintext and a part of the hash, known plaintext attack might reveal the password.
    – SF.
    Dec 21, 2012 at 12:04
  • These hashfunctions are used for key strengthening. This can be done on the client without any issues. You can combine it with a cheap hashing step done on the server.
    – CodesInChaos
    Dec 21, 2012 at 12:09
  • Can you define what you mean by "The honest systems" - my understanding of this phrase really doesn't fit here.
    – Rory Alsop ♦
    Dec 21, 2012 at 12:30
  • @Rory: as per security.stackexchange.com/a/6415/17783 - off-the-shelf hardware, a PC or something comparable. (it is entirely possible I mis-understood the term...)
    – SF.
    Dec 21, 2012 at 13:14

1 Answer 1

Reset to default
3

Protecting passwords in storage and transit are two separate issues. The primary reason for using PBKDF2 or bcrypt is that their resistance to hash cracking is high, in cases where the hashes are captured from the server (e.g. via a database dump through SQLi).

Since you're looking at protecting passwords in transit, I think you may have already fallen into an unexpected trap. If a legitimate user sends a request with a correct response to the challenge, what stops the attacker performing a man-in-the-middle attack and modifying the request contents, whilst keeping the valid response token?

So, first you need to define what you need:

  • Confidentiality of the password.
  • Integrity of the message.
  • Authentication of the client (w.r.t. the password and the message).

A challenge-response system alone can't do this, unless you integrate a MAC (message authentication code) into it. In fact, what you technically need is a MAIC (message authentication and integrity code), since you need to make sure that the exact message you received is the one sent by the user, that it wasn't tampered with, and that the user is who they say they are.

Now you're running into areas where there are mistakes to be made and where implementation flaws run wild. Writing a protocol that effectively provides authentication, confidentiality and integrity is hard, especially on an embedded system using low level languages. However, TLS (SSL) does exactly this. Contrary to what some people say, TLS is amazingly efficient in terms of CPU and memory usage. I've seen it implemented on 40MHz Atmega microcontrollers with very few problems.

So, in conclusion, I highly recommend finding an SSL library (libssl maybe?) that will compile on ARM, and then use that.

Improve this answer
3
  • I'm not very worried about man-in-the-middle: the infrastructure makes it difficult. While sniffing and injection of packets would be still within reach of the attacker, compromising/replacing one of the nodes would be rather hard. Besides, the asset protected isn't very valuable - more of a target for pranks than for data theft - the attacker has little to gain. Still, SSL may be the right avenue; SSH works quite reasonably on the system.
    – SF.
    Dec 21, 2012 at 12:04
  • TLS is easy on CPU most of the time - but the connection process is very hard on CPUs where there is no client side certificate. So if the system has lots of single request SSL connections then the CPU will have a tough time coping. (*depends on what "a lot" is in the context of this question)
    – Callum Wilson
    Dec 21, 2012 at 13:24
  • @CallumWilson It depends on the CPU, really. It's possible to implement SSL on a 40MHz SoC microcontroller and still cope with up to a dozen concurrent clients. If you've got to deal with hundreds or thousands of connections per second, then SSL might become a burden on a modern machine, but below that level you should be absolutely fine.
    – Polynomial
    Dec 31, 2012 at 0:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .