0000:000030000000w_000000000.0000000v>0:0
`
`600000099000000.0mmo00003000000000E.
`
`
`
`
`
`
`000000000000000000000
`
`
`:0:0.00:0000000000000.0000000EE00000000000.0050>_._n0000000000000000w000000
`
`0.00000000:
`
`
`
`0IntoIotln0notQnoIononIonoacounol-noucloncnuncnIocouucouoooooo-noon"
`
`
`
`:o:uv.3_L.:D.:3)
`
`
`
`
`
`00000.0.~=0.=00.==0£=V0000030.0.00=u..0..,~
`
`003..0000_0000000000000000000003
`
`
`
`
`
`
`0.05000000000005.0000.00n__E0000:_0_::0000000.0000030000
`
`
`
`0000000000000000.00005000000000000000000000003000000090.00..0000000000000000m00000
`
`
`
`
`_
`
`
`
`00000>0.000000000300000.000.00.0000:
`
`
`
`
`
`
`
`
`>00.>t._0>000000000000000000000000>000EE0000000000:0000000000000.0
`
`
`000000ED00000000000000000000000£003
`
`
`
`00000000090>000m0000000200000
`
`
`
`uuofimmoE.=.t..Oo00>0v_._m>m_Q
`
`
`
`
`0000050080mmo.00;
`
`
`
`
`00m00.00000:5000000w0_0000_x—mmo
`
`
`
`
`
`
`
`
`
`
`000.0000W.0000000000000000=m00o0-mmOcw0m_000000m_m.00Fm_00_00030200200-050000080-000<I>00_>c0_000000_0__..fl_0G.r0_W.000050:000000500000000.0_-mmOIE_000.E00.0w0_00000.W..00000>00.>0_.0>we...0.000>£00\000B0000
`
`
`
`
`
`
`9000000000000003000000=-mmUI
`
`
`
`
`80000000000000w00000020.000I>00.0m:0__0c000000000w.
`
`
`.
`
`U
`
`
`
`
`
`
`
`0000800900000_>0.2000000000000000I
`
`
`
`
`
`
`:0:0000000000M00300000_0w000_000>00mIEECOO00>0_00>%0000
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`00000w000000000000000000002.000$00.030mc__._000.E000.0000N>00.00:00000000000000000000030000000030c0_000_E0£:0R0000000>_0>0._.00000.00000000.0.3.O0000mmo300000000.0.0000.020080mm000000200.50»mm__.”.0._.0.._.0._»_m,.n_w.0M_“0..mm00m.w%003000000000F...0.00000000C0000000000:wmo00_00000000000000000.0000000000000003000000000000030.0_0E0x00000020000M.M00000000000000mx.h00000000.00000m0003..0230w0.0000000309.0...M._000_w0005000000000000m0003.000000E000_.mm_.__._.80..82>7.0EZ00000m00000.020o%_>.0>085.005502...,as0.0282.2000.T.0000:0>00.00:000:$0.0.00000000000000000000000.0000=000.0=00—Z005000090000000w00.00_0_00..000.00.0000050000000.00:005000000009000.3.0000PEE00000000000.0000020000.000000..00000:.m=0000,0800%2:.
`
`
`
`
`
`
`
`00..0000_000.~0MImm.M>_m00n_._m...00.w00_@0000000w._0w.0m0m0mm0%...00B0=0000000__.m003:000000_W_90000000000>_00>_0:00c0000:_0000:N>00.>0_00>35>00.0:0000.0000D00_0.0000000
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`00000.00000.500000:0000002..0000?5:5000%0».wn00_%0w00m%0x020%E0000000003>00.030:00.000.0.0:wW00000000
`
`
`
`
`
`
`
`00000:mmo<.E2§0>00§._.8=.00<
`
`0030000000000000000000I
`
`
`
`
`
`
`
`
`
`
`69e0
`
`
`
`

