2

I am thinking of a mechanism where I need to authenticate the client and control the access. I am thinking of using SSL for this purpose. I want to know whether using SSL solves my purpose.

My problem is that my so called server have only limited memory and processing power but somehow can deploy an SSL. My client is a mobile device.

What I need to do is establish an SSL connection with the embedded device. For this my mobile device to be authenticated first with the embedded device.

My questions are:

  1. Whether certificate based authentication can do that ?
  2. What all things should be there in the embedded device first?
  3. How does this thing happen actually?
  4. Is there any mechanism other that this for an embedded device?
Improve this question

3 Answers 3

Reset to default
2

A certificate typically implies that you have taken a public key and gotten a certificate authority to sign it to validate identity. You don't need this second step; you just need a list of the public keys you are willing to accept from trusted users. E.g., in ssh you have a list of trusted public keys that you put in your ~/.ssh/authorized_keys allowing people with the associated private keys to ssh into the machine.

Obviously, you may need a signed SSL certificate for your server, so users can verify your identity.

Improve this answer
2

Whether certificate based authentication can do that ?

A certificate can be used to identify an individual. However A certificate does not impose any access control restriction by itself. The normal way this works is you create a user in the system and instead of creating a password (or additionally used with a password) a certificate is bound to the user account. The application or website or whatever the client is connecting to then needs to be configured to prompt the user to supply a certificate and possibly a username.

What all things should be there in the embedded device first?

You would need to have a minimum of: a certificate issued to each client device or user an application/browser capable of supplying a certificate as a user credential

You would also most likely need: The certificate chain of the device/user certificate installed The certificate chain of the server you are connecting the device to installed

How does this thing happen actually?

Certificate based authentication is reasonably common however both the client and the server applications must be programmed to support it. If both client/server support it, it may not be the default way it is configured.

Certificate authentication could be either paired with the device or bound to user. If you are pairing with a device you would need to establish application functionality for new devices to be added as an authorised device for a specific user (this is used in newer smart phone apps). If the client is using a browser then a user certificate is likely the best option. Newer desktop browsers automatically support prompting the user for a certificate however this may not be the case on your mobile device.

Is there any mechanism other that this for an embedded device?

Please clarify. In terms of authentication there are many options, username and password being the most common with likely the most support for mobile devices. If the mobile device is a smart phone and supports JavaScript, options such as OpenId and OpenAuth are available.

Note

Since you mentioned you server has low CPU and memory, SSL encryption may add load to your server.

Hope that helps.

Improve this answer
0

A certificate is a package which contains an identity (a name) and a public key; and it is signed. Verifying the signature gives you some guarantee that the package is genuine, i.e. the public key is really the key owned by the entity designated by the name in the certificate. Verification is done relatively to the public key of whoever signed ("issued") the certificate, and that's a Certification Authority (CA). You may know the CA public key through another certificate, issued by an upper CA, and so on. You have to start somewhere, though, with a public key for a "top-level CA" (known as "root CA") which you know absolutely (it is embedded in the software).

That being said, SSL/TLS uses certificates for authentication, and can be mutually authenticated: both the client and the server can own a private key, and they show each other their certificates. See this answer for details.

In your case, you would have to push a private key and its certificate in the embedded device (or, better yet, have the embedded device generate its own key pair, so that the private key never leaves it); and every mobile device should also have its own private key and a certificate, where the certificate should contain the name of the mobile device (or the name of the mobile device owner). Thus, after the SSL handshake, the connection is secure, the mobile device is sure that it talks to the right embedded device, and the embedded device reliably knows which client is connected (through the name in the certificate).

Caution: authentication and authorization are not the same thing. That the embedded device knows who is currently on the other end of the line does not mean that this person shall be granted access. Generally speaking, certificates are not good for authorization, because they do not allow for fast, immediate revocation of access rights.

To produce certificates you need a PKI, i.e. some software which can organize the process of receiving "Certificate Requests" and turning that into certificates. Doing that properly requires some care, with procedures to follow. Some software can guide you; I usually recommend EJBCA, which is free and opensource.

Improve this answer

You must log in to answer this question.

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