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 23, 2014 6:40 PM

@ Koita

I'd be concerned aboug intercept if the light source, beam itself, or receiver were visible. The best value I see for this is reducing attack surface. Wireless transmission without light tends to bounce and spread all over the place as if to aid enemies' antenna. Light is easier to absorb and more focused. So, less leakage in general.

Funny part is that we're coming full circle: IR ports were once a prominent method for wireless communication. It's gotten a lot faster now. For best stuff, look up Free Space Optics on Wikipedia. The project you linked is a very limited FSO, essentially.

I'll also note LEDs for communication is coming to defenders second: researchers already used it as a covert channel in the past. There's a paper you can Google on that. Actually, two: one leaking processor state incidentally; one controlled by malicious program directly for signaling purposes.

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 12:41 AM

@ Thoth

"When will Cypherpunk 2.0 take place :) ?"

Honestly, I'd rather it not. They focused almost entirely on coding software and crypto. Most attacks happen from hardware to software implementation. Better architectures and directions are known. I'd rather the next movement focus on the architecture of the endpoints to make everything else easier. There's lots for them to build on. Point being, if the devices running the "secure" software can't run software securely at architectural level, then the security is merely an illusion. And advanced resources of opponents will win out for sure.

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 11:15 AM

@ Alessandro

It is bad wording. Far as covert channels, a timing channel can be considered competing for a shared resource as they both keep trying to use it and checking how successful they are. Object reuse doesn't fit at all so it's knocked out entirely. Then an overt channel is just a normal communications channel and processes don't compete for them. Denial of service is when one or more clients flood a channel to deny service from other clients. You're defense here is it virtually never involves two processes: many more and typically distributed so often using different terminology in questions (eg "clients").

So, if it's two processes competing, the most likely is covert channel (timing or resource exhaustion). Denial of Service is a possibility, although rare on modern networks with just two processes involved. The wording *is* horrible and could cost you points. At least you have something to fire back with.

Nick P • May 25, 2014 2:23 PM

@ Clive Robinson

re covert channels and side channels

Thanks for bringing that up as I forgot to mention it. The existence of unintentional channels is important as well. Many covert timing channels that were actually exploited were entirely unintentional. Yet, they were channels nonetheless.

"The obvious problem with the definition is that, if you find a hidden channel is the sender a deliberate design or an accident... the fact that somebody has made use of it via some form of EmSec receiver does not make it a covert channel just that it is being used as one..."

That's the problem I've always had with the definitions. I call all of them covert channels. The reason is that, deliberate or not, the mechanism and result of the leak is the same to attacker. Side channels are also all generally covert if only because people can't really see them in production without plenty effort. So, I stuck with covert channels.

"Further the 73 definition considered "covert" only as hidden from the security monitors in the system"

I like that definition. That's pretty much how I've thought of it as anything is secret until someone knows about it. Yet, these channels still evade detection in practice because they're unmonitored. So, it's probably ideal definition.

@ Mike the Goat

Why has the horn been equipped? And why only one horn? Who broke the other one off!? Give me his name, location, and IP address. I promise nothing unnatural will happen to him.

re BND cracking encryption

I agree that the BND likely hit the crypto in the same ways NSA does: at every aspect except the algorithm. I've always said cryptographers focus their brains entirely too much on the primitives. The brains are needed most in the crypto constructions that apply primitives in secure ways. I'm glad Bernstein et al are taking the lead on that front in their NaCl project. We need more like that, especially in interactive protocols such as TLS.

Regarding S/MIME, I thought its concept and abstract design are OK. Naturally, I'm suspicious past that about RFC's, implementations, and how apps use it. That highly assured mail guards used a variant of it shows it can be made trustworthy enough for DOD/NSA. Thing is, though, that PGP has been built on, reviewed, etc. by contributers ranging from companies to cypherpunks. That leaves little reason to build on S/MIME. So, a highly assured version of PGP is preferrable unless someone has a good reason not to do this.

re hardware

RobertT was our insider on that market. He was clear that, other than intercepting the design, it's hard to subvert a chip at the other layers. And it should be even harder to subvert on most cutting edge process node technology. So, whatever is built should use verifiable tools, hand off design by courier to right people, be able to trust them to produce the mask, courier it to fab, and have fab produce the chip. Knocks out plenty of issues, but plenty still remain.

