Schneier on Security

Nick P • May 23, 2014 6:30 PM

@ Buck

I’ll also add that two probably had DMA and had direct access to user input. These traits give attackers many options from keylogging to code injection. From there, they can also use both BIOS payloads and covert communication channels.

Additionally, I’ve always said among best attacks were places nobody looked. How many people do you know who inspect and circuit probe their trackpad controllers for security purposes? 😉

@ Jonathan Wilson

Re Bahamas phone spying

It would make plenty of sense to collect in many of those island countries, Cayman most of all. Reason is tons of tax dodgers and proxy corporations operate through there. If middlemen’s communication wasn’t protected, spies could slowly piece plent information together for uses ranging from catching tax dodgers to blackmailing politicians.

Nick P • May 24, 2014 12:35 AM

@ Benni

Thanks for sharing the info on the German constitution and how Germany’s legal system is handling all this. Very interesting stuff. It would be nice if we had such an acknowledged right or even lawmakers that really listen to pro-liberty engineers. Neither of those things happen here much.

Nick P • May 24, 2014 5:04 PM

@ Alessandro

Sounds correct to me. Covert channels are one of the most neglected parts of computer security. They’re quite esoteric. Here’s some simple examples to help you understand each type.

Basic Model

Leaker and Receiver. The Leaker has access to secret information, yet no access to network. It might be an app that signs stuff with your private key. The Receiver is a less privileged program with networking access, but not allowed to read secret data in filesystem. The policy of the main access or communication mechanisms is to totally block these two from talking. So, they need to use a method that allows them to communicate, is easy to hide, and bypasses protections.

Covert Storage Channel

There are functions and locations intended for storing data. This include file contents, the data part of a network packet, and an IPC message. The operating system (and admin) usually enforce rules on how these are used, optionally monitoring them. However, processes might have read or write access to something else which can move information.

Examples include newly allocated memory, the header fields on an IP packet, or even grey area of temporary data storage that’s world-readable. In each case, the Leaking program can put data in there, the Receiver can read it, and nobody expects the storage location to be used for unauthorized communication.

Covert Timing Channel

Quite simply, Leaker and Receiver are both looking at something that takes a certain amount of time. Leaker can signficantly change the timing to represent a 1. Leaker can do nothing to timing to represent a 0. Leaker just keeps alternating what it does to resource to represent right sequence of 1’s and 0’s. The Receiver just keeps measuing how long it takes to interact with that resource, getting the data bit by bit. There’s often a certain amount of noise in the system, leading to use of error correction codes like those used for radio’s and such.

One example in a system is the cache. Anything the processor uses from memory gets loaded in the cache first. Then, all access to it are much faster. Cache is limited so new pieces of memory might require knocking something out the cache, then loading in something new. So, if you do an operation on something in cache, it’s fast (1). If not, it’s much slower (0). So, two programs might create a similar chunk of memory, operate on them, and measure timing. Leaker just keeps alternating between using what’s in cache and causing cache misses. Receiver keeps using its data structure and measuring the timing. Hence, without any official communication channel they are able to signal each other. In practice, that channel sends data several times faster than dial-up Internet.

A simplistic example of the same thing can come from networking. Let’s say it’s two computers with network connections that are monitored. The Leaker has secret data, yet can’t talk to external networks. The Receiver can talk to external networks, but isn’t allowed to receive secret data. The monitoring looks at the whole packet so it will see the data leaking.

There’s still hope for the spy as a timing channel is available. Both can send packets of legitimate data to each other. Both systems can measure the time between packets. To leak information, the Leaker process first internally turns it into a series of 1’s and 0’s. Then, it adds a delay to its network packets to represent a 0 or lets them be fast as usual to represent a 1. It might be a slowdown of merely a few hundred milliseconds. It might be every so many packets. In other words, this is “slow” in computer terms as such that Receiver program notices the delay. A human operator might not notice any difference and the admin might write it off as regular network jitter. The effect is that the Receiver measures speed of incoming packets, decides which bit they represent based on delay/speed, and eventually has the data it needs to leak.

And if outgoing connections are monitored, it might send the data out to the next system over yet a new covert channel. 🙂

Resource Exhaustion Channels

