I consider here how to visibly render the security situation on a personal computer whose architecture is capability oriented.
I have seen images in Windows depicting computer components and cables between them.
Such images allow a user to understand where information is able to move.
I want to do the same thing for the information flow within the computer and show how such flow is governed, both generally and specifically as the computer is currently configured.
The advent of bluetooth (and IR ports before that) may require such imagery to speak to the paranoid about how information can leave his machine.
The perimeter drawn graphically may be a strategic part of the solution.
I hope to treat these specific security issues:
- Installation propriety
- Confinement
- durability
- service for hire.
Installation Propriety
There is no good reason that the code from Microsoft that installs their browser should run with the authority to delete or to damage the Netscape browser or conversely.
We address these issues more completely here.
When software is installed it requires a variety of resources and facilities.
Here are some typically required:
- Some particular version of each of several libraries.
The application may allow some latitude as to versions but each application must be able to specify its version.
I consider a font to be a library routine.
- Immutable source of mutable instances of standard objects.
This applies to systems where functionality is available via standard code that abstracts its data from the caller.
Again versions must be specified.
- Access to authority to acquire time and permanent space.
These authorities lasts only until the end of the installation.
Subsequent use of the facility requires the user to provide space and time.
- Some sort of access to any mutable infrastructure such as communication ports.
Note that such access is probably rescindable so that either:
- When better software comes along the port can be reclaimed from the old software,
- The user can grant access to the port to different software at different times.
All of these are immutable.
This section is written from a system design perspective (not the user perspective)!.
I imagine an operation that the user can do that creates a guest apartment in his machine.
The apartment comes pre-equipped with trusted (by user) bootstrap code that imports foreign code and gives it control.
To do this the bootstrap code must have the authority described above and also some authority to fetch the foreign code.
Its only police function is perhaps to:
- check code signatures
- rescind the authority it used to fetch the code, if such authority is not known to be discreet.
The apartment comes equipped with the authority described in the previous section.
The apartment will remain accessible to the user and be deletable, along with its yield, according to durability rules.
There are two facets to the apartment, the tenant’s facet and the landlord’s facet.
The computer user, owner and operator holds the landlord facet and the application is the tenant and holds the tenant facet.
Via the landlord facet, the user can:
- examine and adjust the limits on the time and space available to the apartment dweller,
- see the public key with which the application code was signed,
- delete the apartment subject to durability rules below,
The landlord facet does not provide any other access to the apartment.
Some degree of tamper resistance may be required here.
Durability
Durability ensures that applications do not deteriorate as a side effect of some innocent action.
An installer for an application can easily arrange to make the application safe from accidental deletion.
In fact I would propose that only the specific command to delete an application be able to impact that application.
This means that if the application depends on some shared library then it is impossible to delete the library while the application still exists.
It is also possible to find out what durable objects depend on some such shared mutable object.
Graphically I propose icons for the various apartments with lines running between them with a vertical component.
Higher apartments would depend on lower apartments.
This dependency is a partial ordering.
The rule that Something upon which something else still depends, cannot be deleted. transforms into the rule that You cannot delete something which is connected to something higher.
This is graphically easy to understand.
Efforts by the user to delete something not at the top can evoke a clear explanation of the rules as they apply to this particular situation.
See Software Distribution for further uses of apartments.
See also compartments for a closely related idea.
Dichotomy
There are two cases that are confused above.
I will call them the static and dynamic apartments.
An apartment becomes static just about the time that a factory that it produced becomes sealed.
A dynamic apartment continues its activities independent of any instances that it has produced.
Only static apartments can be durable.
Here are some reasons why some apartments may not be static:
- The tenant may be an agent for an information supplier that receives data from remote correspondents via proprietary protocols.
This activity is necessarily on-going.
Such an agent can probably not to be said to be discreet in any way regarding the queries made of them, at least by capability arguments.
- Compressed data acquired upon initial installation might be decompressed and cached.
- Billing algorithms may run and report or pay for usage.
Confinement
Confinement is somewhat of a dual to durability.
If a user chooses to connect the yield of a discreet factory to some other unconfined thing, then the system could depict this situation.
There are delicate issues of access of a confined object to a screen.
Tempest is especially easy if the image producer wants to export information.
We say that a factory is discreet and also that its yield is discreet.
This is very confusing.
The properties of the factory and its yield are distinct yet related.
The factory is not confined but is widely trusted not to divulge requests and to produce confined objects.
Technical arguments about confinement use diagrams that divide the world into two parts: inside and outside.
I suspect that the same concept is necessary for conveying the correct ideas to the user.
We need to design a secure confinement GUI along with a comprehensible explanation for the user about what is at stake!
I don’t know whether the parts of a confined world are always abstracted from the user.
Here I speculate about images bearing on these ideas.
Service for Hire
There may be data and applications on the personal computer under the agreement that their use will be metered and some payment be made.
The system can provide a degree of assurance that this agreement is kept.
Depending on the degree of trust between the vendor and user, the hardware may need to be tamperproof.
If the hardware is tamperproof then the hardware vendor may be in a position to provide a money back guarantee that the system will not crash nor various other problems arise.
See Why Johnny Can’t Encrypt by Whitten and Tygar for the devastating results of actually testing the usability of PGP.
The authors address issues unique to security interfaces and those issues must be addressed here as well.
See this for worries about complex display hardware.