keys and cards and user interaction

[coderman]

some corrections / clarification:

On 3/31/06, coderman <coderman at 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.