"Perry E. Metzger" <[email protected]> writes: > This does necessitate an extra manufacturing step in which the device > gets "individualized", but you're setting the default password to a > per-device string and having that taped to the top of the box anyway, > right? If you're not, most of the boxes will be vulnerable anyway and > there's no point...
Not quite, you can optimize that. Some software (e.g., OpenWRT) forces users to access the device via (local) ethernet before wireless is enabled. This enables security aware people to configure wireless security, and avoid a period of insecure wireless network. Incidentally, this approach also enables devices to collect entropy from the user session. That could be useful when generating SSH private keys. (Although I believe, unfortunately, OpenWRT generates the SSH key directly after the first boot. It seems unclear what kind of entropy it can hope to have at that point?) I agree with your recommendation to write an AES key to devices at manufacturing time. However it always comes with costs, including: 1) The cost of improving the manufacture process sufficiently well to make it unlikely that compromised AES keys are set in the factory. 2) The cost of individualizing each device. Each of these costs can be high enough that alternative approaches can be cost-effective. (*) My impression is that the cost and risks in 1) are often under-estimated, to the point where they can become a relatively cheap attack vector. /Simon (*) In case anyone doubts how the YubiKey works, which I'm affiliated with, we took the costs in 1) and 2). But they are large costs. We considered to require users to go through an initial configuration step to set the AES key themselves. However, the usability cost in that is probably higher than 1) and 2). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [email protected]
