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
