Schneier on Security

Nick P • December 13, 2013 8:25 PM

How Johnny can safely program Satan’s computer: Survey of hardware/software architectures that protect software

Bruce Schneier called for ways for people to take back control of the Internet and their computers. I’ve often claimed most solutions wont work because the endpoints aren’t safe. This requires dealing with so many issues in hardware, firmware, software, etc. most people don’t know where to begin. That’s where I come in: I’ve kept track of all the work in that area. These papers mainly focus on methods of making systems that are secure/safe/correct ground up, in a pervasive way or against many classes of attack. Extra links are occasionally thrown in for inspiration or historical value.

I hope these keep everyone busy for months building new hardware/software architectures and other things I can’t imagine at the moment. 🙂

DARPA Clean Slate Program projects

OpenFlow: Networking redefined. Already deployed in a cloud provider if I recall correctly.
http://archive.openflow.org/wp/learnmore/

SAFE – A Clean-slate architecture for secure systems by Chiricescu et al.
http://www.crash-safe.org/sites/default/files/ieee-hst-2013-paper.pdf

“the goal of SAFE
is to create a secure computing system from the ground up.
SAFE hardware provides memory safety, dynamic type checking,
and native support for dynamic information flow control. The
Breeze programming language leverages the security features of
the underlying machine, and the “zero kernel” operating system
avoids relying on any single privileged component for overall
system security. The SAFE project is working towards formally
verifying security properties of the runtime software. ”

(Nick’s note: I’m more interested in the SAFE hardware than the rest of the system. It’s so radical that adoption might be hard even for geeks. So, I’ve been thinking of combining it with a type safe imperative language soon as hardware is beyond alpha stage. )

CHERI a research platform deconflating hardware virtualization and protection 2012 Watson et al
http://www.csl.sri.com/~neumann/2012resolve-cheri.pdf

“CHERI’s hybrid capability model provides fine-grained compart-
mentalisation within address spaces while maintaining software
backward compatibility, which will allow the incremental deploy-
ment of fine-grained compartmentalisation in both our most trusted
and least trustworthy C-language software stacks. We have im-
plemented a 64-bit MIPS research soft core, BERI, as well as a
capability coprocessor, and begun adapting commodity software
packages (FreeBSD and Chromium) to execute on the platform. ”

(Nick’s note: Ross Anderson’s Cambrige people and Neumann’s SRI people are teaming up on this one. Like SAFE, they’ve already got prototypes and open works you can toy with. Unlike SAFE, this one is more like old segmented/capability architectures which gives them a route for legacy compatibility and low developer training time.)

End of DARPA Clean Slate list

Papers from DARPA’s earlier OASIS program for intrusion-tolerant apps, systems and networks

Boeing Phantom Work’s OASIS Contribution
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA425566

“This document summarizes the results of the Boeing team’s survivable JBI design effort. The objective of the effort was to develop the design for a JBI system that can operate through sophisticated adversary attack, and yet scale well to wide-area networks. The system design approach ensures that the intrusion tolerance mechanisms do not significantly degrade performance, while still tolerating compromised components. For the system to be deployable and the results to transition to real systems, the performance cost of providing intrusion tolerance must be contained. The design trades opted for solutions that preserve system performance. The final report includes a section on the system design, a summary of system requirements and a concept of operations, design details and a summary of project accomplishments, planning documentation, lessons learned and a conclusion.”

(Nick’s note: My early favorite because it uses many Orange Book era tricks with modern components like Spread. It’s byzantine fault tolerance tradeoff is particularly clever and so is it’s survivability grammar auto-config trick.)

Intrusion Tolerant Software Architectures 2001 Stavrido et al.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.141.533&rep=rep1&type=pdf

“Intrusion tolerance is a new concept, a new design paradigm, and potentially a new capability for dealing with residual security vulnerabilities. In this article we describe our initial exploration of the hypothesis that intrusion tolerance is best designed and enforced at the software architecture level.”

Intrusion-Tolerant Architectures:
Concepts and Design 2003 Verissimo et al.
http://www.di.fc.ul.pt/~nuno/PAPERS/archit-depend-sys-03.pdf

“There is a significant body of research on distributed com-
puting architectures, methodologies and algorithms, both in the fields of fault tolerance and security. Whilst they have taken separate paths until recently, the problems to be solved are of similar nature. In classical dependability, fault tolerance has been the workhorse of many solutions. Classical security-related work has on the other hand privileged, with few exceptions, intrusion prevention. Intrusion tolerance (IT) is a new approach that has slowly emerged during the past decade, and gained impressive momentum recently. Instead of trying to prevent every single
intrusion, these are allowed, but tolerated: the system triggers mechanisms that prevent the intrusion from generating a system security failure. The paper describes the fundamental concepts behind IT, tracing their connection with classical fault tolerance and security. We discuss the main strategies and mechanisms for architecting IT systems, and report on recent advances on distributed IT system architectures.”

An architecture for an adaptive intrusion-tolerant server 2002 Valdes et al.
http://www.csl.sri.com/~valdes/DIT_arch.pdf

“We describe a general architecture for intrusion-tolerant en-
terprise systems and the implementation of an intrusion-tolerant Web
server as a specific instance. The architecture comprises functionally redundant COTS servers running on diverse operating systems and platforms, hardened intrusion-tolerance proxies that mediate client requests and verify the behavior of servers and other proxies, and monitoring and alert management components based on the EMERALD intrusion-detection framework. Integrity and availability are maintained by dynamically adapting the system configuration in response to intrusions or other faults. The dynamic configuration specifies the servers assigned to each client request, the agreement protocol used to validate server replies, and the resources spent on monitoring and detection. Alerts trigger increasingly strict regimes to ensure continued service, with graceful degradation of performance, even if some servers or proxies are compro-
mised or faulty. The system returns to less stringent regimes as threats diminish. Servers and proxies can be isolated, repaired, and reinserted without interrupting service.”

Intrusion tolerant server infrastructure 2001 O’Brien
http://www.tolerantsystems.org/SantaFePres/Dick_OBrien.ppt

“Uses network layer enforcement mechanism to reduce intrusions, prevent propagation of intrusions that occur, provide automated load shifting upon detection, and support automated srver recovery.”

Malicious Code Detection for Open Firmware Adelstein et al
http://www.cs.cornell.edu/~kozen/papers/acsac.pdf

“Malicious boot firmware is a largely unrecognized but significant security risk to our global information infrastructure. Since boot firmware executes before the operating system is loaded, it can easily circumvent any operating system-based security mechanism. Boot firmware programs are typically written by third-party device manufacturers and may come from various suppliers of unknown origin. In this paper we describe an approach to this problem based on load-time verification of onboard device drivers against a standard security policy designed to limit access to system resources. We also describe our ongoing effort to construct a prototype of this technique for Open Firmware boot platforms.”

(Nick’s note: Mac’s use open firmware. Another thread many of us decided to get old hardware to reduce odds of it being subverted. Tech like this might be useful for such machines.)

Integrity through mediated interfaces by Balzer
http://www.tolerantsystems.org/SantaRosa/Integrity_Through_Mediated_Interfaces.ppt

Intrusion Tolerance by Unpredictable Adaptation 2002 Pal and Sanders
https://www.perform.csl.illinois.edu/itua.html

(Nick’s note: I provide a link to their publication list rather than a paper. They have a ton of stuff that’s superceded the original paper.)

Recovery Oriented Computing (ROC):
Motivation, Definition, Techniques, and Case Studies Patterson et al.
http://www.cs.berkeley.edu/~pattrsn/papers/ROC_ASPLOS_draft4.pdf

(Nick’s note: This is NOT part of OASIS. I included the ROC paper because its techniques can be used for similar purposes if modified a bit.)

Updated presentation on ROC 2012
http://www.cs.fsu.edu/~awang/courses/cop5611_s2012/roc.ppt

End of OASIS and ROC list

Uncategorized papers on higher security architectures

Hardware Architectures for Software Security
Edmison
http://scholar.lib.vt.edu/theses/available/etd-10112006-204811/unrestricted/edmison_joshua_dissertation.pdf

(Nick’s note: I haven’t read this yet. I saw it when I was nearing publishing this list. However it had references to several things on my list so I figured it might have decent ideas in it.)

Secure Virtual Architecture: A Safe Execution Environment
for Commodity Operating Systems Criswell et al 2007
http://llvm.org/pubs/2007-SOSP-SVA.pdf‎

