6 ms·

How do you know the thing which takes your design and "builds" (i.e. machine which places physical components) or "compiles" (i.e. the thing which moves bits in

How do you know the thing which takes your design and "builds" (i.e. machine which places physical components) or "compiles" (i.e. the thing which moves bits into an fpga) things isn't subverted?

nickpsecurity 11y ago
There's ways to be reasonably sure. I can't publish it as it would only aid opponents. Here's the base requirements, though: https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624
- sinrostro 11y ago
  You really should publish, as security through obscurity only hurts us! Out in the open, there is a chance that some measures will be taken. Concealment is a guarantee that bad guys will be doing bad things quietly.
  - nickpsecurity 11y ago
    That's a mainstream mantra but not true at all against High Strength Attackers (HSA's). They always have more resources than you do. They more they know, the more they can focus. That's why obfuscation on top of proven security techniques is the best strategy for use against HSA's. Gotta give them nothing (or false things) to aim at then have good detection or recovery measures. Proven strategy. Alternatively, I can publish my model. They can immediately move to counter the very specific things I do. Before you know it, they have a turn-key solution for compromising my devices individually or in bulk. Anyone using it is suddenly less safe. Knowing specifics will also benefit their stealth: less detection capability. Rather not publish that at least until I've developed something better. ;)
    - AnthonyMouse 11y ago
      > That's a mainstream mantra but not true at all against High Strength Attackers (HSA's). They always have more resources than you do. That's why obscurity doesn't work. An attacker with many resources can reverse engineer whatever concealment you've concocted but the concealment is enough to deter other researchers who would have published their results from analyzing your system. So then the HSA knows of the attack and can take advantage of it but you don't so you can't counter it.
      - nickpsecurity 11y ago
        Nonsense. The attacker must expend significant effort to identify both the product- and user-specific obfuscations. That by itself does two things: (a) reduce number that can afford to attack you; (b) possibly force individual attacks instead of one size fits all. On top of this, there's a range of monitoring and tamper-resistance measures that can be employed. So, the result of such obfuscations plus strong, proven methods stops most attackers outright, helps catch some, and at least slows/limits others. Compare that to a situation where every detail is known and TCB (esp hardware & kernel) are same for all users. Find flaw easily, compromise any. That's your model. See the NSA TAO catalog and any reporting of mass hacks to see where that led. Your method simply doesnt work and is defeated even by average attackers. Whereas mine has held off many in practice with the few failures due to over-privileged, malicious insiders. Learn from the evidence. Apply strong methods, obfuscation, diversity, and detection in combination. Or High Strength Attackers own you without breaking a sweat.
        AnthonyMouse 11y ago
        Your argument is upside down. Unraveling obfuscation costs time and money, which means it may be able to deter amateurs (though the history of DRM implies it can't even do that). State-level attackers have nearly unlimited resources. You can't defeat them by costing them money because their money comes out of your paycheck. The only way to defend against them, if you have the hubris to think you're even capable of it, is to find and remove the vulnerabilities so there is nothing for them to exploit. Which makes obfuscation counterproductive because it makes things harder for whitehats who would otherwise help you. And diversity and obscurity are separate things so the diversity argument is a non-sequitur.
    - sinrostro 11y ago
      It is foolish to assume that HSAs don't already have access to whatever you, some guy on the Internet, know. So you can be an asshat, or do the right thing and try to 'protect the muggles' by letting information be available to all. They might feel threatened enough to pull valuables from unsafe places (such as networked computers).
      - nickpsecurity 11y ago
        It's not foolish if one understands high assurance security well enough that his recommendations preempted or predicted many specific things in TAO catalog. And most other stuff they did. It's easy once you understand nature of INFOSEC plus their nature. No they don't have my methodology: I never put it into digital form. Use paper is rule No 1 in high security. The only people I talked go were ideological who I vetted. It's mostly in my head and on paper hidden well in areas with tamper-evidence. They're watching my comms but no black bag jobs. So the method is safe for now. And what are you going to do with it? All of us high security engineers who arent in defense, sell-outs, etc are typically ignored by mainstream INFOSEC. People don't do shit even when we have evidence. People do less than that on open HW even with cheap FPGA's. You really think one of us is gonna burn our own security just to publish an obfuscation people won't use or give us anything for? Like hell... You want write-ups and design details on high security I got plenty of that. Keep master copies on Schneier's blog. Will send them. Not giving away something this big that you cant even afford to use. Not till I have a replacement...
        calgoo 11y ago
        There is also this thing of legacy code... What if 3, 5, 10 years from now when you have moved on to your next super project, but someone has based system XYZ on your code. If they need to write a driver or similar, I'm sure they would be a lot happier to have a documentation that clearly states a design etc then a document saying: "This was hidden so big bad guys cant look!".
        nickpsecurity 11y ago
        High assurance requirements going back to Orange Book's A1 class said the source code and evaluation evidence comes with the software. Further, customers were encouraged to re-run the tests & compilation, generate the system on-site, set it up according to secure configuration guide, and report any problems back to vendor. They become part of the evaluation process although real work was to be done by security professionals at evaluation lab and NSA's pentesters. Here's an example of one from one of father's of INFOSEC that handed NSA's ass to them in 2 years of pentesting: http://www.iwia.org/2005/Schell2005.PDF http://www.iwia.org/2005/Schell2005.PDF The original was based on custom hardware and firmware because Schell etc had good foresight. :) It was put on Intel because DOD and commercial sector wanted commodity products. So, probably issues at those layers that could breach security. Nonetheless, the kernel was what was designed with high assurance and will illustrate nicely what comes out of that. Note that this was the 1980's when it was designed. Still more secure, easier to review, and easier to extend than most modern software... So, I'd have to supply customers the source to meet your requirement. I could also show them how to protect it. However, thanks to design approach, a high assurance proprietary system is easier to work with than a low assurance FOSS system. It's because the process absolutely forces that design to be a simple, modular, layered, and correct as possible. I wrote up some links on how that's done here in context of subversion and hardware: https://news.ycombinator.com/item?id=10478742 https://news.ycombinator.com/item?id=10478742
  - coldtea 11y ago
    >as security through obscurity only hurts us! People keep saying that, but nobody proposes we all reveal our passwords. Obviously SOME obscurity is beneficial...
    - mikeash 11y ago
      Security through obscurity is specifically about secrecy in the design or implementation of a system, not the specific parameters used with the system. It's not a catch-all phrase referring to any possible secrecy.
      - nickpsecurity 11y ago
        I thought it meant that the only security came from secrecy of design or implementation. Pro's keeping a good design/implementation secret, esp hardware, provably increases difficulty for attackers. So it's a legit method we call obfuscation. I'll go further to say it's a pre-requisite against nation-states as knowing design/implementation is first step to compromise. And they usually do.
        mikeash 11y ago
        I think the two ideas are conflated a lot, because it's so rare to have a secret system that is actually secure. In practice, a secret design or implementation is probably insecure, even if theoretically it doesn't have to be. If the design or implementation is fixed in stone, then keeping it secret can only help, certainly. Most aren't, though, especially while they're still being developed. At that stage, if you can get smart people interested in helping, then openness will help far more than it hurts because you're far more likely to discover problems before the bad guys do.
        nickpsecurity 11y ago
        It's usually true that the secret designs are insecure. I'll give you that. I only trust that which is done by pro's with review, esp with high assurance methods. Most things aren't like that. Easy to see how the interpretations would get conflated a lot. Far as help or review, there's a false dilemma that goes around between something being so open I put it in a Hacker's News comment and totally closed. In reality, there's many things between with the review being more important than openness. I tried to address it in this write-up: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_... Goal was to get people to consider proprietary, open-source models more to ensure steady flow of cash to maintain/audit security-critical software. Dual-licensing at the least. Might prevent another OpenSSL debacle. Far as actively developed, that's a good point. The trick there is to make sure you have guidelines for how to use the security-critical functionality and stick to them. The common stuff that's prone to error is done in a way that defaults to security. An example is how Ada or Rust approach memory/concurrency safety vs C. Not a guarantee by itself but raises bar considerably. The parts that are obfuscated have little risk on the security-critical aspects and are more about changing likelihood that shellcode will do its job. There's even methods in academia to do this automatically at compiler level. So, this is what I'm saying. You should definitely have pro's in-house or (if possible) externally to review the design for flaws. Just do Correct by Construction, make design as boring as possible, and obfuscate the hell out of any aspect you can without introducing risk. An example from my work when I did high security consulting was to put guards in front of any networked service. The guard blocked attacks like DMA, TCP/IP, whatever. The messages they passed along were simple, easy to parse, and landed directly in the application. The application itself had automatic checking of buffers, etc. My biggest trick, though, was to use the guard to fake a certain platform/ISA (Windows/Linux on x86) while app actually ran on different OS and ISA (eg POWER/SPARC/Alpha/MIPS). They'd hit it constantly with stuff too clever for me to even want to waste time understanding. Never executed because they couldn't see what they needed to see. And all the good security hardening, patches, monitoring, and whatnot. Strong security practices + effective obfuscation = TLA's remote attacks stood no chance. :)
- kjs3 11y ago
  Bullshit. Historically verifiable bullshit. See: Every security system ever that relied on not telling your opponents the details. When will you amateurs fucking read the literature and understand you're wrong?
  - deleted 11y ago
    [deleted]
  - sinrostro 11y ago
    To clarify: this is to counter the statement that security through obscurity is a good thing. Yeah, that worked out well for the Enigma and countless other systems.
    - nickpsecurity 11y ago
      That commenter was replying to me with more nonsense like your selective example of Enigma that barely fits into the discussion at all. Worse, your example actually supports my side's position: they cracked the best crypto they had the second they knew how it worked and no methods were in place to reliably detect this. Today, they crack the complex systems and protocols people are using shortly after figuring out how they work as quality is so bad and everyone uses same ones. The modern example of enigma would be people using Linux desktops instead of Windows, Foxit instead of Adobe, unusual-but-good web servers instead of Apache, and so on to hope attackers not knowing will keep them safe. And it usually works, too, unless it's a targeted attack by pro's. That's saying something. ;) My method combines vetted mechanisms with ways that adhere to their guidelines for secure usage, is directed by tools designed by security pro's, largely invisible to users, require a hack on system to find, and force custom, difficult attacks. One can mathematically prove that my strategies possess the traits I claim along with immunity from some issues and vastly improved probabilistic security against most others. So, all the evidence is on our side in theory and the field results where compromise is rare for us even in face of pro's whose bonuses require it. Feel free to refute this by showing me how everyone using two browsers, OpenSSL, or a desktop OS (Windows) with no changes on the same platform kept them safe from major attacks. Or led to such a high failure rate for attackers that hacks were actually worth of news rather than scaremongering. My people were safe with my methods: some systems crashed or raised exceptions while many had no problems. I'm guessing you standardize-and-open types had the same experiences? No? :P