This is a newer designation. The situation is the Leaker and Recipient can share a certain resource. They can each tell if there’s any more of the resource available at the moment. If the Leaker totally depletes the resource, that represents a 1. If the resource is available, that represents a 0. That simple. This is commonly memory, processor time, I/O bandwidth, file space, etc.

Conclusion

Most systems contain many timing channels and probably an assortment of storage/exhaustion channels. The definitive method of finding them is Kemmerer’s Shared Resource Matrix. There’s a steady stream of research in IDing, preventing, and/or limiting them. Most focus on automated methods. Remember that there are internal and peripheral hardware components that interact with your software, too. They might be used as channels.

It’s a problem that won’t go away so long as there are shared resources in a system that processes can manipulate to signal one another. Most system designers have no idea how to design compatible, fast, low-cost systems without covert channels. Hence, after all other security holes are closed, covert channels are likely still available to tease secrets out of the system. You’re most practical option is to mostly worry about them at the application-level during data storage or transmission. Those are most likely to be hit, esp if data leaves your system.

re certification

Certification is about marketing. You’re telling employer why they should hire you. CISSP is the most valuabe because it’s the most in demand. Even anti-CISSP, security pro’s often tell newcomers to get it just because it’s a checklist item that gets you in many doors. Certifications in other in-demand technology relavant to the job, such as Cisco, will also help. Far as actually learning, this is best achieved through books, online examples, and hands-on practice. And what your produce or demonstrate with references is the best evidence of what you can do.

Nick P • May 24, 2014 11:51 PM

@ Wesley

The DARPA program behind that included certified compilers, static analysis, separation kernels, etc. I posted some of their work here. Each greatly strengthens an aspect of the system. Unhackable is a stretch by far but the systems do employ much higher assurance methods than typical COTS offerings.

Nick P • May 25, 2014 5:29 PM

My Raspberry Pi Thinks It’s a Mainframe!
http://www.rs-online.com/designspark/electronics/blog/my-raspberry-pi-thinks-it-s-a-mainframe

Interesting port of an old mainframe OS onto a Pi. The KeyKOS capability system ran on System/370, which Hercules emulates. I’d love to see it run on a modern, cheap system.

Nick P • May 26, 2014 8:50 PM

@ Iain Moffat

It could have been. Trips me out that they had so many more options in how to build hardware. Of course, given the difference between hardware then and hardware now, fewer options was probably the better choice. Older stuff was more interesting, though, as you learn what they built and how they built it.

@ Mike the Goat

“the decision to equip the horn was not an easy one, but it had to be done.”

Maybe I’m just slow from all the work I’ve been doing recently [unrelated to security projects] but I’m not sure what the horn represents. The initial impression was being especially serious about a comment’s content. Your elaborating on it makes me think you’re talking about a guard, your SPARC machine, or a combo of them. That it comes on and off adds a layer of “huh” on top of that. I’ll move on to the other stuff you said haha.

“The plan was to have the firmware of the second horn authored by a different (and mutually untrusting) group. ”

I’d have done it if I had firmware expertise. You can always use something like Coreboot or an open source release of Open Firmware. The former has a trusted boot capability, while the later was used by Sun & has open versions online. Test it to see if it works. If it does, trim out everything you don’t need. Then, verify what it has.

“I imagine a ‘trustedPGP’ type project would have to limit the selection of ciphers and cull some of the lesser used features to reduce the size of the code base and make auditing and/or shoring things up more practical. ”

That’s what I was thinking. The NaCl and Ethos projects were taking this approach with good results so far. Keeping it simple with a secure default that works for most use cases will increase adoption as well as assurance. Developers prefer things they can use correctly with little thought.

“but as I suspect you are inferring the cons of using an 8-bit processor are numerous, especially if such a slow chip is going to be doing crypto. I can just imagine key generation! I agree that a RISCy processor would be a better and more flexible choice.”

The main drawback is it has all the key architectural weaknesses that lead to code injection, while having less performance for mitigation. It’s about the worst situation a modern coder can be in far as making something correct, usable, and secure. Hence, my focus on chips whose assembler bakes in safety, security etc with minimal impact on other metrics. The tagged (i.e. typed) and capability based systems seem ideal. Those with memory authentication/encryption, segmentation, randomized ISA’s, etc are next bet. A JX- or SPIN-style system that runs most of OS and apps within a safe runtime is next bet. An obscure OS & chip without persistent storage connected through a guard is… probably not secure upon targeted attack and is a last resort. (Hilarious enough, it was also our first option.)