`
`
`
`
`
`zozuopou...:._oZ._oD..
`
`
`
`on:..2...........................
`
`
`
`
`
`
`
`
`
`
`
`
`Emuhmmmoufi2:3uuEauu:uBa35EouuuwwewEuEouoxczm5ouE>ufiEauuuu8cu»:
`
`
`
`
`
`
`
`mmauxus:Uufiauuucuxrx..auxus:Euuuwmuamum:umzuufinom,H>xuumqouuumwufiauucu
`
`
`auxus.5uoxmBxEobaux8:.ufiBmauouuwasmu>uEuuuuamxmN8.5.aux8:.ufiu>u_.:2
`nuuumouuuuu:uouuumufiEuuuouwauxus:ufiEauuuu9aux8:.2:um::8:.xucE
`
`
`
`
`
`
`8uxnmanuuamxmufiwctucauumuaaxm:2:H8auxuuumauonuufiEcoE8momzuu:::__
`
`
`mauxuw:u=unumum:uu_>uuscam.EuEouuuuouuoaabout8mxmmomouwfimvacuumof.
`
`aux23.2%uwas8%scam.aEofi=mwfiwauuzufian:9ounmxmmm95we“umEVaux__
`
`.oumxEoEEooup9Esoax3auxuuamxmmex35m_Eufiuwcmbm£5mou8&_augh.maux.9
`
`-33mow5:»3,555aux8:.ufimifinooxuoxnauxunu..uuSxobcouufiEuuuoumxusz
`
`
`
`
`
`
`mu:uuamxmxoum.§_§&oMON29%uwan:muwcmnoxuauxuuatfiEauunu9cum:m_£2.
`
`
`ufiuu>oE8.~u>u:mm533.auxmanBE..aux25uuafiunum9mu:cobmuuaufism2::._3._._
`
`
`
`
`
`
`
`
`
`uouaauouucanuoumuucufiaucuwficsxoi.uSB£om\uSBEunwfi_UOUDU_uum:uu:-wmO
`
`
`
`uumauumnzonaouaufism5:5u>_€x>xOm-Q>Qwum:uu=-mmU<
`
`
`
`
`
`
`
`
`
`”wEBo=omufiu>un9vubawuuuummuuusafiouEm=mEoo-mmU
`
`
`
`momnewuu=u=nEuUcanwfimauufiwmo
`
`.uu.E_u
`
`
`
`
`
`ufianuuE>oEupaaavown.ufimvuouuuanoxmfluumfi..uuBo=umuxaouon:wecouuuaumI
`
`
`
`
`HOuuuzézmnmocozmuwuufiHocososwoaufiEwu>_o>EEufiwumatmsui§_aE8a:<
`
`uwfimwas8:8:mEfiao2uuhncuuupamfimmoanwuuuuwmuuu:2:Equaoafiouuumzéom
`
`afiufiamHou>_€
`
`
`
`
`
`AmmumSufiuufiov39:0ouE>woxmcmwezosouuoum
`
`
`
`39:0xmzmxuyomouuuuoum
`
`
`
`
`
`2233Eufiumacmfixusoxwum
`
`
`
`
`
`mufi0EOQEOoO0—u_>vum:uu=-mmD
`
`
`
`mufiouumauoucwéasumfimmu:o::u>u§
`
`
`
`
`
`
`
`
`
`mu:mmuosmco=uo_Eu£:u
`
`
`-mamwcsfiumoufi:5._.,.:_aéa=a_uEoHo:mmumauuzmmo<.m._uxu2Euamamu.._..:..ao
`
`
`
`
`
`
`
`cuaauoucmoEaubwmto5%9cu.$o=mup8:$2:xufikaouE>m.uEEuxuSm.mEmu:m
`
`
`3%mmHOmufimmuufixuwufiooup8:58=35omSawuufiauuuu83052:05E8
`
`
`
`
`
`
`
`
`
`530:8maanouuvzmuu8.an
`
`-Q>Qmomuxmouummfixéa20358uxnmauHo:omxm358m0uxh.xomnam_mwaistouE>
`
`
`
`
`
`
`-umxuvuxucun8:amoatouE>.Q>QH8EufiuwmcmfiEaoxmuuufi5&33:5mOugh
`ufiEcoumfiuomimade.wasmmfl£33uuufiuufi8:5Q8uE>o.E3:5mOus?.uuu:.$
`
`
`
`.wum:uouE>
`
`
`
`
`
`
`
`
`
`mu>u:$2:mumzuuuumauuauuumummuuE8uuummfiE5muxaamfioo.m..u.:=u&=:u_>x85
`330%coumuzmmmufiM8552umamfiumnuozmmo<.€2_22a:=o=uu=.E<
`
`
`
`
`-52:Howuxnmmaommuuuumauxh.éouuumEauucucanmaux8:..€%3uuuuoEumauuzmmv
`
`
`
`
`.wOcammmnosuxbmuuufimwufi9Sufismmxnoumuzammunp..35ouE>.Q>Dmuuuxsmxqwfi
`
`
`
`.3950ouE>
`
`
`
`afifiiomxanoumapuauuficanmauxufimoauuuuumufiminus
`
`
`
`_.E_.Eoo9aux.uau_aa:._u>
`
`
`
`uo:uE._o.Eoommo“mo:
`
`:0vumun—.amxuuuuucum
`
`
`
`om_uucuaux.uau_aumoc
`
`
`
`>9.=o=_8_Eu£.a
`
`3Eu.E9:
`
`a_Euucuauu:_9um:_NauxaEu>
`
`
`
`.8_auxmanmcE2uEu..u._u:um
`
`
`
`u:u._u:umumuooamsxoub.8D.Eu._mu:c_::
`
`
`
`
`
`
`
`:_._:u>_.n
`
`
`
`nauuuuk§Q.~uG.9._u§3\u=v\
`
`.auxwas5:5uuuomaao
`
`c_vuu_E0:auxomficuu.
`.9ou.....Eotauxu_Euuu.
`>0v_um:u__u.._outeucum
`
`
`53>ufiouanouuuuuc
`
`auxmanucuauxuzz
`z/‘ XPETlTIO%ER-O%3LE&\4PPLE-7£H|B
`\_
`
`T 1008
`
`- Page 97
`
`ux
`
`
`
`

