> 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 involve
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.
I
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 sof
Arshad Noor 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 does an attacker who mana
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 tha
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 prove
> 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 en
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
> abo
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 susceptibl
Arshad Noor 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 machine - I'd welcome
I)ruid wrote:
> 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 AE
13 matches
Mail list logo
