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.