1

Assuming that I have a way to associate a combination of public private key encryption with real people/user. The private key is stored on the device of the user.

User have to communicate with some web service on multiple hosts for load balancing. Each host can verify the correctness of this key by calling a function.

Each client encrypt and sign with his key every request (that is tunnelled https anyway) and server always verify the signature and that the key is still trusted.

I mean to protect some CRUD request by verifying every request based on asymmetrical encryption. I’m thinking to use some encryption library. Application on the server receive the request and before processing the requests, It verify the digitally signature of the payload of http requests.

Can I rely only on this scheme for authenticate and accept request from the user? Or I have to add one additional layer of authentication such user/password or oauth2?

2 Answers 2

0

What you are describing is effectively what smart card authentication or the concept behind GPG. Even better, many web platforms support this out of the box such as Microsoft IIS which can enforce mutual authentication for client and server. However, Public Key Authentication is merely one piece of the entire puzzle of authentication.

When it comes down to certificate/key pairs we are really talking about identities. Identities which have been described, usually, in between 1024 and 4096 bits within an RSA private and public key. In fact, these identities are used all the time. Every time you visit an HTTPS website, every time use setup a new EC2 instance within AWS, and many other operations throughout the day. Public key authentication is alive and well and is often sufficient for authentication.

When you are building a service that will consume or manage identities, you are creating what's called and identity provider (IDP). An identity provider can be Active Directory, something you create yourself, or other services like PING, Okta, Duo and more. The identity provider allows entities (machines, service accounts, people) to be represented through a digital identity.

Users have to be expected to register themselves to this IDP in order to receive an identity and have that identity mean something. In terms of Public Key Infrastructure, this means users need to first verify who they are to a Certificate Authority (CA), often through a Registration Authority (RA). During this process, the Issuing CA will sign or generate a certificate for the new user to use as their digital identity.

Now the user is registered, they have been assigned a known public identifier (the certificate), and entrusted with the safe keeping of the private key. This key could be stored within multiple types of certificate vaults including software keychains, TPMs, SmartCards, Yubikeys, and more. The only real requirement is that the private key be held in a secure location that only the entrusted (registered) user can access and use.

With this infrastructure in place, the IDP which you leverage (or create) will allow you to use this as a form of authentication. This alone is sufficient, however, it is not particularly efficient. Without a supporting protocol a user will be prompted for their certificate each time they access a resource which could be laborious. Therefor, it becomes important that the administrator find a method to authorize a session which can be managed in a few ways.

  1. Create your own session management protocol
  2. Leverage a token based system (Kerberos, OpenID, Oath)
  3. Leverage a native session management system (Windows Authentication, PHP Session, etc.)

What makes this a challenge is that a certificate is only as secure the the medium controlling it. I can tell you I've helped expose certificates from macOS and Windows that were "unexportable" and I can further tell you that they are by OS design, not failure. That means you need a way to properly manage user credentials from CA to hardware and that gets more difficult. This is where the FIDO alliance really starts to play a strong hand.

FIDO2 is a method of allowing users to register to services with a hardware token across HTTPS. It can be used for authentication and even is designed to work with other open authentication technologies. Supported by companies like Google, Yubikey, Microsoft, and more; the FIDO protocols will continue to exist for some time. These protocols are currently supported out of the box by Google Chrome with support from Firefox and Microsoft coming out soon. Now you can enforce hardware storage of your certificate, enforce strong authentication, and ensure your application is handling identities in a mature fashion.

In summation, what you want to do is awesome. In fact, it's what most developers should be doing for any application on the internet. As an Identity and Access Management security architect, I have helped to design these solutions for Fortune 5 companies and know it's the critical path to a successful and healthy internet for everyone. Good luck and feel free to ping me for more information!

1

I believe, you want a two-way authentication, when TLS server identifies and authorizes clients based on client certificate information. In fact, it is already implemented and is called mutual TLS authentication. See for "client certificate authentication in TLS" queries. For example, this article provides a good explanation of mutual TLS authentication: https://blog.cloudflare.com/introducing-tls-client-auth/

When properly implemented, there is no much need to implement additional authentication mechanisms as long as you can distinguish uinque clients based on their certificates (e.g. map certificate to a particular user account in users database). Microsoft IIS has a built-in mechanism to authenticate and map client certificates to SAM or Active Directory users and no username/password mechanisms are necessary.

2
  • I think to use some library based on asymmetrical encryption. I’m thinking to use some encryption library. Idea to use TLS mutual authentication is good too, but I have ti find a way to let application layer know about the certificates. I have update my question to clarify.
    – Majascript
    Commented Jan 6, 2019 at 13:39
  • @Majascript - That's going to depend entirely on what your application framework is (and possibly the server). Some, like Microsoft's WCF (and a number of other SOAP-based frameworks), provide this out-of-the-box. Otherwise, you might have to write the certificate->identity mapper yourself. Commented Jan 7, 2019 at 5:59

You must log in to answer this question.

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