Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-20 are pending in this office action.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on August 24, 2023, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lin (Novel Techniques in Recovering, Embedding, and Enforcing Policies for Control-Flow Integrity) in view of Mashtizadeh et al. (CCFI: Cryptographically Enforced Control Flow Integrity).
Regarding claims 1, 8, and 15, Lin teaches an apparatus comprising: a cryptographic circuit to encrypt, with a first key, a first code section to be stored in a single page of memory, and to encrypt, with a second key, a second code section to be stored in the single page of memory (page 53, section 4.1, encrypts each basic block in the program with a key derived from the CFG); decoder circuitry to decode a single instruction into a decoded instruction, the single instruction comprising a key identifier, an identifier of the second code section, and an opcode (page 11, section 2.3.2, Most of these CFI approaches rely on the availability of source code. MCFI [23] propagates source-level information such as type information to the binary level as metadata, and gathers such metadata at program load time to build a precise CFG, which is consulted (or read) by the program to detect CFI violations. Specifically, when a code module is loaded during execution, the loading module’s metadata is combined with the loaded module’s metadata to compute a CFG for both modules, and then the old CFG will be replaced with the new CFG. πCFI [24] starts a program with an empty CFG and let the program itself lazily compute the CFG on the fly) that is to indicate execution circuitry is to, when executing the first code section, determine if the key identifier corresponds to the second key, and in response to corresponding, cause the cryptographic circuit to switch to using the second key to decrypt the second code section, and transfer execution from the first code section to the second code section (page 56, section 4.2.2, whenever the program attempts a control transfer, C3 obtains the caller and callee addresses and reconstructs the key to decrypt the callee basic block before control transfer takes place).
Lin does not teach the execution circuitry to execute the decoded instruction according to the opcode.
Mashtizadeh et al. teaches the execution circuitry to execute the decoded instruction according to the opcode (page 941, abstract, we implemented CCFI in Clang/LLVM, taking advantage of recently available cryptographic CPU instructions (AES-NI).).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine executing the decoded instruction according to the opcode, as taught by Mashtizadeh et al., with the method of Lin. It would have been obvious for such modifications because Lin’s native hardware support at the hardware layer would look to Mashtizadeh et al. which teaches how to construct and execute a hardwares-assisted, cryptographically-enforced control-flow platform utilizing native CPU decoding and execution pipelines.
Regarding claims 2, 9, and 16, Lin teaches wherein the opcode is to indicate that the execution circuitry is to, in response to the key identifier not corresponding to the second key, cause a fault (page 95, chapter 6, this kind of “proof-carrying" code ensures only valid control-flow transfers can decrypt the corresponding instruction sequence and any unintended control-flow transfer would cause program crash).
Regarding claims 3, 10, and 17, Lin as modified by Mashtizadeh et al. teaches further comprising a key identification register, wherein the switch of the cryptographic circuit to using the second key to decrypt the second code section comprises updating the key identification register with the second key (see page 942, section 1, the random secret key used for computing these MACs is stored in dedicated registers so that it can never leak by a memory disclosure bug of Mashtizadeh et al.).
Regarding claims 4, 11, and 18, Lin as modified by Mashtizadeh et al. teaches wherein the second key is a proper subset of a second host physical address for the second code section to be stored in a page table (see page 943, section 4, the MAC is stored alongside the object. Attackers cannot overwrite control objects because they do not posses the MAC key needed to produce a valid MAC for the object. The MAC key is randomly generated at program start, and stored in registers the CCFI compiler reserves (in x86-64 we use XMM5–XMM15). of Mashtizadeh et al.).
Regarding claims 5, 12, and 19, Lin as modified by Mashtizadeh et al. teaches wherein the execution circuitry is to cause removal of the second key from the second host physical address to generate a modified second host physical address that is to be used to access the second code section (see page 941, section 1, this paper introduces a dynamic approach to control flow integrity that allows our compiler to efficiently encode and modify pointer classification at runtime. We associate metadata with all control flow pointers that prevent attackers from arbitrarily swapping or modifying pointers. of Mashtizadeh et al.).
Regarding claims 6, 13, and 20, Lin teaches wherein the opcode is to indicate that the execution circuitry is to, in response to the key identifier corresponding to the second key, switch a page table pointer to an entry that points to the second host physical address (page 10, section 2.3.1, all indirect branches are instrumented to jump to the corresponding address translation routine that determines the targets of the transfers, if one target cannot be found, it means there is a controlflow hijacking attack. However, whenever there is a control-flow transfer, the CFI checks are always executed. Our proposed approach DynCFI does not require to perform CFI check for each control-flow transfer due to the trace mechanism used in the dynamic code optimization platform DynamoRIO [17]. Specifically, the trace mechanism can avoid some indirect branch lookups by inlining a popular target of an indirect branch into a trace.).
Regarding claims 7 and 14, Lin teaches wherein the key identifier is the second key, and the second key is to be generated by adding a compile-time constant for the second code section to a signature value for the first code section (page 56, section 4.2.2, Embedding CFG. C3 transforms branch transfer instructions (indirect branches, conditional jumps, and direct calls) to have a secret share embedded, and then redistributes basic blocks to specific addresses so that all valid callers are on the same secret sharing curve.).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON HOFFMAN whose telephone number is (571)272-3863. The examiner can normally be reached Monday-Friday 8:30AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Pwu can be reached at (571)272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRANDON HOFFMAN/Primary Examiner, Art Unit 2433
Prosecution Insights