12 ms·

State Considered Harmful – A Proposal for a Stateless Laptop

226 points by kushti 11y ago

joveian 11y ago
One random detail that came to mind: I guess the clock would now need to live on the trusted stick?
Shank 11y ago
This is interesting to me, because this is the same sort of thinking that led to the current iteration of Chrome OS devices. While not stateless entirely as the paper suggests, they clearly have the same train of thought. Without the developer switch flipped, verified boot should entrust that Google (and anyone with its private key) is the sole originator of the code on the device. I wouldn't suggest using a Chrome OS device for anything where opsec matters, but I find the similarities, at least in thought, striking. Chrome OS's early security benefits were that the device could be trusted if the dev switch wasn't flipped -- and it could be fully wiped and restored on demand if need be. The trusted stick described in the PDF would likely share similar characteristics as far as disposability goes.
- kuschku 11y ago
  The issue with ChromeOS is that you know that Google controls everything that’s on it – which is not very useful for someone who wants actual security. A state actor could still force Google to install spyware on the devices. In fact, for chromebooks for education, Google even allows the schools to MitM the traffic of the pupils with no way for the pupil to know it. Which gets risky when the pupils take the device home, and the school still controls it.
  - emidln 11y ago
    How is that any different than an employer forcing their laptops provided to employees through a VPN (where the user is subject to inspection/blacklist/whitelist/etc) all the time? In both situations you have a machine provided to someone for a specific purpose (business/education) that likely describes extremely particular acceptable use cases. MITM traffic on whatever network seems like a valid way to enforce that. Doing your banking on your own machine.
    - kuschku 11y ago
      Because in many cases these pupils take it home, and use it for private usage?
    - pierrec 11y ago
      These forced MitMs are all very similar, though I don't see how that gets us anywhere. It's not a valid way of enforcing any policy no matter how twisted, because people will root their devices and circumvent the lock-down. The reason I call it twisted is because I'm wondering why that lock-down is necessary in the first place: you don't want them to "abuse" the device, causing potential damage? This might be a valid concern with company cars due to the life-threatening aspect of driving, but extending this concept to laptops seems abusive. Either way, the risk posed to the school or company's assets can be effectively taken into account by some kind of insurance policy, not by attempting to lock down the device.
      - jackgavigan 11y ago
        "So how did the hackers get into the corporate network?" "One of our execs downloaded a game from the Internet that contained malware and then he connected his laptop to the corporate network..."
        kuschku 11y ago
        If a single person with a laptop can damage your whole network, you have completely different issues.
  - anonbanker 11y ago
    Then install ChromiumOS, which doesn't include the botnet. Or GalliumOS, which is even better. Then replace/restore the write-protection.
    - kuschku 11y ago
      Yes, that is one solution. I’m just arguing that Secure Boot or similar solutions don’t mean that you can make sure to always know what’s on the system, but that the person with the keys can. In this case, that’s an employee at Google.
ddalex 11y ago
Considered harmful essays considered harmful.
- detaro 11y ago
  I guess it is time for "'Considered harmful essays considered harmful' comments considered harmful" Especially since this isn't really a typical one, apart from the title, but includes quite a bit of analysis and proposals.
- officialchicken 11y ago
  click-bait corollary: considered beneficial essays considered beneficial
devit 11y ago
As far as I can tell this proposal allows to ensure that it is possible to "factory reset" a system in a way that removes all malware, and also allows to "dual boot" OSes without any of the OSes being able to compromise the other (by flashing malicious firmware which then exploits the other OS on a subsequent boot). It also prevents some more exotic attacks like replacing the BIOS (but not any hardware) with a malicious one as the laptop is delivered, used without network access (but not with network access) and then stealing the laptop and trying to read unencrypted user data leaked by the malicious BIOS. It is not effective against undetected arbitrary physical attacks (insert a keylogger between keyboard and motherboard) or against persistent software attacks against a single vulnerable OS (persist via the OS autostart mechanism and exploit the OS on each boot). Having an external stick also mitigates detectable physical attacks (e.g. theft of laptop, or manipulation detected by a broken tamper-proof seal) where the attacker has already stolen the encryption password, since they still won't get the stick and thus won't be able to get the data anyway. The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well.
- loudmax 11y ago
  > The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well. You can take out the external USB and keep it in your pocket when you go someplace you wouldn't want to carry a laptop (eg. public bathroom). Whether this is necessary depends on how paranoid you want to be.
- rolandr 11y ago
  I think your observations are pretty much spot-on, except for your last point: > The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well. I think it provides a security-conscious user an added level of comfort/faith over a built-in solution. If you move the flash memory out to this external unit, and there is simply a three wire type of interface that pretty much only gives the system no permanent writability to the flash contents, that is a fairly solid and tangible promise. To some degree, you get to assert a new level of control over the "root of trust," at least the poinbt at which it begins in firmware. That doesn't mean that there is not room for motherboard vendors to improve things, but we will have to have faith in them having done things correctly. I am not even talking about a hostile motherboard vendor - there are plenty of good faith or half baked efforts that end up being circumventable.
hendry 11y ago
My OS https://webconverger.com/ https://webconverger.com/ gets you mostly there. The slate is wiped clean between sessions like https://en.wikipedia.org/wiki/Privacy_mode https://en.wikipedia.org/wiki/Privacy_mode of course.
- schoen 11y ago
  While an OS that doesn't preserve state is an important component of Rutkowska's proposal, and your OS might be one basis for that component, I don't think this is "mostly there" in terms of everything that the paper discusses. Much of what's new in the paper is about hardware issues, especially because it's concerned with firmware attacks that are already being used by attackers like NSA, and that other people clearly understand how to develop in principle. With these firmware attacks, compromising a device at one point in time may allow the compromise to persist even if the user reinstalls the OS or replaces it with a different one. One way to see this paper is as a response to http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-he-is-compromised http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-h... proposing more details of a safer future platform. Right now, someone who can briefly get kernel-level control on a machine intended to run your OS might be able to reprogram the hard drive firmware. At that point you have a serious authenticity challenge when booting your OS, because the hard drive can alter the contents of particular binaries at the moment they're read from disk. There are some powerful software-only defenses against this, but if an attacker knows which ones you use, they can probably design an attack that evades those.