“This paper describes an efficient and robust approach to
provide a safe execution environment for an entire operat-
ing system, such as Linux, and all its applications. The
approach, which we call Secure Virtual Architecture (SVA),
defines a virtual, low-level, typed instruction set suitable for
executing all code on a system, including kernel and applica-
tion code. SVA code is translated for execution by a virtual
machine transparently, offline or online. SVA aims to en-
force fine-grained (object level) memory safety, control-flow
integrity, type safety for a subset of objects, and sound anal-
ysis. A virtual machine implementing SVA achieves these
goals by using a novel approach that exploits properties of
existing memory pools in the kernel and by preserving the
kernel’s explicit control over memory, including custom al-
locators and explicit deallocation. Furthermore, the safety
properties can be encoded compactly as extensions to the
SVA type system, allowing the (complex) safety checking
compiler to be outside the trusted computing base. SVA
also defines a set of OS interface operations that abstract all
privileged hardware instructions, allowing the virtual ma-
chine to monitor all privileged operations and control the
physical resources on a given hardware platform. We have
ported the Linux kernel to SVA, treating it as a new archi-
tecture, and made only minimal code changes (less than 300
lines of code) to the machine-independent parts of the kernel
and device drivers. SVA is able to prevent 4 out of 5 mem-
ory safety exploits previously reported for the Linux 2.4.22
kernel for which exploit code is available, and would pre-
vent the fifth one simply by compiling an additional kernel
library. ”

(Nick’s Note: A good interim solution. Could be even stronger combined with a safe coded OS.)

Memory Safety for Low-Level Software/Hardware Interactions
2009 Criswell et al SVAOS
http://llvm.org/pubs/2009-08-12-UsenixSecurity-SafeSVAOS.pdf

“We have added these techniques to a compiler-based vir-
tual machine called Secure Virtual Architecture (SVA),
to which the standard Linux kernel has been ported previ-
ously. Our design changes to SVA required only an addi-
tional 100 lines of code to be changed in this kernel. Our
experimental results show that our techniques prevent re-
ported memory safety violations due to low-level Linux
operations and that these violations are not prevented by
SVA without our techniques. Moreover, the new tech-
niques in this paper introduce very little overhead over
and above the existing overheads of SVA. Taken together,
these results indicate that it is clearly worthwhile to add
these techniques to an existing memory safety system.
”

(Nick’s note: Follow up paper I just got a hold of Thursday. Seems they cover “processor
state manipulation, stack management, memory mapped I/O, MMU updates, and self-modifying code
” threats to safety with benefits to control flow integrity too.)

Safe to the Last Instruction: Automated
Verification of a Type-Safe Operating System (Verve) Yang and Hawblitzel
https://research.microsoft.com/pubs/122884/pldi117-yang.pdf

“Typed assembly language (TAL) and Hoare logic can verify the
absence of many kinds of errors in low-level code. We use TAL and
Hoare logic to achieve highly automated, static verification of the
safety of a new operating system called Verve. Our techniques and
tools mechanically verify the safety of every assembly language
instruction in the operating system, run-time system, drivers, and
applications (in fact, every part of the system software except the
boot loader). Verve consists of a “Nucleus” that provides primitive
access to hardware and memory, a kernel that builds services on
top of the Nucleus, and applications that run on top of the kernel.
The Nucleus, written in verified assembly language, implements
allocation, garbage collection, multiple stacks, interrupt handling,
and device access. The kernel, written in C# and compiled to TAL,
builds higher-level services, such as preemptive threads, on top of
the Nucleus. A TAL checker verifies the safety of the kernel and
applications. A Hoare-style verifier with an automated theorem
prover verifies both the safety and correctness of the Nucleus.
Verve is, to the best of our knowledge, the first operating system
mechanically verified to guarantee both type and memory safety.
More generally, Verve’s approach demonstrates a practical way
to mix high-level typed code with low-level untyped code in a
verifiably safe manner. ”

(Nick’s note: another advance for formal verification. They verify type safety down to assembler code for most of it. Work like this would be much easier if the processor itself supported more secure or safe execution. Other papers in this collection for that. Mix and match ideas people.)

A Java Operating System as the Foundation of a Secure Network Operating System 2002 Golm et al (JX)
http://www4.cs.fau.de/Projects/JX/publications/jx-sec.pdf

“We present the architecture of the JX operating system,
which avoids two categories of these errors. First, there are
implementation errors, such as buffer overflows, dangling
pointers, and memory leaks, caused by the use of unsafe
languages. We eliminate these errors by using Java—a type-
safe language with automatic memory management—for
the implementation of the complete operating system. Sec-
ond, there are architectural errors caused by complex sys-
tem architectures, poorly understood interdependencies
between system components, and minimal modularization.
JX addresses these errors by following well-known princi-
ples, such as least-privilege and separation-of-privilege,
and by using a minimal security kernel, which, for example,
excludes the filesystem.
Java security problems, such as the huge trusted class
library and reliance on stack inspection are avoided. Code
of different trustworthiness or code that belongs to different
principals is separated into isolated domains. These
domains represent independent virtual machines. Sharing
of information or resources between domains can be com-
pletely controlled by the security kernel. ”

(Nick’s note: It’s TCB is quite small and it can leverage existing Java tools/talent. I’ve previously mentioned combining it with a Java processor for a hell of a TCB. Maybe a tool like Jython to make it even more usable/productive on top of that.)

More JX links:
http://www4.cs.fau.de/Projects/JX/publications.html

Extensibility, Safety and Performance in the SPIN Operating System Bershad et al
http://www.cs.ucr.edu/~harsha/teaching/Fall2012/CS202/readings/spin.pdf

“This paper describes the motivation, architecture and per-
formance of SPIN, an extensible operating system. SPIN
provides an extension infrastructure, together with a core
set of extensible services, that allow applications to safely
change the operating system’s interface and implementation.
Extensions allow an application to specialize the underly-
ing operating system in order to achieve a particular level
of performance and functionality. SPIN uses language and
link-time mechanisms to inexpensively export fine-grained
interfaces to operating system services. Extensions are writ-
ten in a type safe language, and are dynamically linked into
the operating system kernel. This approach offers extensions
rapid access to system services, while protecting the operat-
ing system code executing within the kernel address space. ”

(Nick’s note: The OS, casts, and linking mechanism are made type safe through using a variant of Modula 3. Like JX, this is both a strategy and possible code to draw on. It should be combined with other efforts.)

Gemini Trusted Network Processor – Final Evaluation Report (mid-1990’s)
http://www.aesec.com/eval/NCSC-FER-94-008.pdf

(Nick’s note: A nice piece of history. This is the A1 evaluation of GTNP, built on GEMSOS security kernel. The assurance, design and evaluator comments are particularly interesting. The effort solved plenty of tough problems. GEMSOS is still available through Aesec. I could imagine an updated form of it being combined with the type and memory safe CPU/language efforts. That might be badass.)

Karger’s Retrospective on VAX Security Kernel 1991
http://www.cse.psu.edu/~tjaeger/cse543-f06/papers/vax_vmm.pdf

(Nick’s note: Just a bonus link as it was first high assurance virtualization solution. They even modified the processor microcode to make it easier to virtualize. Their “assurance” activities are informative.)

The KeyKOS® Nanokernel Architecture 1992 Shapiro et al
http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html

“The KeyKOS nanokernel is a capability-based object-oriented operating system that has been in production use since 1983. Its original implementation was motivated by the need to provide security, reliability, and 24-hour availability for applications on the Tymnet® hosts. Requirements included the ability to run multiple instantiations of several operating systems on a single hardware system. KeyKOS was implemented on the System/370, and has since been ported to the 680×0 and 88×00 processor families. Implementations of EDX, RPS, VM, MVS, and UNIX® have been constructed. The nanokernel is approximately 20,000 lines of C code, including capability, checkpoint, and virtual memory support. The nanokernel itself can run in less than 100 Kilobytes of memory.
KeyKOS is characterized by a small set of powerful and highly optimized primitives that allow it to achieve performance competitive with the macrokernel operating systems that it replaces. Objects are exclusively invoked through protected capabilities, supporting high levels of security and intervals between failures in excess of one year. Messages between agents may contain both capabilities and data. Checkpoints at tunable intervals provide system-wide backup, fail-over support, and system restart times typically less than 30 seconds. In addition, a journaling mechanism provides support for high-performance transaction processing. On restart, all processes are restored to their exact state at the time of checkpoint, including registers and virtual memory.”