Note: The DARPA SAFE team has extended their tagging unit concept into a Programmable Unit for Metadata Processing. Paper.

So, that’s my look at it. Not to mention we have open processor cores and academic one’s that might be free/cheap to license. The Amber ARM v2, Plasma MIPS, JOP, and OpenRISC processors all come to mind. Plasma site runs on Plasma, actually. OpenRISC is fastest, I think. The VAMP DLX processor was formally verified and runs at 10Mhz in basic configuration. I’m sure that the tech I mentioned can be added to open designs like these as most stuff I mentioned was already implemented on similar chips by small academic teams. Just takes people knowing what they’re doing.

Btw, I do appreciate getting some credit on your blog for the comment signature schemes. 🙂

@ all re IPv6

It was a botched implementation, but at least they tried to do something. It’s so hard to implement a big change like that. So, I’d rather it be a nearly future proof solution. The 48-bit idea might have been sufficient if the address is only used for identifying machines or users. The reason 64-bit is favored is for the “Internet of Things” and other stuff that might use a ridiculous amount of names. Additionally, it fits in the processors as others have noted. Although, the use of customized network processors sort of defeated the need for that as they changed processors to fit the problem rather than other way around.

I’d also look into changing the scheme from the prefixed scheme to another one. The scheme they use makes it easier for problems like organizations buying up class A’s. That issue shouldn’t even exist. It might be as simple as changing it where IP’s solely represent how to get the packet to a specific device. Then, devices are issued individual IP’s with prefixes being nothing but router aids. Nobody buys a whole class of IP’s: just the individual one’s they need. Then, a length increase to 48- or 64-bit prevents running out. The logical identity behind an IP is handled by another protocol(s), facilitating persistence across networks & certain security designs.

@ Figureitout

” So I think tutorials going step-by-step thru implementations is a good thing; ignoring the fact of running on hardware that may insert something or hide something, killing the security.”

Exactly.

“I’m patiently waiting for what Nick P’s design will be, but mine will be much simpler and still subject to the usual attacks that need extreme resources to repel. ”

As I said, there are several in parallel with different uses. The one’s for desktops just leverage processors similar to CHERI or SAFE with added IO coprocessor in most basic form. This prevents huge classes of errors, biggest being data running as code. Only a select few components need to be trusted for that versus… a ridiculous amount of code in most systems. Building a usable, secure system on hardware prone to attacks is actually tons harder than to build more secure hardware and leverage it. If anything, I’m doing it to save myself work and so amateurs can build software without code injections popping up all over the place.

“Since Nick P’s going for this new “memory tagging” scheme, it’s new and yet to be tested to see just how much security it actually adds or how easy it can be subverted (and then lead to a worse state, false confidence).”

It goes back to the 60’s. The concept was used in numerous mainframes, prototypes in production, and secure system designs. That I recall, none were ever compromised by an attack on that level. The argument for their security is simple: so long as types and rules are defined right, it will probably work without bypasses as it’s enforced every instruction. That’s the key advantage to these architectures.

The IBM i series is the only survivor in the market and has a good security track record far as code injections are considered despite not doing it truly in hardware anymore. Most attacks on them are due to configuration errors or application weaknesses. They’re also highly reliable, fast, support key standards/techs, and mostly manage themselves. So, doing architecture well benefits more than security & one of the best business machines in all traits uses a typed object architecture. That said, I’m pushing this as evidence these architectures work rather than what to design. It’s too complicated for a small, amateur effort. Other stuff I mentioned wasn’t, though.

“Found 2 interesting links. The first is interesting discussion on a “security thru obscurity” question on obfuscating microcode to render some pre-made attacks null.”

I’ve posted that solution here before. The people answering were smart in hardware, but not in topic area. I posted an answer of my own. Thanks for giving me the link and opportunity as a student might read it somewhere, then produce what was described to many’s benefit.