`
`FEDERAL INFORMATION
`
`PROCESSING STANDARDS PUBLICATION l85
`
`l994 February 9
`
`U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology
`
`ESCROWED ENCRYPTION STANDARD
`
`CATEGORY:
`
`TELECOMMUNICATIONS
`
`SECURITY
`
`U.S. DEPARTMENT OF COMMERCE, Ronald H. Brown, Secretary
`NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY,
`
`Arati Prabhakar, Director
`
`Foreword
`
`The Federal Information Processing Standards Publication Series of
`the National Institute of Standards and Technology (NIST)
`is the
`official series of publications relating to standards and
`guidelines adopted and promulgated under the provisions of Section
`lll(d) of the Federal Property and Administrative Services Act of
`1949 as amended by the Computer Security Act of 1987, Public Law
`lOO—235.
`These mandates have given the Secretary of Commerce and
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 98
`
`

`
`NIST important responsibilities for improving the utilization and
`management of computer and related telecommunications systems in
`the Federal Government.
`The NIST,
`through the Computer Systems
`Laboratory, provides leadership,
`technical guidance, and
`coordination of Government efforts in the development of standards
`and guidelines in these areas.
`
`Comments concerning Federal Information Processing Standards
`Publications are welcomed and should be addressed to the Director,
`
`Computer Systems Laboratory, National Institute of Standards and
`Technology, Gaithersburg, MD 20899.
`
`James H. Burrows, Director
`Computer Systems Laboratory
`
`Abstract
`
`This standard specifies an encryption/decryption algorithm and a
`Law Enforcement Access Field (LEAF) creation method which may be
`implemented in electronic devices and used for protecting
`government
`telecommunications when such protection is desired.
`algorithm and the LEAF creation method are classified and are
`referenced, but not specified,
`in the standard. Electronic devices
`implementing this standard may be designed into cryptographic
`modules which are integrated into data security products and
`systems for use in data security applications.
`The LEAF is used in
`a key escrow system that provides for decryption of
`telecommunications when access to the telecommunications is
`
`The
`
`lawfully authorized.
`
`Key words: Cryptography, Federal Information Processing Standard,
`encryption, key escrow system,
`security.
`
`FIPS PUB 185
`
`Federal Information
`
`Processing Standards Publication 185
`
`1994 February 9
`
`Announcing the
`
`Escrowed Encryption Standard (EES)
`
`Federal Information Processing Standards Publications (FIPS PUBS)
`are issued by the National Institute of Standards and Technology
`(NIST) after approval by the Secretary of Commerce pursuant to
`Section 111(d) of the Federal Property and Administrative Services
`Act of 1949 as amended by the Computer Security Act of 1987, Public
`Law 100-235.
`
`Name of Standard:
`
`Escrowed Encryption Standard (EES).
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 99
`
`

