views:

239

answers:

7

This is something I've always wanted to learn. When I design a system (software or hardware) where multiple components communicate with each other, how can I implement some simple encryption or other features in the protocol for some basic security?

I can change the protocol anyhow, since I have low-level access down to the series of bytes that are transmitted / received.

Edit: I'm interested in embedded programming, simple over-the-wire encryption for protocol security.

+2  A: 

OAuth may be interesting for you, in order to permit access control between various APIs.

If you purely want an encrypted channel of data, it's better to just layer that ontop of your protocol; go over SSL or SSH.

Noon Silk
Why is this at -1?
Daniel
I upvoted it and referenced it my answer. Maybe the down-voter hates SSL.
Anthony
+4  A: 

Don't implement basic encryption in the sense of designing it from the ground up. It is VERY hard to correctly implement encryption properly.

Instead, concentrate on using encryption available on your platform... what is your platform?

EDIT:

See this SO post for a list of encryption alternatives, some of which should work quite well in an embedded environment (e.g. CryptoPP and TomCrypt).

Eric J.
Very hard? I need to design some encryption for my hardware. So am I to install Damn Small Linux as firmware, only to use its amazingly secure SSL sockets?!
Jenko
Well, to be fair, you didn't mention your platform. SSL may be overkill for embedded programming.
Matthew Scharley
Whether or not you're doing embedded programming, correctly implementing encryption algorithms is hard. Your platform doesn't change that fact. If it's important enough to encrypt, chances are it's important enough to encrypt right.
Eric J.
@Jeremy: Yes, very hard. Listen to http://www.grc.com/SecurityNow.htm for awhile. Week after week some encryption is cracked or weakened. Unhackable voting machines are hacked. Multiple vulnerabilities are found. It is extremely difficult to get security right, but very easy to get it wrong. And as Eric said, if getting it right isn't that important then why encrypt it at all?
TrueWill
It's easy to build something that *looks* secure - turns plain text into gibberish and correctly decodes it at the other side. What's hard is to make it *actually* secure, against the vast array of clever attackers out there.
caf
If all you care about is looking secure, then base64 works well. Kudo's if you strip the '='s off the end too so that it isn't a blatant giveaway.
Matthew Scharley
No, base64 in no way encrypts data. It encodes data, and anyone that cares at all about decrypting the data will immediately recognize that's happening. I updated my answer with some more reasonable alternatives for embedded programming.
Eric J.
+4  A: 

The simplest solution by far is to just use a SSL socket instead of a normal one, a la HTTPS/FTPS style.

There is no difference at all in the protocol between HTTP and HTTPS, the only difference is that they operate on different ports (80 vs 443 normally), and one uses a normal socket, and the other uses a SSL encrypted socket.

Matthew Scharley
+1  A: 

OAuth is definitely a consideration. In addition to that, you may want to consider WS-Security. By transmitting via a Web Service, you keep everything platform and language agnostic, and adding WS-Security means that the encryption and decryption are on the application layer (end-to-end). So as long as you trust that the messages are safe once they leave the sender, you know that they will stay safe until the client actually receives the message (this means that it won't be decrypted by the server and THEN passed to the client/receiver, but AFTER the receiving application has the message).

So basically you would OAuth to secure/authenticate the various applications, and WS-Security to secure the messages passing between them.

Anthony
+6  A: 

You say "basic security" but that doesn't mean much. What is your threat model? What kind of attack are you defending against? If you are transmitting credit card data, then you're going to need to use robust encryption, such as RSA. But I can't think of an example that needs "less" protection. If you're worried about hackers disassembling your code, it's already game over -- if it's interesting or valuable, they'll hack it. If not, you wasted time implementing it.

John Deters
Absolutely - "security" isn't a fungible commodity that can be applied to a protocol like a coat of paint. It's a set of defences against a defined threat model - you can't skip the "defining the threat model" step.
caf
Someone will break your security on an embedded device, as they can take the device apart and examine it carefully. So the trick is to make it as difficult as possible, as, if you make it more expensive to break than the data is worth you may limit the hacking. Writing the encrypted part in C may be helpful, and have it stored in flash memory on the cpu board will make it more difficult to disassemble.
James Black
+2  A: 

If you are doing embedded programming then where is the encryption concern?

As long as you are staying on the same processor, for example, encryption is useless.

If you are concerned between processors on the device then encryption can be difficult, as a dsp won't necessarily have the spare space for any encryption of any complexity.

If you want fast then a symmetric algorithm is your best bet, and there are many that you can do that are good, such as Blowfish or IDEA. You can store a unique symmetric key, so if they can take the device apart, only one key will be discovered, but each device should have it's own key.

Just tie each key to the serial number, so that if you are communicating with a server then pass the serial number with the packet and the webserver can look up the correct symmetric key and decrypt it quickly.

If you wanted to do a fast hardware encryption, for my MSEE thesis I developed an encryption family that uses arbitrary order calculus, which would be difficult to determine the key as it can be in the hardware circuit using microstrip, as there is no processing, it would be tied in directly before the antenna and everything going over it would be encrypted.

James Black
You say 'if you want fast then a symmetric algorithm ...', but actually, speed has no factor when choosing that.
Noon Silk
On an embedded system fast is everything, as you are dealing with potentially critical operations where time is of the essence. If you are dealing with an iphone where you are playing a game that would be different. Also, RSA is mainly involved with key transfers. If I build a closed device and sell it, I can put the key on at the factory, so there is no need for a key transfer.
James Black
You completely misunderstood my point.
Noon Silk
Symmetric algorithms tend to be used to encrypt the data and PK systems to encrypt keys, unless you are encrypting something small, such as a password then PK can be reasonable since it is smaller than a key. But, symmetric algorithms are faster than PK algorithms, so, fast is a concern, besides, RSA can't encrypt too large of messages, it is limited based on the size of the key.
James Black
No, it's not limited, it's *insecure*. The reason you don't use RSA for large messages is that it's bad *security*, not *speed*. That is what I am implying.
Noon Silk
+2  A: 

There are many things to be considered in designing a secure system. Just to mention a few:

  • Choice of symmetric/assymetric encryption schemes
  • Encryption algorithm (AES, Blowfish, DES)
  • Choice of known protocols (e.g. SSL)
  • Key management and distribution
    • A single master key (if hacked, whole system is compromised)
    • Key per device (key distribution can be more difficult)
    • Protecting the key distribution channels
  • Will a potential hacker have easy access to sample device(s)? E.g. consumer product such as X-box vs a box locked in a telephone exchange. It's harder to protect against hacking if the hacker has physical access.
  • Human factors—social engineering etc.
  • A system is only as secure as its weakest link.

I suggest you read Bruce Schneier's material for starters.

Craig McQueen