“He seems to have extensive experience on many types of attacks, that I would like to design to mitigate as much as possible, or at least detect.”

It’s Bruce’s blog and he for anyone contributing intelligent discussion. I like his stance. So, bring him. He can like us, hate us, anything in between… who cares so long as he might contribute something useful to discussions and the field. (eg reason I’m here)

The guy you linked to seems pretty awesome. Only concern I’d have is Clive scaring him off with a rant about him developing fault-injection attacks before most others, maybe ripped off by Anderson, etc. He brings it up a lot. Anyway, that Skorobogatov is one of the main guys in that field at Cambridge makes that a risk. Yet, Clive also regularly gives them credit for good work and comments on Anderson’s blog (lightbluetouchpaper). So, who knows. We’ll let Clive tell us whether or not he’d make a big deal out of it if Skorobogatov joins us in discussions on those topics.

I’ll add that fault-injection needs plenty more research. However, most of the stuff he described can be beaten in typical systems by using methods such as filters and EMSEC shields. These systems main benefit is to reduce risk when enemy is physically right on the systems, esp in case of insiders (access to computer room) or easily stolen property (eg smartcards). Chips that might have secure, immutable software could still be beaten with attacks like he described. And his field has produced plenty of useful results on the defence side. So, it’s worth more investigation.

@ Alex

“How about having a really simple (check-able) machines or component to perform encryption, instead of the latest 20 nanometers billion gates processor? This could be a fair solution.”

It doesn’t work. A guy here specializing in chip creation, verification and security laughed it off. He pointed out that tools that verify larger structures can’t even see the smaller ones. Simplest method is swapping out one for the other with identical external properties if attacker thinks your chip won’t be checked. The more advanced way is to embed the tiny logic in the larger chip during manufacture. If your not checking it at nanoscale, how would you even know it happened much less prevent it? And non-subverted chip making equipment was similarly impractical so it could be swapped or manipulated to do this stuff.

His meme for this was that once a silicon capability has been invented, you can’t uninvent it for your verification needs. If it can be used against you, it will.

@ Skeptical

“we need truly secure networks and systems, and that means security for everyone). Mind you, I’m not totally convinced by it (yet), since I do not think it’s important that lawful surveillance be possible to implement, but there’s no doubt that such an argument would be far more powerful.”

That’s a nice concession. I proposed here a high assurance lawful intercept system that protected both ends’ needs, while providing restricting LEO access to just what’s specified by a warrant. The NSA is opposed to such a design as they want “collect it all” surveillance. Their true coercion powers are unknown at this point. However, the scheme should work for any targeted order. I even added NSA-sponsored tech & evaluation by NSA-approved lab in my scheme as a preemption on any claim Fed’s make to court about scheme being untrustworthy. Icing on the cake.

So, I’ll compromise and so will many Americans. “Secure us against everyone else and safeguard us a bit against US govt,” we might say. Purists will argue but lawful intercept is the law. Noncompliant services will be shutdown. Additionally, TLA’s are already accessing many machines and accounts out there of people wanting privacy. I think it would be better to get something secure with a highly-assured, auditable backdoor than something full of backdoors & weaknesses one doesn’t know about with only assurance being they’ll be exploited.

However, NSA wants full info, control, and ability to do it covertly with ease. So, they won’t go for it. Their hand has to be forced by lawmakers. Of course, this doesn’t stop privacy advocates from working on non-LI tech in parallel. People will just use it at their own legal risk. Services wanting to be here & stay in business can use a method safer in court.

Nick P • May 27, 2014 11:35 PM

@ Wael

Oh you’re funny. I thought to Nick was to enlighten. Guess I’m not well-versed in British. 😛

Nick P • May 29, 2014 9:18 AM

@ koita

Look up the NaCl crypto library. They aim for high security, few options, and ease of use. If you want more options, check out Botan library as I’ve at least heard they have decent docs.

@ J

“2) TrueCrypt was a secret Microsoft project because they wanted to make a prototype for their future encryption software but didn’t want their technical support deluged with calls about users playing with it and losing their passwords.”

I was just about to post that scenario haha. It was the only thing that made the site’s claims sensible. My version had them being the BitLocker developers as well.

@ yesme

