Remarks
Claims 1-21 are pending.
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 .
Claim Objections
Claim 3 is objected to because of the following informalities: Claim 3 does not include a transitional phrase/word at the end of the penultimate limitation, such as “and” or “or”. Thus, it is unclear if all steps are required or only a single one. Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 12, 14-16, 19, and 20 are rejected under 35 U.S.C. 102(a)(1) and/or 102(a)(2) as being anticipated by Oleksenko (Oleksenko et al., “Revizor: Fuzzing for Leaks in Black-box CPUs”, 5/14/2021, 18 pages).
Regarding Claim 1,
Oleksenko discloses a method of detecting one or more side channels in a processor design, comprising:
Obtaining a program and a set of inputs for the program (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3, etc.; program and inputs, for example);
Performing the program based off the set of inputs in an instruction set simulator of the processor design to obtain a plurality of contract traces for the processor design (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; running program and getting contract traces, for example);
Performing the program based off the set of inputs in a hardware simulator of the processor design to obtain a plurality of hardware traces for the processor design (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; running program and getting hardware traces, for example); and
Comparing at least one contract trace of the plurality of contract traces and at least one hardware trace of the plurality of the hardware traces to determine whether there are one or more side channel vulnerabilities (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; comparing traces to detect violations, for example).
Regarding Claim 14,
Claim 14 is a device claim that corresponds to method claim 1 and is rejected for the same reasons.
Regarding Claim 19,
Claim 19 is a medium claim that corresponds to method claim 1 and is rejected for the same reasons.
Regarding Claim 2,
Oleksenko discloses obtaining a set of programs and sets of inputs, wherein each set of inputs of the sets of inputs corresponds to a different program of the set of programs and wherein obtaining the set of programs and the sets of inputs comprises obtaining the program and the set of inputs for the program (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3, etc.; as above for multiple programs, for example);
Performing each one of the programs in the set of programs based on the corresponding set of inputs in the instruction set simulator of the processor design to obtain pluralities of contract traces for the processor design, wherein each of the pluralities of contract traces corresponds to a different one of the programs and a different set of the inputs, wherein performing each one of the programs based on the corresponding set of inputs in the instruction set simulator of the processor design comprises performing the program based of the set of inputs in the instruction set simulator of the processor design to obtain the plurality of contract traces for the processor design (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; as above for multiple programs, for example);
Performing each one of the programs in the set of programs based on the corresponding set of inputs in the hardware simulator of the processor design to obtain pluralities of hardware traces for the processor design, wherein each of the pluralities of the hardware traces corresponds to a different one of the programs and a different set of the inputs, wherein performing each one of the programs based on the corresponding set of inputs in the hardware simulator comprises performing the program based of the set of inputs in the hardware simulator of the processor design to obtain the plurality of hardware traces for the processor design (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; as above for multiple programs, for example); and
Comparing the at least one contract trace of each of the pluralities of contract traces and the at least one hardware trace of each of the pluralities of the hardware traces to determine whether there are one or more side-channel vulnerabilities, wherein comparing the at least one contract trace of each of the pluralities of contract traces and the at least one hardware trace of each of the pluralities of the hardware traces to determine whether there are one or more side-channel vulnerabilities comprises comparing the at least one contract trace of the plurality of contract traces and the at least one hardware trace of the plurality of the hardware traces to determine whether there are one or more side-channel vulnerabilities (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; as above for multiple programs, for example).
Regarding Claim 3,
Oleksenko discloses comparing the at least one contract trace of the plurality of contract traces and the at least one hardware trace of the plurality of the hardware traces to determine whether there are one or more side-channel vulnerabilities comprises:
Determining one or more groups of contract traces, each group of contract traces includes contract traces generated as a result of implementing the same program with different inputs (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; multiple sets of inputs, for example);
For each of the one or more groups of contract traces, comparing corresponding hardware traces to one another to determine whether there is a mismatch between any of the hardware traces (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; comparing, for example);
For each group of the one or more groups of contract traces, detect a side-channel vulnerability of the one or more side-channel vulnerabilities for each instance that there is mismatch between any of the hardware traces in the group (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; if mismatch between traces, violation present, for example).
Regarding Claim 4,
Oleksenko discloses that the program is a first program, the set of inputs is a first set of inputs, the plurality of contract traces are first contract traces, the plurality of hardware traces are first hardware traces, the one or more side-channel vulnerabilities are one or more first side-channel vulnerabilities, the method further comprising (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3, 3.1, etc.;):
Obtaining a second program and a second set of inputs for the second program (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3, etc.; as above, for another program/inputs, for example);
Implementing the second set of inputs and the second program in the instruction set simulator of the processor design to obtain second contract traces (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; as above, for another program/inputs, for example);
Implementing the second set of inputs and the second program in the hardware simulator of the processor design to obtain second hardware traces (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; as above, for another program/inputs, for example); and
Comparing the second contract traces and the second hardware traces to determine whether there are one or more second side-channel vulnerabilities (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.; as above, for another program/inputs, for example).
Regarding Claim 15,
Claim 15 is a device claim that corresponds to method claim 4 and is rejected for the same reasons.
Regarding Claim 5,
Oleksenko disclose obtaining the program and the set of inputs for the program comprises generating the program and the set of inputs with a side-channel central processing unit (CPU) fuzzer that generates the program and the set of inputs based on a program seed and an input seed (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, 6.2, etc.; random programs and inputs, each experiment run with different seeds, etc., as examples).
Regarding Claim 16,
Claim 16 is a device claim that corresponds to method claim 5 and is rejected for the same reasons.
Regarding Claim 20,
Claim 20 is a medium claim that corresponds to method claim 5 and is rejected for the same reasons.
Regarding Claim 12,
Oleksenko discloses performing the program based off the set of inputs in an instruction set simulator of the processor design to obtain a plurality of contract traces for the processor design comprises implementing the instruction set simulator in accordance with a speculation contract that indicates the contract traces based on the program and the set of inputs (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3, etc.).
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 6, 7, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Oleksenko in view of Kande (Kande et al., “TheHuzz: Instruction Fuzzing of Processors Using Golden-Reference Models for Finding Software-Exploitable Vulnerabilities”, 1/24/2022, 23 pages).
Regarding Claim 6,
Oleksenko discloses generating the program seed and the input seed with a seed generator based on data (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, 6.2, etc.);
Oleksenko does not appear to explicitly disclose generating a master seed; and that the data is the master seed.
Kande, however, discloses generating a master seed; and generating the seeds with a seed generator based on the master seed (Exemplary Citations: for example, Sections 2.1, 4, 4.2, etc.; generating seeds and then further information, such as inputs based on the seeds, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the seeding techniques of Kande into the fuzzing system of Oleksenko in order to allow the system to capture additional behaviors, to allow the system to deal with signal transitions and floating wires, to allow for additional entropy via explicit seed generation, and/or to increase security in the system.
Regarding Claim 17,
Claim 17 is a device claim that corresponds to method claim 6 and is rejected for the same reasons.
Regarding Claim 7,
Oleksenko as modified by Kande discloses the method of claim 6, in addition, Oleksenko as modified by Kande discloses implementing a verification environmental interface to prepare the program seed and the input seed to be functional with the side-channel CPU fuzzer before the side-channel CPU fuzzer generates the program and the set of inputs based on the program seed and the input seed (Oleksenko: Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, 6.2, etc.; random programs/inputs based on seeds, for example; Kande: Exemplary Citations: for example, Sections 2.1, 4, 4.2, etc.; generating seeds then generating from seeds, for example).
Claims 8, 9, 13, 18, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Oleksenko in view of Canakci (Canakci et al., “ProcessorFuzz: Guiding Processor Fuzzing using Control and Status Registers”, 9/5/2022, 17 pages).
Regarding Claim 8,
Oleksenko discloses that comparing at least one contract trace of the plurality of contract traces and at least one hardware trace of the plurality of hardware traces to determine whether there are one or more side-channel vulnerabilities comprises:
Associating contract traces and hardware traces (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.); and
Comparing the contract traces and the hardware traces to determine the one or more side-channel vulnerabilities (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, etc.);
But does not explicitly disclose implementing an aggregator that generates database entries and performs the associating, storing the database entries in a database, and implementing a database analyzer that performs the comparing.
Canakci, however, discloses implementing an aggregator that generates database entries associating contract traces and hardware traces (Exemplary Citations: for example, sections 2.2, 3.1, etc.; transition map associates traces between the simulations, for example);
Storing the database entries in a database (Exemplary Citations: for example, sections 2.2, 3.1, etc.; storing in transition map, for example); and
Implementing a database analyzer that compares the contract traces and the hardware traces to determine the one or more side-channel vulnerabilities (Exemplary Citations: for example, sections 2.2, 3.1, 3.5, etc.; analyzing the above for mismatches, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the transition mapping techniques of Canakci into the fuzzing system of Oleksenko in order to allow the system to keep track of interesting inputs via a database of mappings, to focus on only those inputs that are interesting when matching between the traces, and/or to allow for better verification of vulnerabilities.
Regarding Claim 18,
Claim 18 is a device claim that corresponds to method claim 8 and is rejected for the same reasons.
Regarding Claim 21,
Claim 21 is a medium claim that corresponds to method claim 8 and is rejected for the same reasons.
Regarding Claim 9,
Oleksenko as modified by Canakci discloses the method of claim 8, in addition, Oleksenko discloses obtaining the program and the set of inputs for the program comprises generating the program and the set of inputs with a side-channel central processing unit (CPU) fuzzer that generates the program and the set of inputs based on a program seed and an input seed (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, 6.2, etc.).
Regarding Claim 13,
Oleksenko does not appear to explicitly disclose that the hardware simulator of the processor design is a register transfer level (RTL) simulator.
Canakci, however, discloses that the hardware simulator of the processor design is a register transfer level (RTL) simulator (Exemplary Citations: for example, Abstract, sections 2.2, 3.1, etc.; RTL simulator, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the transition mapping techniques of Canakci into the fuzzing system of Oleksenko in order to allow the system to keep track of interesting inputs via a database of mappings, to focus on only those inputs that are interesting when matching between the traces, and/or to allow for better verification of vulnerabilities.
Claims 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Oleksenko in view of Canakci and Kande.
Regarding Claim 10,
Oleksenko as modified by Canakci discloses the method of claim 9, in addition, Oleksenko discloses generating the program seed and the input seed with a seed generator based on data (Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, 6.2, etc.);
But does not appear to explicitly disclose generating a master seed; and that the data is the master seed.
Kande, however, discloses generating a master seed; and generating the seeds with a seed generator based on the master seed (Exemplary Citations: for example, Sections 2.1, 4, 4.2, etc.). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the seeding techniques of Kande into the fuzzing system of Oleksenko as modified by Canakci in order to allow the system to capture additional behaviors, to allow the system to deal with signal transitions and floating wires, to allow for additional entropy via explicit seed generation, and/or to increase security in the system.
Regarding Claim 11,
Oleksenko as modified by Canakci and Kande discloses the method of claim 10, in addition, Oleksenko as modified by Kande discloses implementing a verification environmental interface to prepare the program seed and the input seed to be functional with the side-channel CPU fuzzer before the side-channel CPU fuzzer generates the program and the set of inputs based on the program seed and the input seed (Oleksenko: Exemplary Citations: for example, Abstract, Sections 2.1, 2.2, 3.1, 6.2, etc.; Kande: Exemplary Citations: for example, Sections 2.1, 4, 4.2, etc.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeffrey D Popham whose telephone number is (571)272-7215. The examiner can normally be reached Monday through Friday 9:00-5:30.
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 Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey D. Popham/Primary Examiner, Art Unit 2432
Prosecution Insights