<bauen1>
so the idea is to make an image like [toc0 header][toc0 items][real bootcode][certificate]
<bauen1>
smaeul: that isn't really right, the image specifies the data offset from the header and the length of the data to be hashed, verified and executed
<bauen1>
but it's quite likely that the DMA descriptor is on the stack before the return address so some math and careful creation of an attack image might be required
<bauen1>
i guess i should try to actually overwrite the stack
<bauen1>
also at least the spi nor boot code doesn't do any length checking (like the h5 and a53 i believe)
<bauen1>
smaeul: that is BROM_CONFIG you're refering to
<smaeul>
bauen1: OEM_PROGRAM is read and cached in SRAM A2 at 0x768. yes, there are several debugging functions (0x354 is another, also present in NBROM)
<bauen1>
perhaps some way of debugging where the brom is by observing memory access ?
<bauen1>
i'm also not really sure what 0x00002f64 does, it looks like it reads a 4 byte value from 0x80000 + (x << 0x8), but there is nothing there
<bauen1>
maybe it would be possible to (completely) disassemble some functions and save that representation with the binary form so it can be matched against other (s/n) brom dumps
<bauen1>
smaeul: i haven't found yet where in the sbrom the oem_program fuse is read, all i've found is reads against BROM_CONFIG
<bauen1>
interestingly there is a "sid_write_rotpk_hash_buf" function present in the sbrom (but unused) 0x37a0
<bauen1>
i'll have to give ghidara another look
<bauen1>
very nice
<smaeul>
bauen1: the bit that switches between TOC0 with and without the extra item is bit 15 of the OEM_PROGRAM fuse
<bauen1>
it also doesn't look like disabling fel is possible
<bauen1>
smaeul: if you have any additional information about 0x10303 please update https://linux-sunxi.org/TOC0
<bauen1>
it probably only needs a somewhat valid 0x10303 unless you actually flash the HUK
<smaeul>
bauen1: there are multiple ways to make a toc0 in dragonsecboot -- some include the additional 0x10303 item (it appears to be a certificate chain)
<smaeul>
apritzel: bauen1: I was using egon2toc0.rb, but now I'm using my own C implementation that matches the output of dragonsecboot
<smaeul>
bauen1: LCJS is used by hardware, not necessarily the BROM. It drives SID register 0xA0, which is a read-only secure mode flag. I flashed bit 11 of LCJS on both (0xf4 on H5; 0x48 on H6), and I just verified that's the only bit flashed (no BROM_CONFIG, no ROTPK_HASH) on both
<bauen1>
it does kind of look like "another certificate" since the operation also involves the rotpk hash
<bauen1>
but first the item has to have some sort of format to get this far
<bauen1>
but if sid[0x5c] == 0 then some more checks should be skipped
<bauen1>
i think i've finally found the function that "parses" 0x10303 and it does some operation on it and the sid HUK field (offset 0x5c)
<bauen1>
or at least it should "increase" the value saved into the sram debug
<bauen1>
smaeul: maybe adding an item with the id 0x10303 to your toc0 image can already make it boot
<bauen1>
in fact there appear to be 2 different implementations that check the signature of an image, one with the new 0x10303 and one without
<bauen1>
oh i see
<apritzel>
bauen1: I know, but normally all-0 or all-1 means: "ignore key". But maybe it doesn't anymore on the H6 (as you hinted). So we now need an actual key that has an all-0 hash.
<bauen1>
he didn't even flash a key so it should be all-1 / all-0
<apritzel>
bauen1: ouch. Do we know a key that generates an all-0 hash? That would maybe fix smaeul's problem
<bauen1>
the code to check if the rotpk is all 0 / 1 is still present, but i'm not really sure if it is called
<bauen1>
there's also some mix of clearly optimised (for speed) memory functions and e.g. this https://termbin.com/j4lg
<bauen1>
or at least some shared library between all broms
<bauen1>
which almost makes me believe that they have 1 git repo for all chips and use preprocessor macros to select functionality as needed
<bauen1>
actually, completely unused functions even (e.g. sid_write in nbrom)
<bauen1>
yes, and useless call wrappers
<bauen1>
it does make it a lot easier to reverse engineer
<bauen1>
almost like it was hand assembled
<bauen1>
yes, it kind of looks like -O0
<bauen1>
apritzel: i think the calling convention is why radare2 sometimes fails to save arguments
<bauen1>
BROM is arm 32 but uses the arm16 calling convention
<bauen1>
i think so
<apritzel>
bauen1: I see, thanks, I will take a deeper look then. I used my own objdump post-processor so far, but objdump doesn't work well with binary mixed Thumb/Arm, for instance
<bauen1>
apritzel: the benefits somewhat outweight the issues caust by loosing argument names / types in some cases
<bauen1>
apritzel: it does save everything else
<bauen1>
apritzel: the integrated emulator also doesn't quite emulate all instructions correctly
<bauen1>
apritzel: i haven't really figured out how to make radare2 retain the arguments and type information however
<bauen1>
yeah it's decent
<apritzel>
bauen1: so is radare2 any good? Would you recommend it? I just installed it the other day, but didn't find time to dive into it yet.
<bauen1>
apritzel: according to smaeul not even the "official" tool manages to create a working image \o/
<bauen1>
thanks to pine64 i now have a pine h64, but still need to pick up an usb cable to access fel
<bauen1>
apritzel: i don't think so
<bauen1>
apritzel: i'm currently using radare2
<apritzel>
bauen1: and do you just stare at objdump listings or do you have some tool to help you out?
<apritzel>
bauen1: do we have some TOC0 image for some H6 board?
<bauen1>
i'll see if i can figure out what 0x10303 does and then see if i can add it to egon2toc
<bauen1>
but yeah, a better tool would be nice
<bauen1>
no not really
<apritzel>
bauen1: I once started with adding the boiler plate part of mkimage support
<apritzel>
bauen1: do you know of any work to get some better tool than egon2toc.rb?
<bauen1>
also i need to make a pr for egon2toc.rb so the run code address is also signed, otherwise you can bypass secure boot easily
<bauen1>
apritzel: i haven't actually booted my h6 yet lol, but yeah h6 has changed the requirements
<apritzel>
bauen1: are you guys using egon2toc.rb? And you are saying that the H6 extended the requirements?
<bauen1>
and now i have to chase pointers again :/
<bauen1>
something of size 0x538
<bauen1>
it _will_ fail without it present (at least on one of the boot modes {try, efuse specified})
<bauen1>
it also looks like the sbrom requires a new item with id 0x10303, no idea what it's for, but maybe something related to NV2
<bauen1>
smaeul: also, the sbrom saves the "progress" into 0x3000000+0xd0, so maybe you can try to boot your toc0 image and when it enters fel dump that address
<bauen1>
smaeul: do you still know what exact bit you burnt to enable secure mode ?
<bauen1>
and it doesn't look like the lcjs is used anymore
<bauen1>
there's a function in the sbrom that actually reads the nv2 part from the sid, so maybe h6 actually implements it
<bauen1>
at least the check before trying other mediums
<bauen1>
it also looks like BROM_CONFIG (SID 0x10) can be used to skip the uboot check
<bauen1>
that is good news
<bauen1>
smaeul: so the brom toggle bit in the sram control register doesn't depend on secure boot being enabled ?
<smaeul>
bauen1: similarly, SMC 0 also works on H6 for switching to secure mode, as long as you switch back (call SMC 0 again) before returning to FEL
<smaeul>
bauen1: turns out I actually did find the BROM swap bit earlier by scanning through the SRAM controller registers... but I neglected the fact that FEL won't work after you swap out the FEL code for whatever is in SBROM
2020-11-08
<smaeul>
bauen1: which brom dump? H6 NBROM is already posted. I cannot access H6 SBROM because I can only access FEL, and I can't switch BROMs from NS mode
<bauen1>
also looks like the usb on the pinephone is wired to the usb-otg, makes it a bit hard to "disable" (i.e. burn) fel on the a53
<bauen1>
smaeul: but maybe you can add the brom dump ?
<bauen1>
the h5 sbrom also copies some informationn related to the rotpk to 0x10000 before entering fel (if it isn't overwritten) so dumping memory even from fel might reveal some helpful information
<bauen1>
but it might be worth a shot
<bauen1>
and iirc there's some code in at least the h3 fel enter code that disables it
<bauen1>
arm cores also have some form of debug, but i believe that is initially disabled
<bauen1>
this is funny, on the one side it would be bad for my use case if we can find a way to enter secure mode, on the other hand i don't fancy bricking my only h64
<bauen1>
DMA shouldn't be possible if the (presumably existing) SPC is configured correctly
<bauen1>
and (if you have an fpga) you could always try to power-glitch the image verification
<bauen1>
i also suspect that code running on the ar100 is always in secure mode, so maybe that is a possible attack vector
<bauen1>
but you've already tried a board with an empty rotpk hash so i just need to try with a valid rotpk
<bauen1>
i suspected that it wasn't really possible to mess with secure boot without bricking a board
<bauen1>
not being able to enter secure mode from fel is actually kind of what i want lol
<bauen1>
so maybe it doesn't work
<bauen1>
but iirc the quick test you did didn't result in hijacking the pc
<bauen1>
smaeul: there's a 2nd attack that does not require a valid toc0, only the magic must match
2020-11-07
<smaeul>
(bauen1: that's why I haven't provided an H6 SBROM dump yet)
<bauen1>
not sure, but it should be faster than the 40mb/s achievable over the usb 2.0 from the pine a64 lts
<bauen1>
i have to test the speed of usb 3.0 on the pine h64 tomorrow, the wiki doesn't seem to have any numbers
<bauen1>
u-boot appears to scan 4 different usb bus, a bit confusing since there should only really be 3
<bauen1>
still waiting on my usb cable to access fel and start digging at the sbrom
<bauen1>
but i've managed to boot this pine a64 lts to linux with only uart
<bauen1>
i wish i could lol
<apritzel>
bauen1: you forgot to re-flash the BootROM as well ;-)
<bauen1>
nice, just flashed an .xz to an microsd and wondering why it won't boot
2020-11-06
<apritzel>
bauen1: but both the PHY driver and the MAC driver did not do the right thing until recently
<apritzel>
bauen1: AFAIU rgmii-id is (mostly) the correct mode (With the Pine64+ being an exception: rgmii-txid), and should have been there from the beginning
<bauen1>
is changing the dt enough ? or is that just fixing a symptom of an underlying issue
<bauen1>
it will still be a few days till i can boot my pine a64
2020-10-31
<bauen1>
libv: backups alone aren't a silver bullet, there is also the bus factor to consider, which you seem to have covered to some extend
<bauen1>
having a page for an SoC makes it easy to link to other relevant information, e.g. a page documenting the memory or certain peripherals
<bauen1>
of course some additional information, e.g. available SBCs, release date and what not would be nice
<bauen1>
gediz0x539: i would say that the datasheets / user manuals are already enough
2020-10-28
<bauen1>
yeah this is looking quite interesting
<bauen1>
lol gcc is from the sifive tools: `Configured with: /var/lib/builds/sifive-tools/freedom-tools-master/obj/x86_64-linux-centos6/build/riscv-gnu-toolchain/riscv-gcc/configure [...]`
<bauen1>
i suppose once the blob has been reverse engineered you could port it to zephyr too ?
<clementp[m]>
bauen1 yes that what I understood too. I don't have lot of knowledge about zephyr but is it a good move to add the Bl602 support in zephyr instead of using freertos ?
<bauen1>
but arm has all the documentation behind a login/nda wall
<bauen1>
it also seems quite likely that allwinner is using arms cryptocell library for the crypto engine, embedded crypto engine and security id, the descriptions from arm match the features provideded quite closely
<bauen1>
from the short view i gave the h5 sbrom sha256 software implementation it looks good, at least the constants have the right values, it also appears to do length checking correctly
2020-10-08
<bauen1>
you could try a 5.9 without the audio driver compiled in
<asdf28>
bauen1: yes i think it's the audio driver
<bauen1>
'debugfs: Directory '1c22c00.codec' with parent 'sun4i-codec' already present' might indicate some video / audio driver error ?
<bauen1>
if you end up doing git-bisect properly you will have to compile the kernel a few times
<bauen1>
also reduce the amount of things compiled into your kernel, both to reduce the number of (unrelated) components that could cause failure and to speed up compilation
<bauen1>
asdf28: git-bisect can help you to narrow it down
<hramrach>
bauen1: sunxi-next is based on master. linux-next is some random merge of development branches so depending on the detup may or may not include the changes from current sunxi-next
<bauen1>
smaeul: thanks a lot, i'll look into updating the toc0 library to also sign the load address to prevent this
<bauen1>
but doesn't really seem to load for me :/
<bauen1>
tags and branches are the same (references), but branches "move"
<bauen1>
sunxi-next is based on linux-next which is based on 5.8, before the next release torvalds will merge some (or all) commits from sunxi-next into linux-next, then designate the commit where linux-next is currently as 5.9
<bauen1>
asdf28: the other way around
<bauen1>
now sunxi-next is actually based on some other branch (probably linux-next from torvalds tree), so you end up having a-b-c-d-e, where 5.8 points to c and a-b-c are commits from mainline, and d-e are commits based on that
<bauen1>
he actually committed it
<bauen1>
but there could be multiple chains, e.g. a-b-c-D and a-b-c-F
<bauen1>
basically commits form a chain, e.g. a-b-c-d-e-f-g
<bauen1>
a git repo is basically a big collection of commits, each commit has some code change, some info (author, description), and a parent
<bauen1>
^ someone with access to the repo should probably change that to sunxi-next
<bauen1>
branches and tags are both refs (references) to a commit
<bauen1>
yes
<bauen1>
but basically yes
<bauen1>
if you have a bit of time, familiarise you with the basic concepts of git, it's really useful
<bauen1>
asdf28: what you probably want is the sunxi-next branch
<bauen1>
asdf28: the 5.8 tag is (quite likely) the same 5.8 tag from torvalds linux repo
2020-10-07
<smaeul>
bauen1: SRAM gap is at 0x18000. yes, I'm using an SD card
<bauen1>
smaeul: you're booting via sd card i presume ?
<bauen1>
there should probably be a few null bytes before, just in case sboot writes something there
<bauen1>
smaeul: you also need to adjust the 0x15000 in the evil_head.S
<bauen1>
smaeul: i just remembered that 0x15000 is probably the start of a sram gap
<smaeul>
bauen1: uart0-h5.toc0 and uart0-h5-evil.toc0 behave as expected. uart0-h5-evil.toc0 gives no UART output and no FEL USB device.
<tllim>
@bauen1, check your PM
<bauen1>
and a read protect efuse wouldn't really make much sense anyway (sid access already requires secure or EL3)
<bauen1>
smaeul: thanks, but as far as i've found they are only enforced in software ?
<smaeul>
bauen1: CHIP_CONFIG (READ_PROTECT/WRITE_PROTECT) are the eFuses controlling eFuse access. the other way to write-protect is to disconnect the eFuse supply voltage
<bauen1>
nope, i've just been living of the rom dumps brovided by smaeul
<bauen1>
asdf28: well it's roughly 60kb too big, not that it exactly matters
<bauen1>
i think the math is a bit off
<bauen1>
smaeul: i've also added a test for the 2. exploit, 'make evil-uart0.toc0', this one is more "unsafe", it should overwrite the stack and cause a jump into (unsigned) code, then activate uart0 and print a message that the exploit succeeded
<bauen1>
and i haven't found any hint that the SID can be locked, e.g. by burning a speicfic fuse it becomes unwritable
<bauen1>
the other vulnerability: a really big (unsigned) toc0 that overwrites the stack, could be solved by SRAM PUF and an unwritable SID
<bauen1>
this could also be modified to include more of the toc0 header, e.g. TOC0_LENGTH, just TOC0_BOOT_MEDIA might be problematic
<bauen1>
then turn the memcpy into a NOP by specifying the (known) address where TOC0_ITEMn_STATUS will be, and put a branch to the actual bootcode in there
<bauen1>
you can modify the bootcode item to not just cover the bootcode, but also the TOC0_ITEMn_STATUS and TOC0_ITEMn_RUN_ADDRESS field
<bauen1>
but i think that can be used as a solution to 1 of the 2 vulnerabilities
<bauen1>
lol
<MoeIcenowy>
bauen1: smells the fell of sighax ;-)
<bauen1>
the h5 sbrom also doesn't appear to validate the item data_offset or data_length, so instead of signing the sha256 of the boot code you could point it anywhere in memory and sign the sha256 of that
<bauen1>
there are only really less than 8318 (less if you cull duplicates and remove illegal instructions), that could be used as ROP entry point by just changing the load_address
<bauen1>
i'm definietly overdoing this
<bauen1>
if you don't really care about physical access you could also just put toc0 in the spi nor and then mark that as secure to prevent non-secure code from accessing it
<bauen1>
an attacker could point the load address into an mmio region, but that would hopefully not be enough to achieve code execution since the sbrom will then also jump to that location
<bauen1>
pointing the load address into the stack can maybe be prevented by clever coding of the bootloader so that any possible byte sequence that is written over the stack top results in code execution jumping to 0x00 (reset), 0x20 (hand), the bootloader or other (friendly) nop locations
<bauen1>
when the bootloader actually runs, it can verifiy the contents of all registers, and known memory and abort if they don't match (good) known values, that way an attacker would only have the option of changing the load address to point into the sbrom or the stack top
<bauen1>
the only good news is, that if you copy the bootloader into the stack you also need to modify the contents of the stack that are modified when memcpy2 returns, otherwise the actual bootloader code is executed and it can prevent attacks
<bauen1>
but you can't really defend against making the sbrom jump to an arbitrary address in the sbrom itself
<bauen1>
it is probably possible to code the bootloader in a way that makes it hard, or even impossible to abuse its content
<bauen1>
you can also copy the bootloader into the stack at an arbitrary point
<bauen1>
so you can try to do ROP programming using the known contents
<bauen1>
the contents of the stack at the time of copying is also pretty public information
<bauen1>
the sbrom also doesn't seem to set register that makes unaligned access an error, so you can actually copy the bootloader anywhere you want without restrictions
<bauen1>
there's approximately 64 bytes on the stack that are accessed by the code after the bootloader is copied to the attacker controlled destination
<bauen1>
and would be limited to work calling whatever is in the sbrom, or copying the bootloader to any memory address
<bauen1>
then an attacker couldn't increase the size of toc0 by much without erasing the private key material
<bauen1>
if the SRAM just after the TOC0 memory location can be used as SRAM-PUF
<bauen1>
now, even if this attack succeeds not all hope is lost, but then a lot depends on if you can lock the SID to prevent erasing the ROTPK
<bauen1>
i hope the uart0 actually works, i've modified the linker script so it can run directly from toc0
<bauen1>
then you can use e.g. 'vimdiff <(xxd uart0-h5.toc0) <(xxd uart0-h5-evil.toc0)' to verify that only the load address and header checksum is different between the images, but not the rsa signature
<bauen1>
smaeul: without any sdcard the h5 should enter FEL, with uart0-h5.toc0 it should print a hello world to uart0, with uart0-h5-evil.toc0 it should enter an infinite loop without enabling uart0
<bauen1>
smaeul: thanks, i will try to keep side effects to the absolute minimum, do you have access to your h5s uart0 ?
<smaeul>
bauen1: sure, send me something to run, as long as it doesn't do anything sneaky like try to program more fuses
2020-10-06
<bauen1>
smaeul: could you maybe help me with confirming that the vulnerability actually exists ? i don't plan on buying a h5 board (and even then shipping would take > 1 month)
<bauen1>
smaeul: i still don't have any boards, so i can't actually dump the roms myself, so i don't have any h6 code to look at yet
<bauen1>
after the length has been read the sbrom will load data from the spi nor in 0x8000 increments using dma
<bauen1>
looking at the code that loads the toc0 from an spi nor chip, the length needs to be a multiple of 0x8000 to be accepted, but that's the only limitation
<bauen1>
smaeul: i'm not 100% if there is no limit, but it appears that at least 1 boot method (idk which one) doesn't have a limit
<bauen1>
and you also don't need physical access to exploit this bug, you just need to be able to write to a boot device
<bauen1>
smaeul: you don't even need to rely on rop, if you find the right word in the signed blob (a pointer to the end of the normal toc0 image) you can select the target location so that the stack is overwritten and upon return from the memcpy you have complete execution
<bauen1>
so at least for the h5 you don't even need any valid (signed) toc0 image to exploit this
<bauen1>
smaeul: i can't test this, i can only look at the dump, but i don't think so
<smaeul>
bauen1: is there not a size limit for TOC0?
<smaeul>
karlp: bauen1: for one thing, you can point it to the "switch to NBROM and enter FEL" code address in the SBROM
<karlp>
bauen1: explainn it like I'm five. you're secure boot bit runs first, how does being able to locate it at an arbitrary memory address do anything?
2020-10-05
<bauen1>
smaeul: oh and if you ever dump the nbrom or sbrom of the h6 i would love to take a look at it too
<bauen1>
if anyone wants to test my theory on an actuall h5 board with secure boot enabled i can probably cook up an image
<bauen1>
allwinner and secure boot, so close yet so far
<bauen1>
and i think the toc0 is loaded at 0x10000 upwards and the stack grows down from ~0x44ff0 downwards you can just make a really big toc0 image, overwrite the stack with pointers to your code
<bauen1>
and that defeats the purpose of secure boot
<bauen1>
you can do a lot of things if you can write to memory
<karlp>
bauen1: right..... and?
<bauen1>
for example if you have your signed code that expects to be loaded at 0x10000, i can load it somewhere else, e.g. 0x1BADBAD and still have it signed
<bauen1>
karlp: the sbrom will copy the contents of the toc0 to that location, and then jump to it
<bauen1>
so you could point that where ever you want the sbrom will (try to) copy the code and then jump to it
<bauen1>
except that only the code executed is signed, but not the location where it is copied to be executed
<bauen1>
in theory this allows for secure boot, i.e. only boot what has been signed by you
<bauen1>
after it has verified the signed code it copies it to the run_address specified in the TOC0
<bauen1>
the secure boot rom verifies that the certificate in the TOC0 matches the one in the SID before executing the code
<bauen1>
or controlled code execution if you target it at read-only memory, e.g. the brom
<bauen1>
at the very least the boot code needs to handle being loaded to arbitrary addresses
<bauen1>
it's basically an arbitrary write of predefined values
<bauen1>
so given a valid toc0 file you can modify the TOC0_SERIAL_NUM, TOC0_STATUS, append additional items, the reserved field, and most importantly the run address
<bauen1>
there's also another fun attack vector: only the boot code is signed, not the run address
<bauen1>
nevermind the $5 iron pipe to the head secret extraction method
<bauen1>
or rather you don't need any trusted storage
<bauen1>
you don't need any storage if you can memorise a number and a password
<bauen1>
you don't really need to carry around an entire computer / laptop, you only really need a trusted way of doing I/O (keyboard + screen) and a processor that can do asymtric encryption
<bauen1>
probably impossible
<bauen1>
hramrach: the real elephant in the room is how a human with (limited) no tools can verify the identity or integrity of an object, but this proof also needs to be impossible to fake
<bauen1>
and if you've got something that is "secure", just increase your attackers budget and keep going lol
<bauen1>
absolutely
<bauen1>
so FEL can also be used to read data (https://linux-sunxi.org/FEL/Protocol FEL_UPLOAD) can also be used to read memory, so either burning the pins or using an SRAM PUF is required to defend against that
<bauen1>
willmore: haven't heard of it yet, but i'm mostly looking for a hardware RISC-V that can run linux without selling a kidney, a few weeks ago rioslabs announced the development of a raspberry pi like RISC-V board (https://rioslab.org/) but so far not much has come of that
<bauen1>
even if FEL doesn't utilise enough SRAM to destroy the data necessary to create the private key it might still be fun to implement (and would make hardware attacks just a bit harder)
<bauen1>
> Thus, to save 256 bits key, it requires 2331 bits
<bauen1>
smaeul: you also have to operate under the assumption that the attacker has access to the valid bootcode and an h6, so any sram touched by the sbrom can be predicted
<bauen1>
ignoring the blob that is nbrom / sbrom, but all things considered that isn't too bad
<bauen1>
so i think i have everything that i want (assuming everything works as expected)
<bauen1>
to prevent tampering / extraction of secrets that isn't actually that stupid of an idea, since you can use radiation to introduce bit-errors in a running processor
<bauen1>
and you also have to trust something at some point
<bauen1>
ideally i would like to have a RISC-V board with a hardened SoC and bootstrap the only initial binary seed by hand, but that won't happen for the next 3 years at least
<bauen1>
but that is another interesting idea
<bauen1>
and not touched during verification
<bauen1>
it seems that is only used for encryption / decryption keys
<bauen1>
smaeul: you mean keysram ?
<bauen1>
understandable, but it seems quite likely that it does
<bauen1>
did you by any chance verify that the 'smc #0' backdoor exists on the h6 too ?
<bauen1>
yes, but FEL might not erase / over write enough SRAM to make this possible and what not
<bauen1>
smaeul: so if FEL writes over some of the SRAM then you don't know the initial values anymore once you execute code and can't calculate the private key
<bauen1>
smaeul: SRAM at boot isn't 0x00 it is usually a random value, what value depends on the actual chip, it is very hard to guess
<bauen1>
smaeul: now (and i'll have to investigate this) fel will over write some of the SRAM and there for some of the data necessary to recover the key
<smaeul>
bauen1: right, and if I have FEL access, I can write whatever I want to SRAM, including whatever values you are expecting
<bauen1>
smaeul: so you don't need all of the sram to be in the right state to construct the key,
<bauen1>
asdf28: not impossible but very hard, you basically blow a fuse on the chip by applying high voltage
<bauen1>
smaeul: to construct the private key you need to read the initial bytes from the SRAM(s), you then add a fancy algorithm that allows for some error correction
<bauen1>
i will probably just burn the usb data lines as suggested one forum post about secure boot
<bauen1>
smaeul: but that is a theory, i would need an actual board to confirm that
<bauen1>
smaeul: you could probably try to construct the private key from the SRAM (PUF, physically unclonable function) but i need an actual board to investigate that
<bauen1>
smaeul: thanks
<bauen1>
depending on the chip that can cost very little to a decent amount of money (for allwinner probably not so much)
<bauen1>
reading out the efuses requires you to either run code on the SoC (in Secure mode) or physicall attack the chip
<smaeul>
bauen1: u-boot SPL has FIT signature verification, so it can extend your chain of trust out to u-boot proper
<bauen1>
then you still have ~1kb of efuses for free use
<bauen1>
for TOC0 / secure boot the sha256 of the rsa publicy key is stored in them and the sbrom checks if the bootloader it is loading is signed with the key
<bauen1>
the a64, h3, h5, h6 all have efuses (write once memory) inside the SoC
<bauen1>
probably writing some proof of concept that does attestiation (basically telling a user that the device is the real one and that it has only loaded trusted code)