SagelyGuru 11y ago
"State Considered Harmful" - this incisive observation applies equally to the state as an organisational structure of human society. Discuss ;)
- KhalilK 11y ago
  [Insert Security vs Freedom debate here]
  - DonHopkins 11y ago
    [Express feeling of verklempt here]
- jMyles 11y ago
  I thought the same thing - "why stop at a laptop? There are mannny aspects of information age society that will benefit from statelessness." :-)
- js8 11y ago
  I am not sure how would you protect and distribute resources without (democratic) state. I am big fan of democracy, and no state (or similar structure) seems like an idea that goes against democracy. And without democracy, I don't see how society can be considered fair, and protect its weaker members from harm.
  - chopin 11y ago
    I am not convinced that democracy protects weaker members of society (let two wolves and one sheep elect what the dinner will be...). Rule of Law does. Democracy gives you a say in politics. Rule of Law gives you a safe life (at least from governmental actions). I concede that both may be not unrelated. But this is not necessarily the case.
    - deleted 11y ago
      [deleted]
    - 11y ago
ge0rg 11y ago
Non PDF version rendered by github: https://github.com/rootkovska/state_harmful/blob/master/state_harmful.md https://github.com/rootkovska/state_harmful/blob/master/stat...
cbd1984 11y ago
Can this be marked as a PDF?
DonHopkins 11y ago
A laptop without any state sponsored back doors sounds like a good idea. I'm also for separation of church and state.
vrtx0 11y ago
I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either create a 'trustworthy' distribution channel for all supported firmware (including all system components and peripheral devices), or support only a select few devices and forbid adding any new peripherals. It also means peripheral devices must either be capable of bootstrapping themselves from this chip, or the system must provide a mechanism that 'sends' this firmware to all peripherals before booting the system. I'm inclined to think that the complex interdependency of this boot process seems impractical. Also, I have to disagree that FPGAs are ideal for the architecture proposed by this paper. Performance and state issues of an FPGA aside, they're field programmable, which seems more vulnerable than 'microcode updates'. Of course, you could just disable field programming, but why even use an FPGA in the first place? Disclaimer: I believe Joanna is much smarter than I am, so I wouldn't be surprised if my comments are based on a fundamental misunderstanding.
- viraptor 11y ago
  > or the system must provide a mechanism that 'sends' this firmware to all peripherals before booting the system. That's pretty much what they note in "The SPI flash chip" section and what's replaced / muxed from the trusted stick in "Putting it all together" (page 15). SPI is that firmware provisioning component here.
- detaro 11y ago
  FPGA: You would reprogram the FPGA on each boot from the trusted source. The performance/energy issues remain of course.
- rolandr 11y ago
  > vrtx0 1 hour ago | parent I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either create a 'trustworthy' distribution channel for all supported firmware (including all system components and peripheral devices), or support only a select few devices and forbid adding any new peripherals. In general, most of the firmware needed for system components is streamed from the main SPI chip to the various components as they are configured by the main system BIOS. Thus, there mainly is a single chip we are concerned about. However, the author identified a second embedded controller )EC_ flash that is also usually present, so we end up being concerned about 2 flash modules. The author addresses other firmwares - the main one being discrete GPUs - and suggests having a system that does not include them. > Also, I have to disagree that FPGAs are ideal for the architecture proposed by this paper. Performance and state issues of an FPGA aside, they're field programmable, which seems more vulnerable than 'microcode updates'. Of course, you could just disable field programming, but why even use an FPGA in the first place? If your only interface between the computer and the FPGA is a three wire interface that emulates an SPI chip, that does not provide any vector for reconfiguring the FPGA. The bitstream for configuring the FPGA is provided via a completely separate set of hardware pins.
asuffield 11y ago
It's an interesting idea, but probably hopeless: all this does is move the goalposts. You're still fundamentally trusting the hardware to read and obey the instructions on your weird "external SPI" device, and if you're willing to trust the hardware then you might as well just put it on the motherboard like today's devices do. If you don't trust your hardware (and I challenge anybody to prove that a motherboard full of chips hasn't had a chunk of flash memory added to it without your knowledge) then you have no reason to think that the code it loaded was the code stored on your "trusted stick". I don't believe that it is possible to build a secure system which isn't based on trusting the device that you hold in your hands. At some level, you need to have a device which is capable of both UI and computation functions to a sufficient extent to validate whatever transaction you are attempting to sign. You could push that onto a smaller device than your laptop (we already know that phone-sized devices are viable), but you still have to end up at the thing you interact with for signing purposes being a device that you trust.
- detaro 11y ago
  I think the main point is that if you trust the main board once, you can trust it (more) in the future. If it doesn't have any changeable memory, modifying it to become hostile is harder and requires physical tampering.
  - nickpsecurity 11y ago
    As Animats said, solving that problem just requires making the firmware read-only at the chip level. Which is cheap. The current problem exists so devices can be easily updated and contain more features. Users demand both with both benefiting hardware market. A a ROM + Flash setup solves the problem but adds a little to cost. Most companies won't do it but it's another viable solution.
- candeira 11y ago
  This circumvention of surveillance could work for current processors that assume they can trust the SPI chip. But it would be easy for Intel to package the SPI chip together with the CPU in future offerings, circumventing the circumvention. I don't see any assurance for anyone that doesn't control the foundry itself.