(Nick’s note: I can’t mention something like GEMSOS without mentioning KeyKOS, the capability-based competition. KeyKOS implemented incredible degrees of both POLA and availability. Like GEMSOS, its design is still more secure than what most modern systems came up with. Both were also in production use for some time. That KeyKOS is worth updating/imitating is obvious in that Shapiro’s EROS and COYOTOS projects worked to do exactly that, with EROS work also giving us nice networking and GUI deliverables.)

More KeyKOS links:
http://www.cis.upenn.edu/~KeyKOS/

Randomized Instruction Set Emulation to Disrupt Binary Code Injection Attacks by Barrantes et al.
http://www.cs.columbia.edu/~locasto/projects/candidacy/papers/barrantes2003randomized.pdf

” A unique and private machine instruction set
for each executing program would make it difficult for an outsider
to design binary attack code against that program and impossible
to use the same binary attack code against multiple machines. As
a proof of concept, we describe a randomized instruction set em-
ulator (RISE), based on the open-source Valgrind x86-to-x86 bi-
nary translator. The prototype disrupts binary code injection attacks
against a program without requiring its recompilation, linking, or
access to source code. The paper describes the RISE implemen-
tation and its limitations, gives evidence demonstrating that RISE
defeats common attacks, considers how the dense x86 instruction
set affects the method, and discusses potential extensions of the
idea. ”

(Nick’s note: It would be nice to have a capability like this that could be used to generate microcode, assembler and debugger for a given machine with a unique instruction set. The instruction set could be the same but with different labels. If each installation did its own, then an adversary could be facing a different ISA with each target although the underlying hardware is the same. Might make it extremely difficult for them. I know it’s doable because Transmeta Crusoes could do essentially this although for different use case.)

Binary Stirring: Self-randomizing Instruction Addresses of
Legacy x86 Binary Code by Wartell et al 2012
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=2A31AD667CB7D0FB7199EE53EC971D4C?doi=10.1.1.376.3156&rep=rep1&type=pdf

“This paper introduces binary stirring, a new technique that imbues
x86 native code with the ability to self-randomize its instruction
addresses each time it is launched. The input to STIR is only the
application binary code without any source code, debug symbols,
or relocation information. The output is a new binary whose basic
block addresses are dynamically determined at load-time. There-
fore, even if an attacker can find code gadgets in one instance of the
binary, the instruction addresses in other instances are unpredictable.
An array of binary transformation techniques enable STIR to trans-
parently protect large, realistic applications that cannot be perfectly
disassembled due to computed jumps, code-data interleaving, OS
callbacks, dynamic linking and a variety of other difficult binary
features. Evaluation of STIR for both Windows and Linux platforms
shows that stirring introduces about 1.6% overhead on average to
application runtimes. ”

(Nick’s note: Black box application, works on Windows + Linux, and provides protection against major attack vector.)

Efficient Validation of Control Flow Integrity for
Enhancing Computer System Security by Park 2010 (hardware)
http://archives.ece.iastate.edu/archive/00000561/01/thesis.pdf

“It is hard, if not impossible, for two programs to expose identical
control flows during program execution. Therefore, control flow integrity checking can
effectively prevent malicious code implants from executing.
This thesis proposes three new protection schemes based on control flow integrity
checking, each with its own assumptions of hardware and/or application scenarios. The
first study, IBMON (Indirect Branch MONitor), utilizes existing hardware features to
efficiently observe unusual control flow transfers and check them for any abnormality.
Prototype systems for proof of concept have been successfully implemented on three
different system platforms to demonstrate its efficacy. By using the hardware features,
IBMON can effectively protect a system from malicious control flow modification trans-
parently to the target applications. We have successfully built prototype systems on
real machines using several processors. Although the prototype system exhibits the best
performance among other control flow validation mechanisms, it still incurs moderate
performance overhead. We further propose IBF-Cache, an enhanced IBMON system
with special hardware support, to minimize the performance overhead associated with
IBMON. Although it requires an extension of existing processors, the cost is negligible
and the run-time of IBMON is reduced to virtually zero. ”

(Nick’s note: If it passes peer review, I’m going to love this one too. Control Flow Integrity has already established itself as the No 1 concern. IBMON is a very simple solution that leaves plenty of chip space and CPU time for solving other problems. )

CryptoPage: an Efficient Secure Architecture with Memory Encryption,
Integrity and Information Leakage Protection by Duke and Keryell
http://www.acsac.org/2006/papers/33.pdf

“We propose the C RYPTO PAGE architecture which im-
plements memory encryption, memory integrity protection
checking and information leakage protection together with
a low performance penalty (3 % slowdown on average) by
combining the Counter Mode of operation, local authenti-
cation values and Merkle trees.”

(Nick’s note: I think it’s designed to trust nothing but the main CPU chip. Btw, ACSAC conference always has good papers. Best to keep up with them and go through the archives. Might find a pleasant surprise.)

AEGIS: Architecture for Tamper-Evident and
Tamper-Resistant Processing by Suh et al
http://csg.csail.mit.edu/pubs/memos/Memo-474/Memo-474.pdf

“Our architec-
ture assumes that all components external to the processor,
such as memory, are untrusted. We show two different im-
plementations. In the first case, the core functionality of the
operating system is trusted and implemented in a security
kernel. We also describe a variant implementation assuming
an untrusted operating system.
aegis provides users with tamper-evident, authenticated
environments in which any physical or software tampering
by an adversary is guaranteed to be detected, and private
and authenticated tamper-resistant environments where ad-
ditionally the adversary is unable to obtain any information
about software or data by tampering with, or otherwise ob-
serving, system operation. aegis enables many applications,
such as commercial grid computing, secure mobile agents,
software licensing, and digital rights management.
Preliminary simulation results indicate that the overhead
of security mechanisms in aegis is reasonable.”

(Nick’s note: AEGIS is one of the original, total-package offerings in this category. Many others built on its features. It might be a burden on programmers compared to some schemes, though. I can’t be sure. I included it in case it’s useful and b/c they deserve credit for their contribution.)

SecureME: A Hardware-Software Approach to
Full System Security∗ by Chhabra et al
http://dl.acm.org/citation.cfm?id=1995914

“We propose
SecureME, a hardware-software mechanism that provides
such a secure computing environment. SecureME protects
an application from hardware attacks by using a secure pro-
cessor substrate, and also from the Operating System (OS)
through memory cloaking, permission paging, and system
call protection. Memory cloaking hides data from the OS
but allows the OS to perform regular virtual memory man-
agement functions, such as page initialization, copying, and
swapping. Permission paging extends the OS paging mech-
anism to provide a secure way for two applications to es-
tablish shared pages for inter-process communication. Fi-
nally, system call protection applies spatio-temporal pro-
tection for arguments that are passed between the applica-
tion and the OS. Based on our performance evaluation us-
ing microbenchmarks, single-program workloads, and multi-
programmed workloads, we found that SecureME only adds
a small execution time overhead compared to a fully un-
protected system. Roughly half of the overheads are con-
tributed by the secure processor substrate. SecureME also
incurs a negligible additional storage overhead over the se-
cure processor substrate. ”

(Note: An improvement in the category and has nice references to many other projects/tech. Unfortunately, you need ACM membership to get it. University libraries often have this.)

Enforcing Executing-Implies-Verified with the
Integrity-Aware Processor by LeMay and Gunter 2011
http://seclab.illinois.edu/wp-content/uploads/2011/06/LeMayG11-TRUST.pdf

“IAP is a processor technology that is specifically designed to efficiently support
a variety of integrity kernels. It provides high performance, hardware-enforced
isolation, high compatibility with target systems and flexible invocation options
to ensure visibility into the target system. We demonstrated the utility of IAP by
developing XIVE, a code integrity enforcement service with a client component
that fits entirely within IAP’s protected space, containing 859 instructions. XIVE
verifies all the code that ever executes on the target system against a network-
hosted whitelist, even in the presence of DMA-capable attackers. ”

Kernel and Application Integrity Assurance: Ensuring Freedom from Rootkits
and Malware in a Computer System by Wang and Dasgupta 2007
http://www.computer.org/csdl/proceedings/ainaw/2007/2847/01/284710583-abs.html