pjtr 11y ago
Perhaps you can adapt "Diverse Double-Compiling" to "Diverse Double-Manufacturing"? http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
- Jach 11y ago
  I had the same thought. I think the hardest part could be "diffing" the outputs, though. Is some particular difference within expected parameters, or can you really detect that hidden bit of metal on layer 5 of the board? Interestingly I stumbled upon this: http://www.sandia.gov/mstc/fabrication/index.html http://www.sandia.gov/mstc/fabrication/index.html
  - nickpsecurity 11y ago
    Didn't know they had a rad-hard, S-ASIC offering. Thanks for the link.
- nickpsecurity 11y ago
  That's not going to happen because the two toolchains won't be anything alike. You won't be able to make them alike either. Worse, that people often quote Thompson's attack shows that INFOSEC teaches subversion very poorly: it's the least likely attack to affect you and you really need to counter the others. What you have to do is make the software correct, make it secure, and ensure no subversion in lifecycle. That's called high assurance or robustness system design. Links below show you how to do that. High assurance software design - nice intro http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt FOSS tools for high assurance http://www.dwheeler.com/essays/high-assurance-floss.html http://www.dwheeler.com/essays/high-assurance-floss.html Certified compilation (HW w/ need certified "synthesis") http://compcert.inria.fr/ http://compcert.inria.fr/ Original work on subversion http://csrc.nist.gov/publications/history/myer80.pdf http://csrc.nist.gov/publications/history/myer80.pdf Example of it in action http://www.cisr.us/downloads/theses/02thesis_anderson.pdf http://www.cisr.us/downloads/theses/02thesis_anderson.pdf Example of high assurance hardware (AAMP7G version is secure but no public paper...) http://www.csl.sri.com/papers/wift95/wift95.pdf http://www.csl.sri.com/papers/wift95/wift95.pdf