The Oberon compiler is an unfair comparison. Wirth designs his languages specifically to make the compiler easy to write. As in, every program you write might take more lines of code just so his language and compiler are simple. Although simplifying things is good, many developers believe he applies it to the wrong end. That the applications, not the compiler, should be simple to build. Python is an example of a language that optimizes at the other end. The language, runtime, and compilers are much more complex than Wirth’s stuff. Yet, they enable people to throw together huge programs with little code, plenty readability, good performance, and good reliability.

Otherwise, I fully agree with you.

@ Mike the Goat

I smell a rat, too.

• Nick P (Glock equipped)

Nick P • May 29, 2014 11:31 AM

@ Mr Pragma

“Wirths priority is not to keep the compiler simple so as to have an easy life as compiler builder.”

No, it actually was his priority. I’m not guessing at it: Wirth stated more than once that his main “heuristic” (his word) for language design was how long it took to compile the compiler. If the system compiled too slow, he believed it meant the language was unnecessarly complex. So, he then removed features and reorganized it. This is why, as you noted, he took out useful features from Modula’s when producing Oberon: language & compiler simplicity was the goal.

That said, he certainly had an overall philosophy of simplicity that made his work higher quality than most. We can certainly imitate that. It’s especially necessary to manage complexity in security work as unnecessary complexity leads to security flaws that would’ve been avoided.

“But to say that Python is more complex (inside) than Oberon is something that would be hard to show in any unbiased way.”

The Oberon report, which includes full grammar, takes less space than just describing the bytecodes of the Python interpreter. Then, there’s Python the language, metaprogramming, REPL, optional compilers, etc. I’m sure I can, without bias, say that Python has way more functionality and complexity than almost any language Wirth has designed. It might have more complexity than many of his combined. Yet, empirical evidence shows that people learn it quickly, they’re very productive, and have a low defect rate (source: Coverity). They’re not superprogrammers so the only explanation is Python is a well-designed language. Seeing how complex the toolchain is, that’s saying something about simplicity vs complexity tradeoffs.

And there’s no bias here as I’m from a BASIC background with some LISP thrown in. If anything, my experience was closer to Wirth languages. Seeing the power of LISP, though, I know how a more complex tool can be better than a simple tool.

” In fact, van Rossum also highly values “keep it simple”, both in Pythons surface and inside of it.”

I agree and need you to understand I’m not arguing against simplifying designs. I’m arguing against solely valuing simplicity like Wirth or Moore (Forth) do. Example: A tagged processor that uses Oberon’s types and enforces code and data separation. Wirth’s processors are typical stack machines without safety features. In the design, I keep each component as simple as I can: use a proven RISC core, small tagging unit, few typing rules, and Oberon language. Wirth’s design is much simpler.

Yet, I choose against simplicity in this case because adding tagging unit prevents entire classes of problems in all code without developer thinking about anything. If I don’t add it (simplicity), then the developers will have to correctly manage types in every piece of code they write and spot hostile constructions in 3rd party code. That’s not simple at all. Had I simplified my problem or layer, I’d just make their layer much more complicated.

See what I mean? Certain simplifying decisions can make things better for everyone. Wirth is excellent at spotting them. We can imitate this. However, many times a simplification of one part of a system (or problem) requires complicating another. My philosophy, unlike Wirth’s, is to accept the complexity any time the benefits it produces are worth it. So, I’d add tagging to hardware, maybe macros to language, syntactic sugar, and so on. Each thing makes my job, the hardware and toolchain, harder. Each one creates a performance hit. Yet, each change makes developers’ and users’ lives so much better that it’s worth going through trouble.

“A side note on Python: I very much regret that Python has become such a large beast (and I strongly assume this being one major reason for a wide spread tendency to include lua as a scripting engine in many projects).”

Yeah, it is getting huge. I’m not sure how good or bad this is given their community’s needs. I hope they aren’t falling into the trap of bloat. Good news is Stackless Python wrote Python in Python. Should help manage complexity of it very well. 😉 Honestly, though, my first idea of getting C++ out of Python was to rewrite Python in either Ada or a Wirth language. Then, the extensions would be written as modules in same safer language so they’d get type-checked and memory safe where possible.

Nick P • May 29, 2014 7:38 PM

@ Clive Robinson

