1

I'm developing a program that contains a login function in C++. The problem is that I don't know how to develop it in my situation. I want to run the software on a raspberry pi, it only has a CPU clocked on 1 GHZ and 512MB of memory. The Memory isn't going to cause a problem, but the CPU does.

The problem is that I can't effort a lot of CPU power on encryption, of course I encrypt all passwords, but I can't encrypt the connection. This is because I think that HTTPS is to heavy. No HTTPS is not a real problem because the data is not classified, but I want to make sure that no one else can capture the connection and preform actions.

This is what I designed till now:

The login functions validates the user, if a correct user name and password is given then the user gets a unique encrypted number. The user must send this number every time to get access to his account.

The problem:

The problem is that every one can capture the unique number of the user, and he could use this number to login to his account. How can I develop a login function with out this problem? I can use the users IP in the encrypted number, but this is not secure when the hacker has access to the targets network.

Besides that, the user sends his credentials over the network. I guess I can also preform some encryption client side, but this isn't very handy for my CPU because I need to do more encryption cycles on my server.

Improve this question
1
  • To make clear why I didn't choose for HTTPS: The target is to create an efficient implementation that doesn't wast CPU power. A requirement of my project is to create everything as efficient as possible. Efficient is more important then time when there is a visible performance improvement. So when I could create something that is 10% more efficient but it cost 20% more time, then I’m willing to spend the extra time to get 10% more performance. But this needs to be on a part of the system that has a great impact on the performance. An encrypted network connection is a big part.
    – Laurence
    Commented Dec 21, 2012 at 14:19

5 Answers 5

Reset to default
7

HTTPS is not too heavy for an RPi at all - they're surprisingly powerful, and SSL is very lightweight in terms of CPU and memory usage. I've seen it implemented on 40MHz Atmega microcontrollers.

If you don't believe me, consider the fact that you can SSH into an RPi with no issues at all.

Improve this answer
2
  • That is also true, the only downside is that the browser can't cache data. Images need to get downloaded every single time. So it will take a lot more bandwidth. But I could do some tests with libcurl. Thanks!
    – Laurence
    Commented Dec 21, 2012 at 13:17
  • 5
    Browsers cache HTTPS data, if you set the HTTP headers right.
    – Matrix
    Commented Dec 21, 2012 at 15:56
3

SSL will be quite heavy on an Pi ARM processor compared to vanilla HTTP connections. Back when normal server processors were 1Ghz, I tested performance of SSL with various SSL hardware accelerators at the time. Typically, SSL would drop to 15% of the performance of vanilla HTTP for apache, IIS etc at the time.

HOWEVER. It is the SSL handshake, i.e. at connection, that uses up the cpu. So if you can minimise this, then the overall CPU usage will become less of a problem.

There are two strategies:

  1. map out the performance model for your app. If the clients are creating new SSL connections all the time then you may suffer performance problems. Perhaps consider maintaining longer sessions between requests and this will reduce the load.
  2. Use mutually assured SSL, i..e with client side certificates. This reduces the CPU load on connection to close to that of vanilla plain text HTTP.

SSH appears to work quite well with my Pi (but not applicable in this scenario)

Improve this answer
1
  • An other problem of HTTPS is that you are encrypting data that doesn't need to get encrypted. This is just a wast of CPU time. I know it is secure, but there needs to be a better way that takes less power. You are 100% ride when you are logging in to a bank account, but I'm building a browser game, it doesn't matter if some one else knows how many supplies some one else has. It doesn't harm the user. The only thing that matters is in this case the users password and that some one else can't send an action to preform by another user.
    – Laurence
    Commented Dec 21, 2012 at 13:32
3

I know of a 50 MHz PowerPC processor which runs a SSL server and routinely handles 70 simultaneous clients; I wrote the code myself. SSL is not heavy. Also, I cough and shriek when I hear about a 1 GHz processor being "slow": a Raspberry Pi would have been a totally rad gaming station back in 2001, and the Internet already existed at that time...

If you have some fetish about CPU cycles, then the good idea is still not to design your own protocol. Instead, use a properly configured SSL (e.g. with elliptic curves for the asymmetric cryptography).

Improve this answer
1
  • Now I'm 100% sure that I don't know anything about the CPU time that encryption needs. I'm going to try it soon, thanks you very much for your answer. I'm sorry that I marked Polynomial answer as correct, but you have my upvote.
    – Laurence
    Commented Dec 28, 2012 at 7:30
1

You are basically implementing a session system. Read more about securing it at https://www.owasp.org/index.php/Session_Management_Cheat_Sheet and https://www.owasp.org/index.php/Session_Management. You basically want to prevent session hijacking and replay attacks. One of the defenses is to bind the session to a client IP address and require re-authorization if the IP address changes. Search the web for more, keyword is "session hijacking".

For best security, you need to use HTTPS. You can minimize the amount of resources that HTTPS (SSL/TLS) uses during the handshake by using 1024-bit RSA certificates instead of standards 2048-bit. For symmetric cipher, use RC4 instead of AES, because RC4 uses less CPU, which is probably why Google is using it, although that should soon change with AES-NI support.

Improve this answer
1
  • 1
    Keep in mind that HTTP is a sessionless protocol, and you will break the internet for many users who are not lucky enough to have a static ip address for their "session".
    – Dog eat cat world
    Commented Jul 27, 2014 at 17:27
0

Alternatively you could setup a proxy that would allow incoming clients to connect to the proxy via HTTPS, and then the proxy can do the encryption/decryption, and get the actual data from the Pi - this allows the Pi to focus on the non-security related aspects of it and offload the HTTPS if that is indeed the issue - note that this requires a "secure" network between the Pi and the proxy if you need it to truly be secure.

Improve this answer

You must log in to answer this question.

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