sklogic 11y ago
By using the open source toolchains, of course. See http://opencircuitdesign.com/qflow/ http://opencircuitdesign.com/qflow/ - it's capable of producing the OSU 0.35um output, ready for a fab. And with such a node you can inspect the result with nearly a bare eye.
- nickpsecurity 11y ago
  I've been wanting to know what they've actually fabbed rather than merely synthesized. What link do you have on them doing an ASIC-proven design at 0.35um? Not just in theory but actually doing it and the chip worked. Far as getting OSS flows lower, I've been collecting methods for doing that. Physical [re-]synthesis is the next step for 130nm and 90nm. A few other tricks they use. I've collected a few papers on methods of doing as many as possible so academics can reimplement them for Yosys, Odin, ABC, etc in the future. It's critical that we get open flows for 90nm. We can do 180nm first as it's still highly useful, esp for custom. However, 90nm is better for standard cell and flash memory. My mindset is that we can combine proprietary tools and open tools in a hybrid approach. Let the proprietary tools catch all the errors, guide re-synthesis, etc. So long as they can be made to produce a series of traces for synthesis and test vectors that open-source tools can check. One or more EDA vendors might go for this as it keeps their secrets secret and profits high while letting us do much easier work that OSS tools are already close to handling. I mean, we still strive for open EDA in long term but use this for interim. What you think?
  - sklogic 11y ago
    Quoting the qflow site: > Early versions of the qflow digital flow were used to create digital circuits used in high-performance commercial integrated circuits. It's real, and it works! So, likely, the OSU cell library was really used for commercial fabrication ( http://vlsiarch.ecen.okstate.edu/flow/# http://vlsiarch.ecen.okstate.edu/flow/# ). I think you're right, OSS can coexist with the proprietary cell libraries and P&R tools. I am (optimistically) expecting that in the near future we'll witness a revolution in vlsi similar to what happened to the PCB fabrication - with the fabs becoming accessible to small companies and even hobbyists. And this should kick start an improvement in both the OSS tools ecosystem and the current closed, secretive world of Cadence, Synopsys and alike.