`
`Category of Standard: Telecommunications Security.
`
`Explanation: This Standard specifies use of a symmetric—key
`encryption (and decryption) algorithm (SKIPJACK) and a Law
`Enforcement Access Field (LEAF) creation method (one part of a key
`escrow system) which provides for decryption of encrypted
`telecommunications when interception of the telecommunications is
`lawfully authorized. Both the SKIPJACK algorithm and the LEAF
`creation method are to be implemented in electronic devices (e.g.,
`very large scale integration chips).
`The devices may be
`incorporated in security equipment used to encrypt
`(and decrypt)
`sensitive unclassified telecommunications data. Decryption of
`lawfully intercepted telecommunications may be achieved through the
`acquisition and use of the LEAF,
`the decryption algorithm and
`the two escrowed key components.
`
`One definition of "escrow" means that something (e.g., a document,
`an encryption key)
`is "delivered to a third person to be given to
`the grantee only upon the fulfillment of a condition" (Webster's
`Seventh New Collegiate Dictionary).
`The term, "escrow", for
`purposes of this standard,
`is restricted to this dictionary
`definition.
`
`is one that
`for purposes of this standard,
`A key escrow system,
`entrusts the two components comprising
`a cryptographic key (e.g.,
`a device unique key)
`to two
`key component holders (also called
`"escrow agents").
`In accordance with the above definition of
`"escrow",
`the key component holders provide the components of a key
`to a "grantee" (e.g., a law enforcement official) only upon
`fulfillment of the condition that the grantee has properly
`demonstrated legal authorization to conduct electronic surveillance
`of telecommunications which are encrypted using the specific device
`whose device unique key
`is being requested.
`The key components
`obtained through this process are then used by the grantee to
`reconstruct the device unique key and obtain the session key which
`is then used to decrypt
`the telecommunications that are encrypted
`with that session key.
`
`The SKIPJACK encryption/decryption algorithm has been approved for
`government applications requiring encryption of sensitive but
`unclassified data telecommunications as defined herein.
`The
`
`specific operations of the SKIPJACK algorithm and the LEAF creation
`method are classified and hence are referenced, but not specified,
`in this standard.
`
`Data for purposes of this standard includes voice, facsimile and
`computer information communicated in a telephone system.
`A
`telephone system for purposes of this standard is limited to a
`system which is circuit switched and operating at data rates of
`standard commercial modems over analog voice circuits or which uses
`basic—rate ISDN or a similar grade wireless service.
`
`Data that is considered sensitive by a responsible authority should
`be encrypted if it is vulnerable to unauthorized disclosure during
`telecommunications.
`A risk analysis should be performed under the
`direction of a responsible authority to determine potential threats
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 100
`
`

`
`The costs of providing encryption using this standard
`and risks.
`as well as alternative methods and their respective costs should be
`projected.
`A responsible authority should then make a decision,
`based on the risk and cost analyses, whether or not to use
`encryption and then whether or not to use this standard.
`
`Approving Authority: Secretary of Commerce.
`
`Maintenance Agency: Department of Commerce, National Institute of
`Standards and Technology.
`
`This standard is applicable to all Federal
`Applicability:
`departments and agencies and their contractors under the conditions
`specified below. This standard may be used in designing and
`implementing security products and systems, which Federal
`departments and agencies use or operate or which are operated for
`them under contract.
`These products may be used when replacing
`Type II and Type III (DES) encryption devices and products owned by
`the government and government contractors.
`
`This standard may be used when the following conditions apply:
`
`An authorized official or manager responsible for data
`1.
`security or the security of a computer system decides that
`encryption is required and cost justified as per OMB Circular A-
`130; and
`
`The data is not classified according to Executive Order
`2.
`12356, entitled "National Security Information," or to its
`successor orders, or to the Atomic Energy Act of 1954, as amended.
`
`However, Federal departments or agencies which use encryption
`devices for protecting data that is classified according to either
`of these acts may use those devices also for protecting
`unclassified data in lieu of this standard.
`
`this standard may be adopted and used by non—Federal
`In addition,
`Government organizations.
`Such use is encouraged when it provides
`the desired security.
`
`Applications: This standard may be used in any unclassified
`government and commercial communications. Use of devices
`conforming to this standard is voluntary for unclassified
`government applications and for commercial security applications.
`
`The encryption/decryption algorithm and the LEAF
`Implementations:
`creation method shall be implemented in electronic devices (e.g.,
`electronic chip packages) which are protected against unauthorized
`entry, modification and reverse engineering.
`Implementations which
`are tested and validated by NIST will be considered as complying
`with this standard.
`An electronic device shall be incorporated
`into a cryptographic module in accordance with FIPS 140-1. NIST
`will test for conformance with FIPS 140-1. Conforming
`cryptographic modules can then be integrated into security
`equipment for sale and use in a security application.
`Information
`about devices that have been validated,
`procedures for testing
`equipment for conformance with NIST standards, and information
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 101
`
`

`
`about approved security equipment are available from the Computer
`Systems Laboratory, NIST, Gaithersburg, MD 20899.
`
`Implementations of this standard are subject to
`Export Control:
`Federal Government export controls as specified in Title 22, Code
`of Federal Regulations, Parts 120 through l3l
`(International
`Traffic of Arms Regulations — ITAR). Exporters of encryption
`devices, equipment and technical data are advised to contact the
`U.S. Department of State, Office of Defense Trade Controls for more
`information.
`
`Implementations of
`Patents:
`and foreign patents.
`
`this standard may be covered by U.S.
`
`Implementation Schedule: This standard becomes effective thirty
`days following publication of this FIPS PUB.
`
`Information Processing Standard (FIPS 185),
`Specifications: Federal
`Escrowed Encryption Standard (EES)
`(affixed).
`
`Cross Index:
`
`FIPS PUB 46-2, Data Encryption Standard.
`a.
`FIPS PUB 81, Modes of Operation of the DES
`b.
`FIPS PUB 140-1, Security Requirements for Cryptographic
`c.
`Modules.
`
`GLOSSARY:
`
`The following terms are used as defined below for purposes of this
`standard:
`
`Data — Unclassified voice, facsimile and computer information
`communicated over a telephone system.
`
`Decryption — Conversion of ciphertext to plaintext through the use
`of a cryptographic algorithm.
`
`— An electronic implementation of the
`Device (cryptographic)
`encryption/decryption algorithm and the LEAF creation method as
`specified in this standard.
`
`Digital data — Data that have been converted to a binary
`representation.
`
`Encryption — Conversion of plaintext to ciphertext through the use
`of a cryptographic algorithm.
`
`— The
`Key components
`(e.g., KUl ~ KU2).
`
`two values from which a key can be derived
`
`Key escrow — The processes of managing (e.g., generating, storing,
`transferring, auditing)
`the two components of a cryptographic key
`by two key component holders.
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 102
`
`

