On Tue, Nov 17, 2009 at 01:35:12AM -0000, John Levine wrote:

> > So should or should not an embedded system have a remote management
> > interface?
> 
> In this case, heck, no.  The whole point of this thing is that it is
> NOT remotely programmable to keep malware out.

Which is perhaps why it is not a good idea to embed an SSL engine in such
a device. Its external interface should be as simple as possible, which
suggests a message-signing device, rather than a device that participates
in complex, evolving, interactive protocols with remote network services.

The integration of the message signing device with a complete system
(computer with browser + device) should include most of the complex
and likely to change software. The device itself, is just a display +
encrypt then sign black-box for suitably simple (to unambiguously
display) messages, and the transmission of the signed message to the
appropriate destination can be left to the untrusted PC.

Such a device does however need to be able to suppor multiple mutually
distrusting verifiers, thus the destination public key is managed by
the untrusted PC + browser, only the device signing key is inside
the trust boundary. A user should be able to enroll the same device
with another "bank", ...

The proliferation multiple of SecurId tokens per user in B2B financial
services has led to a search for greater than "drawer-full of SecurId
cards (with PIN glued to the back of each)" usability. The alternatives
are not always very strong, but a would be more-secure solution needs
to keep usability in mind for the case when the user needs to conduct
secure transactions with multiple parties.

-- 
        Viktor.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to