Animats 11y ago
A read-only memory device for firmware would be helpful. Not flash, not something erasable, but hard ROM, in a socketed device. All the firmware would go in that ROM, and you could take it out if necessary and compare it with other ROMs. There are simple hard-wired ROM comparison devices. This is the approach mandated by Nevada Gaming Commission slot machine regulations.[1] [1] http://gaming.nv.gov/modules/showdocument.aspx?documentid=3309 http://gaming.nv.gov/modules/showdocument.aspx?documentid=33...
- loudmax 11y ago
  I can see that for a slot machine, but a laptop probably needs to do something more than that. Don't you want to run a browser? In this case you're locked into a specific browser version, and if someone figures out an exploit that allows an attacker to hijack your browser you have to replace the ROM. Or do you only run SSH/VNC/RDP and connect to a desktop someplace else?
  - brohee 11y ago
    That's not what he is suggesting, at all. He's suggesting locking up the boot stages, but your can still load any OS you trust.
    - loudmax 11y ago
      You're right. In the blog post, the author refers to problems on the x86 platform and I didn't realize she was talking about firmware. It's clear in the paper.
- rolandr 11y ago
  Once upon a time, most/many PCs had physical BIOS protection in the form of a jumper on the motherboard that would allow you to put the BIOS into a read-only state. However, we have now had many years where such control cannot be manually asserted by the end user, and the flash just sits there writable (although there are chipset-level firmware write protections, various hacks, like Dark Jedi, have found ways around them). Plus, apparently even when you pull down the WO pin on some flash chips, the hardware setting can still be overridden by software commands. The paper suggests, particularly with the more recent versions of Intel ME, that the PC architecture has now evolved to expect, and perhaps require, access to a writable BIOS (in part, because the ROM stores not only firmware, but also things like configuration settings and data for the new ME-implemented TPM). Thus, we may not be able to simply go back to a ROM with today's architectures. However, we can give today's systems something that behaves like a writeable flash chip, but is readily (and automatically) reset to a clean/factory state.
loudmax 11y ago
I had a system nearly like what the author describes after the internal SSD drive on my first generation Acer Aspire One died. There didn't seem to be an easy way to replace the drive with a generic SATA SSD (at least none that I was aware of), and a replacement drive was like $80. This is for a $200 netbook, and it wasn't a very good SSD to begin with. So I put Knoppix on a USB stick and basically used that. Since all my stuff is either on my personal server or in the cloud anyway, it was a workable solution. In my case it worked reasonably well, and if I went though the trouble of identifying or putting together a bootable Linux distro with a desktop I really liked I could probably live with something like that as a permanent solution. I'm not nearly as privacy conscious or paranoid as the author, so I'm satisfied with the convenience of a stateful laptop. I don't even have a screen lock when it wakes from sleep. If you want to use a stateless machine like the author describes, you're going to need a personal server or a cloud provider you really trust to keep your stuff. Edit: ge0rg had already posted link to non-PDF version.
- spydum 11y ago
  I'm not sure you read the paper? The concern centered on all the flash/firmware compnents such as SPI flash and wifi/BT firmware, not just the OS or hard drive. The idea proposed was to have SPI and all device firmware on a secure USB stick that you always keep with you..
  - loudmax 11y ago
    You're right. I read the blog post, then skimmed the actual paper. You can already do what she proposes at the OS level, but her concerns go much deeper.
    - rolandr 11y ago
      It seems like a pretty valid concern. Part of the next generation of rootkits seems to be targeted at SMM-level rootkits (termed "ring -1" by some) that are installed in the BIOS. They are practically undetectable once installed, and can punch through hypervisor protections too. I think that is also part of the author's concern with Intel ME being present on all systems. It is a separate microcontroller in the chipset that has power on the level of "ring -3" (I believe it is used to implement much of the new SGE instruction set, for example).
kriro 11y ago
I really wish there was a good laptop that runs Qubes OS and has no BLOBS/closed code/firmware at all. I do some research on this every now and then and always come up short. The Librem 15 was the last one I looked into but it had closed components. Something like the Novena can't run Qubes but would otherwise be ideal (I'd gladly give up some battery life, looks and whatnot for pure freedom) If anyone happens to know a suitable candidate let me know. Wouldn't mind a bit of hardware replacing etc. if the lone closed component could be swapped out etc.
- rolandr 11y ago
  I do not believe there is are any Intel chips that give you VT-d (IOMMU) and do not require a firmware blob. Blame Intel for that situation. I think AMD has open sourced most of their BIOS, and a lot more of their hardware supports IOMMU anyway. Maybe that is a more fruitful direction to consider.
  - kriro 11y ago
    You are absolutely right. In fact I didn't know that Intel ME is that evil. Interesting (a bit hard to follow imo) talk from the recent CCC: https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops#video https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...
transfire 11y ago
http://tinycorelinux.net http://tinycorelinux.net
deleted 11y ago
[deleted]
- sp332 11y ago
  Could be either. The archetypal paper "Go To Considered Harmful" wasn't satirical, but it was satirizable. https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
tokenizerrr 11y ago
I will never be able to take any article telling me what to consider harmful serious. A shame, really. Considered harmful articles considered harmful?
- mattkrea 11y ago
  Some have been good but it is just being taken too far.
- nabla9 11y ago
  Considered harmful is one type of essay. Considered harmful is great format because the title makes it clear that the author is intentionally taking one side and he is then free to concentrate into one side of the story.
w8rbt 11y ago
I've been saying this about password managers for years: https://news.ycombinator.com/item?id=9731361 https://news.ycombinator.com/item?id=9731361 "The fundamental design flaw of all of these compromised password managers, keychains, etc. is that they keep state in a file. That causes all sorts of problems (syncing among devices, file corruption, unauthorized access, tampering, backups, etc.)."
- curryhoward 11y ago
  There are a few "stateless" password managers worth considering: 1) http://www.supergenpass.com/ http://www.supergenpass.com/ 2) https://www.stephanboyer.com/post/101/hashpass-a-simple-stateless-password-manager-for-chrome https://www.stephanboyer.com/post/101/hashpass-a-simple-stat... (disclaimer: I wrote #2)