`
`— A part of a key escrow system that is
`LEAF Creation Method
`implemented in a cryptographic device and creates a Law Enforcement
`Access Field.
`
`Type I cryptography — A cryptographic algorithm or device approved
`by the National Security Agency for protecting classified
`information.
`
`Type II cryptography — A cryptographic algorithm or device approved
`by the National Security Agency for protecting sensitive
`unc'assified information in systems as specified in section 2315 of
`Title 10 United States Code, or section 3502(2) of Title 44, United
`States Code.
`
`Type III cryptography — A cryptographic algorithm or device
`approved as a Federal Information Processing Standard.
`
`Type III(E) cryptography — A Type III algorithm or device that is
`approved for export from the United States.
`
`Qualifications: The protection provided by a security product or
`system is dependent on several factors.
`The protection provided by
`the SKIPJACK algorithm against key search attacks is greater than
`that provided by the DES algorithm (e.g.,
`the cryptographic key is
`longer). However, provisions of this standard are intended to
`ensure that information encrypted through use of devices
`implementing this standard can be decrypted by a legally authorized
`entity.
`
`Where to Obtain Copies of the Standard: Copies of this publication
`are for sale by the National Technical
`Information Service, U.S.
`Department of Commerce, Springfield, VA 22161. When ordering,
`refer to Federal Information Processing Standards Publication 185
`(FIPS PUB 185), and identify the title. When microfiche is
`desired,
`this should be specified. Prices are published by NTIS in
`current catalogs and other issuances.
`Payment may be made by
`check, money order, deposit account or charged to a credit card
`accepted by NTIS.
`
`Federal Information
`
`Processing Standards Publication 185
`
`1994 February 9
`
`Specifications for the
`
`ESCROWED ENCRYPTION STANDARD
`
`1.
`
`INTRODUCTION
`
`This publication specifies Escrowed Encryption Standard (EES)
`functions and parameters.
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 103
`
`

