rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
Mangy_Dog has quit [Ping timeout: 265 seconds]
_whitelogger has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
chewitt has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
CyBerNetX has quit [Ping timeout: 240 seconds]
atsampson has quit [Ping timeout: 246 seconds]
atsampson has joined #linux-sunxi
lurchi_ is now known as lurchi__
gaston1980 has quit [Quit: Konversation terminated!]
jstein has quit [Quit: quit]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
<willmore> thermally conductive epoxy.
<willmore> Sticy pads are horrible.
mripard has quit [Remote host closed the connection]
mripard has joined #linux-sunxi
anarsoul has quit [Quit: ZNC 1.7.5 - https://znc.in]
anarsoul has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 272 seconds]
abelvesa has quit [Remote host closed the connection]
abelvesa has joined #linux-sunxi
ganbold has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Read error: Connection reset by peer]
_whitelogger has joined #linux-sunxi
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
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]
mcf has quit [Ping timeout: 240 seconds]
veremitz has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
veremitz has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
veremitz has quit [Remote host closed the connection]
veremitz has joined #linux-sunxi
akaWolf has quit [Read error: Connection reset by peer]
akaWolf has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
hanetzer- has quit [Changing host]
hanetzer- has joined #linux-sunxi
hanetzer- is now known as hanetzer
hanetzer is now known as hanetzer-
hanetzer- is now known as hanetzer
akaWolf has quit [Read error: Connection reset by peer]
akaWolf has joined #linux-sunxi
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #linux-sunxi
<bauen1> so what i said earlier about strncpy is actually wrong, they too are limited (correctly) to the buffer length
asdf28 has joined #linux-sunxi
CyBerNetX has joined #linux-sunxi
ldevulder__ has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 260 seconds]
yann has quit [Ping timeout: 260 seconds]
cnxsoft has quit [Quit: cnxsoft]
superprower has quit [Ping timeout: 260 seconds]
rex_victor has quit [Quit: Bye]
RichardG867_ has joined #linux-sunxi
RichardG867_ has quit [Changing host]
RichardG867_ has joined #linux-sunxi
RichardG867 has quit [Ping timeout: 246 seconds]
RichardG867_ is now known as RichardG867
AneoX has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
RichardG867 has quit [Ping timeout: 240 seconds]
RichardG867 has joined #linux-sunxi
lurchi_ is now known as lurchi__
AneoX has quit [Ping timeout: 240 seconds]
AneoX has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
yann has joined #linux-sunxi
lurchi__ is now known as lurchi_
qschulz has quit [Ping timeout: 256 seconds]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
yann|work has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
msimpson has joined #linux-sunxi
msimpson has quit [Remote host closed the connection]
hanetzer is now known as DavyJones
DavyJones is now known as hanetzer
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
sunshavi has quit [Ping timeout: 265 seconds]
MangyDog has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 264 seconds]
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
<asdf28> efuses?
<bauen1> the a64, h3, h5, h6 all have efuses (write once memory) inside the SoC
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<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
mcf has quit [Quit: quit]
mcf has joined #linux-sunxi
jbrown has joined #linux-sunxi
<smaeul> ah, I see
<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> smaeul: i found https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/blob/ceec41bced9047a61df5caa6322376dd278aac6f/u-boot-2014.07/arch/arm/include/asm/arch-sun50iw6p1/platform.h#L47-L48 which describes the SPC / SMC base address, said region is conveniently left empty in the manuals memory map
<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> for SRAM-PUFs there is also a quite lengthy github thread https://github.com/Tribler/tribler/issues/3064
<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]
<willmore> bauen1, in case you're not familiar with it: https://www.bunniestudios.com/blog/?p=5921
lurchi_ is now known as lurchi__