“This paper has presented our hardware-software co-
design for software integrity assurance. Attesting software
integrity is a difficult but critical task to build a secure com-
puting environment. Running on separate hardware, the
SecCore and its verification functionality remains in place
even when the host kernel is thoroughly compromised. The
SecCore is time-driven, independent, and self-sufficient,
and it activates other software checkers on a regular basis
to build up a hierarchical trusted chain. The SecIO is ex-
ploited to interact with the owner for an authentic message.
This out-of-band I/O device along with the SecCore provide
a flexible and robust security solution on software integrity
assurance. We also demonstrate a prototype implementa-
tion of our design approach. The security hardware is sim-
ulated by PCI SBC device, and the software on SecCore
and host computer are a patched Linux kernel. We added functionalities to support PCI interconnection, and we also
developed routines to build an initial software integrity and
compare it with the running software in memory. Our pro-
totype demonstrates both feasibility and efficiency with the
hierarchical checking. ”

(Note: It has at least one serious limitation so it’s a work in progress. However, I often promote both PCI coprocessor and trusted path via dedicated hardware approaches on Bruce’s blog. Interesting to see that they use both to good effect. Least people are thinking in a good direction. Unfortunately IEEE so you need a membership to get it.)

CODESSEAL – compiler FPGA approach to secure applications by Gelbart et al post-2004

“paper proses a join compiler/hardware infrastructure for software protection for fully encrypted execution in which both program and data are in encrypted form in memory. The processor is supplemented with an FPGA-based secure hardware component that is capable of fast encryption and decryption, and performs code integrity verification, authentication, and provides protection of the execution control flow. “

(Nick’s note: One aspect of this design maintains control flow integrity by analysing the code and creating a control flow graph of it to spot valid jump targets. It then enforces them. I like the simplicity of the approach although other links I’ve posted might make it obsolete.)

(Nick’s edit: I couldn’t find a link to this exact paper probably because it’s been turned into a product. Microsemi sells CodeSEAL for use with many OS’s and RTOS’s. Google them if interested.)

Architectural support for Securing Application Data
in Embedded Systems
by Gelbart et al
http://www.seas.gwu.edu/~simha/research/OlgaDataPaper.pdf

“Encrypted execution and data (EED) platforms, where
instructions and data are stored in encrypted form in memory,
while incurring overheads of encryption have proven to be
attractive because they offer strong security against information
leakage and tampering. However, several attacks are still possible
on EED systems when the adversary gains physical access to the
system. In this paper we present an architectural approach to
address a class of memory spoofing attacks, in which an attacker
can control the address bus and spoof memory blocks as they are
loaded into the processor. In this paper we focus on the integrity
of the application data to prevent the attacker from tampering,
injecting or replaying the data. We make use of an on-chip
FPGA, an architecture that is now commonly available on many
processor chips, to build a secure on-chip hardware component
that verifies the integrity of application data at run-time. By
implementing all our security primitives on the FPGA we do
not require changes to the processor architecture. We present
that data protection techniques and a performance analysis is
provided through a simulation on a number of bechmarks. Our
experimental results show that a high level of security can be
achieved with low performance overhead.
”

SAFECODE: A PLATFORM FOR DEVELOPING RELIABLE SOFTWARE IN
UNSAFE LANGUAGES by Dhurjati 2006
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167.2943&rep=rep1&type=pdf

“This thesis presents a new compiler and a run-time system called SAFECode (Static Analysis For safe Execution of Code) that addresses these two problems. First, SAFECode guarantees memory safety for programs in unsafe languages with very low overhead. Second, SAFECode provides a platform for reliable static analyses by ensuring that an aggressive interprocedural pointer
analysis, type information, and call graph are never invalidated at run-time due to memory errors. Finally, SAFECode can detect some of the hard-to detect memory errors like dangling pointer errors with low overhead for some class of applications and can be used not only during development but also during deployment. SAFECode requires no source code changes, allows memory to be managed explicitly and does not use metadata on pointers or individual tag bits for memory (avoiding any external library compatibility issues).
This thesis describes the main ideas, insights, and the approach that SAFECode system uses to achieve the goal of providing safety guarantees to software written in unsafe languages. This thesis also evaluates the SAFECode approach on several benchmarks and server applications and shows that the performance overhead is lower than any of the other existing approaches. ”

(Nick’s note: Decent work. Provides a comparison to methods at the time including Ccured, SFI, and Cyclone.)

Ironclad C++ A Library-Augmented Type-Safe Subset of C++ 2013 DeLozier et al
http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf

“Ironclad C++ is, in essence, a library-augmented
type-safe subset of C++. All Ironclad C++ programs are
valid C++ programs, and thus Ironclad C++ programs can be
compiled using standard, off-the-shelf C++ compilers…. brings type safety to C++ at a runtime over-
head of 12%. ”

(Nick’s note: making existing C and C++ code isn’t just about protecting native apps. Remember that there’s a ton of useful code out there that just happened to be coded in a very unsafe language. Having a way to safely solve a problem with C/C++ code is nice. Ironclad is particularly nice due to low overhead.)

Securing Untrusted Code via Compiler-Agnostic
Binary Rewriting by Wartell et al 2012
http://utd.edu/~kxh060100/wartell12acsac.pdf

“Binary code from untrusted sources remains one of the primary vehicles for malicious software attacks. This paper presents R EINS, a new, more general, and lighter-weight binary rewriting and in-lining system to tame and secure untrusted binary programs. Unlike traditional monitors, R EINS requires no cooperation from code-
producers in the form of source code or debugging symbols, requires no client-side support infrastructure (e.g., a virtual machine or hypervisor), and preserves the behavior of even complex, event-driven, x86 native COTS binaries generated by aggressively optimizing
compilers. This makes it exceptionally easy to deploy. The safety of programs rewritten by R EINS is independently machine-verifiable, allowing rewriting to be deployed as an untrusted third-party service.
An implementation of R EINS for Microsoft Windows demonstrates that it is effective and practical for a real-world OS and architecture, introducing only about 2.4% runtime overhead to rewritten binaries. ”

(Nick’s note: works on Windows binaries with no help from the vendor or debugger. That’s what I’m talking about! Sounds like a good way to deal with legacy windows apps in corporate settings. In conjunction with whitelisting of course…)

Complete Translation of Unsafe Native Code to Safe Bytecode by Alliet and Megacz 2004
http://www.cs.berkeley.edu/~megacz/research/papers/nestedvm.ivme04.pdf

(Nick’s note: the abstract wouldn’t cut n paste and I didn’t feel like typing it. So, summary, they compile native libraries to MIPS, then translate that into Java bytecodes. Clever idea. Might be useful for deploying existing libraries on JX, high level ISA’s, etc. There’s more modern approaches for native to Java, while this can be targeted to many open runtimes and toolsets. This has also be done to run native code in Javascript I think called asm.js.)

Control-Flow Integrity
Principles, Implementations, and Applications by Abadi et al 2007
http://users.soe.ucsc.edu/~abadi/Papers/cfi-tissec-revised.pdf

“The enforcement of a basic safety property, control-flow integrity (CFI), can prevent such attacks from arbitrarily controlling program behavior. CFI enforcement is simple and its guarantees can be established formally, even with respect to powerful adversaries. Moreover, CFI enforcement is practical: It is compatible with existing software and can be done efficiently using software rewriting in commodity systems. Finally, CFI provides a useful foundation for enforcing further security policies, as we demonstrate with efficient software implementations of a protected shadow call stack and of access control for memory regions.”

(Nick’s note: Great stuff.)

Practical Control Flow Integrity & Randomization for Binary Executables by Zhang et al 2013
http://seclab.cs.sunysb.edu/seclab/pubs/oak13.pdf