`
`2. GENERAL
`
`This standard specifies use of the SKIPJACK cryptographic algorithm
`and a LEAF Creation Method to be implemented in an approved
`electronic device (e.g., a very large scale integration electronic
`chip).
`The device is contained in a logical cryptographic module
`which is then integrated in a
`security product for encrypting and
`decrypting telecommunications.
`
`Approved implementations may be procured by authorized
`organizations for integration into security equipment. Devices
`must be tested and validated by NIST for conformance to this
`standard. Cryptographic modules must be tested and validated by
`NIST for conformance to FIPS l40—l.
`
`3.
`
`ALGORITHM SPECIFICATIONS
`
`The specifications of the encryption/decryption algorithm
`(SKIPJACK) and LEAF Creation Method 1
`(LCM—l) are classified.
`
`The
`
`National Security Agency maintains these classified specifications
`and approves the manufacture of devices which implement
`the
`specifications.
`NIST tests for conformance of the devices
`implementing this standard in cryptographic modules to FIPS l40—l
`and FIPS 81.
`
`4.
`
`FUNCTIONS
`
`AND PARAMETERS
`
`4.l
`
`FUNCTIONS
`
`The following functions, at a minimum, shall be implemented:
`
`A session key (80 bits) sha" be used to
`1. Data Encryption:
`encrypt plaintext information in one or more of the fo"owing modes
`of operation as specified in FIPS 8l:
`ECB, CBC, OFB (64), CFB (l,
`8, 16, 32, 64).
`
`The session key (80 bits) used to
`2. Data Decryption:
`encrypt the data shall be used to decrypt resulting ciphertext to
`obtain the data
`
`A Family Key (e.g., KF—l) shall be used to
`LEAF Creation:
`3.
`create a Law Enforcement Access Field (LEAF)
`in accordance with a
`
`The security equipment shall
`LEAF Creation Method (e.g., LCM—l).
`ensure that the LEAF is transmitted in such a manner that the LEAF
`
`No
`and ciphertext may be decrypted with legal authorization.
`additional encryption or modification of the LEAF is permitted.
`
`4.2
`
`PARAMETERS
`
`The following parameters shall be used in performing the
`prescribed functions:
`
`The identifier unique to
`(UID):
`1. Device Unique Identifier
`a particular device and used by the Key Escrow System.
`
`2. Device Unique Key (KU):
`
`The cryptographic key unique to
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 104
`
`

`
`a particular device and used by the Key Escrow System.
`
`The field identifying
`3. Cryptographic Protocol Field (CPF):
`the registered cryptographic protocol used by a particular
`application and used by the Key Escrow System (reserved for future
`specification and use).
`
`A binary pattern that is
`(EA):
`Escrow Authenticator
`4.
`inserted in the LEAF to ensure that the LEAF is transmitted and
`
`received properly and has not been modified, deleted or replaced in
`an unauthorized manner.
`
`A mode and application
`(IV):
`Initialization Vector
`5.
`dependent vector of bytes used to initialize, synchronize and
`verify the encryption, decryption and key escrow functions.
`
`The cryptographic key stored in all
`Family Key (KF):
`6.
`devices designated as a family that is used to create a LEAF.
`
`The cryptographic key used by a device
`Session Key (KS):
`7.
`to encrypt and decrypt data during a session.
`
`8.
`
`Law Enforcement Access Field (LEAF):
`
`The field
`
`containing the encrypted session key and the device identifier and
`the escrow authenticator.
`
`5.
`
`IMPLEMENTATION
`
`The Cryptographic Algorithm (i.e., SKIPJACK) and a LEAF Creation
`Method (e.g., LCM—l) shall be implemented in an electronic device
`(e.g., VLSI chip) which is highly resistant to reverse engineering
`(destructive or non—destructive)
`to obtain or modify the
`the CPF,
`cryptographic algorithm,
`the UID,
`the KF,
`the KU,
`the EA,
`the operational KS, and any other security or Key Escrow System
`relevant information.
`The device shall be able to be
`
`programmed/personalized (i.e., made unique) after mass production
`in such a manner that the UID, KU (or its components), KF (or its
`components) and EA fixed pattern can be entered once (and only
`once) and maintained without external electrical power.
`
`The
`The LEAF and the IV shall be transmitted with the ciphertext.
`specifics of the protocols used to create and transmit the LEAF,
`IV, and encrypted data shall be registered and a CPF assigned.
`CPF
`(and the KF—ID, LCM—ID) shall then be transmitted in
`
`The
`
`accordance with the registered specifications.
`
`Various devices implementing this standard are anticipated.
`implementation may vary with the application.
`The specific
`electric, physical and logical interface will vary with the
`implementation.
`Each approved, registered implementation shall
`have an unclassified electrical, physical and 'ogica'
`interface
`specification sufficient for an equipment manufacturer to
`Some of
`understand the general requirements for using the device.
`the requirements may be classified and therefore would not be
`specified in the unclassified interface specification.
`
`The
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 105
`
`

`
`(each a
`The device Unique Key shall be composed of two components
`minimum of 80 bits long) and each component shall be independently
`generated and stored by an escrow agent.
`The session key used to
`encrypt transmitted information shall be the same as the session
`key used to decrypt received information in a two—way simultaneous
`communication.
`The Lead Creation Method (LCM),
`the Cryptographic
`Protocol Field (CPF), and the Family Key Identifier (KF—ID) shall
`be registered in the NIST Computer Security Object Register.
`
`It does not
`This standard is not an interoperability standard.
`provide sufficient information to design and implement a security
`device or equipment. Other specifications and standards will be
`required to assure interoperability of EES devices in various
`applications. Specifications of a particular EES device must be
`obtained from the manufacturer.
`
`The specifications for the SKIPJACK algorithm are contained in the
`R21 Informal Technical Report entitled "SKIPJACK"
`(S), R2l—TECH—
`044—9l, May 21,
`l99l.
`The specifications for LEAF Creation Method
`1 are contained in the R21 Informal Technical Report entitled "Law
`Enforcement Access Field for the Key Escrow Microcircuit" (S).
`Organizations holding an appropriate security clearance and
`entering into a Memorandum of Agreement with the National Security
`Agency regarding implementation of the standard will be provided
`access to the classified specifications.
`Inquiries may be made
`regarding the Technical Reports and this program to Director,
`National Security Agency, Fort George G. Meade, MD 20755-6000,
`ATTN: R21 .
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 106
`
`

`
`Chooseanythree.
` S
`P Download
`
`Abot
`
`”
`
`'
`
`‘
`
`Small. Fast. Reliable.
`
`S'tema
`
`Documentation
`
`License
`
`News
`
`Support
`
`The Architecture Of SQLite
`
`Introduction
`
`This document describes the
`
`architecture of the SQLite library. The
`information here is useful to those who
`
`want to understand or modify the inner
`workings of SQLite.
`
`A block diagram showing the main
`components of SQLite and how they
`interrelate is shown at the right. The
`text that follows will provide a quick
`overview of each of these components.
`
`This document describes SQLite version
`3.0. Version 2.8 and earlier are similar
`
`but the details differ.
`
`Interface
`
`Much of the public interface to the
`SQLite library is implemented by
`functions found in the main.c,
`|egacy.c, and vdbeapi.c source files
`though some routines are scattered
`about in other files where they can
`have access to data structures with file
`
`Block Diagram Of SQLite
`
`SQL Comma
`
`E-'.'I
`-§0VI'5-‘II
`<1)U'0
`‘Cl:
`
`scope. The sqlite3_get_table()
`routine is implemented in tab|e.c.
`sq|ite3_mprintf() is found in printf.c. sq|ite3_comp|ete() is in tokenize.c. The
`Tcl interface is implemented by tclsqlite.c. More information on the C interface to
`SQLite is available separately.
`
`To avoid name collisions with other software, all external symbols in the SQLite
`library begin with the prefix sq|ite3. Those symbols that are intended for external
`use (in other words, those symbols which form the API for SQLite) begin with
`sqlite3_.
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 107
`
`