purpled_haze 11y ago
Done: http://cdn.rsvlts.com/wp-content/uploads/2013/02/1671718-slide-p139-4jpg1.jpeg http://cdn.rsvlts.com/wp-content/uploads/2013/02/1671718-sli... + https://www.youtube.com/watch?v=m98agJUoCck https://www.youtube.com/watch?v=m98agJUoCck
joveian 11y ago
One thing I would love to have that could be a solution to the worst case early boot encryption issues is an external crypto processor that generates and stores long term keys, implements authentication, and only releases temporary keys to the main system (to which it only connects via a simple serial connection). It has enough of a screen and input to receive a password and query the user before performing various actions. That is, something like Bitcoin Trezor but maybe a little more complex input and for more general crypto use. Ideally, such a device could even physically store the trusted stick (or several), although that trusted stick shouldn't interact with the rest of the system differently than any other device for maximum reliability. This way the most sensitive crypto is not performed on a general purpose system and the user could authenticate to the device once and then the device can authenticate the user and provide keys to multiple independent systems without hastle. It is an additional expense so hopefully wouldn't be necessary, but would be one way to solve the early boot encryption problem (if needed and less expensive solutions do not work) in a not completely special purpose way.
nickpsecurity 11y ago
Short on time, but I'll say she's looking in the right idea in general. This idea has actually been done before. Removable firmware part used to happen in older machines, too. Far as I know, I came up with it first with a proposal on Schneier's blog, etc to put both the CPU and trusted state on a stick or card you inserted into a machine containing only peripherals maybe with RAM. Research CPU's at the time had RAM encryption/integrity to make it untrusted. I was thinking PC Card rather than stick due to EMSEC, storage, and cost issues. I'll try to find the link later today. It was actually inspired by foreign, airport security compromising stuff. People asked me to develop a convenient solution. So, real problem was physical access to the trusted components. That access couldn't happen but can't keep all our gear with us or away from inspection. A simple chip or PC Card they carried on would be better. The chassis, from laptop to whatever, they could acquire in country or ship separately with inspection. I further imagined a whole market popping up supplying both secure sticks/cards and the stuff you plug them into. Inspiration for that was iPod & its accessories like docks. One more part was that each user could determine how much protection, from tamper-evidence to EMSEC, to apply to their trusted device. As it sometimes happens, another company showed up with government backing IIRC and R&D on security devices. Their proposed portfolio was very similar. They undoubtedly started patenting all of it. This created a second risk for anyone attempting what I or now Joanna is attempting: a greedy, defence-connected, third party legally controlling pieces of your core business. They usually just rob people but I predicted on Schneier's blog & later here in a heated debate that they could attempt to change or get rid of the product using their patents. Especially true if a proxy for an intelligence agency. We might have just seen that happen with Apple over iMessage but I can't be sure. Anyway, do know there's both prior art and probably patents on these concepts in defense industry. So, it was a cool concept. It was one of those I was proudest of given it collapsed problems with all kinds of devices to design and protection of one component. That's basic Orange Book-era thinking I try to remember. Unfortunately, after much debate with marketing types, we determined there was a chicken and the egg problem with these [at the time]. The NRE cost would be high to the point you'd want to be sure there was a demand for thousands of them plus people willing to pay high unit prices. Custom laptops were often closer to $10,000 than $3,000 if low volume. My greater market idea was chicken-and-the-egg times a million. That plus risk of 3rd party patents made me back off the idea as nice but not practical. Since then, what's changed is dramatically lower cost for homebrew hardware or industrial prototyping. Projects like Novena show it can probably be done for lower NRE than before. However, this is security-critical design that needs strong expertise in both hardware (esp analog/RF) and Intel x86. That will up the NRE and odds of them screwing up. ARM or MIPS ("cheaper ARM") might be easier to do but still need HW expert and significant NRE. So, there's my take. It's a good idea that two of us in security industry already fleshed-out with removable firmware being proven in ancient mainframes. Serious marketing obstacles to getting this done and done securely. A high-level design for the technology, as I did, is pretty straight-forward and will teach one many lessons. It was a good learning experience if nothing else.
OJFord 11y ago
Interesting (and surprising to me) that the word 'laptop' is used instead of 'computer'.
- gbtw 11y ago
  It is the formfactor of a portable computer that you could own completely, unlike anything more mobile where at least some of the chips are configured and run by someone else. Also you would take your I/O with you because it makes no sense if you hardly trust a device you don't let leave your side to interface with some static hardware that any third party could have modified. Current monitors have more processing power than early mainframe computers and more than enough room to hide rf equipment for remote snooping.
deleted 11y ago
[deleted]
peterburkimsher 11y ago
SD cards have SPI pins, so I recommend SD for Trusted Stick rather than repurposed USB. I've bought a 512GB SDXC card for the purpose of backing up my laptop, and often wonder whether to use it as a boot device. It's much less vulnerable to theft when it's safe in my pockets, compared to in a bag. I'd make one small change. Rather than aim for a laptop first, mod a WiFi SD card or other pocket-sized device. The KeyAsic platform (PQI Air Card/Transcend) has been extensively hacked, and Ubuntu can run on it. Client devices (laptop, phone, etc) could connect over WiFi and run VNC through a web browser. It's still vulnerable to keystroke logging on the client, but it would be possible to switch clients halfway through typing important messages. In my opinion the most secure client device would be an iPod running Rockbox, and connecting to the PQI Air Card over serial. My "WiPod" seems like the closest thing we have to a practical pocket-sized open source device, and it lets me share photos from an SD card to my phone :).
jakeogh 11y ago
C3TV – Towards (reasonably) trustworthy x86 laptops: https://news.ycombinator.com/item?id=10833637 https://news.ycombinator.com/item?id=10833637