“CFI has not seen wide indus-
trial adoption. CFI suffers from a perception of complexity and inefficiency: reported overheads (average/max) have been as high as 7.7%/26.8% [13] and 15%/46% [9]. Many CFI systems require debug information that is not available in COTS applications, and cannot be deployed incrementally because hardened modules cannot inter-operate with un-hardened modules. We propose a new practical and realistic protection method called CCFIR (Compact Control Flow Integrity and Randomization), which addresses the main barriers to CFI adoption. CCFIR collects all legal targets of indirect control-transfer instructions, puts them into a dedicated “Springboard section” in a random order, and then limits indirect transfers to flow only to them. Using the Springboard section for targets, CCFIR can validate a target more simply and faster than traditional CFI,
and provide support for on-site target-randomization as well as better compatibility. Based on these approaches, CCFIR can stop control-flow hijacking attacks including ROP and return-into-libc. Results show that ROP gadgets are all eliminated. We observe that with the wide deployment of ASLR, Windows/x86 PE executables contain enough information in relocation tables
which CCFIR can use to find all legal instructions and jump targets reliably, without source code or symbol information. We evaluate our prototype implementation on common web browsers and the SPEC CPU2000 suite: CCFIR protects large applications such as GCC and Firefox completely automatically, and has low performance overhead of about 3.6%/8.6%
(average/max) using SPECint2000. Experiments on real-world exploits also show that CCFIR-hardened versions of IE6, Firefox 3.6 and other applications are protected effectively. ”

(Nick’s note: More awesome work via CFI-based techniques. They’re on a roll, yeah?)

Language-Independent Sandboxing of
Just-In-Time Compilation and Self-Modifying Code by Ansel et al 2011
http://research.google.com/pubs/archive/37204.pdf

“ this paper introduces general mech-
anisms for safely and efficiently sandboxing software, such as
dynamic language runtimes, that make use of advanced, low-
level techniques like runtime code modification. Our language-
independent sandboxing builds on Software-based Fault Isolation
(SFI), a traditionally static technique. We provide a more flexible
form of SFI by adding new constraints and mechanisms that allow
safety to be guaranteed despite runtime code modifications.
We have added our extensions to both the x86-32 and
x86-64 variants of a production-quality, SFI-based sandboxing
platform; on those two architectures SFI mechanisms face different
challenges. We have also ported two representative language
platforms to our extended sandbox: the Mono common language
runtime and the V8 JavaScript engine. In detailed evaluations,
we find that sandboxing slowdown varies between different
benchmarks, languages, and hardware platforms. Overheads are
generally moderate and they are close to zero for some important
benchmark/platform combinations. ”

(Nicks note: Native Client was one of the best things to happen in the security field in a while. This work expands it to handle dynamic and JIT languages. It demonstrates that on Mono and Javascript. If that doesn’t prove practical usefulness, I don’t know what does.)

Retaining Sandbox Containment Despite Bugs in
Privileged Memory-Safe Code by Cappos et al 2010
http://cs.brown.edu/~jeffra/papers/sandbox-ccs10.pdf

“In this work, we construct a Python-based sandbox that
has a small, security-isolated kernel. Using a mechanism
called a security layer, we migrate privileged functionality
into memory-safe code on top of the sandbox kernel while re-
taining isolation. For example, significant portions of mod-
ule import, file I/O, serialization, and network communica-
tion routines can be provided in security layers. By moving
these routines out of the kernel, we prevent attackers from
leveraging bugs in these routines to evade sandbox contain-
ment. We demonstrate the effectiveness of our approach by
studying past bugs in Java’s standard libraries and show
that most of these bugs would likely be contained in our
sandbox. ”

(Nick’s note: We know the language sandboxes can solve a ton of problems. This work protects unsafe aspects of those sandboxes. It’s nice that they ported Python to it: a recent Coverity report showed Python code having the lowest defect level of all code and you know it’s language decisions had a big role in that. And it’s fun, popular and easy to learn.)

Leveraging Legacy Code to Deploy Desktop Applications on the Web by Doceur et al 2007 XAX architecture
https://research.microsoft.com/pubs/72878/xax-osdi08.pdf

“Xax is a browser plugin model that enables developers
to leverage existing tools, libraries, and entire programs
to deliver feature-rich applications on the web. Xax em-
ploys a novel combination of mechanisms that collec-
tively provide security, OS-independence, performance,
and support for legacy code. These mechanisms include
memory-isolated native code execution behind a narrow
syscall interface, an abstraction layer that provides a con-
sistent binary interface across operating systems, sys-
tem services via hooks to existing browser mechanisms,
and lightweight modifications to existing tool chains and
code bases. We demonstrate a variety of applications and
libraries from existing code bases, in several languages,
produced with various tool chains, running in multiple
browsers on multiple operating systems. With roughly
two person-weeks of effort, we ported 3.3 million lines
of code to Xax, including a PDF viewer, a Python inter-
preter, a speech synthesizer, and an OpenGL pipeline. ”

(Nick’s note: This is a great piece of work with plenty potential beyond browser plugins. Their approach to dealing with system calls is awesome. The numbers alone show it. Love or hate Microsoft, you gotta admit there’s some great minds at Microsoft Research.)

InkTag: Secure Applications on an Untrusted Operating System 2013 Hoffman et al.
http://www.cs.utexas.edu/lasr/download.php?uid=52

“InkTag is a virtualization-based architecture that gives strong safety
guarantees to high-assurance processes even in the presence of a
malicious operating system. InkTag advances the state of the art
in untrusted operating systems in both the design of its hypervi-
sor and in the ability to run useful applications without trusting the
operating system. We introduce paraverification, a technique that
simplifies the InkTag hypervisor by forcing the untrusted operating
system to participate in its own verification. Attribute-based access
control allows trusted applications to create decentralized access
control policies. InkTag is also the first system of its kind to ensure
consistency between secure data and metadata, ensuring recover-
ability in the face of system crashes. ”

(Nick’s note: It does a whole lot. I read the paper recently and I’m still trying to let it all sink in. It should be evaluated as an interim solution to use until ground-up secure solutions are ready.)

A Nitpicker’s guide to a minimal-complexity secure GUI Feske and Helmuth
http://www.acsac.org/2005/papers/54.pdf

“we present the design and
implementation of Nitpicker—an extremely minimized se-
cure graphical user interface that addresses these prob-
lems while retaining compatibility to legacy operating sys-
tems. We describe our approach of kernelizing the win-
dow server and present the deployed security mechanisms
and protocols. Our implementation comprises only 1,500
lines of code while supporting commodity software such as
X11 applications alongside protected graphical security ap-
plications. We discuss key techniques such as client-side
window handling, a new floating-labels mechanism, drag-
and-drop, and denial-of-service-preventing resource man-
agement. Furthermore, we present an application scenario
to evaluate the feasibility, performance, and usability of our
approach. ”

(Nick’s note: secure GUI done right. It’s minimal, usable, and securable. Enough said.)

Architectures for MLS Database Management Systems Notargiacomo
http://www.acsac.org/secshelf/book001/19.pdf

“This essay presents a survey of the basic architectures that have been
used in the research and development of trusted relational database
management systems (DBMSs). While various approaches have been
tried for special-purpose systems, the architectures presented here are
those developed for general-purpose trusted DBMS products. In addi-
tion, this essay presents research approaches proposed for new trusted
DBMS architectures, although worked examples of these approaches
may not exist in all cases. ”

(Nick’s note: This essay summarizes different approaches for MLS databases. Certain design aspects, or outright designs, might be useful for someone looking to make high assurance databases.)

jVPFS: Adding Robustness to a Secure Stacked File System
with Untrusted Local Storage Components 2011 Weinhold and Hartig
http://www.usenix.org/event/atc11/tech/slides/weinhold.pdf

“The Virtual Private File System (VPFS) [1] was built to
protect confidentiality and integrity of application data
against strong attacks. To minimize the trusted com-
puting base (i.e., the attack surface) it was built as a
stacked file system, where a small isolated component
in a microkernel-based system reuses a potentially large
and complex untrusted file system; for example, as pro-
vided by a more vulnerable guest OS in a separate virtual
machine. However, its design ignores robustness issues
that come with sudden power loss or crashes of the un-
trusted file system.
This paper addresses these issues. To minimize dam-
age caused by an unclean shutdown, jVPFS carefully
splits a journaling mechanism between a trusted core and
the untrusted file system. The journaling approach mini-
mizes the number of writes needed to maintain consistent
information in a Merkle hash tree, which is stored in the
untrusted file system to detect attacks on integrity. The
commonly very complex and error-prone recovery func-
tionality of legacy file systems (in the order of thousands
of lines of code) can be reused with little increase of com-
plexity in the trusted core: less than 350 lines of code
deal with the security-critical aspects of crash recovery.
jVPFS shows acceptable performance better than its pre-
decessor VPFS, while providing much better protection
against data loss. ”

Iris: A Scalable Cloud File System with
Efficient Integrity Checks by Stefanov et al 2012
http://eprint.iacr.org/2011/585.pdf

