Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Edit: seems like I was quite hasty when typing in my question at first, so here is an updated version of it.

I am developing an application that runs on PCs which are on the same LAN as other devices. I want to connect to these devices. Since the data communicated between the PC and the devices is sensitive, I want to protect it with encryption, authentication and integrity. Therefore I am using TLS.

The idea is that if someone manages to get access to the LAN from outside (somehow) he should not be able to use the data sent between a PC and a device (because of encryption). Also if someone gets access to the LAN from within he should not be able to just connect to any of the devices. There is currently no real user/password protection on the devices so I need some other sort of authentication. I was thinking of certificates here. The idea is as follows:

The company which is running the LAN represents the Certificate Authority. There is a general server certificate which is stored on the devices. There is also a client certifcate which is held private on the PC's that should be allowed to connect to the devices (like service notebooks, for example). The company signs both of those certificates.

Now, if someone is able to get access to the LAN, he might be able to sniff out any traffic, but it's encrypted so he cannot use the data. Moreover, if he wants to connect to any device, the connection will be refused since he is not in possession of the appropriate client certificate. However, clients can check if the devices they are connecting to are really those devices and not some intruder.

My question is: is this the right certificate infrastructure? Is this effective? Are the certificates sent via encryption or will they be sent unencrypted? If they are sent unencrypted, does this even have any use? I guess an intruder can just log the certificate sent by the client and then hold it on his own machine.

share|improve this question
1  
What data are you trying to protect? What threats do you want to reduce? –  GdD Nov 19 '13 at 9:28
    
I agree with @GdD. Without a proper threat model, we cannot even begin to approach your question. –  Adnan Nov 19 '13 at 10:16
    
Sorry, I re-issued my question and hope that is is more clear now what I want to know. –  WMEZ Nov 19 '13 at 14:25
add comment

2 Answers

It's rather hard to give a sensible answer without knowing what you are trying to acheive.

Using self-signed certificates you'll get secure point to point communications, but there is no intrinsic authentication - I can walk into your office with a laptop using my own certificate and start connecting to your services. OTOH if you run your own certificate authority, then you have the ability to restrict communications based on the issuer of the certificate (in this case your CA). The common name is just a convention used as an assertion of identity (it doesn't have to be a fqdn) which is certified by the CA.

However, I don't have a domain name because all of the computers and devices will get dynamical IP addresses inside the LAN

Nonsense:

1) what you don't have is an entry in the public DNS to identify your network - there's nothing to stop you calling your network anything you like - but you may experience problems connecting to the other google.com if you call your network that.

2) DHCP does not preclude using using static IP addresses for some hosts

3) DHCP does not preclude having a consistent hostname with varying IP addresses.

I want that only users in posession of the certificate

Then why are we talking about FQDNs and IP addresses? These are properties assigned to machines not to people.

I think you've still got a long journey ahead of you before you are asking the right questions.

share|improve this answer
1  
Sorry, I re-issued my question and hope that is is more clear now what I want to know. –  WMEZ Nov 19 '13 at 14:24
    
Question is improved - you're closer to explaining what you're trying to acheive rather than how you intend to acheive it. Assuming that you don't need to integrate with application level authentication then it sounds like you need a VPN (which might use SSL/TLS). Maybe OpenVPN. But this is no use for authorization (only authentication and privacy) –  symcbean Nov 19 '13 at 16:43
add comment

A simple approach to this is to use a pre-shared key. The PC and devices would all have the same key, which is used to encrypt and protect communications. This avoids public key crypto, which would be beneficial if the devices are low powered. However, while it protects against outside attackers, it doesn't protect devices and the PC from each other.

You could improve on this using only symmetric crypto by having individual device shared secrets, while the PC knows all of them. The exact arrangements will depend on the communication lines you need (do devices talk to each other directly?) and the trust that's in place (do devices trust the PC implicitly?)

You can also use public key crypto. You would usually give the PC and each device an individual certificate. In a simple setup you could use self-signed certificates If each device has the certificate saved for any other device it needs to connect to, it can verify the self-signed certificate securely. Or you can use the solution you outlined, with an in-house certificate authority.

I expect the biggest difficulty will be your installation procedure. You will have to think carefully about the user experience. Take some cues from WiFi and Bluetooth about their approach - shared password vs device pairing. Once the PC and devices are installed with the correct secrets/keys/whatever day-to-day operations should be straightforward.

share|improve this answer
    
Thanks. Is it not possible to create a single certificate that each devices shares as well as a single certificate that each PC shares? Devices will never connect to PC's, only PC's will connect to devices (the devices kinda acts like a server while the PC's are representing the client-side of TLS). –  WMEZ Nov 20 '13 at 7:40
    
It is possible... Whether it is a good idea is another question. Why have you rejected all the options I outlined? If you can explain that I can understand what your needs are. –  paj28 Nov 20 '13 at 10:32
    
Ok I am clarifying a bit more: the devices come together with a software that is able to communicate with them. Both the devices and the software will be sold to differenct companies and therefore they will be placed in different LANs. The software can be installed (for example) on a service notebook to connect to the devices. Only a machine that has the software installed and is authenticated as "service machine" should be allowed to connect to the devices. On the other hand, all connected devices must prove their identity (hence the two certificates). –  WMEZ Nov 20 '13 at 13:54
    
So, I don't want to use pre-shared keys since I need authentication. Individual device shared secrets sounds like a lot of administration to do especially if I want to add new devices to a LAN (every PC needs to obtain the shared secret of the newly added device). So far I have come up with your idea of an in-house certificate authority. The manufacturer of the devices acts as the CA and signs certificates for both client and device. These certificates will be installed on every device and PC and only on those who are allowed to connect to any device. –  WMEZ Nov 20 '13 at 13:59
    
You can do authentication using pre-shared key. In fact, it sounds like the appropriate approach. –  paj28 Nov 20 '13 at 15:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.