Issues like this are why Clive and I periodically bring up voter schemes of mutually untrusting chips. In this case, they would be made at different fabs that presumably are unlikely to cooperate on a subversion. Such a system would likely be a timesharing system rather than a real-time system. That's why I switched one of my designs to fast timesharing. It expands options I can use for initial systems. One idea was making whole system a virtual machine ported to arbitrary chips and whose code can also be re-arranged internally. This means we're not strictly relying on the chip itself. Scheme has its own issues.

" I am thinking along the lines of a Z80 clone - easy enough to organize fan, easy enough to verify and not too many places for anything malicious to hide."

I disagree. If we're starting from scratch, build a simple RISC processor with tagging or capability addressing. SAFE and CHERI both show it takes little hardware to accomplish, while providing massive & flexible protection. So, a simple system with such a modification should be the goal. I've also added dedicated I/O processor to my requirements to eliminate effects of tons of interrupts, make tagging to/from devices seemless, and isolate their memory access.

Right choice of components would simplify this by keeping each component simple except for RISC core. That's inherently more complex than most things, yet could be shared for any components doing processing: main CPU, I/O coprocessors, crypto engines, app-specific coprocessors, etc. And good news is OpenCore's site already has most of the components people need. Examples of implementing tagging/capability units can be found in the open specs of DARPA clean slate efforts and in the big Capability Based Systems ebook online.

This is all easy to do for knowledgeable people if the target is FPGA's or ASIC's. That small teams with little hardware experience are producing working prototypes under DARPA says plenty to that affect. If you're using TTL's, etc I'm not sure how easy it will be. I know the System/38 capability architecture was built out of IBM's version of TTL's. That's hopeful as it was a brilliant architecture for its time with many good properties. The Burrough's tagged architecture (1961) is said to use "discrete transistor logic," although I'm not sure what that implies about implementation on TTL's. And it was a mainframe.

These are much more complex than the simple tagged/capability architecture I mentioned above. That is necessarily more complex than a Z80 clone. Yet, if we don't solve the POLA & code vs data problem at the hardware level, it's pushed onto developers above the hardware. And we've seen what that's led to in both proprietary and FOSS solutions, haven't we? Whoever designs the next stack has to get this stuff right that one time. Otherwise, they're expecting their users to get everything right every time.

@ Mr Pragma

Good call as all the firmware is the reason I decided against using the old machine I bought in any connected application. I told people here that these are best used behind an assured guard. Mike has a particularly clever one. Clive has his thing. My design is a cross between a network guard and NRL's Pump, but with no DMA. And it and the air gapped machine check each other.

Regardless, the problems only exist if the machine is connected. The machine can still be used for all kinds of stuff it it's unconnected. The common case is to produce signed data on the machine, such as executables or documents, then put them onto write-once media to transfer to connected machine. The guards and such allow them to safely receive data, albeit don't guarantee the data will have no effect. At least that allows people using same program (eg GPG) to communicate with each other over Internet, but with manual steps. This would necessarily be used for stuff that demands the extra protection.

Regarding usability, I think you would be surprised. One of early attempts at usable, older than subversion, hardware was a Mac laptop from around 2003. Most subversion efforts I've seen were 2004 up so I gambled on this. Most early Mac laptops didn't have built-in Wifi & seller didn't list it so I assumed it didn't have it. (Rule: never assume). First boot I discover I'm online as convenient Rendevous system turned on wireless, found an open network somewhere, and connected. So, that system is burned (sigh).

Yet, it did provide an opportunity. I decided to use it as an untrusted, backup system in event main machine fails. I tested it on various sites, including YouTube, to see it worked fine if a bit laggy at times. There's Linux's and software of all sorts (even VLC) for PPC so the 2003 machine is beyond usable. There's people doing similar stuff on even older x86's with Linux distro's designed for it.

Now, one can use even older hardware if he or she is willing to trade the Web away for the Internet. The modern Web takes tons of HTTP, Javascript, SSL, Flash, etc. The "Internet" came before it. It supported basic HTTP/HTML, email, IRC, Usenet, music, movies, pictures, business apps, client-server, P2P, and more. That's quite usable, although the machine won't participate in the apps/services of the masses.

And one can run an entire business on such systems if they use two separate machines for each user: trusted, limited system for business critical (and confidential) stuff; untrusted, Web-enabled system for the benefits it brings. Web would mainly be used for emails, research, etc. I've built things like this. I often used a KVM switch for end user convenience and included a guard to safely release information from business network to untrusted network. Designed right, the delay from the guard is 30s-1m. That's bearable.

