It would be interesting to throw this URL as far up the internal chain as possible... and see what happens. :P

I'm curious myself, and there are a lot of other people who wouldn't mind knowing too. Fast AND trustworthy turnkey silicon is both a completely untapped hole in tech at the moment and something that's desperately needed in this climate of NDA'd garbage-quality security systems (see https://www.devever.net/~hl/smartcards for one of thousands of examples) and increasingly locked down chipsets.

I'm not sure what else is out there, but I recently learned of RISC-V (http://www.adapteva.com/andreas-blog/why-i-will-be-using-the... ); I'll admit I was impressed to learn a free (open design) CPU has just broken the GHz barrier (http://riscv.org/download.html#tab_rocket_core), but this chip and ISA are still in the early prototyping stages, although the spec seems complete.

On the other hand, x86 is a widely (!) used, well-known ISA with a lot of legacy software running on it, and VIA already have proven CPUs and chipsets and motherboards. I only know about VIA as "the low-power alternative CPU company," so I have no idea what it's position or stance on secure applications is, but it could well net itself some unique contracts by investing in security.

One of the big problems in this space (or at least what's being made into a problem by the major chip vendors) is secure bootstrapping: I can verify the entire boot device (a 128MB boot image could read in a second or two from eMMC)... but how do I know that "I", aka the code doing the verification, have not been compromised? It's a chicken-and-egg problem.

Here's my back-of-an-envelope approach: create a CPU with a secure, write-once, write-only (executable) PROM of say 64KB (maybe 256KB? 512KB?), and ship the chips with this area blank. The customer writes whatever data they like to that area of the chip, and then the chip begins execution (ie, PC = 0, or close to it) running whatever code it finds there. Maybe you'd call this the "pre-BIOS area".

You could write a public key and a verification routine in there and use it to verify everything else the system wanted to load. Besides verifying the BIOS, which would be nice, you could verify the boot media..... bam. Trustworthy boot sequence.

This might be surprising to hear, but right now, the above is a pipe dream. It's 2016, and yet, even something as basic as this does not exist - if anything, we're moving away from such a position with the current state of things. The above cannot be done with any hardware/ISA/chipset I'm aware of. For example, the Raspberry Pi Zero (the latest one) still uses the proprietary ARM core in the GPU to handle bootup (http://raspberrypi.stackexchange.com/questions/38585/raspber...), which is basically the opposite of what I've just described here.

Whoever says "I can do this!" is going to get some interesting offers. The military can of course afford to design/get whatever they want, and fat contracts from them are always fun... but think of all the private companies that would benefit from guaranteeably secure data acquisition and/or communication... that's everything from the stock market to secure money courier vans. All that industry, taken together, amounts to a lot of (untapped!) potential. What's more, the private sector is always going to come up with ideas that would be best implemented on a secure platform, so having something "anybody" can get their hands on, rather than only playing ball within the military space, might work out more profitably.

Besides contracts, whoever does this will inevitably get a LOT of publicity from the open source movement, so they'll need to have a good department to handle that, along with the sometimes OCD-to-the-point-of-being-awkward stance that GNU takes sometimes.

There are other issues, such as running the system off entirely free-software drivers; I'm not sure where VIA's at on that front, but that would be an arguably necessary part of such a platform as this (the argument against this type of thing being that if there are Components(TM) in the hardware that can do fun tricks, said Components(TM) need to be communicated with, and that might be happening in the drivers.)

And I'd finally get to build the secure communications device I've always wanted to make. :D

(Incidentally, current smartphones are a security nightmare: https://www.devever.net/~hl/nosecuresmartphone is as non-theoretical as it gets without providing PoC explots, IMO).

[PS. Honestly not trying to big-note myself or anything - I'm just a tinkerer/hobbyist - but feel free to copy/forward this text.]