How do you know the thing which takes your design and "builds" (i.e. machine which places physical components) or "compiles" (i.e. the thing which moves bits into an fpga) things isn't subverted?

nickpsecurity 11y ago

There's ways to be reasonably sure. I can't publish it as it would only aid opponents. Here's the base requirements, though: https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624

sinrostro 11y ago
You really should publish, as security through obscurity only hurts us! Out in the open, there is a chance that some measures will be taken. Concealment is a guarantee that bad guys will be doing bad things quietly.
- nickpsecurity 11y ago
  That's a mainstream mantra but not true at all against High Strength Attackers (HSA's). They always have more resources than you do. They more they know, the more they can focus. That's why obfuscation on top of proven security techniques is the best strategy for use against HSA's. Gotta give them nothing (or false things) to aim at then have good detection or recovery measures. Proven strategy. Alternatively, I can publish my model. They can immediately move to counter the very specific things I do. Before you know it, they have a turn-key solution for compromising my devices individually or in bulk. Anyone using it is suddenly less safe. Knowing specifics will also benefit their stealth: less detection capability. Rather not publish that at least until I've developed something better. ;)
  - AnthonyMouse 11y ago
    > That's a mainstream mantra but not true at all against High Strength Attackers (HSA's). They always have more resources than you do. That's why obscurity doesn't work. An attacker with many resources can reverse engineer whatever concealment you've concocted but the concealment is enough to deter other researchers who would have published their results from analyzing your system. So then the HSA knows of the attack and can take advantage of it but you don't so you can't counter it.
    - nickpsecurity 11y ago
      Nonsense. The attacker must expend significant effort to identify both the product- and user-specific obfuscations. That by itself does two things: (a) reduce number that can afford to attack you; (b) possibly force individual attacks instead of one size fits all. On top of this, there's a range of monitoring and tamper-resistance measures that can be employed. So, the result of such obfuscations plus strong, proven methods stops most attackers outright, helps catch some, and at least slows/limits others. Compare that to a situation where every detail is known and TCB (esp hardware & kernel) are same for all users. Find flaw easily, compromise any. That's your model. See the NSA TAO catalog and any reporting of mass hacks to see where that led. Your method simply doesnt work and is defeated even by average attackers. Whereas mine has held off many in practice with the few failures due to over-privileged, malicious insiders. Learn from the evidence. Apply strong methods, obfuscation, diversity, and detection in combination. Or High Strength Attackers own you without breaking a sweat.
      - AnthonyMouse 11y ago
        Your argument is upside down. Unraveling obfuscation costs time and money, which means it may be able to deter amateurs (though the history of DRM implies it can't even do that). State-level attackers have nearly unlimited resources. You can't defeat them by costing them money because their money comes out of your paycheck. The only way to defend against them, if you have the hubris to think you're even capable of it, is to find and remove the vulnerabilities so there is nothing for them to exploit. Which makes obfuscation counterproductive because it makes things harder for whitehats who would otherwise help you. And diversity and obscurity are separate things so the diversity argument is a non-sequitur.
  - sinrostro 11y ago
    It is foolish to assume that HSAs don't already have access to whatever you, some guy on the Internet, know. So you can be an asshat, or do the right thing and try to 'protect the muggles' by letting information be available to all. They might feel threatened enough to pull valuables from unsafe places (such as networked computers).
    - nickpsecurity 11y ago
      It's not foolish if one understands high assurance security well enough that his recommendations preempted or predicted many specific things in TAO catalog. And most other stuff they did. It's easy once you understand nature of INFOSEC plus their nature. No they don't have my methodology: I never put it into digital form. Use paper is rule No 1 in high security. The only people I talked go were ideological who I vetted. It's mostly in my head and on paper hidden well in areas with tamper-evidence. They're watching my comms but no black bag jobs. So the method is safe for now. And what are you going to do with it? All of us high security engineers who arent in defense, sell-outs, etc are typically ignored by mainstream INFOSEC. People don't do shit even when we have evidence. People do less than that on open HW even with cheap FPGA's. You really think one of us is gonna burn our own security just to publish an obfuscation people won't use or give us anything for? Like hell... You want write-ups and design details on high security I got plenty of that. Keep master copies on Schneier's blog. Will send them. Not giving away something this big that you cant even afford to use. Not till I have a replacement...
      - calgoo 11y ago
        There is also this thing of legacy code... What if 3, 5, 10 years from now when you have moved on to your next super project, but someone has based system XYZ on your code. If they need to write a driver or similar, I'm sure they would be a lot happier to have a documentation that clearly states a design etc then a document saying: "This was hidden so big bad guys cant look!".
        nickpsecurity 11y ago
        High assurance requirements going back to Orange Book's A1 class said the source code and evaluation evidence comes with the software. Further, customers were encouraged to re-run the tests & compilation, generate the system on-site, set it up according to secure configuration guide, and report any problems back to vendor. They become part of the evaluation process although real work was to be done by security professionals at evaluation lab and NSA's pentesters. Here's an example of one from one of father's of INFOSEC that handed NSA's ass to them in 2 years of pentesting: http://www.iwia.org/2005/Schell2005.PDF http://www.iwia.org/2005/Schell2005.PDF The original was based on custom hardware and firmware because Schell etc had good foresight. :) It was put on Intel because DOD and commercial sector wanted commodity products. So, probably issues at those layers that could breach security. Nonetheless, the kernel was what was designed with high assurance and will illustrate nicely what comes out of that. Note that this was the 1980's when it was designed. Still more secure, easier to review, and easier to extend than most modern software... So, I'd have to supply customers the source to meet your requirement. I could also show them how to protect it. However, thanks to design approach, a high assurance proprietary system is easier to work with than a low assurance FOSS system. It's because the process absolutely forces that design to be a simple, modular, layered, and correct as possible. I wrote up some links on how that's done here in context of subversion and hardware: https://news.ycombinator.com/item?id=10478742 https://news.ycombinator.com/item?id=10478742
- coldtea 11y ago
  >as security through obscurity only hurts us! People keep saying that, but nobody proposes we all reveal our passwords. Obviously SOME obscurity is beneficial...
  - mikeash 11y ago
    Security through obscurity is specifically about secrecy in the design or implementation of a system, not the specific parameters used with the system. It's not a catch-all phrase referring to any possible secrecy.
    - nickpsecurity 11y ago
      I thought it meant that the only security came from secrecy of design or implementation. Pro's keeping a good design/implementation secret, esp hardware, provably increases difficulty for attackers. So it's a legit method we call obfuscation. I'll go further to say it's a pre-requisite against nation-states as knowing design/implementation is first step to compromise. And they usually do.
      - mikeash 11y ago
        I think the two ideas are conflated a lot, because it's so rare to have a secret system that is actually secure. In practice, a secret design or implementation is probably insecure, even if theoretically it doesn't have to be. If the design or implementation is fixed in stone, then keeping it secret can only help, certainly. Most aren't, though, especially while they're still being developed. At that stage, if you can get smart people interested in helping, then openness will help far more than it hurts because you're far more likely to discover problems before the bad guys do.
        nickpsecurity 11y ago
        It's usually true that the secret designs are insecure. I'll give you that. I only trust that which is done by pro's with review, esp with high assurance methods. Most things aren't like that. Easy to see how the interpretations would get conflated a lot. Far as help or review, there's a false dilemma that goes around between something being so open I put it in a Hacker's News comment and totally closed. In reality, there's many things between with the review being more important than openness. I tried to address it in this write-up: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_... Goal was to get people to consider proprietary, open-source models more to ensure steady flow of cash to maintain/audit security-critical software. Dual-licensing at the least. Might prevent another OpenSSL debacle. Far as actively developed, that's a good point. The trick there is to make sure you have guidelines for how to use the security-critical functionality and stick to them. The common stuff that's prone to error is done in a way that defaults to security. An example is how Ada or Rust approach memory/concurrency safety vs C. Not a guarantee by itself but raises bar considerably. The parts that are obfuscated have little risk on the security-critical aspects and are more about changing likelihood that shellcode will do its job. There's even methods in academia to do this automatically at compiler level. So, this is what I'm saying. You should definitely have pro's in-house or (if possible) externally to review the design for flaws. Just do Correct by Construction, make design as boring as possible, and obfuscate the hell out of any aspect you can without introducing risk. An example from my work when I did high security consulting was to put guards in front of any networked service. The guard blocked attacks like DMA, TCP/IP, whatever. The messages they passed along were simple, easy to parse, and landed directly in the application. The application itself had automatic checking of buffers, etc. My biggest trick, though, was to use the guard to fake a certain platform/ISA (Windows/Linux on x86) while app actually ran on different OS and ISA (eg POWER/SPARC/Alpha/MIPS). They'd hit it constantly with stuff too clever for me to even want to waste time understanding. Never executed because they couldn't see what they needed to see. And all the good security hardening, patches, monitoring, and whatnot. Strong security practices + effective obfuscation = TLA's remote attacks stood no chance. :)
kjs3 11y ago
Bullshit. Historically verifiable bullshit. See: Every security system ever that relied on not telling your opponents the details. When will you amateurs fucking read the literature and understand you're wrong?
- deleted 11y ago
  [deleted]
- sinrostro 11y ago
  To clarify: this is to counter the statement that security through obscurity is a good thing. Yeah, that worked out well for the Enigma and countless other systems.
  - nickpsecurity 11y ago
    That commenter was replying to me with more nonsense like your selective example of Enigma that barely fits into the discussion at all. Worse, your example actually supports my side's position: they cracked the best crypto they had the second they knew how it worked and no methods were in place to reliably detect this. Today, they crack the complex systems and protocols people are using shortly after figuring out how they work as quality is so bad and everyone uses same ones. The modern example of enigma would be people using Linux desktops instead of Windows, Foxit instead of Adobe, unusual-but-good web servers instead of Apache, and so on to hope attackers not knowing will keep them safe. And it usually works, too, unless it's a targeted attack by pro's. That's saying something. ;) My method combines vetted mechanisms with ways that adhere to their guidelines for secure usage, is directed by tools designed by security pro's, largely invisible to users, require a hack on system to find, and force custom, difficult attacks. One can mathematically prove that my strategies possess the traits I claim along with immunity from some issues and vastly improved probabilistic security against most others. So, all the evidence is on our side in theory and the field results where compromise is rare for us even in face of pro's whose bonuses require it. Feel free to refute this by showing me how everyone using two browsers, OpenSSL, or a desktop OS (Windows) with no changes on the same platform kept them safe from major attacks. Or led to such a high failure rate for attackers that hacks were actually worth of news rather than scaremongering. My people were safe with my methods: some systems crashed or raised exceptions while many had no problems. I'm guessing you standardize-and-open types had the same experiences? No? :P

