--- Log opened Sun Sep 15 00:00:39 2013
20:49 < jgarzik> basic auction server complete.  now rewriting JSON-RPC -> HTTP REST ;p
22:08 < petertodd> nifty
22:09 < petertodd> jgarzik: I'm doing some work on what I'm calling the bitcoin.chain module to handle stuff like blockchain header maintenance and what not for python-bitcoinlib
22:11 < petertodd> jgarzik: Thinking it should look something like a magical box where you can ive it blockchain headers, and it figures out what's the biggest sum-work sub-chain, similar to sipa's work on headers-first.
22:12 < petertodd> jgarzik: (obviously it's ok if the box uses a pile of ram in degenerate cases... so long as the more obvious way to do it works well)
22:17 < BlueMatt> how did I end up leaving here? :(
22:17 < BlueMatt> petertodd: researching attacking tpms in what sense? dma to break txt or so?
22:17 < petertodd> BlueMatt: I guess Hogwarts expelled you.
22:18 < BlueMatt> <petertodd> There's a lot of possible attacks, but yeah, breaking memory is a big one. Of course, the big issue with even Intel's TPM stuff is that AFAIK main memory is unencrypted - rather useless.
22:18 < BlueMatt> petertodd: yea, well if you can rewrite kernel code via dma, tpm data can be read arbitrarily, essentially
22:18 < petertodd> Yup, and people overestimate how hard it is to get data out of main memory: just cool down the RAM sticks, turn off the machine, and transfer them to another machine for a cold-boot attack.
22:19 < BlueMatt> hence why txt exists (run program protected from dma, etc, where you can get new tpm status so that you can protect better)
22:19 < petertodd> IE, any application that needs sensitive data stored in RAM is insecure, making a lot of applications useless.
22:19 < BlueMatt> ofc there are (apparently) attacks against txt where you can break the IOMMU protection and then get access to the "protected" program
22:19 < petertodd> Yes, but TXT execution still leaves the program data in RAM unless you do really clever stuff with L1/L2 cache.
22:20 < BlueMatt> petertodd: see https://github.com/TheBlueMatt/linux for some work Ive been doing (and am now continuing) that builds on the TRESOR store-encryption-keys-in-registers stuff
22:20 < BlueMatt> petertodd: yes, but you can get the tpm to hash the program and only allow private data to be read when you load the right program
22:20 < petertodd> Ah cool, yeah that's a nifty approach, and easier to implement than cache tricks from what I hear.
22:21 < BlueMatt> well, except for dma tricks where you just rewrite the kernel code.....
22:21 < petertodd> (note that my main TPM interest is remote attestation, for wallet stuff your type of security is probably fine)
22:22 < BlueMatt> ahh, well yea I mean you essentially need secure IOMMU limits st no hardware can write arbitrary crap to kernel memory
22:23 < BlueMatt> which is being worked on...but there are still drivers that dont do it right (hence my desire to find programmable pcie chips...)
22:23 < petertodd> I also have a project I want to do that'll just be a uC with a cheap FTDI USB<->serial chip and some very simple anti-tamper stuff to store full-disk-encryption keys, as well as provide a way to detect tamper events - the latter could be used to wipe system memory in conjunction with a in-case UPS.
22:24 < petertodd> You basically want to be sure the attacker can't plug in some hardware to a running machine right?
22:24 < gmaxwell> BlueMatt: so there are things like fpga devkits with pcie, but the pcie bus connection is some fixed logic, and may not be able to make do what you want.
22:24 < BlueMatt> petertodd: well, my threat model is how to protect against an attacker who can
22:24 < petertodd> Er, right, make sure an attacker who can can't do anyting interesting. :)
22:25 < BlueMatt> petertodd: see https://forums.hak5.org/index.php?/topic/28816-howto-anti-forensics-mass-storage-device-as-a-key-device-for-fde/ where I build a flash drive that is smart and tries to figure out when someone is trying to read it
22:25 < BlueMatt> petertodd: yea
22:25 < petertodd> BlueMatt: Lol, yeah I saw that earlier, very nifty.
22:26 < petertodd> See, my thinking is that there's probably so much backdoor crap and exploits in standard hardware, that it'd be more productive to add more hardware to the problem, but simple hardware that we can trust.
22:26 < BlueMatt> gmaxwell: fixed bus logic there should be fine, you just have to be able to change how it reports itself to the host
22:27 < BlueMatt> petertodd: yes, a smaller trust base would be nice, but its theoretically possible to do it all properly without any custom hardware so thats what Im looking at
22:28 < BlueMatt> also: doing a wallet in tpm should be done...
22:28 < BlueMatt> wallet in intel txt would be the ultimate in security for private key storage and signing
22:28 < BlueMatt> ofc you should probably just do a hardware thinggy instead, but....
22:29 < petertodd> BlueMatt: Well, they're both ideas with advantages and disadvantages so... if I build my little USB thing, think it'd be easy to write some kernel drivers/dmcrypt startup scripts to use it? I suspect it won't be a very hard project, much less than the other stuff you're working on.
22:31 < petertodd> BlueMatt: Reminds me: apparently the newer intel TXT stuff can even display things on screen securely, and take in user input from the keyboard and mouse securely, at the hardware level!
22:31 < BlueMatt> ooooooooooo
22:32 < BlueMatt> petertodd: in my case its incredibly easy because I just treat it like a flash drive and read in a sector
22:32 < BlueMatt> petertodd: thats probably one of the easiest ways (its already implemented...) and you can still do that in trusted hardware
22:32 < BlueMatt> but reading over serial shouldn't really be any harder
22:33 < petertodd> Well, remember the key idea I have is to make my USB thing actually connect to anti-tamper sensors, so when the thieves steal your server at the colo center the moment they open the case/move it the keys get wiped, yet you can still reboot it/handle power failures.
22:34 < petertodd> (or for that matter, ship it in the mail)
22:34 < BlueMatt> petertodd: you can do that in usb too...
22:34 < BlueMatt> usb with the same chip on the backend
22:34 < BlueMatt> (internal-case usb headers instead of standard A plug, probably)
22:35 < petertodd> BlueMatt: Yeah, interal-case header was exactly what I was thinking of.
22:35 < petertodd> BlueMatt: Easy to keep the whole dongle short enough to still fit in a 1U case.
22:35 < BlueMatt> hell, you could do that with my setup in pure-software, if you get a case_open message, read from a known-killing sector
22:36 < petertodd> BlueMatt: Nope, you won't get the case_open message if the power is off.
22:36 < BlueMatt> oh, well ok true
22:37 < BlueMatt> anyway, aside from dma attacks, the next biggest issue is just in-memory disk caches, db caches, etc
22:38 < petertodd> Yeah, which is why I'd much rather just put it all in a tamper-resistant box. :) Getting custom-made 1U cases made where the motherboard ports aren't exposed is surprisingly cheap.
22:39 < petertodd> And both approaches can be combined too: protect aganinst thieves and hackers.
22:39  * jgarzik reads scrollback, as this could apply to my security robot project
22:42 < BlueMatt> petertodd: yea, need to protect against coldboot too, which is the hard one assuming io caches...
22:44 < petertodd> BlueMatt: Yup. Integrated power-supplies + UPSs are available these days, so you can count on the kernel being alive to start wiping memory at least, but that does add cost.
22:45 < BlueMatt> well, you should be able to force-disable some of the kernel-level io caches of unencrypted data
22:45 < petertodd> that too
22:45 < BlueMatt> its the application-level ones that are hard (and, being not in low memory, would get cleared later in the process) :(
22:45 < BlueMatt> depending on what you're protecting, ofc
22:46 < petertodd> Oh, I was just figuring you'd halt execution and wipe all of system memory the moment the anti-tamper switch is triggered.
22:46 < BlueMatt> yea, but wiping all system memory isnt that quick a process, given a motivated and fast-working attacker
22:46 < BlueMatt> depending on memory size/speed
22:46 < petertodd> UPS is just there to keep things running long enough for the kernel to do that.
22:47 < BlueMatt> if a person can get in the case and rip out memory before then, though...
22:47 < petertodd> Right, but SDRAM speeds are on the order of gigabytes/second, so they've only got at most a second or two to do that.
22:47 < petertodd> Not ideal, but that sure makes life difficult.
22:48 < BlueMatt> yep, except that three seconds is plenty if you just shove a knife in the case in the right spot....
22:48 < BlueMatt> 1) xray 2) freeze whole server 3) knife at base of dram chip 4) coldboot
22:48 < petertodd> Sure, but don't forget that vibration sensors are an option, as an example. Once we assume that level of attacker we can't assume things like light sensors or switch sensors are good enough.
22:48 < BlueMatt> or on processor or wherever
22:49 < BlueMatt> that isnt an incredibly high bar, really
22:49 < BlueMatt> xray is probably overkill, I mean you can probably look up server model
22:49 < BlueMatt> depending on level of custom-ness
22:50 < petertodd> The big advantage to all this stuff is actually more that if the thieves don't know you're using it, it's very likely they'll trip it accidentally, and if they do know you're using it, their job to steal a few dozen/hundred servers now sucks.
22:50 < petertodd> And... it's extremely cheap protection.
22:50 < BlueMatt> true
22:51 < BlueMatt> still, I like the idea of very basic commodity hardware which is properly protected against most attacks even without physical protection
22:51 < BlueMatt> because physical protection is usually trick-able
22:51 < petertodd> Sure, and as I said before you can combine this type of really cheap protection with your TPM-based stuff for a solution that combined is actually pretty damn good.
22:52 < BlueMatt> yep
22:52 < BlueMatt> but if the software stuff is good enough, you dont need the hardware stuff in theory
22:52 < BlueMatt> it just provides protection for bugs, essentially
22:52 < BlueMatt> (which is hugely valuable considering the number of subtle security flaws that are in any one of a million kernel modules)
22:53 < petertodd> The hardware for the software stuff isn't good enough yet: your stuff doesn't work well in a colo situation for instance, other than some limited examples. IE full-disk-encryption isn't helped.
22:54 < petertodd> (specifically, isn't helped due to cold boot attacks)
22:54 < BlueMatt> well, you can use my stuff in combination with tpm-backed key storage eg bitlocker
22:54 < BlueMatt> which would provide similar levels of protection
22:54 < BlueMatt> yea, it doesnt exist, but its entirely possible
22:55 < jgarzik> https://github.com/jgarzik/auctionpunk   "auctiond" is the JSON-RPC server, communicates with bitcoind.  "auctionuser" creates auctions and places bids.
22:55 < petertodd> Thieves still just stole all your transaction data for instance.
22:55 < phantomcircuit> depending on how much your trust the tpm manufacturer
22:55 < phantomcircuit> iirc there's only 3 that are widely used
22:55 < BlueMatt> phantomcircuit: well, ok, trust is always an issue
22:55 < jgarzik> Each bid MUST include the same TX input, guaranteeing only one winner out of all bidders.  The unique auction ID is hash(outpoint), making this publicly auditable.
22:55 < jgarzik> The auctioneer is guaranteed everyone puts up money during bidding.
22:56 < BlueMatt> jgarzik: ooo, that looks useful when implementing TD's automated-self-owned-self-replicating-quadcopter-delivery-service stuff
22:56 < BlueMatt> petertodd: yes, hence the need to limit in-memory unencrypted storage
22:56 < jgarzik> Protocol spec: https://gist.github.com/jgarzik/6546194
22:57 < jgarzik> handles first-price-sealed-bid auctions for now.  soon will add Dutch, hopefully others.
22:58 < petertodd> BlueMatt: Anyway, point is, I wanna know what you know about USB on Linux; what's the easiest way to implement this so writing the kernel bits is easy?
22:59 < jgarzik> petertodd, with USB, you can just use a userland lib and avoid writing a kernel driver altogether, unless you're doing something like high speed, high throughput DMA'ing
22:59 < BlueMatt> petertodd: absolutely nothing, my suggestion: use my existing code and just make the device report as a usb mass storage device
23:00 < jgarzik> petertodd, bfgminer and cgminer are example code
23:00 < BlueMatt> (+ I want an audit of my code...)
23:00 < petertodd> jgarzik: Right, through the USB lib bit-banging stuff.
23:00 < jgarzik> petertodd, but it largely depends on the major USB device class type (storage, printer, audio, serial, ...)
23:01 < petertodd> BlueMatt: USB mass storage is a complex protocol - I want this to be able to run on a cheap *low-power* 8-bit PIC chip easily.
23:01 < BlueMatt> petertodd: msc isnt that complicated....
23:01 < BlueMatt> petertodd: if you want keys that arent in-registers then just make it a mass storage controller and just give dm-crypt a keyfile
23:01 < BlueMatt> then no user-space code need be written
23:01 < jgarzik> bah, mass storage is not complex
23:02 < jgarzik> it's dumb scsi over dumb usb
23:02 < jgarzik> if you can do usb, you can do mass storage
23:02 < petertodd> I think we're all having different viewpoints on what we define as complex. :) When I say simple, I'm thinking of using one of FTDI's converter chips that do it all for you and present a really dumb big-bang interface.
23:03 < petertodd> I'm also thinking uC's with just a few hundred bytes of ram, because those are the ones with really low-power sleep modes.
23:03 < petertodd> I also like that route because then the sourcecode, all of it, is dead simple and can actually be audited easily, and for that matter, the resulting assembler output.
23:08 < jgarzik> yeah, just a simple serial interface then
23:08 < jgarzik> bfgminer and cgminer have examples of the userland side of such things...
23:09 < petertodd> That should cover it mostly then, only remaining thing will be if the drivers + libraries can be made available easily enough in the boot image or whatever it's called that dmcrypt uses to ask for the disk passwords.
23:19 < BlueMatt> petertodd: best lazy-man's bet: put a script in initrd that reads from the serial device and writes it to a keyfile which is fed into dm-crypt
23:19 < BlueMatt> or maybe dm-crypt can be made to read the serial dev which responds with key"EOF"
23:20 < petertodd> Yeah, lookins like that's enough, as the initrd image these days has all the bits to load USB devices - key storage on USB keys is common.
23:20 < petertodd> s/lookins/looking/
23:21 < petertodd> FTDI's chips can do both serial and USB HID, so changing it to a HID device if needed - like for kernel-level memory wiping - is just a firmware change.
23:25 < BlueMatt> surprised it cant do usb msc too then
23:27 < petertodd> oh, I misspoke, HID isn't supported, something called "FTDI direct" is
23:29 < jgarzik> petertodd, that's what bfgminer/cgminer talk to, with most USB ASIC miners
23:29 < jgarzik> it's common
23:29 < petertodd> ah good, I can just copy that then
23:49 < Luke-Jr> jgarzik: cgminer stopped using kernel drivers entirely actually
23:49 < Luke-Jr> opting to just reinvent them in userspace for no reason
23:49 < jgarzik> nod
--- Log closed Mon Sep 16 00:00:43 2013