I also discovered that the concept can be pushed further back in time. Steve Job's NEXTSTEP 3 demo shows a system that's quite usable today if we're focusing it on critical data. It has GUI, multimedia, email, networking, ease of use features, minimal resource requirements, etc. The date is 1992. So, anyone willing to port GPG, some guard drivers, and an Oberon compiler to NextStep can work on a quite usable air-gapped machine. And anyone homebrewing a system with minimal resources has some inspiration as to what can be achieved with early 90's technology.

And if you don't need graphics... well, I'm sure you can see where this is going. There's plenty of options going further and further back. Just depends on what price people will pay for subversion resistance, verifiability, usability, etc. Lots of tradeoffs to leverage until more secure architecture is designed, produced, and (somewhat?) validated.

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 26, 2014 8:59 PM

@ Wael

re key reuse

There's a lot of research showing it destroys stream ciphers and OTP's. There were issues with it in public key crypto that led to countermeasures. I'm not sure about block ciphers. I'd ask a cryptographer who was involved in actual breaking efforts such as AES competition. (Maybe Bruce will shed light.) Be sure to be clear that you're not talking about one time pads or stream ciphers. You want to know about block ciphers, with the mode being a common one.

Note: they also have an initialization vector that must change much like stream ciphers' keys.

My policy has been "Why take the risk?"Additionally, there's tricks like generating temporary keys using master keys combined with public data (eg counter or nonce). So, even without generation or exchange of random numbers for sessions, one can get pretty far with simple mechanisms so long as a pre-shared master secret exists.

Nick P • May 27, 2014 2:33 PM

I decided to take a closer look at IPv6 situation. I figured some of my points might be off as I haven't used it in years. My first mistake is that I thought it was 64-bit addresses: it's 128-bit. That's indeed ridiculous because 64-bit is vastly more than enough. It's hard to believe anything over 64-bit is necessary given that supercomputing vendors believe 64-bit will be enough for *them* for decades.

So, let's look at potential benefits to be fair. The Wikipedia article list these:

1. Address space issues for 32-bit. Main IPv6 benefit here is it makes end-to-end reachability happen without worrying about issues such as NAT traversal. NAT approaches simply cause too many headaches to justify. There's entire libraries and protocols designed just to deal with this. One little change in IP and all that can start going away. So, I'm for a change that eliminates both address exhaustion *and* NAT being a necessity. I'm including ports they cause headaches for me.

2. Multicasting instead of broadcasting. This is useful and many IPv4 networks are using hacked solutions to achieve it. That's usually a sign that the protocol should be changed. I'm not saying it's necessary: just convenient for many IP networks.

3. Stateless address autoconfiguration. Automatic host configuration. So far has been an added layer on top of IPv4 layer, although it's an IP-specific concern. Putting a form of it into IP itself makes sense. My own preference is to isolate such stuff for security/reliability purposes. Most networking stacks don't care about my preferences, though.

4. Network-layer security. Building network layer security into the network rather than as an optional layer on top has benefits. Many think it's the only sensible thing to do. Other's say it's unnecessary or just hate IPsec. I have no comment except to say putting protection features into IP by default makes a lot of sense for many reasons.

5. Packet processing by routers. Simplified header, no fragmentation, and no checksum. These should improve router efficiency.

6. Mobile IPv6 routing is better than mobile IPv4 routing. There's a lot of academic research and commercial work in this area. It would be nice to have a standard in most devices that solves this problem. Although, this is lower priority to me.

7. Options extensibility. Reduce odds of future protocol rewrite. I've always pushed for making protocols easier to upgrade. The alternative is hacked solutions on top, bottom and all around them. HTTP & FTP come to mind. So, extensibility is a necessity.

8. Jumbograms. Improve performance over certain links. A convenience feature for the big pipes I imagine.

So, quite a few benefits for endpoints and middlemen. The biggest problem here, as Mr Pragma notes, is that they're practically throwing away all the old stuff and forcing a complete redesign on network. The best criticism of that is by Bernstein:

http://cr.yp.to/djbdns/ipv6mess.html

Bernstein, Pragma, and I all agree that the IPv6 solution is harder to adopt than an IPv4 replacement should be. I could easily imagine extensions to IPv4 that extend address space, enable efficient routing, etc. without causing these problems. The main goal should've been compatibility, solving most critical problems, and forced yet non-disruptive migration. IPv6 doesn't meet these requirements. Instead, it forces an all or nothing game on the Internet that few are willing to play.

That's why it's a failure.