I can’t remember if I posted this before. I’ve changed my thinking on our triple redundant voting schemes. I think it’s still good for correctness/reliability. However, for security against sophisticated threats I doubt it. The bug hunters looking at Chrome, for example, are now stringing five to six bugs together to produce a vulnerability and claim it’s easy. Finding the bugs won’t be hard at all even if developers are different. So, this leads me to two lines of thinking:

1. More focus on obfuscation of how and where code/data runs. ISA, scheduling, registers, stacks, memory locations, control flow targets, etc. Most of this is covered by the software diversity and randomization security research. I won’t re-hash it here.
2. Ensure the architectures are really different, including security methods and how the software works.

The second one is important because there’s many common methods of solving a problem. It’s not uncommon for several teams to do something similar, esp if they use same language. My old scheme called for separate countries, ISA’s, OS’s, runtimes, languages, etc. This isn’t enough. What’s needed is three separate schemes that are each good enough to give a serious opponent many headaches.

The simple solution is to start with the high security projects I’ve posted here in the past. One might be a SAFE processor with its tagging. One might be a Java processor. One might be a CHERI processor with control flow protection hardware. One might be a typical processor with ISA obfuscation. And so on. The best solutions to code or fault injection we have. The software running on them, as I pushed previously, would be a simplified and predictable runtime (eg separation kernel, tiny RTOS). This facilitates the timing. One might even improve the voter chip by improving its security where its functionality is immutable (ROM’d) except for the timing data, supplied via trusted port upon start-up.

Such a solution should provide real protection that properly leverages extra nodes. The use of COTS architectures and different teams might just provide an illusion of security against adversaries of increasing talent. I’m not even talking NSA: just people with spare time are getting better and better at bug finding.

re post length

You’re too funny. Yeah, my posts are getting that way, eh? Still, don’t hand the crown off to me yet. You’ve worn it so long removing it from your head might cause a medical complication. 😛

Nick P • May 29, 2014 8:22 PM

@ Mr. Pragma

I’d love to, but can’t. I did language design work years ago. I lost it and years worth of other stuff when three encrypted drives failed in succession. An alarming coincidence that’s made me afraid of HD’s. The rest was work done under NDA so I can’t share it (and frankly don’t keep it). I mainly did security engineering so I didn’t care to expand on that. A regrettable mistake now.

Anyway, I can trace my experience. I started with BASIC. I later learned Visual BASIC 6 to get first feel for RAD. A GUI app in minutes? That’s great. Extending it required me to learn C & C++ for some legacy applications. That didn’t last long. I decided they were so complex, unsafe and time consuming that I’d be better off coding a BASIC to C++ compiler that added checks & did optimizations automatically. That took a day to write in BASIC, although dealing with C++ compiler’s quirks too much more. I could then write readable, safe code that compiled fast and ran fast. And it had perfect compatibility with legacy code written in garbage language. 🙂 Closest I’ve been to a Wirth-like language.

Next thing I noticed was plenty of stuff was easy to describe in English, but not in BASIC. It simply took too much code or got incomprehensible quickly (eg nested if’s or long case statements). Pascal etc had same problem. I realized I’d be better off bringing the language up to do more work for me. As my field was automatic programming, I stumbled onto LISP to see a language so powerful & ahead of its time that I could barely wrap my mind around it. So I didn’t lol. It’s macro’s did language extension I wanted, it’s millisecond (on Pentium 2) incremental compiles didn’t interrupt my mental flow, and it allowed live updates/debugging of the program. That was on a whole different level from Pascal, BASIC, or C/C++. The small amount of it I learned greatly expanded my perspective on what programming could do.

So, my work diverged into two directions. The first step was creating an equivalent version of my BASIC in LISP. So, now I could code it interactively, debug it as such, and type one command to code generate efficient machine code. I could also apply macro’s to extend BASIC’s language without modifying my BASIC system. I think I re-implemented that part in LISP anyway to get rid of separate step. My memory is poor these days so some details are missing. I think I did selective compilation of modules so certain ones could run interactively & some were compiled for high efficiency, then linked back into the running image. I’ve been doing stuff like that a long time so hard to tell where I started with it.