“We present Iris, a practical, authenticated file system designed to
support workloads from large enterprises storing data in the cloud
and be resilient against potentially untrustworthy service providers.
As a transparent layer enforcing strong integrity guarantees, Iris
lets an enterprise tenant maintain a large file system in the cloud.
In Iris, tenants obtain strong assurance not just on data integrity,
but also on data freshness, as well as data retrievability in case of
accidental or adversarial cloud failures.
Iris offers an architecture scalable to many clients (on the or-
der of hundreds or even thousands) issuing operations on the file
system in parallel. Iris includes new optimization and enterprise-
side caching techniques specifically designed to overcome the high
network latency typically experienced when accessing cloud stor-
age. Iris also includes novel erasure coding techniques for the first
efficient construction of a dynamic Proofs of Retrievability (PoR)
protocol over the entire file system.
We describe our architecture and experimental results on a pro-
totype version of Iris. Iris achieves end-to-end throughput of up
to 260MB per second for 100 clients issuing simultaneous requests
on the file system. (This limit is dictated by the available network
bandwidth and maximum hard drive throughput.) We demonstrate
that strong integrity protection in the cloud can be achieved with
minimal performance degradation. ”

Poly2 Paradigm: A Secure Network Service Architecture Bryant et al (CERIAS)
https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/01254339.pdf

“The Poly2 approach is to separate network services onto
different systems, to use application-specific (minimized)
operating systems, and to isolate specific types of network
traffic. Trust in the entire architecture comes from the sepa-
ration of untrusted systems and services. The separation of
network services helps contain successful attacks against in-
dividual systems and services. Therefore no single compro-
mised system can bring down the entire architecture. The
minimized operating systems only provide the services re-
quired by a specific network service. Removal of all other
services reduces the functionality of the system to a bare
minimum. Specific types of network traffic such as adminis-
trative, security-specific, and application-specific traffic are
isolated onto special sub-networks. Because the nature of
the traffic on each sub-network is specific and known in ad-
vance, deviations in normal traffic patterns are more easily
detected .”

(Nick’s note: This is more akin to best practices. They noticed what I noticed about physical separation being much cheaper than in the past. They use this to their advantage. )

CodeShield: Towards Personalized Application
Whitelisting by Gates et al. 2012
http://www.cs.purdue.edu/homes/gates2/publications/acsac2012-codeshield.pdf

“ In this paper we propose the concept of Person-
alized Application Whitelisting (PAW) to block all unsolicited for-
eign code from executing on a system. We introduce CodeShield,
an approach to implement PAW on Windows hosts. CodeShield
uses a simple and novel security model, and a new user interac-
tion approach for obtaining security-critical decisions from users.
We have implemented CodeShield, demonstrated its security effec-
tiveness, and conducted a user study, having 38 participants run
CodeShield on their laptops for 6 weeks. Results from the data
demonstrate the usability and promises of our design. ”

(Nick’s note: really usable whitelisting might have stopped many of so-called APT attacks that just trick people into executing programs.)

SHIELDSTRAP: Making Secure Processors Truly Secure 2009 Chhabra et al.
http://dl.acm.org/citation.cfm?id=1792410

“Many of these attacks target a system during booting
before any employed security measures can take effect. In
this paper, we propose SHIELDSTRAP, a security architecture
capable of booting a system securely in the face of hardware
and software attacks targeting the boot phase. SHIELDSTRAP
bridges the gap between the vulnerable initialization of the
system and the secure steady state execution environment
provided by the secure processor. We present an analysis of
the security of SHIELDSTRAP against several common boot
time attacks. We also show that SHIELDSTRAP requires an
on-chip area overhead of only 0.012% and incurs negligible
boot time overhead of 0.37 seconds. ”

(Nick’s note: ACM again…)

Project Oberon The Design of an Operating System and Compiler by Wirth and Gutknecht
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf

“This book presents the results of Project Oberon, namely an entire software environment for a modern workstation. The project was undertaken by the authors in the years 1986-89, and its primary goal was to design and implement an entire system from scratch, and to structure it in such a way that it can be described, explained, and understood as a whole. In order to become confronted with all aspects, problems, design decisions and details, the authors not only conceived but also programmed the entire system described in this book, and more. ”

(Nick’s note: It’s a great piece of work to look at. It lives in in modernized form in A2 Bluebottle OS which is downloadable off the net, source and all. The book/paper outlines the details of the design of their OS, compiler, etc. in a way that it could be quite easily reproduced. I’m including it mainly as a starting point for people trying to figure out how to design an OS easy to analyze for subversion and that can run on minimal hardware. Their OS already accomplished both, the former just because it’s easy enough to comprehend and therefore see everything is there for a good reason.)

A list of capability based computer systems and their details:
http://homes.cs.washington.edu/~levy/capabook/

Knockoffs of those will be easier to secure than knockoffs of vanilla hardware. Flex was a similar type of machine which Ten15 was to run on. I’m not sure I’ve seen anything even today like Ten15 but it’s worth remembering for any wisdom to glean from it.

Ten15
http://mca-ltd.com/martin/Ten15/introduction.html

HISC – Object-oriented instruction set processor w/ built-in GC
http://www.ee.cityu.edu.hk/~hisc/HISC.pdf

Java processors, VM’s, realtime, etc. plenty good material and even working chip
http://www.jopdesign.com/teaching.jsp

List of Forth and stack chips for people into that sort of thing
http://www.ultratechnology.com/chips.htm

LISP Machines since almost anything can be done with LISP. It’s code as data can be restricted.
https://en.wikipedia.org/wiki/Lisp_machine

Nick P • December 14, 2013 12:08 PM

@ Figureitout, Mike re my paper release

This paper release is specificly for removing the low hanging fruit: software issues. That it’s nearly impossible to put programs on a machine without vulnerabilities undermines every use case before hardware level issues are even considered. So, I’ve always advocated that we try to solve the software problem first then solve the next one. If they can be solved simultaneously, even better. I’m focusing on the major problem first, though.

re paywall

An unfortunate reality of modern academia. Thing is, the IEEE and ACM memberships are worth the annual price if one wants all the cutting-edge and/or arcane tech hidden in there. There’s a bunch which I’ve referenced here plenty of times and some of which solved big problems while still being relatively unknown. I actually have the three papers on my HD but there’s certain serious copyright laws in my country, along with 250,000+ potential witnesses on this blog. 😉

Just check your local and college library to see if they have free access to ACM/IEEE. Many do. Then, just mass download everything onto flash drives. Good keywords include “secure,” “high assurance,” “NUMA,” “networking,” “MLS,” “protocols,” “software engineering,” and “TCB.” Of the three I listed, SecureME improves on SecureCore and Aegis. It’s the most useful. (Btw, Google SecureCore or SP architecture as I should’ve included them.) SHIELDSTRAP does just one thing but it’s chip surface is tiny so maybe another tool in the toolbox. The other I just threw in b/c it fit the theme.

@ figureitout re chip fabrication

Our resident expert on this (RobertT) and I just had a debate on various aspects of it. We got the discussion down to these critical points:

1. Even a free fab cost millions to operate and customers are hard to keep. It’s why there’s many for sale right now: even experienced chip companies can’t afford to keep them open.
2. Even a fab using old technology subject to optical inspections can be subverted by insiders using cutting edge nanoscale chip technology. 20nm attack structures might be used against a micron process chip. You can’t “uninvent the chip advances” once they happen.
3. Chips, even simple ones, actually get cheaper as the fab gets more expensive so there’s no economic reason to invest in lower grade fab technology.
4. Biggest point was that 20nm process node tech is so exotic that experts can barely get chips to function at all, much less build them in insidious ways. This extra difficulty might make it the safest technology.

So, I’ve decided the fab issue can’t be managed economically for the mean time. The best way to do it is a vetted hardware design, vetted macros/cells, vetted translation, and a trustworthy distribution method to the fab. From that point on, it’s all a matter of faith anyway so why waste money on inferior process node tech. 20nm process node seems to be a good default choice.

A newcomer to the blog also gave me an interesting idea. That person posted a link to new tech where a company had developed a processor that could be fabbed by a memory tech fab. Processors usually aren’t done at those fabs for various technical reasons. The poster was interested in it because memory chip tech costs many fold less (100x?) than CPU fab tech and the innovating company already had a core ready to go.

