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.

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?

  • Two endpoints doesn't do much good in comparison to for example using file encryption. It is common to encrypt a file encryption key with device public keys. The same approach can also be used for credentials to access a service (maybe SRP or similar can be used for authorization).
    – Natanael
    Dec 13, 2015 at 16:27
  • 1
    How important is the access control from a business/risk perspective? I think there are simpler alternatives to what you are suggesting, but it depends how secure access needs to be (not that it is particularly secure using a single private key to provide access to thousands of devices!).
    – R15
    Dec 13, 2015 at 21:25
  • 1
    The information contained in the messages could be quite sensitive, but that depends on the client and what information they wish to broadcast. We wanted to avoid credentials since this would create a lot of overhead for us and our clients and would make configuration via an EMM much more tricky. Using this approach seemed like a simple win, since they would be aware of lost/compromised devices and could just update our service to block access. I'm open to alternatives as I want the best balance between security and ease of setup. Dec 15, 2015 at 16:31
  • I'm confused, why would distributing a private key to customers be preferable to distributing login credentials? Having multiple copies of the private key seems like an undesirable option, as you would then have to deal with certificate expiry etc. Feb 2, 2016 at 6:03
  • We simply don't want to maintain login credentials. This is an overhead we are trying to avoid. As the certs are only distributed via an MDM, the customer will be responsible for pushing out new certificates and the end user won't have to take any actions. We're still exploring the idea, so your comments are useful! Thx Feb 2, 2016 at 7:12

2 Answers 2


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.
  • Thanks for your answer. We didn't want to put private keys on each device since the service itself doesn't manage users individually. Having to generate private keys for thousands of users and administer them makes the software more complex. However, when it comes to encrypting the messages, your temp random key process is interesting and I'll explore it further when we need to add this feature. Apr 15, 2016 at 6:55
  • 1
    @tomasmcguinness "Having to generate private keys for thousands of users and administer them makes the software more complex." ... nonsense. How do you think corporates (and indeed some cloud providers) manage. Its not that "complex" ! Jun 14, 2016 at 10:00
  • Complex was a poor choice of word. It would increase the administration required. Jun 15, 2016 at 5:35
  • Have you thought about how users are going to move the private key and certificate from one device to another? And if so, how is this more difficult (for you or the user) than creating a new keypair & cert, and adding it to the existing account? Jun 15, 2016 at 22:27

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.

  • Thanks for your answer. The system doesn't have the concept of users, so we don't have users & passwords to manage. When people download the app, they can subscribe anonymously. This simplicity is one of the key selling points. I realise that it's not as secure as it could be, but if one device is compromised, the end result is the same. We are using MobileIron to store the private key, so there is an authentication barrier between my app and the certificate itself. It's not ideal, but given the message content, I feel it's a good compromise. Jun 15, 2016 at 5:43

You must log in to answer this question.

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