The other direction was 4GL’s. Automatic programming research produced this, too. An early one was a CASE tool that took data descriptions, control flow diagrams, etc from a system designer and automatically produced entire applications in COBOL. My mind was brimming. So, I got a hold of 4GL’s and started prototyping them, too. I noticed the best of them identified the functionality a developer used 80+% of the time, integrated it into the language itself, and made its syntax easier. A single line of 4GL language might equal dozens of lines of structured programming with no real drawback in application programming. Only survivor of general-purpose 4GL’s that I’m aware of is WINDEV. Their marketing is over-the-top I will say. 😉

This doesn’t even count languages that I’ve toyed with such as Mercury, Haskell, APL, etc. They had different paradigms that I didn’t spend enough time on to really talk about. Focusing on my strong-suit, hybrid functional and imperative programming style, I’ve experienced a variety of languages and approaches. A BASIC-like 4GL or a professional LISP runs circles around structured programming languages in many areas. Just makes you waste less effort on things machines can do better.

The idea language would have best features of LISP environments, 4GL’s, and safe/efficient languages such as Wirth’s. It doesn’t exist yet. My own prototypes created solid production code, while giving me a competitive advantage against C++ and Pascal coders whose tools couldn’t keep up with their minds. The recipients never knew how the binaries or C/C++ source was generated either. They were only told I used a “highly structured development process…” run by machines acting on mostly ultra-high-level code. 🙂

Nick P • May 30, 2014 11:47 PM

@ Skeptical

Glad you liked it. Approval of someone with your views provides hope that the agencies might like it, as well. Quite a few of us have tried to compromise. I assure you they won’t stick with it unless it’s secret and facilitates their espionage. The problem it would be internationally is a good catch as that’s quite a problem. The cost of high assurance is large enough that one needs international sales to recover the costs. Most developers wanted to sell to allies (eg NATO and more harmless neutral’s). That was blocked by US govt (via NSA influence) for most of INFOSEC history so few will gamble on it.

The mostly local market that consistently buys this stuff is so niche that even an established player such as BAE’s XTS-400 is only operational at around 200 sites. International sales are necessary to get market large enough. I always thought it was funny that they didn’t want me selling high assurance terminals and firewalls to countries they sold fighter jets, bombs, sniper rifles, and hacking kits to. The funnier part is that Europe knows how to build high assurance stuff as well as we do. Nothing needed is outside the public record. Same lack of willpower or market support as here. The US agencies just want so much to spy on allies too that they will not compromise on this issue.

And so high assurance is still a charity in the general market if the company is located in the US.

Nick P • May 31, 2014 10:56 AM

@ name.withheld

I’m flexible about which FPGA. I just mentioned 3-series because development kits start at $150. Far as toolchain, there is at least one open source toolchain that could be targeted to FPGA of choice. There’s also quite a few academic ones focused on verification, performance, etc which might be licensed and targeted to it.

I totally forgot about Structured ASIC’s. Thanks for reminding me about them! They were a clever creation. The reason I’m mentioning FPGA’s is that ASIC’s are just too expensive. The intial solution will probably be done by volunteers or pro’s with small sponsorship. I’m not sure what a Structured ASIC costs but I figure it isn’t cheap either.

The verification and testing points you mentioned were interesting, too.

Nick P • May 31, 2014 11:19 PM

re Structured ASIC’s

To recap based on what the each source said. Source that is pro S-ASIC’s gives these benefits:

1. Better performance and power consumption than FPGA’s.
2. Most layers forming the device are pre-fabricated, reducing design time. One offering only required customers do one layer.
3. Vendor addresses most “signal integrity, power grid, and clock-tree distribution issues.” Reduces necessary expertise and certain tool costs for customer.
4. Use of repeated, regular structures makes it easier to put a design on a newer, immature process node technology.

5. Is feasible at production ranges of as little as 10,000 units a year. ASIC’s tend to take many times more volume to justify cost.

6. Altera’s S-ASIC conversion process (HardCopy) can convert an Altera FPGA-proven design to a pin- and package-compatible S-ASIC. Must work as it accounts for 5% of their revenues.

7. The focus on Systems, Networks, and Platforms on a chip lends itself nicely to S-ASIC’s modularity and easily redoing designs.