However, I noticed ANOTHER benefit: the odds of subversion are extremely low. This is a fab process that was believed impossible to produce usable CPU’s with and is currently producing memory chips en masse. Although there’s been proposals to hide backdoors in memory chips, there’s no logical reason to believe the memory fab is subverted in a CPU defeating way. So, our choices are a vetted design on 20 nm CPU process node tech with vendor supplied logic or on the memory tech licensing that one company’s logic cells. A side benefit is 20nm gives you plenty of room for performance or security enhancements, too.

“and I am sure that a design could be licensed from the Chinese. They’ll sell anything at the right price.”

The Elbrus processors from Russia are SPARC compatible & hence worth considering. They have small ones, dual cores (w/ fault resilience support), quad core, and so on. The reason I bring up SPARC is there’s at least one ground up enhancement that builds on SPARC cores. The Russians also have MIPS chips too. The CHERI project (with many others) uses MIPS. Matter of fact, NonStop used MIPS for a long time for five 9’s with high throughput. They’re pretty versatile. Then, there’s China’s MIPS Loongson as you pointed out.

Finally, the Japanese companies have knockoffs of SPARC and the like. One of them is used in mainframe style machines so it’s probably reliable as hell. The Russian one had a ccNUMA feature in its spec so it’s probably used in large SMP machines. Might imply reliability. All in all, getting a core licensed from another country under NDA, taking out risky parts, adding security enhancements, and sending that to a 20nm fab might be a decent route.

I still thinking getting some CPLD’s or FPGA’s vetted in 20nm might be a nice idea. Could just get an endless supply of reconfigurable chips and keep putting open designs on them, building the real ASIC only that one time. Maybe use the write-once FPGA’s too to keep the security risks down. The prototyping can be done on untrusted COTS FPGA’s that are truly reprogrammable, then it’s ported to the write once FPGA’s that are already being fabbed. Might keep costs down.

@ mike re TEMPEST

TEMPEST is no doubt a concern. The best way to deal with it right now is to run the systems in a shiedled room on battery or generator. The soundproofing I used to recommend also just became a better idea due to the audio-based malware research. As per old DOD rules, either no cellphones or they have batteries removed. Any data lines have appropriate shielding. Use of rural areas is preferred as you can then create a min 100 yard zone around the site with cameras.

In parallel and long-term, I’d like to see more academic research into it. The governments have several decades experience in defence and offence. Academia has a few years basically. We need really smart people with good funding looking into everything in COTS hardware, power cords, active emanation attacks, etc along with shielding options for rooms and individual products. Essentially, they need to recreate all that locked away classified research from scratch and put it in the open with their recommendations. At that point, regular manufacturers and regular equipment will be able to produce cheap TEMPEST shielded workstations.

(Note: I’ve already seen books on shielding that might serve that purpose. Anyone trying at EMSEC defence should look at about every available work on dealing with regular EM/RF noise as I’m sure that will help in preventing passive leaks.)

re cell phones

Yeah, they can’t be trusted. I was working on that problem again during the paper release. I think the safe execution architectures could really help with that. Here’s the basic proposal:

1. Safe (tagged/capability/bytecode/whatever) chip with almost all phone software running on top of it.

2. Dedicated chip for baseband stack running a modified version of whatever they normally run.

3. Careful interface for the two where (a) GSM stack only accesses restricted part of memory which is hardware mediated and (b) safe chip decides when to cooperate with main GSM functions.

For instance, the GSM chip might activate its hidden silent answer feature, but safe chip isn’t in call mode so doesn’t send any microphone data. The safe chip actually has to move data into the buffer (or over some IO line) before GSM chip can physically see it so the GSM chip at best can ask for permission.

The one big risk I still see with this architecture is EMSEC attacks. Cellphones weren’t allowed around secure phones for a long itme. It was even noted at having a Nextel phone near a STU-III caused a key compromising leak almost immediately due to EM interactions. It took a while before mobile phones got secure enough for NSA approval (e.g Sectera Edge). They’re no doubt designed to minimize emanations.

So, the attack vector that comes to my mind is that the attacker-controlled baseband stack causes the radio to leak (a) the trusted phone’s secrets or (b) some other device’s secrets nearby. The easiest route will probably be to separate the radio from the protocol interpreter, then somehow ensure they both behave a certain way. Yet another safer chip design… In any case, it seems my ad hoc architecture protects against the majority of attacks and the radio attack is somewhat exotic. Might still be beneficial.

@ Winter

Thanks for the link. I look forward to his articles when he gets them online.

Nick P • December 14, 2013 11:58 PM

@ Zaphon

You’re welcome! My only hope is it benefits people building The Next Secure Thing. (And they actually build a secure thing this time.)

@ Fab!

“Now, this isn’t possible using the fab you’re using. So, at least, if you can verify your chip and verify the tools used to create them, then you can be reasonably sure that the chips do not contain such 20nm features, no (modulo being able to ensure the chip was really done by this verified fab) ?”

Are you being sarcastic or asking me a question? Regardless, the end result of the discussion with RobertT was that none of them were trustworthy unless I could ensure the workers didn’t betray me (without being able to verify it). The cornerstone of my scheme was certain ideas for handling the personnel security part plus building a fab with controls on key areas of manufacturing. RobertT thought both were nonsense and I’ll just quote him rather than say it myself.

“BTW ALL subversion of product at the Fab stage is probably done by motivated enterprising individuals without any cooperation from fab management. WHY would this be any different at a fab that you own?” (RobertT)

“You dont seem to understand that 20nm is about 1/50th the size of the minimum structure that a typical optical inspection microscope can resolve even at 130nm your dealing with structures that are about 1/4 the wavelength of Green light (about 500nm). You might be able to sort-off see 130nm cells but you have no idea what the edges of the structure really look like its all just a diffracted blurry mess. ” (RobertT on optical inspection of nm chips)

And the whopper:

“To understand what is possible with a modern fab you’ll need to understand cutting edge Lithography, Advanced directional etching , Organic Chemistry and Physics that’s not even nearly mature enough to be printed in any text book. These skills are all combined to repeatedly create structures at 1/10th the wavelength of the light being used. Go back just 10 or 15 years and you’ll find any number of real experts (with appropriate Phd qualifications) that were willing to publicly tell you just how impossible the task of creating 20nm structures was, yet here we are!

Not sure why you believe that owning the fab will suddenly give you these extremely rear technical skills. If you dont have the skills, and I mean really have the skills (really be someone that knows the subject and is capable of leading edge innovation) then you must accept everything that your technologists tell you, even when they’re intentionally lying. I cant see why this is any better then simply trusting someone else to properly run their fab and not intentionally subvert the chip creation process.” (RobertT)

Everything he said makes sense. Although I indicated I had a method to get a bunch of that under control, the truth is it doesn’t contradict his belief that the tech is simply too complicated and exotic for security types to get a handle on. It essentially comes down to two major possibilities:

1. they’re too busy doing all the hard science making chips work and have no time for the subversion shit at cutting edge process levels.
2. They can be paid to subvert a chip using their esoteric knowledge despite whatever security precautions are put into place.

For a good process node tech, these seem to be true. I’d also say that even the older fabs could probably be subverted by subverting the [still custom] equipment. I’ve pushed silicon experts in the past on what aspects of fab I need to focus security on and worked out ways to build both tools and fab assuming untrustworthy parties. Let’s just say it gets so complex, painstaking and uncertain that it would probably be subverted anyway assuming it didn’t fail due to cost.

So, perverse as it seems, this problem might be best solved by staying so close to the cutting edge that subversion itself becomes difficult or unreliable. That along with revamping older machines and using things that aren’t made with electrical engineering. Like typewriters. 😉

Nick P • December 15, 2013 6:26 PM

@ Fab!

“(I hadn’t seen that discussion about trusting the fab operators, and any chain of custody).I’ll go back to lurking now…”

No need for lurking or anything. I was just trying to get clarity on where you were coming from. It’s all good. 😉

@ 65535

“I though Microsoft was insecure. Why did Gen. Dyn use it?”

The main strategy of most devices for processing classified information is domain separation. They try to use crypto, physical separation, virtualization, etc. to keep the low and high sensitivity material/operations totally separate. I know the device has two buttons representing sensitivity levels allowing you to switch between them. They probably use two different instances of Windows CE and put some strong isolation/crypto in to protect the sensitive one.

@ Bryan