226 points by kushti 11y ago

One random detail that came to mind: I guess the clock would now need to live on the trusted stick?

Shank 11y ago

This is interesting to me, because this is the same sort of thinking that led to the current iteration of Chrome OS devices. While not stateless entirely as the paper suggests, they clearly have the same train of thought. Without the developer switch flipped, verified boot should entrust that Google (and anyone with its private key) is the sole originator of the code on the device. I wouldn't suggest using a Chrome OS device for anything where opsec matters, but I find the similarities, at least in thought, striking. Chrome OS's early security benefits were that the device could be trusted if the dev switch wasn't flipped -- and it could be fully wiped and restored on demand if need be. The trusted stick described in the PDF would likely share similar characteristics as far as disposability goes.

kuschku 11y ago
The issue with ChromeOS is that you know that Google controls everything that’s on it – which is not very useful for someone who wants actual security. A state actor could still force Google to install spyware on the devices. In fact, for chromebooks for education, Google even allows the schools to MitM the traffic of the pupils with no way for the pupil to know it. Which gets risky when the pupils take the device home, and the school still controls it.
- emidln 11y ago
  How is that any different than an employer forcing their laptops provided to employees through a VPN (where the user is subject to inspection/blacklist/whitelist/etc) all the time? In both situations you have a machine provided to someone for a specific purpose (business/education) that likely describes extremely particular acceptable use cases. MITM traffic on whatever network seems like a valid way to enforce that. Doing your banking on your own machine.
  - kuschku 11y ago
    Because in many cases these pupils take it home, and use it for private usage?
  - pierrec 11y ago
    These forced MitMs are all very similar, though I don't see how that gets us anywhere. It's not a valid way of enforcing any policy no matter how twisted, because people will root their devices and circumvent the lock-down. The reason I call it twisted is because I'm wondering why that lock-down is necessary in the first place: you don't want them to "abuse" the device, causing potential damage? This might be a valid concern with company cars due to the life-threatening aspect of driving, but extending this concept to laptops seems abusive. Either way, the risk posed to the school or company's assets can be effectively taken into account by some kind of insurance policy, not by attempting to lock down the device.
    - jackgavigan 11y ago
      "So how did the hackers get into the corporate network?" "One of our execs downloaded a game from the Internet that contained malware and then he connected his laptop to the corporate network..."
      - kuschku 11y ago
        If a single person with a laptop can damage your whole network, you have completely different issues.
- anonbanker 11y ago
  Then install ChromiumOS, which doesn't include the botnet. Or GalliumOS, which is even better. Then replace/restore the write-protection.
  - kuschku 11y ago
    Yes, that is one solution. I’m just arguing that Secure Boot or similar solutions don’t mean that you can make sure to always know what’s on the system, but that the person with the keys can. In this case, that’s an employee at Google.

ddalex 11y ago

Considered harmful essays considered harmful.

detaro 11y ago
I guess it is time for "'Considered harmful essays considered harmful' comments considered harmful" Especially since this isn't really a typical one, apart from the title, but includes quite a bit of analysis and proposals.
officialchicken 11y ago
click-bait corollary: considered beneficial essays considered beneficial

devit 11y ago

As far as I can tell this proposal allows to ensure that it is possible to "factory reset" a system in a way that removes all malware, and also allows to "dual boot" OSes without any of the OSes being able to compromise the other (by flashing malicious firmware which then exploits the other OS on a subsequent boot). It also prevents some more exotic attacks like replacing the BIOS (but not any hardware) with a malicious one as the laptop is delivered, used without network access (but not with network access) and then stealing the laptop and trying to read unencrypted user data leaked by the malicious BIOS. It is not effective against undetected arbitrary physical attacks (insert a keylogger between keyboard and motherboard) or against persistent software attacks against a single vulnerable OS (persist via the OS autostart mechanism and exploit the OS on each boot). Having an external stick also mitigates detectable physical attacks (e.g. theft of laptop, or manipulation detected by a broken tamper-proof seal) where the attacker has already stolen the encryption password, since they still won't get the stick and thus won't be able to get the data anyway. The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well.

loudmax 11y ago
> The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well. You can take out the external USB and keep it in your pocket when you go someplace you wouldn't want to carry a laptop (eg. public bathroom). Whether this is necessary depends on how paranoid you want to be.
rolandr 11y ago
I think your observations are pretty much spot-on, except for your last point: > The stick being external doesn't seem to provide much advantage otherwise, since if the laptop hardware is malicious it doesn't help, and if it is not malicious then an internal trusted stick equivalent works just as well. I think it provides a security-conscious user an added level of comfort/faith over a built-in solution. If you move the flash memory out to this external unit, and there is simply a three wire type of interface that pretty much only gives the system no permanent writability to the flash contents, that is a fairly solid and tangible promise. To some degree, you get to assert a new level of control over the "root of trust," at least the poinbt at which it begins in firmware. That doesn't mean that there is not room for motherboard vendors to improve things, but we will have to have faith in them having done things correctly. I am not even talking about a hostile motherboard vendor - there are plenty of good faith or half baked efforts that end up being circumventable.

hendry 11y ago

My OS https://webconverger.com/ https://webconverger.com/ gets you mostly there. The slate is wiped clean between sessions like https://en.wikipedia.org/wiki/Privacy_mode https://en.wikipedia.org/wiki/Privacy_mode of course.

schoen 11y ago
While an OS that doesn't preserve state is an important component of Rutkowska's proposal, and your OS might be one basis for that component, I don't think this is "mostly there" in terms of everything that the paper discusses. Much of what's new in the paper is about hardware issues, especially because it's concerned with firmware attacks that are already being used by attackers like NSA, and that other people clearly understand how to develop in principle. With these firmware attacks, compromising a device at one point in time may allow the compromise to persist even if the user reinstalls the OS or replaces it with a different one. One way to see this paper is as a response to http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-he-is-compromised http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-h... proposing more details of a safer future platform. Right now, someone who can briefly get kernel-level control on a machine intended to run your OS might be able to reprogram the hard drive firmware. At that point you have a serious authenticity challenge when booting your OS, because the hard drive can alter the contents of particular binaries at the moment they're read from disk. There are some powerful software-only defenses against this, but if an attacker knows which ones you use, they can probably design an attack that evades those.