pjtr 11y ago

Perhaps you can adapt "Diverse Double-Compiling" to "Diverse Double-Manufacturing"? http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/

Jach 11y ago
I had the same thought. I think the hardest part could be "diffing" the outputs, though. Is some particular difference within expected parameters, or can you really detect that hidden bit of metal on layer 5 of the board? Interestingly I stumbled upon this: http://www.sandia.gov/mstc/fabrication/index.html http://www.sandia.gov/mstc/fabrication/index.html
- nickpsecurity 11y ago
  Didn't know they had a rad-hard, S-ASIC offering. Thanks for the link.
nickpsecurity 11y ago
That's not going to happen because the two toolchains won't be anything alike. You won't be able to make them alike either. Worse, that people often quote Thompson's attack shows that INFOSEC teaches subversion very poorly: it's the least likely attack to affect you and you really need to counter the others. What you have to do is make the software correct, make it secure, and ensure no subversion in lifecycle. That's called high assurance or robustness system design. Links below show you how to do that. High assurance software design - nice intro http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt http://web.cecs.pdx.edu/~hook/cs491sp08/AssuranceSp08.ppt FOSS tools for high assurance http://www.dwheeler.com/essays/high-assurance-floss.html http://www.dwheeler.com/essays/high-assurance-floss.html Certified compilation (HW w/ need certified "synthesis") http://compcert.inria.fr/ http://compcert.inria.fr/ Original work on subversion http://csrc.nist.gov/publications/history/myer80.pdf http://csrc.nist.gov/publications/history/myer80.pdf Example of it in action http://www.cisr.us/downloads/theses/02thesis_anderson.pdf http://www.cisr.us/downloads/theses/02thesis_anderson.pdf Example of high assurance hardware (AAMP7G version is secure but no public paper...) http://www.csl.sri.com/papers/wift95/wift95.pdf http://www.csl.sri.com/papers/wift95/wift95.pdf

