keys and cards and user interaction
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 ""
some corrections / clarification: On 3/31/06, coderman <coderman@gmail.com> wrote:
... "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.
note that within a graphical environment you may be prompted for passwords or authentication unrelated to the root/core identities which are stored in the "keys" volume(s). within the janus wireless software all password/passphrase management for root/core identities (the "keys" volume(s)) occurs at a text console and usually during boot. facilities are in place to prevent you from needing passwords in other contexts although this cannot cover every possibility. (that is to say, within janus we encourage the use of certificates and signatures for authentication and captcha/PINs for liveness detection. the identity management provided by janus wireless software is intended to make these keys/certificates easy to create, distribute, manage and revoke in any external domains where they are used.) this console mode only password use is done to prevent UI attacks (phishing, spoofing, etc) and text console provides a good way to avoid these.
... (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.)
the secure key management mode can import and export keys and cards and supports a wide variety of filesystems to do so. key backup (if used, please do) occurs in this domain and may consist of saving the password protected volume to multiple USB keys, compact flash drives, hard disks, or burned to CD/DVD media. you can use a different password/passphrase for these backup volumes. (for example, a random 256bit key written on a card stored in a safe) the other "keys" authorized modes simply consume/use existing keys. the "live" and internet connected modes are ephemeral, and thus only use public "cards" when pubkeys/certificates are required to access resources. if replay / MITM is a concern the public keys used should be one time only.
example: .../coderman/ (petname) .../coderman/id.txt (512 byte GUID / nonce in hex)
that should read: 512 _bit_ GUID or nonce in hex string.
coderman might be a social context while mpeck is a professional context.
a social and professional context are the two types provided by default. the number of contexts supported is limited only by storage space on the "keys" volume and your ability to assign distinct pet names to each.
participants (1)
-
coderman