Public/Private key pair protection on Windows

Dear all,

Anyone with good information regarding the protection of the key pair?

Cheers,

/T

Thomas K

Thomas K wrote:
> Dear all,
>
> Anyone with good information regarding the protection of the key pair?
>
> Cheers,
>
> /T
>
>

What you really might want to protect is the private part (no pun intended).

imo a token, smart card or hsm is the best place for it.

All else fails.

Groetjes
John

John

"Thomas K" <> wrote in message
news:4243b1bd$0$44096$ i.nl...
> Dear all,
>
> Anyone with good information regarding the protection of the key pair?
>
> Cheers,
>
> /T
>
>
>
If the private key does not have a "good" password associated with it and
someone else has physical access to your machine, you are not well
protected. Further since MS often leaves the key around in "cache" if you
ever use your private key, you are not well protected.

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



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Edward A. Feustel

Edward A. Feustel wrote:

> For best results, generate your private key in a token (2048 bits or more
> preferred) and NEVER
> export it to a Windows machine.

Normal tokens do not allow the private key to be exported.

Groetjes
John

John

"Edward A. Feustel" <> 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/

Anne & Lynn Wheeler

Thx for all the feedback !

I'd also like to how how OS (MS OS) knows that a private key is associated
to a certificated located in one of the personal crypto stores
(user/machine)?
When double clicking a certificate, it reads "You have a private key that
corresponds to thise certificate". How does the OS know that?

Cheers,

/T

"Thomas K" <> wrote in message
news:4243b1bd$0$44096$ i.nl...
> Dear all,
>
> Anyone with good information regarding the protection of the key pair?
>
> Cheers,
>
> /T
>
>

Thomas K