Tightener Repository - zwettemaan/TightenerDocs GitHub Wiki

Machine Hash table

hash_state, machine_register_hash, prv_machine_register_hash, last_accessed_date

User hash table

user_guid, public key

Software hash table

issuer_guid, software_guid, name, description, version

Hashes in table:

User

This is a GUID for a particular user or entity.

userGUID = hash(user name + email address + password).

The repo registers these userGUID.

The validity of a userGUID can be verified by asking for the input data and re-generating the hash, then consulting the repo table for State = 1

Machine

Each machine in the system has a machine_guid, a randomly generated GUID. This GUID is retained locally, not stored in the repo.

The machine also stores a last_accessed_date timestamp value which it received from the repo last time the machine_guid was verified.

The machine calculates a local_hardware_hash = hash(user name, IP address, computer system info...)

machine_register_hash = hash(machine_guid + local_hardware_hash)

If the machine is getting a new machine_guid, it needs to register machine_register_hash with the repository. The repository checks whether magine_register_hash already exists. If it does, it returns an error. If it does not, it will create a new record with hash_state = 1, prv_machine_register_hash = 0, last_accessed_date = now, and it returns last_accessed_date to the machine.

If the machine has an existing machine_guid, the repo can verify the validity of (machine_register_hash, last_accessed_date) by looking up machine_register_hash, verifying the last_accessed_date matches and verifying the hash_state is 1. When the verification succeeds, the repo updates the last_accessed_date and returns that date to the machine for the next verification.

If the hash_state is 0 or the last_accessed_date does not match, then the machine needs to generate a new random machine_guid, and register the new magine_register_hash with the repo.

This way, each machine has a unique machine_guid which can be queried locally by a Tightener API, and a unique machine_register_hash which is retained on the repo.

Capability files

A capability file has two parts: content and verification.

The recommended format for a capability file is JSON.

The content could be things like an issuer GUID, a software GUID, a user GUID, a capability (e.g. can run x machines with the software until some date),... The capability file content can encode all kinds of data, but of most interest would be to encode a software license tied to a user GUID.

The verification part is a signature of the content part which can be verified with a public key retained by the repo for the issuer GUID.

The file has two parts - a content part and a verification part. The verification part is stripped and ignored when calculating the content part hash.

The verification part stores a signed hash of the content part. This hash is signed with a private key owned by the third party.