Skip to main content

Identities

For correct operations ThingsIX requires that gateways, mappers and routers are identifiable and are able to proof their identify. This is done through an ECDSA keypair on the secp256k1 curve. The public key is used to derive a ThingsIX id that identifies the entity and is registered in the ThingsIX smart contracts.

caution

Not all ECDSA keypairs are valid ThingsIX keypairs. The ThingsIX forwarder and router have support to generate a valid keypair. If you want to use your own software to generate keys read the next section careful.

Generation

To generate a valid ThingsIX id the user will need to generate a ECDSA secp256k1 keypair that satisfies a constraint that ThingsIX dictates. To explain this constraint we will first describe what a public key is and how it can be represented.

A public key is a point on the secp256k1 curve and consists of an X and Y value, both 256 bits numbers that are concatenated together. This is called the uncompressed public key and a 0x04 byte is prefixed to it to mark it as such. This make the total uncompressed public key 520 bit long. ThingsIX uses the Polygon blockchain that uses the 256 bits Ethereums Virtual Machine (EVM). Therefore working and storing 520 bits uncompressed keys is inefficient and expensive since many instructions will only work on 256 bits and storing 520 bits values requires 3 storage slots.

Since the curve and its parameters are public the Y value can be calculated from the X value and is therefore redundant. The public key without the Y components saves 256 bits and is called the compressed public key. There is 1 complication, due to characteristics of the EC curve for each X coordinate there are 2 valid Y coordinates (called even and odd). Therefore the full public key can not be derived from just the X coordinate. This is solved by prefixing the X coordinate with a 0x02 (even) or 0x03 (odd) byte. With this information the full uncompressed public key can always be calculated from just the compressed public key. The downside is that the X coordinate with this byte prefix is 264 bits and still inefficient to use in the EVM.

ECDSA provides enough security margin to apply another trick. ThingsIX only accepts "even" keys. These are keys from which the compressed public key starts with the 0x02 prefix. The registry stores only the X value and when the public key is needed the X value is prefixed with 0x02 to assemble the full compressed public key. From this compressed for the full uncompressed public key can be calculated. Since the X coordinate without the prefix is 256 bits the EVM can work on it efficiently reducing transaction costs. The downside is that only the "even" keys are valid and there is no efficient method to generate valid ThingsIX keys. Since half of the keys are valid a brute force approach to simply generate keypairs until a valid ThingsIX keypair is created is practically feasible.

Both the ThingsIX packet forwarder and router have support to automatically generate valid ThingsIX identity keys. But it is also possible to generate these keys with your prefered software. Here are some examples how to generate a valid key:

const { randomBytes } = require('crypto');
const secp256k1 = require('secp256k1');

function generateKey() {
for (;;) {
// generate random key and test if it's on the EC curve
const privateKey = randomBytes(32);
if (secp256k1.privateKeyVerify(privateKey)) {
// accept key only if its public key is even
const compressedPublicKey = secp256k1.publicKeyCreate(privateKey);
if (compressedPublicKey[0] == 0x02) {
return privateKey;
}
}
}
}