Digital Trust Protocol Key Management
DTP key management is part of the Digital Trust protocol
Key management is hard. The more valuable a key is to you, the more secure and protected the key needs to be. On the other side, a key has to be accessible and not too inconvenient to use. Those two features contradict the other.
Digital keys have the soft spot of being easy to copy, picked up by spy software, or being stolen from network hacks. A good solution is to store and sign with the key on a separate device specifically built for the purpose. This is similar to a real physical key, to steal the key, you need physical access.
From the cryptocurrency world, hardware wallets and key signing devices have evolved to the best protection at this point. When managing a lot of money with your key, you go for the best protection. Because there is no pullback of the money (coins) if you lose it, that you otherwise would be able to in a regular bank.
Trezor have been randomly chosen as an example, and the author has no preferences between different hardware signing devices.
DTP uses a public/private key algorithm to generate an identity. Therefore it would be possible to update some of the hardware devices with software to be able to sign DTP claims. This would give the user the best protection from losing the key against attacks and still having convenient access to the key.
Multisignature key signing is also an option, especially as a Safe key for the Public Address of an identity. Multisignature key management splits up the signing process into multiple different keys that are handled by different entities. This makes it harder to steal the key, as you will need to get the keys from multiple locations.
Web of trust key management
Creating and using the same key for your DTP Public Address and signing of claims daily is a bad idea. The risk is that when other entities have trusted your Public Address and your key gets stolen. You lose control of the trust given to you, and the thief can act on your behalf, issuing trust to controversial subjects, that you otherwise would never trust.
The owner of Public address A, is trusted directly by the Persons A,B,C. Key A directly trust Subject A and B.
A hardware device can be used to generate the DTP Public address and sign claims daily, but this is not very suitable as it requires access to the device each time a claim has to be signed.
For strong identity management, delegate identities can be used by using a double signing technique. A person creates a safe key on a hardware device that others can trust. Then create a less secure private key, stored on the computer for daily use, that is trusted by the highly secure hardware key. The delegate claim message must contain signatures from both the issuer (high secure key) and the subject (daily key).
When a DTP search server recognizes a delegation claim, it channels through it without increasing the degree. This way, it is possible to create deeper networks without hitting the limit of three degrees when searching for subjects.
When Person B search for Subject A within her/his network, it will get the following result back.
The DTP search counts the degrees to Subject A as only 1 degree. Person B is the starting point, Safe Key is the first degree, and the daily key is from a delegate claim and therefore, still within the first degree. Subject A is the result and does not count as a degree.
If the daily key is compromised, it can be replaced by a new daily key B, by the owner of the safe key. This happens by issuing a claim distrusting the old daily key A and trusting the new daily key B. The distrust claim still has to contain a signature from both the safe key, daily key A.
After propagation of the new claims in the system, all DTP search servers ignore the old daily key A, because of the distrust claim and uses the new daily key B. From anyone’s else perspective; it looks like the web of trust network is unchanged. They do not need to change their trust to the Public address A as it has not changed.
The only difference is that the Daily key B is used to route through to Subject A. This is mostly unnoticeable from the perspective of Person B, as the end result is still the same.
Signing packages with multiple claims
Claims cost virtually nothing to issue, as it is a statement of your trust on others, only the limits of your hardware and service providers is in effect. The signing of each claim can be a time-consuming process; therefore, this can be solved by using the template feature within the package schema. This enables the user to sign a high number of claims with one signature.
For specifications on how this work go here
Conclusion
Using hardware devices or multi-signature schemes to protect your safe key for your Public address is the best option. However, it usually not suitable for daily use of issuing new claims. A good solution is to replaceable identities generate from keys stored on less secure location but more accessible.
Issuing many claims can be solved by using the template feature of the package schema. This requires only one signature for all the claims in the package.
