keys and cards and user interaction

[coderman]

comments?  suggestions?

"keys" store password/passphrase protected volumes with cryptographic
keys, certs, and other credentials associated with digital identities.

"cards" are read only volumes with the public keys and public
identifiers associated with digital identities.

it is very important that they not be confused, and that "keys" are
only used on a trusted system.


solution:

"keys" are the only volume which will ever prompt for a
password/passphrase to open them.  if you are asked for a password it
should only be on a system you trust and as expected when using or
managing your keys.  keys are stored on an XFS filesystem on USB or
other media (USB by default) which contains the encrypted key store. 
this scales well (multi-gig USB volumes) and uses existing crypted
file system support to implement privacy.  Any number of other volumes
(for example hdd installed OS'es) can be tied to this "keys" volume by
storing the AES keys and disk identifiers associated with that volume
inside the "keys" protected volume.

the only boot targets which may use private "keys" are:
 - the "keys" secure key management mode.
  - the "install" mode to create new loop-aes keys and install OS on
this trusted system.
  - the "hdd" mode to boot an encrypted OS installation on a trusted system.

the other boot targets should only reference public "cards" and will
never prompt for authentication at boot or during operation.

"cards" are ISO9660 filesystems that can be stored on a public USB
memory stick or burned to mini-CDR / DVD-R, etc.  "cards" are public,
and can be copied freely and will never ask for authentication.

the "keys" authorized modes thus explicitly mount a USB volume as XFS
when a "keys" volume is expected.  the key mgmt mode will explicitly
mount as iso9660 when a "cards" volume is expected.  thus a confused
user could not accidentally write secret "keys" data to a public
"cards" volume, and vice versa.

this also allows the key management mode to determine what kind of
volume is present as indicated by the file system type. (the secure
key management mode is the only mode where public "cards" can be
imported to your secret "keys".  the hdd and install modes will never
prompt for a public card.  note that the "live" boot mode may use
"cards" to connect to remote services securely.)

summary:

"keys" storage:

[XFS volume ...
   (petname for this volume)
   (public GUID / nonce)
   (GPG or loop-aes encrypted file)
<additional identies are stored under additional subdirs and the key
mgmt mode will prompt for which identity to access/authenticate when
managing keys for multiple ID's.  petnames must be distinct.>
]

example:
.../coderman/  (petname)
.../coderman/id.txt   (512 byte GUID / nonce in hex)
.../coderman/keys.dat   (encrypted key store, gpg or loop-aes)
.../mpeck/
.../mpeck/id.txt
.../mpeck/keys.dat

coderman might be a social context while mpeck is a professional context.


"cards" storage:
[ ISO9660 volume ...
  (sha512 hash of identity public key)
  (identity public key)
  (nickname or alias for identified entity)
  (additional volumes or metadata)
  (signatures for nicknames and other metadata)
]

example:
.../1496b640690342ed/  (hex digits of first 8 bytes of sha512 digest
of public.key)
.../1496b640690342ed/digest.txt  (full hex digits of sha512 digest of
public.key)
.../1496b640690342ed/public.key
.../1496b640690342ed/nickname.txt  ("coderman's public weblog")
.../1496b640690342ed/nickname.sig
.../1496b640690342ed/aaaaaa.dat   (arbitrary metadata - an image? etc)
.../1496b640690342ed/aaaaaa.sig   (signature for above)
.../1496b640690342ed/foo.dat   ""
.../1496b640690342ed/foo.dig   ""