in order for the application to have access to the keys in
the crypto hardware upon an unattended reboot, the PINs to the hardware
must be accessible to the application.
The cards that I know about work differently -- you configure them to
allow unattended reboot, and then no PIN is involved.
Richard Salz wrote:
The cards that I know about work differently -- you configure them to
allow unattended reboot, and then no PIN is involved. This is a little
more secure, in that it requires a conscious decision to do this, as
opposed to sticking the PIN somewhere on the filesystem.
On Aug 2, 2009, at 4:00 PM, Arshad Noor wrote:
Jerry Leichter wrote:
How
does a server, built on stock technology, keep secrets that it can
use to authenticate with other servers after an unattended reboot?
Without tamper-resistant hardware that controls access to keys,
anything the
Arshad Noor arshad.noor strongauth.com wrote:
to the keys, in order for the application to have access to the keys in
the crypto hardware upon an unattended reboot, the PINs to the hardware
must be accessible to the application. If the application has automatic
access to the PINs, then so
Arshad Noor wrote:
Almost every e-commerce site (that needs to be PCI-DSS compliant) I've
worked with in the last few years, insists on having unattended reboots.
Not only that but many will be multi-node High Availability cluster
systems as well or will be horizontally scaled. This means
On Sun, 2 Aug 2009, Joseph Ashwood wrote:
So far, evidence supports the idea that the stereotypical Soviet
tendency to overdesign might have been a better plan after all,
because the paranoia about future discoveries and breaks that
motivated that overdesign is being regularly proven out.
All the HSMs I've worked with start their system daemons automatically;
but the applications using them must still authenticate themselves to
the HSM before keys can be used. How do the cards you've worked with
authenticate the application if no PINs are involved?
Sorry, I wasn't clear
On 08/01/2009 02:06 PM, Jerry Leichter wrote:
A while back, I evaluated a
technology that did it best to solve a basically insoluble problem: How
does a server, built on stock technology, keep secrets that it can use
to authenticate with other servers after an unattended reboot?
This
If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended
reboot - but can prevent an attacker from gaining access to those keys
after compromising a legitimate ID on the machine
This is the conundrum of the of
Hi,
If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended
reboot - but can prevent an attacker from gaining access to those keys
after compromising a legitimate ID on the machine - I'd welcome hearing
about
Paper and details are not yet public, but Schneier provides a summary:
http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
Basically, if AES-256 is implemented with fewer rounds than the standard
specifies (essentially the number of rounds recommended for AES-128), it
is
Arshad Noor arshad.n...@strongauth.com writes:
If you (or anyone on this forum) know of technology that allows the
application to gain access to the crypto-hardware after an unattended reboot
- but can prevent an attacker from gaining access to those keys after
compromising a legitimate ID on the
12 matches
Mail list logo
