Cirrent takes product and network security very seriously. Every aspect of the Cirrent service has been designed with security in mind – protecting the connected products, protecting the networks to which they connect, protecting the Cirrent cloud, protecting our partner clouds (network providers and product companies) and protecting the users who use ZipKey-enabled connected products.
There are four main elements to the Cirrent service:
- Automatic connection to a nearby ZipKey hotspot – when a ZipKey-enabled device is powered up, it looks for nearby ZipKey hotspots. If it finds one, it associates to the hotspot, authenticates, and uploads its status to the Cirrent cloud.
- Associating the device with a user (Device User Binding - DUB)– From their mobile app, a user can find nearby devices that have not been associated with any user yet, and associate them to their account.
- Moving the device over to the user’s private Wi-Fi network (Secure Credential Distribution - SCD) via Cirrent cloud – the user or their network provider can supply private Wi-Fi credentials that the device can fetch from the Cirrent cloud. When the device receives private Wi-Fi credentials, it disconnects from the ZipKey network and connects to the private Wi-Fi network.
- Moving the device over to the user's private Wi-Fi network via SoftAP or other local means – if the device is not in range of a ZipKey network, the user can associate to a temporary Wi-Fi network that the device makes available (the SoftAP network) and pass credentials to the device over that network. Some products may also use other local mechanisms (e.g. BLE, or sound) to convey private network credentials to the device.
Securing the Device Credentials
Every ZipKey-enabled device is pre-provisioned during manufacturing with a unique device identifier and a device secret (the device credentials). It is up to the product company to determine how best to protect these credentials on the device, and Cirrent works closely with the product companies to ensure that best practices are being followed to protection these credentials. As each device has a unique set of credentials, exposure of one set of credentials is a limited risk, as they cannot be used to gain access to information for any other device.
The device secret is used to derive two secrets: the Network key and the API key.
The Network key is used to authenticate the device when connecting to a ZipKey provider network. The ZipKey device id and Network Key are never conveyed in the clear, either being conveyed within a HTTPS tunnel (for WISPr authentication) or within the EAP method for WPA2-Enterprise networks. The device has a repository of certificates that it uses to verify that the network to which it is connecting is a valid ZipKey network provider so that it will only present the device credentials to the network’s authenticated ZipKey network provider. The only time the Network key is exposed outside of the device or Cirrent’s cloud are on ZipKey networks that use WISPr authentication: the network provider has access to the Network key in their infrastructure (between the WISPr termination point and the RADIUS client). Cirrent only works with reputable companies as ZipKey partners, and Cirrent has isolated the use of the Network key to only allow limited Internet access, so the risk is managed.
When the device has an Internet connection, it makes calls to the Cirrent cloud. All device to cloud communication is over HTTPS. The device uses the device id and the API key to authenticate to the Cirrent cloud, and validates that the certificate being presented matches the Cirrent cloud certificate that is pre-configured in the device.
Securing End User Access
Cirrent does not manage end-user accounts – these are managed by the product company. When an end user needs to access the Cirrent cloud (e.g. to provide private Wi-Fi credentials), the mobile app first authenticates to their product cloud, and then the mobile app fetches a token from the product cloud, authorizing the user to manage a particular device. The token is signed with the product company’s APP API key and secret, and verified by Cirrent before it allows the mobile app to get any information about the device, or upload private Wi-Fi credentials for the device.
The token used by the mobile app is signed by a company-specific API key and secret, which they store within their cloud. Every token that the product cloud generates is signed with their key and secret so it can be verified by Cirrent.
Securing Device User Binding
Cirrent’s Device User Binding (DUB) service makes it simple to associate the device with the user account, based on a combination of location, time, and device type. When the device is powered up, and associates to a ZipKey network, the device uploads its Wi-Fi scan list to the Cirrent cloud (the SSIDs and BSSIDs that the device can see). When a user wishes to claim a device, the mobile app uploads its location information (GPS coordinates and Wi-Fi scan list). The Cirrent cloud compares the locations and only makes available devices that have been powered-on recently, are of the right product type, and are near to the user (based on overlapping Wi-Fi scan lists and/or the GPS info). If more than one device is nearby, powered-on recently, and of the correct type, there are a number of additional safeguards to ensure the user chooses the right device. The device can provide a unique DUB key that the mobile app can use to prove it is the correct device. The user can take some action on the device (e.g. press a button) and the device will tell the Cirrent cloud whether an action was taken. The user can instruct the device to take some identifying action (e.g. flash a light or play a sound). Through these additional steps, the user can be confident that they have selected the correct device or devices. Once a user has claimed the device, that device is never offered to any other users, unless it has been reset in the Cirrent cloud by the product cloud.
Securing Private Wi-Fi Credentials
During the Secure Credential Distribution process, user’s private network credentials are uploaded to Cirrent’s cloud. Cirrent encrypts these credentials using a device-specific Secure Credential Distribution (SCD) key so that only the approved device can decrypt the credential. Cirrent’s cloud always stores these credentials in encrypted form in the Credential Vault, which is isolated within the Cirrent cloud.
If the mobile app is unable to find the device in the Cirrent cloud (either because the device is not in range of a ZipKey network, or because the user’s location cannot be determined), the mobile app will associate to the device’s SoftAP network, and retrieve device information directly from the device. The device will provide its SCD public key, and a unique identifier (the DUB key). The mobile app can check with the Cirrent cloud that this is a valid device (by checking the device id and the DUB key). The mobile app then encrypts the private network credentials with the device’s SCD key so that the private network credentials cannot be intercepted over the SoftAP network, and can only be decrypted by the correct device.
Securing Access to ZipKey Hotspots
ZipKey Hotspots can be secured in multiple ways:
- In some cases, ZipKey Hotspots whitelist Cirrent’s API IP addresses or domains. In these cases, all other IP addresses and domains are blocked.
- In other cases, ZipKey Hotspots require authentication. In these cases, devices log in with their unique credentials, and are provided limited Internet access. The ZipKey network provider can limit the bandwidth and domains the device can access, so that a compromised device could not gain access to any unauthorized networks or consume more bandwidth than it is entitled to.
Securing Cirrent’s Cloud
The Cirrent cloud is deployed as a geographically redundant set of servers within the Amazon Web Services. Cirrent follows the AWS recommendations to ensure that the Cirrent cloud is scalable, robust and secure. The Cirrent cloud is regularly audited to ensure that it conforms to industry best practices for secure cloud services.
Engineering best practices
All the software that Cirrent develops is intended for production use, and conforms to industry best practice for production software. For example, any passwords entered in any Cirrent software are never written to a log file. The software does not contain any debug backdoors or ways to enable unauthorized access.