SagelyGuru 11y ago

"State Considered Harmful" - this incisive observation applies equally to the state as an organisational structure of human society. Discuss ;)

KhalilK 11y ago
[Insert Security vs Freedom debate here]
- DonHopkins 11y ago
  [Express feeling of verklempt here]
jMyles 11y ago
I thought the same thing - "why stop at a laptop? There are mannny aspects of information age society that will benefit from statelessness." :-)
js8 11y ago
I am not sure how would you protect and distribute resources without (democratic) state. I am big fan of democracy, and no state (or similar structure) seems like an idea that goes against democracy. And without democracy, I don't see how society can be considered fair, and protect its weaker members from harm.
- chopin 11y ago
  I am not convinced that democracy protects weaker members of society (let two wolves and one sheep elect what the dinner will be...). Rule of Law does. Democracy gives you a say in politics. Rule of Law gives you a safe life (at least from governmental actions). I concede that both may be not unrelated. But this is not necessarily the case.
  - deleted 11y ago
    [deleted]
  - 11y ago

ge0rg 11y ago

Non PDF version rendered by github: https://github.com/rootkovska/state_harmful/blob/master/state_harmful.md https://github.com/rootkovska/state_harmful/blob/master/stat...

cbd1984 11y ago

Can this be marked as a PDF?

DonHopkins 11y ago

A laptop without any state sponsored back doors sounds like a good idea. I'm also for separation of church and state.

vrtx0 11y ago

I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either create a 'trustworthy' distribution channel for all supported firmware (including all system components and peripheral devices), or support only a select few devices and forbid adding any new peripherals. It also means peripheral devices must either be capable of bootstrapping themselves from this chip, or the system must provide a mechanism that 'sends' this firmware to all peripherals before booting the system. I'm inclined to think that the complex interdependency of this boot process seems impractical. Also, I have to disagree that FPGAs are ideal for the architecture proposed by this paper. Performance and state issues of an FPGA aside, they're field programmable, which seems more vulnerable than 'microcode updates'. Of course, you could just disable field programming, but why even use an FPGA in the first place? Disclaimer: I believe Joanna is much smarter than I am, so I wouldn't be surprised if my comments are based on a fundamental misunderstanding.

viraptor 11y ago
> or the system must provide a mechanism that 'sends' this firmware to all peripherals before booting the system. That's pretty much what they note in "The SPI flash chip" section and what's replaced / muxed from the trusted stick in "Putting it all together" (page 15). SPI is that firmware provisioning component here.
detaro 11y ago
FPGA: You would reprogram the FPGA on each boot from the trusted source. The performance/energy issues remain of course.
rolandr 11y ago
> vrtx0 1 hour ago | parent I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either create a 'trustworthy' distribution channel for all supported firmware (including all system components and peripheral devices), or support only a select few devices and forbid adding any new peripherals. In general, most of the firmware needed for system components is streamed from the main SPI chip to the various components as they are configured by the main system BIOS. Thus, there mainly is a single chip we are concerned about. However, the author identified a second embedded controller )EC_ flash that is also usually present, so we end up being concerned about 2 flash modules. The author addresses other firmwares - the main one being discrete GPUs - and suggests having a system that does not include them. > Also, I have to disagree that FPGAs are ideal for the architecture proposed by this paper. Performance and state issues of an FPGA aside, they're field programmable, which seems more vulnerable than 'microcode updates'. Of course, you could just disable field programming, but why even use an FPGA in the first place? If your only interface between the computer and the FPGA is a three wire interface that emulates an SPI chip, that does not provide any vector for reconfiguring the FPGA. The bitstream for configuring the FPGA is provided via a completely separate set of hardware pins.

asuffield 11y ago

It's an interesting idea, but probably hopeless: all this does is move the goalposts. You're still fundamentally trusting the hardware to read and obey the instructions on your weird "external SPI" device, and if you're willing to trust the hardware then you might as well just put it on the motherboard like today's devices do. If you don't trust your hardware (and I challenge anybody to prove that a motherboard full of chips hasn't had a chunk of flash memory added to it without your knowledge) then you have no reason to think that the code it loaded was the code stored on your "trusted stick". I don't believe that it is possible to build a secure system which isn't based on trusting the device that you hold in your hands. At some level, you need to have a device which is capable of both UI and computation functions to a sufficient extent to validate whatever transaction you are attempting to sign. You could push that onto a smaller device than your laptop (we already know that phone-sized devices are viable), but you still have to end up at the thing you interact with for signing purposes being a device that you trust.

detaro 11y ago
I think the main point is that if you trust the main board once, you can trust it (more) in the future. If it doesn't have any changeable memory, modifying it to become hostile is harder and requires physical tampering.
- nickpsecurity 11y ago
  As Animats said, solving that problem just requires making the firmware read-only at the chip level. Which is cheap. The current problem exists so devices can be easily updated and contain more features. Users demand both with both benefiting hardware market. A a ROM + Flash setup solves the problem but adds a little to cost. Most companies won't do it but it's another viable solution.
candeira 11y ago
This circumvention of surveillance could work for current processors that assume they can trust the SPI chip. But it would be easy for Intel to package the SPI chip together with the CPU in future offerings, circumventing the circumvention. I don't see any assurance for anyone that doesn't control the foundry itself.

Animats 11y ago

