abelvesa has quit [Remote host closed the connection]
abelvesa has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
random_yanek has quit [Ping timeout: 260 seconds]
random_yanek has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
msimpson has joined #linux-sunxi
msimpson has quit [Remote host closed the connection]
cmeerw has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
<bauen1>
i wouldn't be terribly surprised if the asn.1 parser and verification logic contains a buffer overflow or more
<bauen1>
the parser result is stored on the stack and the parser itself seems to verify the length of buffers before copying, but in case the supplied length is higher than the buffer less is copied (good) and the length is saved anyway (bad length > buffer size)
<bauen1>
and later when verifying the certificate there are a number to strncpy calls that just take the parsed length and don't do any limiting on the length
<bauen1>
i'm not sure if that is even exploitable
yann has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
iyzsong has quit [Ping timeout: 240 seconds]
ldevulder__ has quit [Ping timeout: 240 seconds]
iyzsong has joined #linux-sunxi
hanetzer- has joined #linux-sunxi
warpme_ has joined #linux-sunxi
gumblex_ has joined #linux-sunxi
lvrp16 has quit [Ping timeout: 240 seconds]
hanetzer has quit [Ping timeout: 240 seconds]
gumblex has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 240 seconds]
merbanan has quit [Ping timeout: 240 seconds]
merbanan has joined #linux-sunxi
lvrp16 has joined #linux-sunxi
TheSeven has joined #linux-sunxi
dev1990 has joined #linux-sunxi
dev1990_ has joined #linux-sunxi
dev1990 has quit [Excess Flood]
TheSeven has quit [Read error: Connection reset by peer]
netlynx has quit [Remote host closed the connection]
<asdf28>
why does no one say anything?
<montjoie>
I have nothing to say
<montjoie>
...related to #sunxi, if you know good chip for current monitoring I am interested, I need to monitor my sunxi zoo power usage
sunshavi has joined #linux-sunxi
lurchi_ is now known as lurchi__
CyBerNetX has left #linux-sunxi ["WeeChat 2.3"]
lurchi__ is now known as lurchi_
mcf has joined #linux-sunxi
<bauen1>
asdf28: if you want to i can talk about secure boot, trustzone, my future plans with a h6 sbc, and my recent reverse engineering of the h5 sbrom, interested ? lol
<asdf28>
q:-=>
<asdf28>
what are your plans?
<bauen1>
the end goal is to build a (cheap) proof of concept of a trusted soc that is tamper proof against evil maid attacks (or at least once with a small budget)
<bauen1>
so basically storing a private key in the "secure" efuses of the h6 and using secure boot to ensure that only trusted code can access the secrets
<bauen1>
so that involves actually buying an h6 board, figuring out how get secure boot to work and writing a bootloader that fits in the limited space provided by the sbrom and implements proper secure boot
<bauen1>
then i kind of need to figure out what to do with that
<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)
<asdf28>
that sounds interesting, but also very complicated. i didn't even know such chips had a secure boot feature
<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>
then you still have ~1kb of efuses for free use
<smaeul>
bauen1: u-boot SPL has FIT signature verification, so it can extend your chain of trust out to u-boot proper
<bauen1>
reading out the efuses requires you to either run code on the SoC (in Secure mode) or physicall attack the chip
sunshavi has quit [Remote host closed the connection]
<bauen1>
depending on the chip that can cost very little to a decent amount of money (for allwinner probably not so much)
<bauen1>
smaeul: thanks
<smaeul>
I'm not sure how you could attest that FEL mode hasn't been entered, other than physically detaching the USB0/MUSB data lines
<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: but that is a theory, i would need an actual board to confirm that
<bauen1>
i will probably just burn the usb data lines as suggested one forum post about secure boot
<smaeul>
yes, that's a good idea, though it may be possible for a FEL user to cover their tracks
<asdf28>
write once memory? so you write a key into it and it's physically impossible to change it afterwards?
<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>
asdf28: not impossible but very hard, you basically blow a fuse on the chip by applying high voltage
<bauen1>
smaeul: so you don't need all of the sram to be in the right state to construct 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: 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
<asdf28>
very interesting
<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: 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
<smaeul>
if the initial values are sufficiently unique, I won't know what to write
<bauen1>
yes, but FEL might not erase / over write enough SRAM to make this possible and what not
<bauen1>
did you by any chance verify that the 'smc #0' backdoor exists on the h6 too ?
sunshavi has joined #linux-sunxi
<smaeul>
no, I haven't put any h6 boards into secure mode yet
<bauen1>
understandable, but it seems quite likely that it does
sunshavi has quit [Read error: Connection reset by peer]
<smaeul>
fwiw, there's also a block of secure SRAM used by the crypto engine. maybe that could be useful to attest a successful signature verification
<bauen1>
smaeul: you mean keysram ?
<bauen1>
it seems that is only used for encryption / decryption keys
<bauen1>
and not touched during verification
<bauen1>
but that is another interesting idea
<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>
and you also have to trust something at some point
<buZz>
nuclear hardened? :D
<buZz>
radiation*
<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>
so i think i have everything that i want (assuming everything works as expected)
sunshavi has joined #linux-sunxi
yann|work has quit [Ping timeout: 265 seconds]
<bauen1>
ignoring the blob that is nbrom / sbrom, but all things considered that isn't too bad
<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>
> Thus, to save 256 bits key, it requires 2331 bits
<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)
tuxd3v has joined #linux-sunxi
mcf has quit [Quit: quit]
mcf has joined #linux-sunxi
asdf28 has quit [Ping timeout: 240 seconds]
jbrown has quit [Ping timeout: 272 seconds]
Ntemis has joined #linux-sunxi
cmeerw has quit [Ping timeout: 240 seconds]
jbrown has joined #linux-sunxi
Ntemis has quit [Read error: Connection reset by peer]