Re: Public/Private key pair protection on Windows
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 03/25/05
- Next message: Rodney Kelp: "Re: Ad-Aware Update SE1R34 23.03.2005"
- Previous message: John: "Re: Public/Private key pair protection on Windows"
- In reply to: Edward A. Feustel: "Re: Public/Private key pair protection on Windows"
- Next in thread: Thomas K: "Re: Public/Private key pair protection on Windows"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 25 Mar 2005 08:29:50 -0700
"Edward A. Feustel" <efeustel@direcway.com> writes:
> For best results, generate your private key in a token (2048 bits or
> more preferred) and NEVER export it to a Windows machine. Only
> insert the token in the USB port when you must and only as long as
> it must be there. Further, be certain that any buffering of the key
> by Windows is erased when you are done using the private key, i.e.,
> close the session, or turn off the power for at least 20
> seconds. This will minimize the chances that someone else will
> acquire access to your key or be able to tale end your sessions. Ed
for rsa key-pair ... there is also specification for ecdsa, related thread
reference with pointer to nist fips186-2 ecdsa
http://www.garlic.com/~lynn/2005e#22 PKI: the end
because of various issues with pc vulnerabilities .... there is
the EU FINREAD standard ... misc posts:
http://www.garlic.com/~lynn/subpubkey.html#findread
... where you have a separate unit connected to pc with display and
keypad that directly talks to the token ... for accurately displaying
transaction and safely entering a token's pin/password.
use of hardware token addresses direct copying of the private key. EU
FINREAD attempts to address a couple additional vulnerabilities:
* various kinds of keyloggers capturing the token pin/password and
being able to execute transactions while the token is connected w/o
your knowledge. EU FINREAD has its own keybad for pin/password
entering.
* virus corrupting the transaction where the screen displays some
transaction supposedly to be digitally signed, but what gets sent to
the token for signing is totally different. EU FINREAD has its own
(small) display for presenting transaction (somewhat oriented towards
financial transactions ... akin to what you might find a supermarket
checkout counter).
there is also a dual-use attack.
digital signature infrastructure primarily is a mode from 3-factor
authentication ...
* something you know
* something you have
* something you are
where the relying party succesfully validating the digital signature
can assume that the originating party is in possession of the
corresponding private key (aka "something you have" authentication).
A digital signature authentication scheme may be a flavor of
challenge/response (countermeasure for replay attacks) ... where the
relying party transmits some random bits which the other end digitally
signs and returns the digital signature. the relying party then
validates the digital signature with the public key ... which is proof
that the other end is in possession of the corresponding private key
(aka "something you have" authentication).
Some infrastructures have also looked at use of public/private key
digital signatures to imply more than simple authentication ... aka
that verification of a digital signature is equivalent to a human
signature ... which not only implies "something you have"
authentication, but also implies something similar to a human
signature, aka implication of reading, understanding, approving,
agreement, and/or authorization.
A dual-use attack is when the same private key is used for both 1)
authentication events where random bits (that are never viewed, read,
or understood) are digitally signed and 2) human signature events
where there isn't some additional additional proof that some human
hasn't actually read, understood, arpproved, agreed, and/or authorized
the related bits being digitally signed.
So a dual-use attack is for some attacker, in a supposedly purely
authentication operation, transmit some bits for digital signing that
purports to be random ... when the bits actually can be interpreted to
represent some obligation as in a human signing event. A possible
analogy is in the MASH show where Radar is getting the col. to sign
stuff where the col. isn't actually reading what he is signing.
Part of the issue may be the semantic ambiquity with the term "digital
signature" ... where the use of the word "signature" is automatically
taken to imply some relation to "human signature" ... even tho
"digital signature" can be commonly used in situations where there is
no implication at all of the equivalent conditions for human signature
(read, understood, approved, agreed, and/or authorized).
somewhat unrelated, hardware tokens can also be considered somewhat a
phishing countermeasure. A lot of phishing is social engineering,
convincing people to perform electronic act that makes them vulnerable
(divulging their userids and passwords and other information that
enables things like account theft and/or id-theft ... where
transactions and/or other obligations happen w/o the person's
knowledge).
When a hardware token is also required, it is probably going to be
somewhat more difficult to convince a victim to mail off their
hardware token. It still doesn't eliminate the social engineering
where the attacker convinces the victim to directly execute the
transactions for the benefit of the crook (however, it does somewhat
minimize the ability for the crook to do their own fraudulent
transactions w/o the owner's knowledge).
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: Rodney Kelp: "Re: Ad-Aware Update SE1R34 23.03.2005"
- Previous message: John: "Re: Public/Private key pair protection on Windows"
- In reply to: Edward A. Feustel: "Re: Public/Private key pair protection on Windows"
- Next in thread: Thomas K: "Re: Public/Private key pair protection on Windows"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|