A read-only memory device for firmware would be helpful. Not flash, not something erasable, but hard ROM, in a socketed device. All the firmware would go in that ROM, and you could take it out if necessary and compare it with other ROMs. There are simple hard-wired ROM comparison devices. This is the approach mandated by Nevada Gaming Commission slot machine regulations.[1] [1] http://gaming.nv.gov/modules/showdocument.aspx?documentid=3309 http://gaming.nv.gov/modules/showdocument.aspx?documentid=33...

loudmax 11y ago
I can see that for a slot machine, but a laptop probably needs to do something more than that. Don't you want to run a browser? In this case you're locked into a specific browser version, and if someone figures out an exploit that allows an attacker to hijack your browser you have to replace the ROM. Or do you only run SSH/VNC/RDP and connect to a desktop someplace else?
- brohee 11y ago
  That's not what he is suggesting, at all. He's suggesting locking up the boot stages, but your can still load any OS you trust.
  - loudmax 11y ago
    You're right. In the blog post, the author refers to problems on the x86 platform and I didn't realize she was talking about firmware. It's clear in the paper.
rolandr 11y ago
Once upon a time, most/many PCs had physical BIOS protection in the form of a jumper on the motherboard that would allow you to put the BIOS into a read-only state. However, we have now had many years where such control cannot be manually asserted by the end user, and the flash just sits there writable (although there are chipset-level firmware write protections, various hacks, like Dark Jedi, have found ways around them). Plus, apparently even when you pull down the WO pin on some flash chips, the hardware setting can still be overridden by software commands. The paper suggests, particularly with the more recent versions of Intel ME, that the PC architecture has now evolved to expect, and perhaps require, access to a writable BIOS (in part, because the ROM stores not only firmware, but also things like configuration settings and data for the new ME-implemented TPM). Thus, we may not be able to simply go back to a ROM with today's architectures. However, we can give today's systems something that behaves like a writeable flash chip, but is readily (and automatically) reset to a clean/factory state.

loudmax 11y ago

I had a system nearly like what the author describes after the internal SSD drive on my first generation Acer Aspire One died. There didn't seem to be an easy way to replace the drive with a generic SATA SSD (at least none that I was aware of), and a replacement drive was like $80. This is for a $200 netbook, and it wasn't a very good SSD to begin with. So I put Knoppix on a USB stick and basically used that. Since all my stuff is either on my personal server or in the cloud anyway, it was a workable solution. In my case it worked reasonably well, and if I went though the trouble of identifying or putting together a bootable Linux distro with a desktop I really liked I could probably live with something like that as a permanent solution. I'm not nearly as privacy conscious or paranoid as the author, so I'm satisfied with the convenience of a stateful laptop. I don't even have a screen lock when it wakes from sleep. If you want to use a stateless machine like the author describes, you're going to need a personal server or a cloud provider you really trust to keep your stuff. Edit: ge0rg had already posted link to non-PDF version.

spydum 11y ago
I'm not sure you read the paper? The concern centered on all the flash/firmware compnents such as SPI flash and wifi/BT firmware, not just the OS or hard drive. The idea proposed was to have SPI and all device firmware on a secure USB stick that you always keep with you..
- loudmax 11y ago
  You're right. I read the blog post, then skimmed the actual paper. You can already do what she proposes at the OS level, but her concerns go much deeper.
  - rolandr 11y ago
    It seems like a pretty valid concern. Part of the next generation of rootkits seems to be targeted at SMM-level rootkits (termed "ring -1" by some) that are installed in the BIOS. They are practically undetectable once installed, and can punch through hypervisor protections too. I think that is also part of the author's concern with Intel ME being present on all systems. It is a separate microcontroller in the chipset that has power on the level of "ring -3" (I believe it is used to implement much of the new SGE instruction set, for example).

kriro 11y ago

I really wish there was a good laptop that runs Qubes OS and has no BLOBS/closed code/firmware at all. I do some research on this every now and then and always come up short. The Librem 15 was the last one I looked into but it had closed components. Something like the Novena can't run Qubes but would otherwise be ideal (I'd gladly give up some battery life, looks and whatnot for pure freedom) If anyone happens to know a suitable candidate let me know. Wouldn't mind a bit of hardware replacing etc. if the lone closed component could be swapped out etc.

rolandr 11y ago
I do not believe there is are any Intel chips that give you VT-d (IOMMU) and do not require a firmware blob. Blame Intel for that situation. I think AMD has open sourced most of their BIOS, and a lot more of their hardware supports IOMMU anyway. Maybe that is a more fruitful direction to consider.
- kriro 11y ago
  You are absolutely right. In fact I didn't know that Intel ME is that evil. Interesting (a bit hard to follow imo) talk from the recent CCC: https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops#video https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...

transfire 11y ago

http://tinycorelinux.net http://tinycorelinux.net

deleted 11y ago

[deleted]

sp332 11y ago
Could be either. The archetypal paper "Go To Considered Harmful" wasn't satirical, but it was satirizable. https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful

tokenizerrr 11y ago

I will never be able to take any article telling me what to consider harmful serious. A shame, really. Considered harmful articles considered harmful?

mattkrea 11y ago
Some have been good but it is just being taken too far.
nabla9 11y ago
Considered harmful is one type of essay. Considered harmful is great format because the title makes it clear that the author is intentionally taking one side and he is then free to concentrate into one side of the story.

w8rbt 11y ago

I've been saying this about password managers for years: https://news.ycombinator.com/item?id=9731361 https://news.ycombinator.com/item?id=9731361 "The fundamental design flaw of all of these compromised password managers, keychains, etc. is that they keep state in a file. That causes all sorts of problems (syncing among devices, file corruption, unauthorized access, tampering, backups, etc.)."

curryhoward 11y ago
There are a few "stateless" password managers worth considering: 1) http://www.supergenpass.com/ http://www.supergenpass.com/ 2) https://www.stephanboyer.com/post/101/hashpass-a-simple-stateless-password-manager-for-chrome https://www.stephanboyer.com/post/101/hashpass-a-simple-stat... (disclaimer: I wrote #2)

