Welcome!

Thanks for your interest in HARES; I'm glad you're interested in the fascinating world of x86 and I wanted to answer some questions & address some misunderstandings I've been seeing following the publication of the WIRED article on HARES. As the article was much less technical than my upcoming talks, please understand that it should not be considered a deep technical dive into the research. I would very much appreciate constructive criticism or feedback and references that I may have missed during my search for related works either as a comment below or on my Twitter.

Common Misunderstandings

1. HARES is a software-only solution that does not require modifications to the existing Intel Core-i series CPU, as long as the CPU is fairly modern. HARES is implemented as a thin-hypervisor. HARES is not a "perfect security" tool, it only aims (and claims) to significantly increase the difficulty to reverse engineer a program.
2. The AES key (128 or 256-bit) for the system is not stored in a non-volatile fashion in the CPU, it must be securely loaded into the CPU at each boot and does not persist between reboots.
3. HARES uses TLB-splitting to protect the decrypted instructions, even a compromised OS kernel that tried to read out the in-memory decrypted instructions would only see the encrypted memory page(s); if the CPU is performing an instruction fetch on the page, it would transparently be redirected to the decrypted copy.

Weaknesses

1. Yes, HARES will most certainly be vulnerable to physical attacks and side-channels, Intel SGX is a very exciting technology that should encompass much of the security benefits of HARES in a more hardened, hardware-based manner.
2. HARES does not protect against AMT & SMM attacks. DMA attacks will be discussed in my upcoming talks.
3. HARES could be vulnerable to being loaded into an emulated CPU, or a nested VMM; during my technical talk at both Syscan and INFILTRATE, I will cover secure deployment mechanisms and key management ideas that would significantly reduce the likelihood of being run in an emulated environment.

Errata

1. The release of the HARES source-code has not been confirmed nor scheduled, sorry if the WIRED article got your hopes up INFILTRATE attendees.
2. Fully homomorphic encryption (FHE) could allow for a program to operate on encrypted data without having the key for decrypting that data or, Indistinguishability Obfuscation (IO), a related field would allow for a program to execute encrypted instructions without ever revealing the instructions. (EDIT: Thanks to Martin Albrecht for pointing out the differences between FHE and IO)

References & Kudos

I wanted to take a moment to cite/reference all the great past work done on this field, my "intellectual sponsors" so to speak:
1. Tilo Muller's TRESOR - This is the basis for the on-CPU AES that protects keys from cold-boot RAM attacks.
2. GRSecurity team and Jamie Butler & Sherri Sparks for their work in TLB-splitting, respectively.
3. Mudge and DARPA for their support on MoRE, the work that helped pave the way for HARES.
4. Mark Bridgman for his help on the HARES prototype.
5. Loc Nguyen and Ryan Stortz for their input on past-performance and bypass techniques.