@ Mr Pragma

There were alternatives that tried to redo things in a way that would make distributed computing much easier. Tanenbaum et al's Globe project is a nice idea. There were even papers showing how it could do Web stuff better than the web, along with distributed applications. And it didn't need IPv6 to accomplish such things. I say if someone wants to throw much of the Internet out they should (like Globe team) offer a compelling reason to do it. Otherwise, they should just fix it while changing as little of it as possible.

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. :P

Nick P • May 28, 2014 11:33 AM

@ Clive Robinson

Interesting. I looked up the platforms it's on. The Linux version supports quite a few architectures. Funny that the Alpha architecture was supported long before ARM. Two recent projects, a certifying compiler and a tagging engine, also used Alpha ISA for their work. Goes to show that there's something about those Alpha processors that makes people just not want to let go of them.

Nick P • May 28, 2014 8:54 PM

What do people think of the truecrypt site? This is a pretty interesting statement:

"The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP."

They don't show anything of their old site. Just migration and a statement that it's not secure. And an implication it was funded by or depended on Microsoft. First thing I thought is they might have been hacked to put something on site to drive people away from Truecrypt. Then again, it might be exactly what it appears to be. Strange, strange.

Nick P • May 28, 2014 9:16 PM

@ Thoth

My concern exactly.

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:22 PM

@ Mr Pragma

Compile time is partly influence by bad language decisions. The other thing it's influenced by is what the language does for you and how the compiler itself is written (eg 1 pass vs multipass). An Ocaml programmer wouldn't want to drop to Oberon as many things that are safe and easy in Ocaml would be more difficult and take more code in Oberon. That's because Gallium team (led by brilliant Xavier Leroy) sacrificed a certain amount of simplicity to make the language more powerful, leading to more concise and still fairly simple programs. And nice extras like functional programming, DSL's, fast code, etc. Their compiler has decent performance, too.

And my LISP system allowed me to develop at whatever level I wanted to, extend the language with macro's, etc while still compiling extremely fast. Matter of fact, I could compile one function at a time into a live image and even debug a running program. Building a tool like that with native performance isn't simple at all. Yet, the programmer is better off for it and going back to a mere structured programming language is pain. One LISP even has strong types. :)

So, compile speed isn't a good indicator of whether language is good. Might have been for procedural, structured programming languages in Wirth's day on old hardware. My theory says there's an optimal tradeoff between simplicity and complexity at each point. The languages that let me get stuff done fastest are more complex than Wirth's most complex language. I put simplifying and enhancing the whole development process above simplifying the language grammar or compiler. So, I think we can make better tradeoffs than Wirth's by putting a bit more power in the language. Just need to cut it off at a point where it starts getting too big.

And ensure it has clean, consistent design. That's another positive point from Wirth (and others) that greatly aids compilation speed and programmer comprehension.

re processors

Wirth's first machine, Lilith, used a custom CPU. He built a stack machine similar to P-code. Later, he just used COTS processors and ported the System part to them. And most are register-based including moving function arguments through registers (i.e. register windows). Their ISA's are inherently unsafe without POLA or ability to prevent data being treated as code. Wirth, like any other user of these, must somehow make sure his software never does that under any circumstance. Even when arbitrary code is loaded via 3rd party software. Let's just say that's hard enough that the first vid I found of latest Oberon OS (Active Oberon 2 Bluebottle) was someone doing a vanilla exploit on it. ;)

"Most importantly though, this has little to do with Oberon."

I was attacking Wirth's simplicity over everything mantra, not Oberon. I even said my hypothetical CPU was customized for Oberon ("Oberon types"). Wirth's processors are customized for Oberon and typeless. So, this was a fair comparison. Wirth's thinking simplicity triumphs all leads him to choose an unsafe architecture as mentioned above where programmer at various levels must watch out for every little thing. The language helps, but doesn't eliminate the coding concerns. A processor enforcing type safety for basic types *per instruction* catches most illegal operations instantly whether programmer knew of them or not. Almost every common form of code injection becomes impossible without further effort, with others constrained a bit. POLA is also easier to achieve as objects are just user-defined types in Oberon and most tagged achitectures support software-defined tags. That's compartmentalization at object-level, enforced by hardware, and with no kernel mode there for bypass.

