Digital Signature

Full Title or Meme

A Digital Signature is a string of bits created by a cryptographic process that is extremely difficult to create without access to a Private Key.

Context

• Nearly all of our digital lives depends on the ability to make a mark that can be known to have been make by the Subject.
• A (sem-)legal definition is a mark or sign made by an individual on an instrument or document to signify knowledge, approval, acceptance, or obligation.

  The term signature is generally understood to mean the signing of a written document with one's own hand. However, it is not critical that a signature actually be written by hand for it to be legally valid. It may, for example, be typewritten, engraved, or stamped. The purpose of a signature is to authenticate a writing, or provide notice of its source, and to bind the individual signing the writing by the provisions contained in the document.

  Because a signature can obligate a party to terms of a contract or verify that the person intended to make a last will and testament, the law has developed rules that govern what constitutes a legally valid signature. The Internet and other forms of telecommunication have created the need to transact legally binding agreements electronically. Almost all states have passed laws that recognize the validity of Digital Signatures."

  In the absence of a statutory prohibition, an individual can use any character, symbol, figure, or designation he wishes to adopt as a signature, and if he uses it as a substitute for his name, he is bound by it. For example, if a contract refers to "William Jones" but Jones signs his name "Bill Jones," the contract is still enforceable against him. An individual can also use a fictitious name or the name of a business firm. A signature might also be adequate to validate an instrument even if it is virtually illegible. The entire name does not have to be written, and the inclusion of a middle name is not significant.

Problems

• Not all Subjects are legal entities, so the meaning of the signature would be unclear.
• Public/Private Key technology is itself subject to attack and so the meaning of a secure public key technology is subject to revision from time to time as technology advances.
• Technologists somehow got the idea that they could define what a signature means. This is demonstrably untrue.
• The contents of the document signed are a key determinate to what a signature means. This cannot be changed by wishful thinking.
  • For example the level of assurance of an identity statement carries information about the live of verification that was applied by the signatory.

Revocation

Revocation is an idea from the credit card industry of the 1950's. The idea was that a cred card (or a driver's license) has an expiration date, but that the authorization implied in that credential can be revoked by the issuer. Revocation depends on the legal contract that applied to the grant. When it is permitted, there is a ceremony that the issuer must complete for the revocation to be effective. All conditions must be met.

1. The original grant of authorization must clearly state the conditions for revocation.
2. The conditions for revocation are followed by the issuer.
3. The verifier can access the state of the grant.

Common forms of revocation of digital certificates are (1) certificate revocation lists, (2) online access to the state of the certificate. At a fundamental level revocation is non-deterministic, but these work-arounds seem to be adequate for the problem at hand.

Solutions

• Samuel M Smith crated a taxonomy of trust carried by a signature. This is helpful for technologists, but, in and of itself, has no impact on the meaning of a signature. He was worried about the basis for trust, this page is focused primarily on the concept of enforceability. Still the concepts are valuable for architects, if not for lawyers.

1. Persistent Authorization Model = Any signed statement that is signed with the set of authoritative keys at the time of its signing, is valid until revoked (rescinded) with another signed statement that is signed with the set of authoritative keys at the time of the signing of the revocation statement.
2. Ephemeral Authorization Model = All statements signed with the set of authoritative keys at the time of their signing are automatically revoked when that set of authoritative keys are rotated.
3. Some Authorizations are Persistent, and Some are Ephemeral (Hybrid) Model = Any presentation of a signed statement with persistent authorization must include a refer- ence to its location in the VDR (log) to determine the authoritative keys at the time (loca- tion) in the VDR when the statement was signed. The signed statement is authorized until revoked (rescinded) with another signed statement that is signed with the set of authori- tative keys at the time of the signing of the revocation statement. If the VDR location ref- erence is absent in the presentation, then the authorization is assumed to be ephemeral and the verifier uses the current authoritative keys to verify the authorization status of the signed statement.
4. Rotate the Identifier not the Keys Model = A signed statement's authorization is persistent until the ephemeral identifier associated with the authoritative keys has been rotated. Rotation of the identifier effectively rotates the authoritative keys.

Zero Trust

Sam's paper also listed the features of a zero trust architecture which are:

1. Network Hostility. = The network is always hostile, internally & externally; Locality is not trustworthy. Solutions must provide means to mitigate network layer security vulnerabilities (man-in-the-middle, DNS hijacking, BGP attacks).
2. E2E Security.= Inter-host communication must be end-to-end signed/encrypted and data must be stored signed/encrypted. Data is signed/encrypted in motion and at rest.
3. E2E Provenance. = Data flow transformations must be end-to-end provenanced using verifiable data items (ver- ifiable data chains or VCs). Every change shall be provenanced.
4. Verify every-time for every-thing. = Every network interaction or data flow must be authenticated and authorized using best prac- tice cryptography.
5. Authorization is behavioral. = Policies for authentication and authorization must be dynamically modified based on behav- ior (reputation).
6. No single point of trust. = Policies for authentication and authorization must be governed by end-verified diffuse-trust distributed consensus. Policy is protected by diffuse trust.
7. Hosts locked down. = Hosts or host components executing any of the logic mentioned above must be locked down. Any changes to the host execution logic or behavior must be fully security tested and vali- dated over the respective possible combinations of hardware and software platform. This means locking down key management and cryptographic operations on the devices. This in- cludes key generation and storage, as well as signature generation and signature verification. These may benefit from the use of some form of trusted execution environment (TEE) either generally or specially as in a trusted platform module (TPM) or a hardware security module (HSM). In addition to key management and cryptographic operations, special security measures must be implemented regarding secure execution of the application logic (e.g. code injection, insecure object references, cross-site/service request forgery, cross-service script- ing, etc.).