sklogic 11y ago

By using the open source toolchains, of course. See http://opencircuitdesign.com/qflow/ http://opencircuitdesign.com/qflow/ - it's capable of producing the OSU 0.35um output, ready for a fab. And with such a node you can inspect the result with nearly a bare eye.

nickpsecurity 11y ago
I've been wanting to know what they've actually fabbed rather than merely synthesized. What link do you have on them doing an ASIC-proven design at 0.35um? Not just in theory but actually doing it and the chip worked. Far as getting OSS flows lower, I've been collecting methods for doing that. Physical [re-]synthesis is the next step for 130nm and 90nm. A few other tricks they use. I've collected a few papers on methods of doing as many as possible so academics can reimplement them for Yosys, Odin, ABC, etc in the future. It's critical that we get open flows for 90nm. We can do 180nm first as it's still highly useful, esp for custom. However, 90nm is better for standard cell and flash memory. My mindset is that we can combine proprietary tools and open tools in a hybrid approach. Let the proprietary tools catch all the errors, guide re-synthesis, etc. So long as they can be made to produce a series of traces for synthesis and test vectors that open-source tools can check. One or more EDA vendors might go for this as it keeps their secrets secret and profits high while letting us do much easier work that OSS tools are already close to handling. I mean, we still strive for open EDA in long term but use this for interim. What you think?
- sklogic 11y ago
  Quoting the qflow site: > Early versions of the qflow digital flow were used to create digital circuits used in high-performance commercial integrated circuits. It's real, and it works! So, likely, the OSU cell library was really used for commercial fabrication ( http://vlsiarch.ecen.okstate.edu/flow/# http://vlsiarch.ecen.okstate.edu/flow/# ). I think you're right, OSS can coexist with the proprietary cell libraries and P&R tools. I am (optimistically) expecting that in the near future we'll witness a revolution in vlsi similar to what happened to the PCB fabrication - with the fabs becoming accessible to small companies and even hobbyists. And this should kick start an improvement in both the OSS tools ecosystem and the current closed, secretive world of Cadence, Synopsys and alike.