`
`Tokenizer
`
`When a string containing SQL statements is to be executed, the interface passes
`that string to the tokenizer. The job of the tokenizer is to break the original
`string up into tokens and pass those tokens one by one to the parser. The
`tokenizer is hand—coded in C in the file tokenize.c.
`
`Note that in this design, the tokenizer calls the parser. People who are familiar
`with YACC and BISON may be used to doing things the other way around --
`having the parser call the tokenizer. The author of SQLite has done it both ways
`and finds things generally work out nicer for the tokenizer to call the parser.
`YACC has it backwards.
`
`Parser
`
`The parser is the piece that assigns meaning to tokens based on their context.
`The parser for SQLite is generated using the Lemon LALR(1) parser generator.
`Lemon does the same job as YACC/BISON, but it uses a different input syntax
`which is less error—prone. Lemon also generates a parser which is reentrant and
`thread—safe. And lemon defines the concept of a non—termina| destructor so that
`it does not leak memory when syntax errors are encountered. The source file that
`drives Lemon is found in parse.y.
`
`Because lemon is a program not normally found on development machines, the
`complete source code to lemon (just one C file) is included in the SQLite
`distribution in the ''tool'' subdirectory. Documentation on lemon is found in the
`"doc" subdirectory of the distribution.
`
`Code Generator
`
`After the parser assembles tokens into complete SQL statements, it calls the
`code generator to produce virtual machine code that will do the work that the
`SQL statements request. There are many files in the code generator: attach.c,
`auth.c, build.c, de|ete.c, expr.c, insert.c, pragma.c, select.c, trigger.c,
`update.c, vacuum.c and where.c. In these files is where most of the serious
`magic happens. expr.c handles code generation for expressions. where.c
`handles code generation for WHERE clauses on SELECT, UPDATE and DELETE
`statements. The files attach.c, de|ete.c, insert.c, select.c, trigger.c update.c,
`and vacuum.c handle the code generation for SQL statements with the same
`names. (Each of these files calls routines in expr.c and where.c as necessary.)
`All other SQL statements are coded out of build.c. The auth.c file implements
`the functionality of sqlite3_set_authorizer().
`
`Virtual Machine
`
`The program generated by the code generator is executed by the virtual machine.
`Additional information about the virtual machine is available separately. To
`summarize, the virtual machine implements an abstract computing engine
`specifically designed to manipulate database files. The machine has a stack
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 108
`
`