So, my solution was superior for developer despite adding complexity in form of tag checking. Now, how much harder is such a chip to build? Several academic groups have thrown together working SOC's with tagging support on a limited budget so it's probably easy enough. The SAFE team got their CPU, along with new languages & tools, running on FPGA's in about 2 years. Theirs is the most complex to date out of academia with things like garbage collection support, software-defined types, and HLL system code. That puts an upper bound of 2 years on these things for a good feature set. (Wirth's initial Lilith board took similar time.) A simple CPU + tagging unit with predefined types would probably be much easier than SAFE, taking months to a year. So, my solution wasn't simpler: just better for a number of practical reasons.

And Wirth wouldn't have done something like that because it contradicts his philosophy. And his users would've paid the price when the bugs and hackers came a knocking. That's the problem with relying exclusively on his philosophy, methods, and tools in security engineering. They're a start to a real solution at best.

"I'm also somewhat afraid that trying to solve to many problems at once risks to have one tinkering and reasoning eternally. "

A person can take it too far. Yet, there are often many variables to optimize for in a project. What pre-existing I.P. can we integrate to save time with what constraints? What languages are allowed? What external interfaces? What performance? And so on. Once the problem is properly defined, the path to the solution is much easier.

"Granted, Wirth has, seen from our perspective, gone too far in terms of simplicity but I also feel that your approach needs quite some more refinement, too "

You're absolutely right. That's why you see me exploring many things. I'm continually trying to improve and/or refine my approach to solving these problems. I'm running several in parallel on hardware end because the situation justifies it. The attacker's end has been thoroughly explored, hardware-software security has had few resources, and I don't want to miss a possibility. Especially while I'm free to make mistakes & changes without affecting a real product in development.

"I feel humble and a need to be very careful and to profoundly think before criticising that man."

He's a bright guy. It has no effect on whether or how I'll criticize a decision of his, though. Scientific method dictates we judge the work, not the guy. I know how Wirth thinks, what his priorities are, what he's done, and so on. He's accomplished plenty in that I've given him plenty of respect here and promoted some of his work. Yet, given my expertise in security and systems engineering, I can see plenty of potential improvements esp at hardware and language levels. It's because my goals and requirements are different. In some ways, his work doesn't meet them. So, I point this out to signal the next group with similar goals as myself to know what to look out for or possible improvements.