purpled_haze 11y ago

Done: http://cdn.rsvlts.com/wp-content/uploads/2013/02/1671718-slide-p139-4jpg1.jpeg http://cdn.rsvlts.com/wp-content/uploads/2013/02/1671718-sli... + https://www.youtube.com/watch?v=m98agJUoCck https://www.youtube.com/watch?v=m98agJUoCck

joveian 11y ago

One thing I would love to have that could be a solution to the worst case early boot encryption issues is an external crypto processor that generates and stores long term keys, implements authentication, and only releases temporary keys to the main system (to which it only connects via a simple serial connection). It has enough of a screen and input to receive a password and query the user before performing various actions. That is, something like Bitcoin Trezor but maybe a little more complex input and for more general crypto use. Ideally, such a device could even physically store the trusted stick (or several), although that trusted stick shouldn't interact with the rest of the system differently than any other device for maximum reliability. This way the most sensitive crypto is not performed on a general purpose system and the user could authenticate to the device once and then the device can authenticate the user and provide keys to multiple independent systems without hastle. It is an additional expense so hopefully wouldn't be necessary, but would be one way to solve the early boot encryption problem (if needed and less expensive solutions do not work) in a not completely special purpose way.

nickpsecurity 11y ago

Short on time, but I'll say she's looking in the right idea in general. This idea has actually been done before. Removable firmware part used to happen in older machines, too. Far as I know, I came up with it first with a proposal on Schneier's blog, etc to put both the CPU and trusted state on a stick or card you inserted into a machine containing only peripherals maybe with RAM. Research CPU's at the time had RAM encryption/integrity to make it untrusted. I was thinking PC Card rather than stick due to EMSEC, storage, and cost issues. I'll try to find the link later today. It was actually inspired by foreign, airport security compromising stuff. People asked me to develop a convenient solution. So, real problem was physical access to the trusted components. That access couldn't happen but can't keep all our gear with us or away from inspection. A simple chip or PC Card they carried on would be better. The chassis, from laptop to whatever, they could acquire in country or ship separately with inspection. I further imagined a whole market popping up supplying both secure sticks/cards and the stuff you plug them into. Inspiration for that was iPod & its accessories like docks. One more part was that each user could determine how much protection, from tamper-evidence to EMSEC, to apply to their trusted device. As it sometimes happens, another company showed up with government backing IIRC and R&D on security devices. Their proposed portfolio was very similar. They undoubtedly started patenting all of it. This created a second risk for anyone attempting what I or now Joanna is attempting: a greedy, defence-connected, third party legally controlling pieces of your core business. They usually just rob people but I predicted on Schneier's blog & later here in a heated debate that they could attempt to change or get rid of the product using their patents. Especially true if a proxy for an intelligence agency. We might have just seen that happen with Apple over iMessage but I can't be sure. Anyway, do know there's both prior art and probably patents on these concepts in defense industry. So, it was a cool concept. It was one of those I was proudest of given it collapsed problems with all kinds of devices to design and protection of one component. That's basic Orange Book-era thinking I try to remember. Unfortunately, after much debate with marketing types, we determined there was a chicken and the egg problem with these [at the time]. The NRE cost would be high to the point you'd want to be sure there was a demand for thousands of them plus people willing to pay high unit prices. Custom laptops were often closer to $10,000 than $3,000 if low volume. My greater market idea was chicken-and-the-egg times a million. That plus risk of 3rd party patents made me back off the idea as nice but not practical. Since then, what's changed is dramatically lower cost for homebrew hardware or industrial prototyping. Projects like Novena show it can probably be done for lower NRE than before. However, this is security-critical design that needs strong expertise in both hardware (esp analog/RF) and Intel x86. That will up the NRE and odds of them screwing up. ARM or MIPS ("cheaper ARM") might be easier to do but still need HW expert and significant NRE. So, there's my take. It's a good idea that two of us in security industry already fleshed-out with removable firmware being proven in ancient mainframes. Serious marketing obstacles to getting this done and done securely. A high-level design for the technology, as I did, is pretty straight-forward and will teach one many lessons. It was a good learning experience if nothing else.

OJFord 11y ago

Interesting (and surprising to me) that the word 'laptop' is used instead of 'computer'.

gbtw 11y ago
It is the formfactor of a portable computer that you could own completely, unlike anything more mobile where at least some of the chips are configured and run by someone else. Also you would take your I/O with you because it makes no sense if you hardly trust a device you don't let leave your side to interface with some static hardware that any third party could have modified. Current monitors have more processing power than early mainframe computers and more than enough room to hide rf equipment for remote snooping.

deleted 11y ago

[deleted]

peterburkimsher 11y ago

SD cards have SPI pins, so I recommend SD for Trusted Stick rather than repurposed USB. I've bought a 512GB SDXC card for the purpose of backing up my laptop, and often wonder whether to use it as a boot device. It's much less vulnerable to theft when it's safe in my pockets, compared to in a bag. I'd make one small change. Rather than aim for a laptop first, mod a WiFi SD card or other pocket-sized device. The KeyAsic platform (PQI Air Card/Transcend) has been extensively hacked, and Ubuntu can run on it. Client devices (laptop, phone, etc) could connect over WiFi and run VNC through a web browser. It's still vulnerable to keystroke logging on the client, but it would be possible to switch clients halfway through typing important messages. In my opinion the most secure client device would be an iPod running Rockbox, and connecting to the PQI Air Card over serial. My "WiPod" seems like the closest thing we have to a practical pocket-sized open source device, and it lets me share photos from an SD card to my phone :).

jakeogh 11y ago

C3TV – Towards (reasonably) trustworthy x86 laptops: https://news.ycombinator.com/item?id=10833637 https://news.ycombinator.com/item?id=10833637