Source that’s anti-S-ASIC lists these criticisms:

1. Starting point is that FPGA’s got better than gate array ASIC’s, which he implies are better than S-ASIC’s.

2. S-ASIC is a scheme by ASIC vendors to pull customers from FPGA vendors.

3. The S-ASIC architecture is inefficient and unnecessary.

4. He implies there’s no trouble moving from FPGA’s to ASIC’s as synthesis tools take care of everything in minutes to hours and underlying hardware doesn’t matter.

5. Argument of popularity in that few FPGA customers turn their designs into S-ASIC’s.

6. He claims that S-ASIC’s are intended by FPGA vendors to be a safety net for customers in event that FPGA’s don’t work out. (Contradicts 2?)

7. He reiterates that some vendors don’t do it anymore, naming LSI Logic, to argue industry is against it.

8. He says the economical solution (and alternative) is to bring back the gate array. And make it have less NRE and turn-around time.

Another article makes these points:

1. Large ASIC providers had to invest plenty of resources in ensuring these worked with their backends and design flows. They didn’t.

2. Certain S-ASIC providers claimed the FPGA-to-SAIC design flow would be seemless. It wasn’t: the designs still had to be modified to be more ASIC-like.

3. Certain S-ASIC providers apparently weren’t experienced enough to deliver working designs consistently. Customers don’t like getting burned twice.

So, I’m looking at the claims. There are certain benefits. However, one must pick the vendor carefully and realize the transition might not be seemless. I don’t buy into market preference criticism as market often prefers inferior solutions for various reasons. The argument that synthesis tools eliminate the problems sounds bogus given how many projects must be modified, tested, and sometimes fail to work on ASIC. Obviously, the tools haven’t eliminated the problem. One critic essentially supports the S-ASIC approach by arguing for a similar approach (gate arrays) and the other rejects the current offerings rather than the idea.

If anything, the problem right now is that vendors overpromise and underdeliver. The tech is also only a few years old. Last I checked, the competition didn’t become No 1 overnight. There were kinks to work out, lessons to learn, etc. So, S-ASIC is promising, might be a thing in the future, and should invite caution for potential customers in the present.

@ name.withheld

Your analog loving friends might find Triad Semiconductor’s mixed signal S-ASIC’s interesting.

Nick P • May 31, 2014 11:57 PM

@ Mike the goat

Making it a cheap chip or reusing a controller is possible. However, RAID controllers parity checks might not tell us anything as parity checks are simple XORing most of the time. That’s what… one or several sets of bytes per cycle? Even a slow processor can XOR many MB/s. Crypto algorithms are usually measured in cycles per byte. AES256 counter mode on P4 iss around 27.5 cycles per byte. That means XOR parity operation is at least 27 times faster than a crypto primitive simpler than XTS mode often used on FDE. So, we’d have to test it to be sure if it’s good at both or just one.

The other issue is your speculating on hackability. Assuming you make it work, this has two risk areas. One is that you succeed, start piggybacking on their work, and then they do something that kills your effort off. The second is the use of a chip you have no internal data on leads to attack vectors on it. For these reasons, using your own chip that you’ve thoroughly understood and developed for is superior. Especially if you’re aiming for security and they weren’t.

Now, how to do that while things are still cheap? Well, one can turn to the many SOC’s that are on the market. You just need one that’s cheap in volume, integrates with a desktop, can support a disk, can support encryption, can remember configuration, and has internal storage for keys. So, I went shopping in the marketplace to see what’s already been built.

Marvell’s SATA controller jumps out due to two features:
http://www.marvell.com/storage/system-solutions/sata-controllers/

Intel’s Atoms are doing decent on crypto tests
http://www.servethehome.com/Server-detail/intel-atom-c2750-8-core-avoton-rangeley-benchmarks-fast-power/

First Freescale chip I found had accelerated XOR’s and crypto
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8548E

Any of these should be modifiable to do what you want to do. These companies are also known for affordable chips. Reuse keeps development costs down. Using a specific chip with documentation creates the benefit that you know what’s in it and control how its used. The last benefit is it (or one like it) will probably keep being available to supply your customers for some time.

@ Wael

Remember that RobertT used analog components in his designs partly to throw off those trying to understand them.