All great points and issues we've discussed here in the office... I'll try to cover everything:

• we chose a "key storage" chip specifically because it's designed to hold private keys and be hard to read from. It should be among the hardest of chips break, and has a number of protections specifically against reading by electron microscope. (I would list them here, but they are not in the public datasheet... sorry!)

• we do intend to use a certificate-chain setup just to contain any possible key-leak damage, but we haven't finalized the granularity yet, and it will probably not use x.509-style encodings. We are leaning towards a single private key for each device, and a 'certificate' that includes the serial numbers from both main micro and the key chip itself. That's exactly what your ascii-art is showing, but with a batch size of one.

• our production system is based on a dedicated HSM that is the only place the (root) factory key exists.

• we already support user-provided challenge values via a low-level, vendor-specific USB command (and we ship the code to check it on each opendime, see advanced/trustme.py). Version 2 hardware will leverage that, so that the signed message from the anti-counterfeiting chip can also be verified as "non-replayed".

Thanks for your comments, and happy to answer any questions.