`
`which is used for intermediate storage. Each instruction contains an opcode and
`up to three additional operands.
`
`The virtual machine itself is entirely contained in a single source file vdbe.c. The
`virtual machine also has its own header files: vdbe.h that defines an interface
`
`between the virtual machine and the rest of the SQLite library and vdbeInt.h
`which defines structure private the virtual machine. The vdbeaux.c file contains
`utilities used by the virtual machine and interface modules used by the rest of
`the library to construct VM programs. The vdbeapi.c file contains external
`interfaces to the virtual machine such as the sq|ite3_bind_... family of functions.
`Individual values (strings, integer, floating point numbers, and BLOBs) are stored
`in an internal object named "Mem" which is implemented by vdbemem.c.
`
`SQLite implements SQL functions using callbacks to C—|anguage routines. Even
`the built—in SQL functions are implemented this way. Most of the built—in SQL
`functions (ex: coalesce(), count(), substr(), and so forth) can be found in
`func.c. Date and time conversion functions are found in date.c.
`
`B-Tree
`
`An SQLite database is maintained on disk using a B—tree implementation found in
`the btree.c source file. A separate B—tree is used for each table and index in the
`database. All B—trees are stored in the same disk file. Details of the file format
`
`are recorded in a large comment at the beginning of btree.c.
`
`The interface to the B—tree subsystem is defined by the header file btree.h.
`
`Page Cache
`
`The B—tree module requests information from the disk in fixed—size chunks. The
`default chunk size is 1024 bytes but can vary between 512 and 65536 bytes. The
`page cache is responsible for reading, writing, and caching these chunks. The
`page cache also provides the rollback and atomic commit abstraction and takes
`care of locking of the database file. The B—tree driver requests particular pages
`from the page cache and notifies the page cache when it wants to modify pages
`or commit or rollback changes. The page cache handles all the messy details of
`making sure the requests are handled quickly, safely, and efficiently.
`
`The code to implement the page cache is contained in the single C source file
`pager.c. The interface to the page cache subsystem is defined by the header file
`pager.h.
`
`OS Interface
`
`In order to provide portability between POSIX and Win32 operating systems,
`SQLite uses an abstraction layer to interface with the operating system. The
`interface to the OS abstraction layer is defined in os.h. Each supported operating
`system has its own implementation: os_unix.c for Unix, os_win.c for Windows,
`and so forth. Each of these operating—specific implements typically has its own
`header file: os_unix.h, os_win.h, etc.
`
`PETITIONER — ORACLE-APPLE — EXHIBIT 1003 — Page 109
`
`

`
`Utilities
`
`Memory allocation and caseless string comparison routines are located in util.c.
`Symbol tables used by the parser are maintained by hash tables found in hash.c.
`The utf.c source file contains Unicode conversion subroutines. SQLite has its own
`private implementation of printf() (with some extensions) in printf.c and its own
`random number generator in random.c.
`
`Test Code
`
`If you count regression test scripts, more than half the total code base of SQLite
`is devoted to testing. There are many assert() statements in the main code
`files. In additional, the source files test1.c through test5.c together with md5.c
`implement extensions used for testing purposes only. The os_test.c backend
`interface is used to simulate power failures to verify the crash—recovery
`mechanism in the pager.
`
`PETITIONER - ORACLE-APPLE - EXHIBIT 1008 - Page 110
`
`

`
`Published in the January 2, 1997 issue of the Federal Register:
`
`DEPARTMENT OF COMMERCE
`
`National Institute of Standards and Technology
`
`[Docket No. 960924272-6272-0l]
`RIN 0693-ZAl3
`
`ANNOUNCING DEVELOPMENT OF A
`FEDERAL INFORMATION PROCESSING STANDARD FOR
`ADVANCED ENCRYPTION STANDARD
`
`AGENCY: National Institute of Standards and Techno