Most developers want productivity, maintainability, safety/security, an ecosystem, and performance. An optimal decision that balances these must be made. It's often not the simplest one because our needs often aren't simple. :( One can accomplish a baseline of work (maybe) with the simplest option. I'm not aiming for the minimum, though: I want my tools to give me the best results as quickly and reliably as possible. So, people in my boat must make different tradeoffs than a guy whose work is designed to explore simplicity of hardware/software and teach students. ;)

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. :P

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:54 AM

@ Mike the Goat

re Custom disk encryption boards

Funny you ask about IME's. There was this proposal from 2009 about inline disk encryption for confidentiality & quick erasure. ;) Clive and I have fleshed out a number of variations on it here over the years. My prototypes, like most at the time, used VIA Artigo boards due to how cheap they were and their Padlock Engine. Padlock accelerated common algorithms along with an onboard TRNG. That it was x86 meant using it as a coprocessor didn't require things like changing endianness. Anyway, that work is long gone but certain traits in my posts can be copied.

Let's start with a variation of my old design that's *not* an IME. It's operating system specific. The idea is to put a secure coprocessor (eg Padlock) on the system with access to main memory and internal memory. Using Truecrypt as a reference, even for actual code, one puts a full disk encryption solution onto the coprocessor. The coprocessor is activated at boot, with option to keep the key or demand password on startup. Coprocessor has a trusted path in form of pinpad and LCD. So, this works just like TrueCrypt except the crypto is isolated and accelerated. The zeroize button can be helpful as well.

Next version is an IME. NSA's was my reference. Another with a picture of interface. The IME's main benefit is it's OS neutral. The lesser known (and really best) benefit is it takes OS out of TCB of encryption scheme. The drawback is the entire thing is going to be custom if it's to be secure and meet performance of today's drives. That's read speed, write speed, latency, and transparent encryption. The encryption method, if integrity protection is included, will likely have overhead that the IME hides from OS by simply showing less space available on disk.

Note: They also cost more than software disk protection. Those meeting NSA's standards, incl. MILSPEC and TEMPEST, are usually around $8,500. Comes down to approx $7,000 if you buy at least 1,000 of them. Hopefully, we can do better if we leave off MILSPEC, TEMPEST, and a defense contractor sized profit margin. ;)

The design for this starts as a board with two connectors, a main CPU for disk driver + mgmt, ROM, RAM, a serial port for trusted path, a simple device that plugs into it, and an FPGA to implement both high-speed I/O mgmt & encryption. The main CPU directs the FPGA. Trusted path is used for authentication and status. Once key is generated (eg from password), it goes into the FPGA. Any memory involved in setting up the crypto is wiped after initialization. This allows total erasure of all data on drive simply by issuing a command to FPGA to kill the key. CPU can range from a low-power RISC processor to a high security processor depending on needs. A 3-Series Xilinx FPGA should be used for prototyping to enforce low costs, while an anti-fuse FPGA should be used for production version.

A few quick additions. The FPGA should be setup as a pipeline with separate I.P. cores doing data encryption, data moving, etc. This way it happens in parallel and nothing is ever waiting too long. Ensures throughput. Also, there should be a command that causes IME to release an encrypted version of master key for file system. Backups can also be done to other media, combined with secure backup technology, just in case. I mean, to OS it's all plain text anway so that shouldn't be a problem. I just can't underemphasize the importance of the phrases "make backups" and "media that's not hard disks." I've lost too much work to want someone to experience the same. And the first batch of these things will *not* be reliable. ;)

A few boards here with small size, plenty I/O and a huge FPGA.

The third evolution of it was a drive enclosure. I mean, the IME probably would've been an drive enclosure anyway. I'm talking more on the lines of being able to swap disks out of it easily. This led to idea of a secure, self-encrypting, external hard disk. The enclosure would contain the IME. The use of an external enclosure also gave opportunity to put trusted path on the enclosure itself. One example. I think it can be improved plenty.

A fourth variation I just came up with is for the backups. Let's say a series of these things is in use: main system drive, external drives for extra storage, and backups done onto DVD-R's. One can potentially make an embedded system that receives the data, encrypts it, and burns it onto a number of DVD-R's. It can reconstitute them later. I'm not sure how necessary this one is. I just recall doing it manually for hundreds of DVD's and it was a P.I.T.A. Like the other systems, the master keys should be blackened and exported so another device can recover the data upon failure.

Nick P • May 30, 2014 11:18 PM

@ Mr Pragma

"Prof. Bernstein seems to have understood that. He may speak for or against something but it's obvious that he always speaks HIS mind -- and that creates trust.
One can argue with him or like his views but, no matter what, one knows that he speaks HIS mind and not the interests of others."

That's a *very* good point you bring up. I agree on Bernstein. This is also my style although I'm more for compromise on some issues just to get something done. (Sensible compromises, not BS defeating whole purpose.) I've always believed that I should be able to build a certain amount of trustworthiness if I continue to be myself, stay on my principles, and promote what I believe regardless of its popularity. I've pissed plenty of people off and missed plenty of financial opportunities because I stick with my principles. If I didn't think it was secure, I wouldn't put my name on it or even participate in it when security was a stated goal.

My way of judging people, for performance or trustworthiness, is always by character. I look at statements, actions, and consistency. I expect a certain amount of failure or BS. "To err is human." Overall, though, the most trustworthy person is he or she who consistently acts over time in accordance with their principles. The principles might be good or evil, but so long as action matches words one can trust future behavior to be whats expected. Such people, with good principles I'll add, are the best people to have on security projects like those proposed here. It reduces the odds of the worst risk of all: trusted insiders being anything but trustworthy.

@ Clive Robinson

I was considering making the device trusted for key material for practical reasons. Usability, mainly. I agree that it isn't ideal. Far as smart cards, that's a decent idea. You already know I like leveraging highly assured tech, even smart cards, where possible. Remember my "high assurance authentication server" that was just a pile of smart cards and a load balancer in a box? ;)

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:32 AM

For anyone following hardware discussions, here's a great article talking about Structured ASIC tech that compares those vendors among each other and S-ASIC's against other tech's.

http://www.soccentral.com/results.asp?CategoryID=488&EntryID=19387

I found it enlightening. I guess Structured ASIC might be my new end goal seeing that most of my abstract designs fit into FPGA's. FPGA's for prototyping or limited release production, Structured ASIC's for large production at lower cost/complexity.

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.

Nick P • June 2, 2014 12:02 PM

@ Mike the Goat

The specs are impressive. They probably have accelerators like I mentioned that they don't list. I'm all for trying to hack on such things in spare time. Just not for a production system unless device was designed for such flexibility. Examples include PS3's "Other OS" option, SOC's that use vanilla hardware with customized firmware/software, etc. Lessens some of the risk.