This is meant to serve two purposes
The 370 Keykos came with domain code that would own (via a capability)
the physical interface to the proprietary Tymnet network.
That domain code handled the protocol stack up to the point where channels (or circuits) were distinguished, and would create keys with which to access those objects.
New circuits initiated from the outside are introduced to the “receptionist” which is a program charged with authenticating the user thru a familiar password scheme.
Typically the receptionist would reattach the circuit to a constant object selected by the user name and which had retained its state since the prior connection.
For developers that object was a persistent command language interpreter.
- To consider an architecture for network software within a capability system
- To illustrate distribution of authority to such software to achieve security and reliability ends not efficiently possible in Unix like systems.
We update that design to the new world of internet and extend our design to include one or a few styles of crypto software, now that the agent at the other end of the session is likely to be able to support crypto.
Public Key Crypto
This is the simplest efficient “objectification” of public key crypto that I can think of.
This abstraction might or not might not be ideal or even suitable to underpin higher level crypto facilities.
So far it is an exercise in finding a minimal abstraction.
Indeed I will not include signing for I want to be able to use Diffie-Hellman and I do not understand Elliptic curve signatures.
I think a symmetric key crypto object should also be defined which the PKO should then use.
There is an object type PKO that may or may not hold a private key.
While it holds no private key it is called an anonymous PKO.
There is a PKO factory.
A PKO uses some constant public key algorithm.
Perhaps this algorithm is chosen as the PKO is created or perhaps it is fixed.
The obvious candidate algorithms are:
- RSA, in which case we may use the finger print in place of the public key below.
- Diffie Helman, ditto regarding fingerprint.
- Elliptic Crypto
An anonymous PKO can be directed to produce a private key, after which it will yield its corresponding public key.
There is an issue regarding a source of noise or entropy that goes into creating the private key.
The crypto literature presumes a reliable source of unguessable bits.
Some systems gain advantages in providing environments where such sources are unavailable.
I think that an entropy source is a necessary parameter to the order on the PKO to create a key.
Consideration should also be given to the “choosing your private key”.
There is an order on a PKO to produce a channel object that may be used to communicate via some other PKO, perhaps over an insecure link.
Here are the arguments to this call:
Before we are done we shall have to call out which properties are required of the insecure channel, and the consequences of failing to provide them.
For instance must the secure channel have:
- Public key of the far end PKO
- Insecure byte stream channel to other end.
Symmetric crypto may easily be adapted to provide strong authentication.
Should our version do so?
We must guard against accepting bogus incoming packets produced or replayed by someone without knowledge of the shared secret key.
Prompt stream ciphers are vulnerable to this.
This is where I type a bare CR in a telnet session hoping for a prompt response.
The comm system may be tempted to XOR the CR with a byte of key material and send the result.
It is awkward to contemplate not protecting against substitution of the short unprotected cipher text in this case.
The attractive alternatives here seem to be:
- strong authentication
- error control
- prompt delivery?
It seems poor to get the crypto code involved with such traditional and available services as error control and protection against duplicate delivery.
Yet it is worrisome to let the intruder attack those mechanisms.
- padding the CR with enough constant material, such as 64 bits of 0, or better, sequence number, enciphering with the shared secret key, transmitting, deciphering, demanding 64 bits of zero padding.
- doing the MAC thing.
After a short discussion with Chris Hibbert I now think the following:
We need unencrypted lower level error control for historical and probably other reasons.
This level must tolerate and recover from some level of errors.
Recovery is complex and bug prone.
Our security should not be subject to such bugs, especially bugs provoked by malicious intruders.
Authentication and replay protection must be repeated within the crypto protected realm.
In this case recovery is replaced by a security alarm.