1

I've been redirected here from SuperUser, I hope the question is appropriate.

I need to restrict usage of a certain site to a limited number of customers.

More than that, actually: I would like to allow access from a restricted number of physical devices (Win + Android).

This means I should generate "device locked" certificates.

What is the best way to generate and deploy such certificates?

Note that:

  • Solution should not be browser specific (if possible; IE, FFox and Chrome are minimum).
  • Browser should combine certificate with some hardware fingerprint before trying to use.
  • I do not care if certificate is invalidated by system upgrade (I am perfectly OK issuing a new one... and deleting the old).
  • Checking should be done "server-side".

A SuperUser comment says:

There is no binding of a certificate to a hardware.
If you want this you need to use certificates which 
are integrated into the hardware and cannot be extracted 
from there, i.e smartcards.

Smartcards are not a viable solution for me, but some kind of USB equivalent could be used, if necessary, provided devices are cheap enough (few USD/each).

Alternatively I could request browser to send some information and try to validate the Client for there (something akin to https://panopticlick.eff.org/ coupled with custom certificate). Would that work? If so: what would I need? Are there libs performing similar checks Server-Side?

I searched the suggested "Similar Questions" but I didn't find something resembling my problem.

  • 1
    You can never trust the client as there will always be the risk that the client is lying. Hardware is harder to duplicate so it can make duplication less likely, but even copy-proof devices can be copied with enough effort. (This seems the right site for this question.) – Neil Smithline Dec 9 '15 at 0:32
  • Thanks @Neil, I am fully aware complete trust and security is difficult if not impossible. I would be more than happy with degree associated with smartcards. I was thinking about either USB devices or using a combination of self-signed certificates and browser fingerprinting, if I can find some "easy way" to implement (I would rather avoid reinventing the wheel). – ZioByte Dec 9 '15 at 8:28
  • Do you control the client devices ? Or do customers provide their own devices? – André Borie Dec 9 '15 at 10:07
  • @AndréBorie:I have mixed case. I do provide some devices (mostly tablets with preinstalled software), but others prefer using their own (mostly PCs). I cannot rely on controlling client devices, but I can, if necessary, provide some custom USB device to attach. – ZioByte Dec 9 '15 at 11:19
  • @Zio for the devices you provide, make sure they have USB ports and an OS that supports PKI cards (Windows and Linux work with OpenSC, not sure about Mac), and provide USB smart card readers and supply the key material on a PKI card. Though for the devices that you don't provide, you can't be sure they're clean - they may be already compromised and while the attackers won't be able to steal the private key, they'll be able to use it while the card is inserted. – André Borie Dec 10 '15 at 8:15
2

What you need is HTTPS with mutual authentication (client authenticates server based on its trusted certificate store, and server authenticates client by requesting a client certificate).

You should put the key for the client certificate on a smart card or equivalent HSM so that it can't be stolen if the client machine is compromised - there is no other way around this. If your inability to use smart cards is because the clients don't have readers, there are USB readers available. There are even pendrive-shaped readers that take a mini smart card (the same form factor as a SIM card) so you can order your PKI cards in that form factor and the whole solution will look just like a flash drive.

Card readers work fine with most OSes including Windows, Mac, Linux, and even Android through a generic USB API (you'd have to make your custom app talk to the reader though, the OS doesn't provide a library for that).

You could use certificates in software but the key material will then be at risk of being stolen via malware, so a hardware solution is definitely more secure.

For BYOD devices, they may already be compromised and a hardware solution will not fully protect you from an attacker using the key maliciously while the HSM or card is inserted.

| improve this answer | |
  • I agree. I am not looking for fireproof security, but rather a reasonable compromise which will keep an attacker without physical access to either server or client out and it will make "inconvenient" for legitimate customers to duplicate access (client) devices. Problem with USB smartcard readers (and other USB devices also) is most Android/IOs device do not have a readily accessible host USB port, I was thinking to some kind of HW fingerprinting coupled with two-way authentication (certificate-based). Can that be made reasonably secure? – ZioByte Dec 10 '15 at 9:59
  • @ZioByte the real problem of Android isn't the lack of USB - rather it's the lack of a standard software stack to interact with card readers and smart cards. – André Borie Dec 10 '15 at 13:09
  • I will accept Your answer because it's the most exhaustive in the given context. Thanks. I will, most likely, rely on another (less secure) method to fingerprint devices and then simply chose from a list of exchanged certificates. IMHO this should give me enough discrimination, while keeping costs down (with much less security, of course). Further comments welcome. – ZioByte Dec 11 '15 at 12:39
0

Sorry: just re-read the question and the fact that it's for website access again, so ignore the answer below (unless you want to get hardware info with Java or something).


For what it's worth, Maplesoft (sellers of symbolic algebra programme Maple) handle a similar situation by using an online activation process that generates a licence file tied to the computer's MAC address (and possibly some other info, but MAC is the main thing).

Purchaser receives a code that is used to activate, so server-side validation/logging/revocation and/or counting how many activations the purchaser has done (typical purchases, eg. by universities, allow multiple activations per key) is possible upon activation.

The licence file is checked at run time, so moving the hardware doesn't let you use more copies than you have bought. Cloning or just changing the MAC address on another device might, but there should be other info incorporated in the licence file's hashed code to prevent that. Or just make each activation key one-time usable.

Alternatives like smart cards sound tedious for the user (and require physical distribution). Whether the MAC address of an Android device can be accessed by an app I do not know, however, but perhaps they have a unique device identifier (UUID) like iPhones that could be used instead.

| improve this answer | |
-1

Use some feature-rich VPN. What you need cannot be portably done with only browser+OS. There are plenty VPNs which suit your requirements, especially the hardware/smartcard part and Android support.

Most VPNs can be configured to only apply to one IP address (or a few IP addresses) and allow insecure traffic to the rest, if you don't want to annoy the clients with breaking the rest of their connections.

| improve this answer | |
  • 1
    That seems only to shift the problem: How do I lock a VPN client to a physical device? All this security stuff seems to rely on certificates of one kind or another, which are easily transferred around. ... am I missing something? – ZioByte Dec 9 '15 at 11:23
  • NOTE: I did not downvote Your answer, even though it doesn't seem very helpful at first glance; I positively hate people downvoting without giving a hint on the reason why. – ZioByte Dec 9 '15 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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