It’s a decent plan. I’m entirely for a physical switch for firmware. For instruction set randomization, one of my schemes was to simply create a tool that changes the instruction names in the microcode, then do a microcode update. I don’t code chips at that level so I don’t know if this is feasible but it seems like a simple idea. It’s also consistent with my A1-inspired lifecycle security requirements like on-site generation of the system from trusted tools, source, etc.

The main gripe I have is that there are stronger methods in the links I have that are immediately usable. At least read all the abstracts of the hardware security mechanisms and let them really sink into your mind. The techs on segmentation and legacy code protection in particular have very strong methods. The main goals of security in our case should be controlling what states the system can be in with its execution such that none lead to a compromise. And of course detection and recovery where possible. I’m sure there are ways to combine these techs for thorough protection that we’re just not seeing yet, although my mind is brimming.

Random ISA technique might also have a risk when legacy software like JIT’s help enemies execute code on your machine that they use to extract your instruction set or otherwise attack your system. CFI and CPU type controls have the most promise for stopping largest classes of attacks with little programmer skill.

Note: One potential risk for your firmware idea is it will be subverted by govts directly or indirectly through industry. It’s been claimed that this has happened already with UEFI.

@ Iain Moffat
(Clive Robinson part of my reply to you is in here)

Thanks for joining the discussion as we need more people in it who know what they’re talking about hardware wise. 😉 And thanks for the suggestion as I totally forgot about those! I actually posted a link here before to Magic 1, an amazing homebrew system. It used TTL’s with 8086 type performance. It ran Minix 2 and acted as a web server for a while. So, Magic-1 definitely validates your idea that it can be done today and be useful.

Funny part about you mentioning old mainframes and minicomputers is I was up all last night looking at them. I was reading manuals on Burrough’s, GCOS, and Tandem looking at the specific technical approaches they used for robustness. IMHO, they’re still ahead of many modern PC’s in those regards: Burrough’s protected procedures and high level language for OS; GCOS using segments for fine-grained memory isolation in addition to its paging (similar to Native Client); Tandem designing system for linear scalability & five 9’s. I was also considering capability machines like Cambriges CAP and Secure Ada Target.

So that’s my initial reaction. What’s your opinion on simply making a duplicate of one of these older machines and developing on it using modern tools? I mean, people used to do networking, accounting, secure messaging, etc. on this old technology. Esp with TTL route, it seems like it might be easier to come up with non-subverted tech if we just create a modern version of a capabiliity or segmented machine wired together with TTL’s. The prototypes for hardware might be made quickly using modern tools, then the output carefully checked in an old school way.

A few other uses of the lower-resourced TTL machine come to mind:

1. Use it as the voter in a triple modular redundancy type system where the three workhorse systems are COTS for performance.
2. Use it as a guard for air gapped networks with simplified protocols at the interface rather than TCP/IP.
3. Use it as a root of trust containing the private key, source code hashes, directories, etc. Any service that might be justified in offloading to secure, dedicated server or device.
4. Use it for private messaging and collaboration of many kinds, possibly with a gateway connected to it to translate from standard to primitive interface protocols.

5. Full disk encryption for a SAN. Ok, I know this sounds ridiculous, but it popped in my head that the secure machine could front end to COTS storage machines. The secure machine would take in the plaintext, apply proper crypto, and store cipher text on untrusted storage nodes. It might maintain an index. Confidentiality, integrity and quick destruction of data would all be easier to do if the key security component was highly robust.

Each of these doesn’t seem like it would take too much CPU or storage for the trusted device. Each is quite useful. Each function in one form or another was performed by such machines in the past. So, there’s a precedent.

More Musings on Developing the Hardware

Another thing that comes to mind is that all the hardware might not need to be TTL or old. I’m sure that certain chips have simple enough function that COTS variety could be ordered. Heck, if the TTL chip does IOMMU, entire devices might be able to work untrusted without compromising system operation. Question is how much functionality really needs to be on the TTL’s or custom silicon for a general purpose system to work securely?

I could see using a mix of COTS components, FPGA’s, and TTL’s where each was selected based on risk. Tricky to decide which is which. For instance, last night I was thinking of combining a trusted memory interface with regular COTS RAM. An attack based on subverting the RAM to do more than read/write bits immediately jumped into my mind. The more of the system that can be untrusted the easier it will be to build.

It’s why I love designs where all one has to trust is the main chip functions. Makes things so much easier. Most of them take a lot of transistors though… (sighs)

@ Lynx

Thanks for the mention of the Cookbook. Might come in handy. Btw, what kind of effort do you think it would take to build a knock off of one of the segmented/capability/mainframe machines I mentioned using today’s TTL’s or other easily inspected chips? Also, 32-bit is my preference as well but it doesn’t have to be 32 bit. I’d say 16 at a minimum but something between 16 and 32 might be acceptable.

@ saucymugwump

“Some people here believe that fabbing (if that’s a word) in China or Russia is safer than in the USA, yet the former has declared that large parts of the Pacific Ocean are its private domain and is the top source for industrial espionage, and the latter is the top source for online theft. If the fab is in the USA, you can easily and quietly travel to it to check on things, but if the fab is in China or Russia, they will know you are coming long before you arrive. Not to mention the language problem.”

I wasn’t aware of any fabs in the US that let you thoroughly inspect each aspect of how they build your chips. Far as I recall, they don’t exist. US fabs must be trusted just as one trusts those overseas. Seeing as I’m the guy who posted the China and Russia solution I’ll explain the logic behind it (along with the critical context you left off).

1. DOD certified fabs in US like Freescales or US companies like Intel are more likely to be subverted by NSA than any foreign company.

2. The Chinese and Russian chips are more likely to be subverted by them than NSA.

3. My solution was to separate work onto different hardware based on who one worried about: (a) Chinese/Russian chips if worried about Big Five countries and/or Israel; (b) US chips if worried about Russia, China, Japan, and France. There’s other potential combinations.

4. Use strong controls at interfaces and preferrably air gaps.

Combined with the “use old hardware” idea, it seemed a halfway decent interim solution until a better one was found. What I didn’t say was put any kind of blind trust into chips made in Russia or China which, as you pointed out, are high risk espionage countries. My strategy was more playing opponents against each other to avoid risks on each side.

re germany and finland

Germany’s government has been spying on its citizens too I heard. That doesn’t sound safe from subversion or honest, esp as they gripe about NSA revelations. The Finnish, on the other hand, have been repeatedly spied on by both US and Russia. If they haven’t been infiltrated by now, I’d be surprised especially seeing what NSA did to Belgium. I have considered Finland for my operations as I actually agree with you about people over there being less risky. Like with chips though, that would only be a tiny piece of my security strategy.

” AMD already has one in Dresden.”

That other chipmaker that’s headquartered in the United States and makes all kinds of important chips? Oh I’m sure the NSA wasn’t interested in them. 😉

Nick P • December 19, 2013 9:23 AM

@ Figureitout

I think in discussing this we need to remember that Mr Moore always wears the Forth hat. His focus in programming language discipline is so narrow and consistent that he sees everything in that light. So, he may make general statements that seem true in his experience but would be dead wrong in a mainstream language. I think this is one of them.

Local variables can only be accessed within a function, loop, class, etc. They’re allocated when function is called and disappear afterward. Global variables can be accessed anywhere. They don’t disappear. This means global variables tend to take up more memory right off the bat. They might also need to go in the heap depending on the size of the program.

More relevant to our field is information hiding and POLA. POLA says to give each execution unit as little capability as it needs. For code, this would be access to certain variables, functions or language/platform capabilities. Information hiding (i.e. modularity) says to hide details behind an interface to (a) make things easy to change and (b) enforce a form of POLA. This is so powerful that it’s been used to achieve POLA in highly assured system designs and was one of the fundamentals of running unsafe code in a sandbox a la Java.

(You could even say capability architectures are about “information hiding” behind capabilities or addresses. If true, it only adds more weight to information hiding principle.)

So, Moore is saying this is all BS and we’ll be fine if we just analyse the subtle stack interactions of a ridiculous amount of code and global data. Competing languages give us types, modules, global vs local variables, interfaces, smart compilers and so on to let us think closer to the ideas we’re implementing. And catch plenty of errors before the user/hacker. Decades of programming experience shows the latter approach is superior for code security (where it was a goal lol), maintainability, productivity, reliability, and so on.

If Moore achieved these in Forth at comparable levels, it would be more a testament to his own skills rather than correctness of his claims. 😉