Back
[08:10:20] <dusted> I'm trying to find a way where only the bootloader is able to reprogram the chip, it must not be possible to erase or in any other way manipulate with the firmware, except through the bootloader, but it seems that even with lock-bits, one would still be able to do chip-erase ?
[08:10:33] <dusted> and not render the chip useless, but instead upload new, compromised firmware
[08:13:25] <LeoNerd> If you have physical access to the chip such that you can perform a chip erase, you can always desolder it and replace it with your own newly-burned compromised one anyway, right?
[08:13:41] <specing> dusted: HVSP / HVPP is meant as a rescue method, you cannot disable it
[08:13:41] <LeoNerd> The point of the lock bits is not to protect the /other/ circuitry, it's to prevent people reading out your code and stealing it
[08:13:48] <specing> yep
[08:14:07] <specing> dusted: you could flash your firmware so many times to wear out the flash
[08:14:21] <LeoNerd> Hah! 100k rewrite cycles though? ;)
[08:15:00] <specing> thats 2 days of programming with decent programmers
[08:15:12] <specing> and small enough flash
[08:15:28] <specing> but seriously, this is stupid
[08:15:40] <dusted> specing, thank you for the insight, that's a bit dissapointing, the thing is: the firmware is opensource, but it is of some importance that the user can trust it, so, I've already modified the bootloader such that they need to enable flashing and hold a physical switch to program it, so that if their pc was compromised, an intruder wouldn't be able to flash it without their knowledge
[08:15:42] <specing> and rude to those of us who scavenge chips from old/dead electronics :)
[08:16:28] <dusted> but, someone could still steal their device and connect it to an isp and then flash a compromised version of the firmware
[08:17:36] <antto> there are always ways to ruin teh fun, aren't there
[08:17:37] <dusted> while I believe that an onchip solution would provide some secuirty (you'd have to decap the chip and modify the (lockbit I hoped existed) with a focused electron beam or similar), but other physical tamper-proofing is not as safe
[08:17:39] <LeoNerd> Surely: just provide a standard ISP header obviously close to the chip and clearly uninterrupted. If the user wishes to verify the firmware on the chip, they can read it out using their own reader software/harder of choice, and verify it independently
[08:17:56] <LeoNerd> Alternatively: go with an OTP PIC chip
[08:19:11] <LeoNerd> IMHO the best way to achieve this kind of security in open hardware is to make the thing so open and introspectable that anyone can easily read out the code and verify it for thesmelves
[08:19:12] <dusted> LeoNerd, hmm, that's actually a pretty neat idea, I guess there's not really any way to fake that, however, it'd require external circuitey
[08:19:31] <LeoNerd> Only an external 2x3 pin header
[08:20:03] <dusted> true, but it'd require the users to hook up a programmer, I guess those paranoid enough to want this feature would also have access to that, so yea.. Maybe that's really the way to go
[08:20:05] <antto> ship the device with a police officer
[08:20:20] <dusted> antto, that's a pretty neat idea! :D
[08:20:27] <antto> whenever someone tries to do something "bad" - the officer would spank him
[08:20:34] <dusted> xD
[08:20:35] <antto> >:)
[08:21:41] <dusted> Physical security is hear
[08:21:43] <dusted> *hard
[08:21:53] <antto> how about.. if you add a feature to the firmware to read itself
[08:22:04] <LeoNerd> But you couldn't trust that
[08:22:10] <antto> so that you don't need a programmer
[08:22:10] <dusted> exactly
[08:22:15] <antto> why?
[08:22:22] <LeoNerd> Because if it was compromised it could just lie about itself
[08:22:29] <dusted> because you can replace the firmware with a version that lies
[08:22:32] <antto> a "bad" firmware would fake the whole data?
[08:22:45] <dusted> hmm
[08:22:52] <LeoNerd> Whereas the firmware can't prevent the /hardware/ from lying abou tit
[08:22:57] <twnqx> might be difficult to fit it
[08:22:58] <LeoNerd> Er. can't cause, I mean
[08:23:06] <dusted> maybe i could use the memory constraints of the chip to make it unfakable
[08:23:14] <dusted> noh
[08:23:33] <antto> say the chip is 16kB flash, the firmware is 14kB..
[08:23:57] <twnqx> antto: leaves you 2k to fit your extensions + fake info :D
[08:24:13] <antto> a fake firmware would need a 14kB lookup table, or some very clever code, to reproduce the whole 14B of "proper" data
[08:24:19] <twnqx> no
[08:24:31] <twnqx> you'd just put the minor hooks into the correct firmware
[08:24:36] <dusted> I'm going to agree with twnqx, that some clever code could do that
[08:25:00] <antto> hmz
[08:25:15] <dusted> for all I know, the right kind of "hack" would only require to change some jmp address, I guess the "read it back to me" function could easily be modified to hide that
[08:25:21] <antto> this is too much into h4x0r teritories.. i'm no good at that
[08:25:28] <twnqx> lol
[08:25:37] <twnqx> that's kinda my job o/
[08:25:43] <twnqx> to find holes like this
[08:25:50] <dusted> sounds like a cool job :)
[08:25:51] <LeoNerd> I still vote for my plan - make it so obviously simple that there's no way someone could put an exploit into it
[08:26:05] <antto> well, how about this
[08:26:08] <LeoNerd> If it's really simple you can additionally claim "look, nothing up my slieve"
[08:26:14] <dusted> LeoNerd, I think for many cases, your idea is the best fallback so far
[08:26:15] <antto> artificially max-out the flash space ;]
[08:26:18] <twnqx> where can i now send my invoice, antto?
[08:26:25] <dusted> but for the mainstream user, it'd be too much hassle
[08:26:35] <LeoNerd> Does the mainstream user care?
[08:26:45] <antto> twnqx how about this?
[08:26:46] <twnqx> no
[08:27:04] <dusted> LeoNerd, no, and that's the point, I should mention that it's a security device, so those that care the least are the ones that need to be protected the most
[08:27:10] <twnqx> depending how you generate the data it should work
[08:27:28] <antto> max-out the firmware via adding some (otherwise useless) const uint8_t arrays in the firmware
[08:27:36] <antto> so that there's no room for any extra code
[08:28:27] <antto> make sure that the "void filling" data is very random and non-repeatable
[08:28:33] <dusted> twnqx, hmm, I do have cryptography functionality on the chip, I guess it'd be a diffierent scenario if the whole stream is encrypted, as one minor change would cause a major change in the rest of the stream ?
[08:28:48] <twnqx> yes
[08:28:58] <twnqx> well, depends on the algorithm
[08:29:02] <twnqx> stream ciphers - yes
[08:29:03] <dusted> it's just aes256
[08:29:34] <LeoNerd> AES256 is just a block cipher
[08:29:43] <twnqx> then it depends on the extras
[08:29:55] <twnqx> like operation mode
[08:31:49] <dusted> I'm thinking that if this "readmeback" function generated twice the amount of data that's available in the flash, and all that data depends on being read.. no.. wouldn't work still
[08:32:28] <dusted> a clever person could then trick the input to the encryption function to replace the "bad parts" before they are ever processed
[08:33:19] <dusted> Ya, I'll give up and provide an isp for the paranoid,
[08:34:20] <dusted> I guess it's good enough that someone has to steal it, take it apart and put it together again to compromise it, still better than what most people rely on
[08:34:29] <LeoNerd> Hrm.. Why is RikusW never around when I want to talk to him.. (or her?)
[08:34:56] <LeoNerd> Plus the ISP header makes it trivial for people with compromised hardware to reset it again :)
[08:36:19] <dusted> Hmm, but equally trivial to compromise it, and if you forget to check it just once, or worse, leave it connected to the ISP, exposing it to the evil forces that might lurk in the dark corners of your pc, you're as far as before
[08:36:40] <dusted> ofcause, flashing the firmware needs to be done on a clean system that's never been connected to the internet, in a bunker of lead, on mars
[08:45:06] <antto> what's the problem with the "readmeback" function?
[19:48:39] <joshb> ≈p
[20:15:00] <Casper> now...
[20:15:12] <Casper> how long 'till tom's programmer pass the customs...
[20:20:22] <Casper> oh yeah... no wonder why no update today... it's an holliday... so customs were closed... duh...