log☇︎
93500+ entries in 0.054s
swiftgeek: asciilifeform: yep it needs to be open otherwise lol
asciilifeform: we were discussing 'hardware which you trust to do rsa exponentiation' , neh
swiftgeek: hl`: and nobody dumped yet trackpoint code either :>
hl`: Sure. Honestly, I'm surprised nobody has managed to dump decrypted Intel microcode yet. Seems to me you could probably accomplish something with glitching.
hl`: (especially since they have a bloody _firmware update_ capacity. !)
hl`: pretty much - agreed that TPMs with nonfree firmware (i.e. all of them which currently exist) are pretty dubious for that reason.
asciilifeform: if i cannot audit the contents of the device, it is impossible to prove the nonexistence of magic key.
asciilifeform: this is the fundamental fallacy that resulted in a market empty of honest iron.
hl`: asciilifeform: not exactly. the fundamental premise is just to measure the computing environment - this can be used to pro-owner ends if you control the tpm.
asciilifeform: whole concept of 'tpm' is explicitly counter to owner control. starting from when it was called 'palladium' and pushed by ms.
hl`: to be clear, any company which ships chips fused to only run their code gets a 'fuck you' from me
swiftgeek: hl`: softbrick in thinkpad provides resistance against evil maids :)
asciilifeform: hl`: how much do you like google's tpm, which opens in 3 seconds to 'evil maid' with the magic rsa key ?
hl`: there's not really that much point to tpms if physical attacks aren't in your threat model. if they are, they can provide resistance against evil maids, etc.
swiftgeek: if there is no root of trust on device then it's just another layer of obfuscation
asciilifeform: my 'root of trust' is iron that i assembled with own hands, out of soviet components, and sealed with glitter polish. fuck fritz tpm.
swiftgeek: asciilifeform: it depends on having root-of-trust (tpm isn't it), then it's a fun store of secrets
asciilifeform: http://trilema.com/2014/spy-stuff/ << like this.
asciilifeform: you don't resell crypto hardware, you thermite it
swiftgeek: hl`: especially when you think about reselling the device
hl`: yes, exactly. i'm talking about the use of owner-controlled TPMs to secure against other parties.
swiftgeek: hl`: but OTP root of trust is not a solution either
swiftgeek: hl`: if you have more devices on same bus you can figure out something to sniff it, and later replay
asciilifeform: and i am definitely not interested in iron that protects against ~my~, the owner's, physical attack.
asciilifeform: hl`: i am not interested in buying iron that specifically protects against everybody-but-nsa physical attack.
swiftgeek: hl`: you don't need physical attack there really
asciilifeform: whole concept of 'root of trust' is a crock of shit.
swiftgeek: hl`: it depends on root of trust being somewhere else
asciilifeform: over in the civilized world, we http://trilema.com/2013/how-to-airgap-a-practical-guide/ our crypto.
asciilifeform: they're a nsa boobytrap, sold under the fraudulent pretense of 'security'
swiftgeek: hl`: not exactly that case either
hl`: not really trustworthy if they have non-free firmware on them, but theoretically they have a use case ☟︎
hl`: no, TPMs _can_ be used to secure your own stuff if _you_ control them
swiftgeek: then everything would need to be implemented properly in SoC
asciilifeform: why the FUCK would you want 'open' manacles ?
swiftgeek: yeah i was just saying about having TPM module implemented in open manner
asciilifeform: but would like to try cleansing commercial arm64 board, first.
asciilifeform: understand, i can have ice40 boards to fit lappy chassis roll off conveyor in 6mo, if i want.
asciilifeform: j2 at least has the virtue of being small, and fitting in ice40 fpga.
asciilifeform: fuck riscv. it was deliberately designed with no arithmetical carry, to cripple cryptography. ☟︎
swiftgeek: sure but they will chip into contributing to toolchain
asciilifeform: no thx.
asciilifeform: other than as fpga softcore -- where ?
asciilifeform: fabrication, is the rub.
asciilifeform: it is not difficult to design a usable cpu, if you don't need bincompatibility with anything
swiftgeek: j2 would be fine too
swiftgeek: would be nice to have nicer implementation with riscv :D
asciilifeform: i am not particularly interested in infineon, you can safely desolder it from any box that has it
asciilifeform: so 'it's a tpm' is not anything like whole story.
asciilifeform: swiftgeek: the typical x86 pc 'infineon' etc tpm, cannot do such interesting things as overriding bios write protect, accessing microphone, etc
swiftgeek: so if somebody has separate module they are left vulnerable
swiftgeek: what i'm annoyed about is that infeon is not distributing updates directly to consumers
asciilifeform: ( this was possible because i purchased a unit having cr50.r0.0.10.w0.3.3 fw )
swiftgeek: asciilifeform: ditto for any other TPM
asciilifeform: i've established that cr50 ~will~ accept fw update if ver is incremented and rsa signature is valid. so anybody with google's rsa key and 10 seconds of physical access can insert new fw into cr50.
asciilifeform: ( afaik strictly via the console, but this remains to be determined )
asciilifeform: so this part is not so interesting imho.
asciilifeform: i can also 'replace the card' by switching off its power rail via ec and inserting usb nic dongle.
a111: Logged on 2018-06-11 20:09 asciilifeform: swiftgeek: my specific interest is to get arbitrary code exec on the device.
asciilifeform: swiftgeek: understand, i have a quite specific aim in re this machine, outlined in http://btcbase.org/log/2018-06-11#1822866 . i do not particularly care re the irrelevant details, e.g. the shape of the antennae in m2, or the exact diameters of the screw holes, etc. ☝︎
swiftgeek: yeah another one of those modular certification
swiftgeek: asciilifeform: i can tell at the very least it doesn't look like anything ROHM would make (the chip)
swiftgeek: hmm let's take last ditch detour, FCC ID
asciilifeform: ( and by the total unavailability, other than as antique, of actual computer )
asciilifeform: swiftgeek: i personally am more annoyed at rubbish masquerading as computer, than by general-purpose rubbish
swiftgeek: while it's illegal dump, you have to deal with it nevertheless
swiftgeek: it's kinda like neighbouring country dumping some trash in forest of other country
asciilifeform: hl`: please read the chan logs and make use of the search, before asking q, http://btcbase.org/log/
swiftgeek: but don't actually treat them like that
swiftgeek: asciilifeform: well if you want to blame google/asus sure
asciilifeform: swiftgeek: as soon as they roll off the conveyor.
asciilifeform: what brings you to #trilema, hl` ?
swiftgeek: asciilifeform: anyway if you can tell i care a lot about e-waste and such chipie is creating serious problems
swiftgeek: and included in commercial device at that
a111: Logged on 2018-06-11 19:57 asciilifeform: swiftgeek: given your introduction ( http://btcbase.org/log/2018-06-11#1822589 ) i assume you may be interested in verifying fact that cr50 is not a subfunctionality of the ordinary (i.e. kept in winbond spi ) bootrom or the EC controller ('nuvoton' arm , visible in right hand of photo ). this is very simple to do:
asciilifeform: at any rate i encourage folx who think that i dreamed it all, to build the snake ( i posted schem ) and do the exact experiment suggested earlier in http://btcbase.org/log/2018-06-11#1822821 . ☝︎
swiftgeek: i didn't know they have actually made it finally
asciilifeform: fella seemed quite surprised that h1 exists at all
asciilifeform: ( their chan's )
swiftgeek: gagarine is the machine
asciilifeform: see the june 9 log.
asciilifeform: seems that we have already spoken
asciilifeform: not to mention that i do not have the 'servo' device, nor see anything to be won from building it ( it gives access to the consoles, which i already have, and spi, which i already have via soldered probes, and that's it. )
swiftgeek: libreboot thinkpad doesn't have it easy, neither BSDLs nor XOR test chains are described for our montevina targets
asciilifeform: a chinese shop could, for instance, mount the http://www.loper-os.org/pub/c101pa_dbg.jpg ( 'google servo' ) connector, on to the vacant pads. BUT this does not give me anything that i do not already have via the 'suzyq'.
swiftgeek: with that amount of tools you could fix those devices during a coffee break xD
swiftgeek: whether they use it or not it's up to them xD
swiftgeek: asciilifeform: anyway authorized repair shop has ridiculous amount of tools to diagnose board
a111: Logged on 2018-06-08 17:15 asciilifeform: i was able to flash in the https://gsdview.appspot.com/chromeos-localmirror/distfiles/cr50.r0.0.10.w0.3.4.tbz2 image ; it supports a few moar commands, including 'rma open' returned-to-factory unlocker thing. but result was , unsurprisingly, 'with notes from hitler only' : http://www.loper-os.org/pub/c101pa/c101pa_unlock_nodice.txt
asciilifeform: so far my only clue that h1 actually runs the given fw , is that i was able to flash in a vendor update : http://btcbase.org/log/2018-06-08#1821699 and ended up with a slightly different, in the ways suggested by the src, console ☝︎☟︎
swiftgeek: either chipie does far less or the thing is secret
swiftgeek: together with your explanation of purpose of the chip
asciilifeform: but i have no way to verify the truth of what he said, aside from noticing that there is 0 discussion anywhere on the net, aside from #trilema and my www, of the h1.
asciilifeform: according to amstan , the fella claiming to be a designer of c101pa , everything connected with cr50 is deeply trade secret, and shared with no one outside of google.
swiftgeek: that m.2 module thing took seriously way too much time for us xD
swiftgeek: otherwise you are literally reversing open source code to figure out something that is presented clearly and for sure in boardview/schematics
swiftgeek: we need it to have something proper
asciilifeform: fwiw the only nonstandard chip is the h1.
asciilifeform: well yes, the schem
asciilifeform: i have already identified all of the major components