License was widely used on many software/hardware area, such as Microsoft Windows Series, which use dedicated hardware to store their key and other information to verify the booting OS is legal or not. Dell or EMC or Oracle Database use license to limit how many HW resource can be used. So, license system is an valuable assert to the company as it can bring the direct profit.

Aspects when designing license system

• Security
• Compatible

Background

In common, the company would like to design a universal HW platform to carry on different requirements with the reason of decreasing the complex of BOM, leverage the cost on HW expense, etc. In order to make more profit on a universal hardware platform, then you need a license system to give the right authority to your sales/customer. For example, in the wireless system, some company would like sale the HW without any charge or very low price, but those HW only can carry on low volume data/service in the BASIC state, f.g. LTE station in BASIC mode only can take 16 Users in one BST, a limited throughput, a limited Cells can be setup. Basically, you had to buy a suitable license paper meeting your requirement, just like the menu in the restaurant, you can’t image how many menus did the company make ready for you. In one word, License can make money!!!

License file structure

I suppose the company had already made through on what functionality can be made into license, then a license list need to be properly designed with readable language and description. XML will be the good choice to record such list. Some necessary element in this XML should include:

• License Name
• License Number (unique number among the license)
• License Signed Date (2017-10-05)
• License period of validity (2017-10-05 — 2018-10-05)
• License specify contents (this will be specified according to each license with nested XML representation)
• Encrypted signed message using the PK(private key) to protect the integrity and security of license message

Store the public key

ARM based SoC provide TrustZone tech to the end-user, It use hardware-based hypervisor to run two VMs in one SoC. The software running in the TrustZone protected zone was only allowed by the release company, which means any software which want to run in TrustZone area must get signed by the SoC company. Technically, the TrustZone is the more safe method to store the key and other security information, even in the Motorola smartphone, the cracker success bypassing the protection of the TrustZone link The latest HuaWei smartphone claim they can replace the hardware token released by the BANK in their device when do some money transition, they all use TrustZone tech. The latest Qualcomm use their own property SPC instead of ARM trustzone to store such security information. But it will be BIG for us if we only want to store a key or some unique number on the SoC using TrustZone as there are no requirement that the app running in the SoC need or less need to store their per-app key into system. As an alternative, In most SoC, there is an OTP(on-time-programming) area in the system, many SoC has such kind of area in their design, such as efuse area in Intel platform, qfuse area in Qualcomm platform, even some FLASH manufacture (Macro) make some area for such usage, but if some old device or the latest device which don’t consider such requirement in advance don’t have any such kind area with such attribute, how to handle such issues? My suggestion is use one series of non-modifiable code (make some confusion work on this code) (unique ID include your CPU ID, etc)to sign your public key file, this method can protect you in some certain range.

The whole procedure will be like:

Manage the private key

As time intensity, I select the Vault to manage the private key, and wrote the back-end license generating tools using Go. We define the 2 different role on managing/using the private key.

• Administrator (who can generate the new pair key and revoke the key)
• Operator(who can use the back-end tools to generate the license key) As the Operator has no authority to see the private key, then it guarantee the security on generating the license file.

Conclusion

Actually, the cracker still has many path to crack this license system, like searching the public API nm string in the binary code and do the binary translate work or code injection, modifying the contents if you put some sensitive contents into fixed address in ram. etc.

So, it need programmer know some basic knowledge when they work on the sensitive information, don’t store such information in fixed address area, try to use stack or do some confusion work on such information.

It is better read/care the latest security information released in the public, and make your defend with much consideration.

##–Continued Finally, after some discussion with other guys working in Standard Organization, they recommended to fully meet the requirement of the 3GPP TS133.320. This specification defines a Trusted Environment(TrE) to perform sensitive functions and store sensitive data. This data must be unknowable to unauthorized entities. Some requirements follows:

• The TrE must be built from a hardware root of trust.
• The Integrity of the TrE must be verified during the boot process.
• The TrE must verify the integrity of the rest of the system software.
• The TrE must perform the required sensitive functions to validate the device and device integrity.
• The TrE must perform the required sensitive functions to authenticate the device with the operator network.
• …

So, if we fully support this standard, then we need the help of the TrustZone, where we build the TrE for the eNodeB.

• The HNB’s identity (SN) shall be stored in the TrE and shall not be modifiable. (it was wrote during the production with a stardard)
• The HNB’s private key shall be stored in the TrE and shall not be exposed outside of the TrE. (private key was used on such like IPSEC procedure)
• The root certificate used to verify the signatures on the SeGW certificate shall be stored in the TrE and shall be writable by authorized access only. The verification process for signatures shall be performed by the HNB’s TrE. (this related to the revoking work)
• The HNB’s TrE shall be used to compute the AUTH payload used during the IKE_AUTH request message exchanges.

We are now evaluating the OP-TEE in our product, I will make another blog on this work.

Here is a good representation on the OP-TEE.