Using certificates to secure

Question

I'm working on an application that comprises of a C# WebAPI (on Azure Websites) and a native mobile app. Essentially, a client creates a series of messages using a Web interface and these can be browsed on the mobile app. At present, there is no restriction on this data.

A new feature requires that some clients can secure their data, so only authorized people are allowed access. We don't want to use a username/password as the overhead would be too great. Our clients could have hundreds or thousands of people who want to browse their messages.

My approach was going to be:

1. User creates a service using our web portal.
2. User uploads a public key into this service, which we store.
3. User distributes the corresponding private key using an MDM to all devices that wish to browse the messages.
4. HTTP requests for these messages require the certificate to be presented.
5. The API validate the request using the public key.

There are two things that are bugging me.

We won't be using a CA to verify the cert chain. The client's certificates could be self signed. I don't see this as being a big issue since we know who our clients are.

Having the private key distributed on lots of devices could be considered a bad thing, though I believe this scenario is pretty common e.g. authenticating to MS Exchange. Responsibility for securing the private key would reside with the client.

So, to my question: Does this approach appear sound?

Additionally, Azure Websites only supports an on/off configuration of client certificates, making it impossible to mix both public and private calls. Would having two endpoints be considering good practice e.g.

• https://public-messages.azurewebsites.net
• https://private-messages.azurewebsites.net

It would require intelligence in the app's to know where to go, but it would make configuration of the apps much easier since they either have the client certificate or they don't.

My bonus question: Is using two endpoints a common practice?

Answer 1

Private keys should exist only in one place. If you distribute the private key to "authorized users", then the "authorized users" have all access of the original, and cannot be revoked.

The correct method would be:

• All devices share their public key, never their private key.
• The public key is approved by the account holder.
• Any changes logged should include the public key that was used, including the above approval process.
• If you want data to be shared between nodes, but not let the server/a hacker have access to it, generate a random key, encrypt the piece of data with the random key, and store it; then, encrypt the random key with each public key in turn, and store those. Then throw away the random key. Each authorized user can grab the encrypted random key, decrypt it with their private key to get the random key, and use that to unencrypt the data.

Answer 2

I am putting this as a separate answer, to draw attention to it.

The above question is a very common issue - "I want security, but don't want the effort of security. So I am going to cut corners on my security"

Your system will be insecure.

The overhead of managing customers' keys will be about the same as the overhead of managing their passwords. People will lose their keys, just as they will lose their password. People will have their keys compromised, a lot easier, since they didn't put a password on it. If a device is stolen, click on a bookmark and you're in.

The practice of storing their certificate, and verifying the certificate from a database, rather than following the CA chain, is fine - you are essentially verifying the public key. That's all you need to do. Distributing the same keys to multiple devices is a bad idea.