Wireless Water Cooler

last person joined: 17 days ago 

Hang out and socialize with other community members in this off topic forum. Everything from industry trends to hobbies and interests are welcomed!
Expand all | Collapse all

802.1x flavor question

This thread has been viewed 0 times
  • 1.  802.1x flavor question

    Posted Nov 04, 2015 11:43 AM

    I'm responsible for the Aruba side of our 802.1x EAP-TLS wireless network. We had a person say that they exported his cert off of his Mac and installed in on his iPhone. He then was able to get on the network without using credentials.

    The person who runs the cert server believes the cert is setup, so it should not be exportable.

    If this is possible how do other organizations mitigate against the risk of someone exporting their cert to another device?



  • 2.  RE: 802.1x flavor question

    EMPLOYEE
    Posted Nov 16, 2015 02:42 AM

    This is a tricky question. From a scienentific standpoint, unless something prevents private keys to be exported, they can be exported.

     

    Let me try to add some background.

     

    To really enforce that keys will not be exported, you typically end up with some hardware protection to store the keys. Examples of such devices are Hardware Security Modules (HSM), Smartcards, or the Trusted Platform Module (TPM).

     

    Many operating systems store the private key in a software protected place (key store) in the operating system, for OSX this is called the Keychain if I'm correct. Some of those key stores allow the storage of the key in a TPM, so it is enforced in hardware to prevent export. Most systems however obfuscate and try to protect to the maximum what is possible to protect users from exporting keys (however theoretically they will not stand in a targeted attack), and some systems understand that and allow users to simply export the certificates with their keys. I'm not sure to which category the OSX key chain belongs, but from your observation is might be the last one.

     

    In addition to that, there is an important step in the process where you place the key in the user's or computers key-store. If you send the user a certficate with key, typically in a PKCS#12 or .p12 file, nothing really prevents him from importing that certificate on other systems than the one you targeted. Basically that .p12 file has everything that is required to import the certificate, and ignore any 'import as non-exportable' field or setting. Also, there is no way of enforcing a user to import the key into a TPM or other hardware protected key-store; you might have that possibility if you import the key yourself instead of having the user import the key.

     

    I'm not a Mac OSX expert, but from https://discussions.apple.com/thread/2229944?start=0&tstart=0, I read: -x Specify that private keys are non-extractable after being imported.
    This won't stop the user from copying the whole keychain off, however.

     

    So it seems like on OSX you will need to do something specific to import the keys non-exportable. And probably if you have the keychain file and the user's password you have still access to the keys.

     

    In a summary: key stores are as secure as their implementation, for real protection a hardware key store is a pre-requisite, and providing uses with their certificate in a .p12 file (or alternative format) gives anyone with access to that file and its password (may be cracked!) to the key and certificate.

     

    Hopefully this helps you understanding this issue, and that 'marking non-exportable' is easy as an idea, but a tricky thing to make really work realiably.



  • 3.  RE: 802.1x flavor question

    EMPLOYEE
    Posted Nov 24, 2015 09:29 PM

    You can also layer in authorization of the certificate by checking things like:

    - Does the MAC address(es) embedded in the cert match the connecting device's MAC address?

    - Has the profile of the device changed all of a suddent (Mac all of a suddent becomes an iPhone? Red flag, deny access)



  • 4.  RE: 802.1x flavor question

    Posted Dec 13, 2015 05:43 PM

    @cappalli wrote:

    You can also layer in authorization of the certificate by checking things like:

    - Does the MAC address(es) embedded in the cert match the connecting device's MAC address?

    - Has the profile of the device changed all of a suddent (Mac all of a suddent becomes an iPhone? Red flag, deny access)


    That's a great idea since I've had this concern as well.  However, I'm not sure if Microsoft CA embeds the MAC in the cert.  I'll have to check tomorrow if I can remember, unless you happen to know.