3 ms·
Simple solution: codesign the “official” builds. Have a “test mode” LED on the device, and have the firmware refuse to turn the light on when running an unsigne
by Gaelan 9y ago
Simple solution: codesign the “official” builds. Have a “test mode” LED on the device, and have the firmware refuse to turn the light on when running an unsigned build. Bonus points if you allow dual booting into the standard build for testing.
- exikyut 9y agoI've been pondering a similar problem to this - secure state verification - and it seems fundamentally hard. In the case of the LED, it would be simple to open the case and cut the trace to the LED. Now you have to put every single calculator into test mode to verify the LED lights up before you can start the test. That won't work.
- revelation 9y agoYou seem to be suffering from a rather common affliction in tech circles. Normal people do not care in the slightest if someone could open the calculator and cut the LED trace.
- fasquoika 9y agoYeah, this should be pretty clear from the parent post talking about the TI-89. It's almost impressive how little effort actually goes into preventing cheating. It's basically honor system + harsh threats
- exikyut 9y agoFor what it's worth, I'm actually trying to solve the problem of creating a verifiably secure device based on a tamper-resistant design at the moment, so that bias crept in a bit. I fully realize that what I'm trying to do (build a trustable boot path that's also hackable) is impossible to 100% achieve; I'm instead trying to see if I can build a super cheap design that's irritatingly expensive to circumvent (for a known value of "expensive", with hopefully 5 or 6 zeroes). It's a thought experiment at this point; I guess I'm practicing hammering every nail in sight with my ideas to test if my mindset is actually sane or not :P
- Gaelan 9y agoWouldn’t you need to put everybody in test mode anyway for, you know, the test?