as) United States
`a2) Patent Application Publication co) Pub. No.: US 2011/0067012 Al
` Eisenetal. (43) Pub. Date: Mar. 17, 2011
`
`
`
`US 20110067012A1
`
`(54) SYSTEM AND METHOD FOR GENERATING
`WHITE-BOX IMPLEMENTATIONS OF
`SOFTWARE APPLICATIONS
`Inventors:
`Philip Allan Eisen, Ottawa (CA);
`Grant Stewart Goodes, Manotick
`(CA); Daniel Elie Murdock,
`Ottawa (CA)
`
`(75)
`
`(73) Assignee:
`
`IRDETO CANADA
`CORPORATION,Ottawa, ON
`(CA)
`
`(21) Appl. No.:
`
`12/992,318
`
`(22) PCT Filed:
`,
`(86) PCT No.:
`“
`§ 371 (c)(1)
`2
`.
`(2), (4) Dateo
`
`May25, 2009
`,
`PCT/CA09/00755
`
`.
`°
`Nov. 12, 2010
`
`Related U.S. Application Data
`
`(60) Provisional application No. 61/055,694, filed on May
`23, 2008.
`
`Publication Classification
`
`(51)
`
`Int. Cl
`(2006.01)
`GO6F 12/14
`2006.01
`GO6F 9/44
`S008 Ol)
`GO6F 9/45
`,
`(52) US. CD. veces creseneeeseceneees 717/140; 713/189
`(57)
`ABSTRACT
`
`A developmentsuite for generating files, such as DRM-pro-
`tected files, using white-box cryptography. The suite consists
`of a code generationtool, a data transformation engine, and a
`white-box data generation tool, and a white-boxlibrary. In the
`white-box cryptography context,
`the data transformation
`engine is used to protect the boundary between the crypto-
`graphic operation and the surrounding code. In particular, the
`data transformation engine is used to apply data transforma-
`tions to the inputs to and outputs from the cryptographic
`operations. If the user specifies that transformations are
`required via a white-box parameterization file, the code gen-
`eration tool puts the information specified by the user into a
`form the data transformation engine understands, namely as
`qualifiers on data variables and function prototypes. The data
`transformation engine then applies the specified transforma-
`tions, and passes information to the data generation tool
`regarding which transformations were chosen.
`
`100
`
`User code with WBfunctioncalls
`
`
`
`wofunc{ ... );
`
`wbfund w
`
`
`Angygagg Stub build 1102oe
`130
`Paramet-
`Apply code |—!
`Compile and link
`§
`Smooth erypto library
`
`rization
`
`
`generation tool
`file
`
`
`132
`
`ee 1
`Test vo
`
`>
`
`134
`
`144
`
`White -..box
`
`library
`
`
`_ yo 147
`
`Robust build 114
`
` .
`
`Generate diversity
`
`i
`
`elements
`
`Diversit
`
`1
`
`APPLE 1011
`
`APPLE 1011
`
`1
`
`

`

`Patent Application Publication Mar. 17,2011 Sheet 1 of 6
`
`US 2011/0067012 Al
`
`User code with WB function calls
`and Xcommands
`
`- xc_transform XC_Octet plain[1024];
`whfunc( wl)
`
`whfunc( ... ):
`
`406
`|
`108
`
`cencebeeen (Co
`
` White-
` box
`
`library
`
` Protected executable
`
`Figure 1
`
`2
`
`

`

`Patent Application Publication
`
`Mar.17, 2011 Sheet 2 of 6
`
`US 2011/0067012 Al
`
`BLLa
`
`001
`
`
`
`
`
`Aieiqi0}dAI9qnys
`
`
`
`9/qe]ND9Xx9p|jI9}0lg
`
`ajqe}noexe
`
`qnis
`
`-JOwWeIe¢
`
`uoneziu
`
`oly
`
`("Jounjqm
`
`(Jounsqan
`
`9]qe}nNI9x9
`
`yjoowsg
`
`
`
`
`
`s|jeoUOTOUNYGAAJIMBpodJES
`
`Zaunbis
`
`
`
`PLLPlingisnqoy
`
`S}]UDUIa|9
`
`Ayssaaiq
`
`
`
`3
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Mar.17, 2011 Sheet 3 of 6
`
`US 2011/0067012 Al
`
`¢eunbl4
`
`
`
`jU9]}U09«——
`
`==—==—a—aeeeaeeeeSsSSSiC
`eeceeiSSSO
`eee
`
`andyyo)+——_
`
`yoqJUSJUOD+—
`
`SAV
`
`AO|\dAsoue
`
`«—]U9}U09
`
`JOMOS
`
`JUSIO
`
`4
`
`
`

`

`Patent Application Publication Mar. 17,2011 Sheet 4 of 6
`
`US 2011/0067012 Al
`
`Figure4
`
`CKEPrus
`
`contentEc«
`
`
`RSA/AES
`
`Server
`
`Client
`
`5
`
`

`

`Patent Application Publication
`
`Mar.17, 2011 Sheet 5 of 6
`
`US 2011/0067012 Al
`
`Ggeinbi4
`
`QS/
`
`
`
`
`
`}pounryqm|:(LSuondo*)pounsqm
`
`apoo
`
`
`
`‘(gsuoido‘*-)zounsqu
`
`XOGHYM(pexeo|d)puepodpaxeojD
`
`
`!4
`
`uabeyepqm
`
`COL
`
`
`
`eyeponjb6-qmu
`
`preenabecnane,
`
`VSL
`
`apoox
`
`leseonseenoual
`
`ajuoeZUe}aWesed
`
`XOqO}IUM
`
`
`
`
`
`
`
`uabapoogm{suoydo‘,yndyno‘zindul‘pyndui‘;Jouryqa
`
`OOL
`
`
`
`S]|eDUOIJOUNYGAAUJIMBpOdJasH
`
`17
`
`
`
`
`
`
`
`‘(zsuojdo‘zyndyno‘pyndu‘eyndul‘Zzounsqm
`
`6
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Mar.17, 2011 Sheet 6 of 6
`
`US 2011/0067012 Al
`
`
`
`961r6l9eunbPane
`
`CSL
`
`o'poyeojoonjB-apoaiesn
`Z6L|2Yayawies
`OBL_Arameeeee
`
`961
`
`ajqeynoexe
`
`{CPeOULPiEpUeIsSayAapaxlyXx
`FCLsuanda°°")LOUALQALloa
`
`
`
`
`
`‘(ZSUONGOVZIUNIQMPloAapa
`
`aan|G-spojuesn
`
`
`
`apnjouryeneepneuyanji-apo9iasn
`
`‘anjb-apo7aesn
`
`‘(pauondoPPUNyqesPOAWeKE
`
`OSL
`
`cLbvLl
`
`aaeeloan
`
`¥
`
`vel
`
`S|lqUoeZVeywWeIeYGA
`s/fe>UORSUN)GARUJIMSOepogsesn4OOL:
`
`UqaDXfox
`
`OLL
`
`
`
`
`
`4'an|o-apOSM,BAN[OUgE
`
`QNLlSGAADKJePUe
`
`
`
`(YG2YOX,,aPNIU
`
`S|PMa
`
`
`
`
`
`
`
`'Cpsuando‘yyndyno‘zindui‘pyndur'|jounyqn
`
`
`
`
`
`‘Czsuaydo'zindine‘pindur'cyndur'zJouryqaa
`
`
`
`
`
`7
`
`
`
`
`
`
`
`
`
`

`

`US 2011/0067012 Al
`
`Mar. 17, 2011
`
`SYSTEM AND METHOD FOR GENERATING
`WHITE-BOX IMPLEMENTATIONS OF
`SOFTWARE APPLICATIONS
`
`FIELD OF THE INVENTION
`
`[0001] The present invention relates generally to cryptog-
`raphy. Moreparticularly, the present invention relates to the
`development of software applications designed to operate
`securely in an environment where an attacker has full access
`to and control over the executing software.
`
`BACKGROUND
`
`software
`[0002] White-box cryptographic software is
`which performs cryptographic functions in a white-box
`attack context; that is, in an environment in whichat least
`portions of a software application, and potentially the entire
`implementation,is potentially exposed to an attacker who has
`at least some degree of control, and possibly complete con-
`trol, of the platform on which the software is running.
`[0003]
`Such a context arises, for example, in connection
`with cryptographic applications such as digital rights man-
`agement (DRM), where television programs, movies, music,
`and the like, are shown on a personal computer (PC)or other
`similar commodity computational device, rather than on a
`conventional television via broadcast or via a DVD player.
`While many owners of such commodity devices will respect
`copyright laws, there are others who will attempt to make a
`profit on media directed to PCs or similar devices by stealing
`the content without paying its ownersfor their use by making
`and selling illicit copies of the media content. PCs are a
`particularly exposed environment: a knowledgeable attacker
`can gain complete control of the device and can watch the
`software running in detail and control, halt, or modify its
`execution using a debugger, and can repeatedly execute the
`same code looking for patterns of behavior which can be
`exploited, andthe like.
`[0004] White-box cryptographic software is designed to
`run in such acontext. A cryptographic function targeted to the
`white-box attack context, while it may well implement a
`conventional cipher, implements it in profoundly unconven-
`tional ways, in order to impede the understanding of the
`attacker of the way in which the software operates. For
`example,
`typically,
`the keys are either embedded in the
`remainder of the white-box cryptographic software by partial
`evaluation, or they are encoded. Moreover, the input and
`output texts of the cipher are typically encoded to make the
`attacker’s knowledge of conventional implementationsof the
`cipher muchless useful in mounting an attack on a white-box
`cryptographic implementation.
`[0005]
`In the past, a user would be required to determine
`and specify security parameters which would be incorporated
`within user defined software which also includes API calls
`
`used to access white box library tools. In other words, in the
`past white-box cryptographic operations have been injected
`into software applications by including constructed white-
`box implementations into the software and then optionally
`securing their interface data (e.g., for an encryption, this
`typically comprises the key and plaintext inputs and the
`ciphertext output) using an obfuscating and/or tamper-proof-
`ing tool, such as the Cloakware Transcoder™. The responsi-
`bility for correctly connecting together the software employ-
`ing the cryptographic functionality and the software
`implementing it, the key (or keys, in the case of public key
`
`cryptography), the text input, and the text output, lies with the
`programmer using the cryptographic functionality (the pro-
`grammer/user).
`[0006] Because every step is under the control of the pro-
`grammer/user, it has all of the problems that come from
`expecting perfect performance from human beings. When the
`programmer/user succeeds, theresult is that the functionality
`is as intended.If the programmer/user misses a step, or per-
`formsa step incorrectly, the functionality may differ in gross
`or subtle ways from what is intended. Thelatter is far more
`dangerous: gross errors are usually caught in testing; subtle
`errors can easily be missed.
`[0007]
`It is evident, therefore, that, while the advent of
`white-box cryptographic implementations, has made DRM
`content distribution systems more viable, nevertheless, a
`large problem remains with what we might call the peri-
`cryptic (where unenciphered text enters or leaves the white-
`box implementation) and inter-cryptic (where enciphered
`text moves from one form of encipherment
`to another)
`aspects of the implementation. We have determined that as
`well as the white-box ciphers or cryptographic hashes them-
`selves, there is a need to improve the construction of the
`software in which the white-box ciphers or cryptographic
`hashesreside, and of the construction of connections among
`different cryptographic components where a system employs
`multiple encryptions and hashes which form the ‘plumbing’
`of the information pipes along which enciphered or hashed
`contenttravels, where the peri-cryptic and inter-cryptic parts
`of the software formerly had to be hand-constructed in detail
`by a knowledgeable user.
`
`SUMMARY
`
`[0008] There is provided a computer-implemented method
`of generating a protected software application using white-
`box cryptography, and a computer program product embody-
`ing the method. The method comprises receiving at least one
`input source file including application source code and
`abstracted white-box function calls; and receiving a param-
`eterization file containing cryptographic domain parameters
`for each abstracted white-box function call. White-box call
`definition data is then generated defining each abstracted
`white-box function call in accordance with its cryptographic
`domain parameters. At least one data transformation, such as
`a block or asymmetric cipher, is then applied to the input
`source file and the white-box call definition data to respec-
`tively generate a transformed source file and transformed
`white-box call definition data. Data initializations, containing
`instance-specific data for each white-box function call in
`accordance with the white-box call definition data and the
`
`transformed white-box call definition data, are then gener-
`ated. The transformedsourcefile, the transformed white-box
`definition data and the datainitialization code are then com-
`piled, and the resulting compiled codeis linked to a white-box
`library to provide an executable software application. The
`white-box call definition data generates code, in an automated
`manner, connecting white-box implementation Application
`Procedural Interfaces (APIs) to the application source code,
`and code connecting a white-box implementation API to
`another white-box implementation API when they must com-
`municate.
`
`[0009] According to embodiments of the this aspect, the
`white-box call definition data can comprises a white-boxcall
`definition file and white-box metadata specifying parameters
`chosen for each white-box function call, and applying the at
`
`8
`
`

`

`US 2011/0067012 Al
`
`Mar. 17, 2011
`
`least one data transformation to the transformed white-box
`call definition data generates a transformed white-box call
`definition file and transformation metadata specifying data
`transformations chosen for selected parameters. Generating
`the data initializations can comprise generating a data initial-
`izationfile in accordance with the white-box metadata and the
`transformation metadata.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0010] Other aspects and features of the present invention
`will become apparent to those ordinarily skilled in the art
`upon review ofthe following description of specific embodi-
`ments of the invention in conjunction with the accompanying
`figures.
`[0011] Embodiments of the present invention will now be
`described, by way of example only, with reference to the
`attached Figures, wherein:
`[0012]
`FIG. 1isa diagram ofa basic design flow for white-
`box cryptography integration according to an embodimentof
`the invention;
`[0013]
`FIG. 2 is a diagram of an expanded design flow for
`white-box cryptography according to an embodimentof the
`invention;
`[0014] FIG.3isa diagram ofa chained encryption scenario
`according to an embodimentofthe invention;
`[0015]
`FIG. 4is a diagram ofa chained encryption scenario
`in which a chained encryption APIis utilized according to an
`embodimentof the invention;
`[0016]
`FIG. 5 is a schematic diagram illustrating an
`embodimentof the invention and its operation; and
`[0017]
`FIG. 6 is a diagram that illustrates the steps for
`building a robust implementation according to an embodi-
`mentofthe invention.
`
`DETAILED DESCRIPTION
`
`It is evident that there is a need for a method and
`[0018]
`system wherebythe steps of constructing the peri-cryptic and
`inter-cryptic portions of applications employing white-box
`cryptographic functionality can be automated, in order that
`the current error-prone methodsofbuilding such systems can
`be replaced by far more reliable automated methods. To
`achieve this, embodiments are disclosed in which the ordi-
`nary intra-cryptic portions of applications (the parts which
`actually perform the white-box operations) become more
`flexible than they havetraditionally been,to fit into the above
`automated system.
`[0019] The benefits of such a system are analogousto the
`benefit that is achieved by compiling code instead of writing
`handcrafted assembly code. In theory, good programmers
`should be able to write an application in handcrafted assem-
`bly code.In practice, however, hand-crafted assembly codeis
`immensely error-prone, and compilers, by replacing a low-
`level, highly detailed software construction regime with a
`much more automated one, makepossible software systems
`of a complexity which could never have been achievedat the
`assembly-codelevel.
`[0020] One aspect of the instant application is to provide a
`system and method wherebytheperi-cryptic and inter-cryptic
`aspects of white-box implementations can be abstracted and
`automated, making it possible for its users to implementuses
`of white-box cryptographic implementations at a level of
`complexity which waspreviously either difficult or infeasible
`to achieve by peri-cryptic and inter-cryptic hand-coded soft-
`
`ware, while also benefitting even simpler uses of white-box
`cryptography by making them far easier for the programmer/
`user to create, just as even simple programsbenefit by replac-
`ing hand-crafted assembly code by code compiled from the
`source code of a high-level language, such as C++.
`[0021] Anaspect ofthis automationis the unification ofthe
`ways in which different forms of cryptographic functionality
`are expressed. For example, in a compiled language such as
`C++, the same syntactic form is used for an addition whether
`it is two integers, two floating-point numbers, or two complex
`numbersthat are being added. The language andits compiler
`abstract addition as a concept which is implemented appro-
`priately for each context in whichit is used, irrespective of
`whether the implementationis built in to the compiler(as it is
`for integers and floating point numbers) or is part of a stan-
`dard library (as it is for complex numbers). A similar unifi-
`cation is disclosed herein for white-box cryptographic opera-
`tions: if each cryptographic operation has its own unique
`interface and requires its own unique mannerof expression,
`little automation is possible; much of the responsibility of
`making appropriate choices must necessarily remain with the
`programmer/user. Ifthe interfaces and mannersof expression
`are unified, the system can abstract away from particular
`ciphers and deal with the needs of each context in an auto-
`mated fashion.
`
`[0022] Accordingly, embodiments are disclosed that sepa-
`rate the security related parameters from the user-defined
`software, which includes API calls used to access white box
`library tools. This allows for easily changing the type and
`security level of the protection applied to an application sim-
`ply by changing the parameters without requiring changes to
`the user defined software. This allows for field upgradeable
`capability, wherein the security implementations, and codes
`can be changed,or additional tools and/orlevels ofprotection
`can be utilized. In the event that a hacker breaches the secu-
`
`rity, such a system can respond by providing new and/or
`additional challenges to hackers by changing the parameters
`and recompiling the application.
`[0023]
`Presently preferred embodiments provide for the
`possible use of many diverse security implementations, with
`multiple security measures being possible for each applica-
`tion. This is beneficial to ensure that a successful attack on
`one implementation does not become a successful attack on
`all or many implementations of a given software application
`employing white-box cryptography.
`[0024] Generally,
`the disclosed embodiments provide a
`computer-implemented method and system for integrating
`white-box cryptographyinto a softwarefile, which comprises
`separating the API’s and the parameters used to encrypt,
`obfuscate, or otherwise protect the application orfile. A par-
`ticular benefit of such an integrated developmentsuite is the
`protection of the boundaries between cryptographic applica-
`tions and the surrounding application, throughthe use of data
`transformations which can be applied in the application and
`which are understood by the white-box cryptographic imple-
`mentation.
`
`Inthe following description, for purposes of expla-
`[0025]
`nation, numerousdetails are set forth in order to provide a
`thorough understanding of the present invention. However,it
`will be apparent to one skilled in the art that these specific
`details are not required in order to practice the present inven-
`tion. In other instances, well-knownelectrical structures and
`circuits are shown in block diagram form in order not to
`obscure the present invention. For example, specific details
`
`9
`
`

`

`US 2011/0067012 Al
`
`Mar. 17, 2011
`
`are not provided as to whether the embodimentsofthe inven-
`tion described herein are implemented as a software routine,
`hardware circuit,
`firmware, or a combination thereof.
`Embodiments of the invention may be represented as a soft-
`ware product stored in a machine-readable medium (also
`referred to as a computer-readable medium,a processor-read-
`able medium, or a computer-usable medium having a com-
`puter
`readable program code embodied therein). The
`machine-readable medium may be any suitable tangible
`medium, including magnetic, optical, or electrical storage
`medium including a diskette, compact disk read only memory
`(CD-ROM), memory device (volatile or non-volatile), or
`similar storage mechanism. The machine-readable medium
`may contain various sets of instructions, code sequences,
`configuration information, or other data, which, when
`executed, cause a processor to perform steps in a method
`according to an embodimentofthe invention. Thoseofordi-
`nary skill in the art will appreciate that other instructions and
`operations necessary to implement the described invention
`may also be stored on the machine-readable medium.Soft-
`ware running from the machine-readable medium mayinter-
`face with circuitry to perform the described tasks.
`[0026] Throughout this document, the term “white-box”is
`frequently used as a prefix, creating terms like “white-box
`call”, “white-box library”, “white-box function”, etc. When
`used as sucha prefix, the term “white-box”is shorthand for a
`“cryptographic implementation designed to provide security
`against a white-boxattacker.” Similarly, the term “white-box
`cryptography”is itself shorthandfor a “cryptographic imple-
`mentation designed to provide security against a white-box
`attacker”. To be clear, in no case does the “white-box”prefix
`refer to the item itself; since the described embodiments
`function in a software environment, it is a given that the
`embodiments andthe user’s application are an open book to
`the attacker; in other words, they are a white-box. In reality,
`these termsare just another shorthand. For example, a “white-
`box library”is a library containing implementationsof cryp-
`tographic functions that provide security against white-box
`attackers, or slightly more succinctly, a library containing
`white-box cryptography (here we see how “white-box
`library”is thus a double shorthand). A “white-box function”
`is one of the functions in the white-box library. A “white-box
`function call”, orjust “white-boxcall”, is a call to a white-box
`function. Other terms should be interpreted similarly.
`[0027] The described embodiments integrate white-box
`cryptography into a software developmentsuite. Referring to
`FIG.1, at a very high level, integration ofwhite-box cryptog-
`raphy into an application according to the present invention
`involves the user making a numberofchoices, both functional
`and robustness-related, about the cryptographic functionality
`and flow of critical security parameters throughout their
`application. As shown at 100, the user adds abstracted calls
`(shown as wbfunc(. .. )) toa white-box API to implementthe
`desired cryptographic functionality, and also adds commands
`throughouttheir code to identify the protection required for
`critical security parameters. Using a number of white-box
`tools andlibraries (step 102) a robust code 104 is then created,
`which can be compiled and linked (step 106) to a white-box
`library 108 to create an executable file 109 that performs
`cryptographic operations in a secure way, and that protects
`critical security parameters throughoutthe entire data flow of
`the application.
`[0028] Conceptually, however,it is easier to understand the
`process as an evolution, wheretheuser first makes and imple-
`
`ments the most basic choices about cryptographic function-
`ality and key flow in their application, then further refines the
`functional parameters, and finally takes steps to add robust-
`ness. At each stage, there is the ability to build andtest the
`application, and at the end, the user tunes the robust applica-
`tion and optionally personalizes each build. This expanded
`design flow is shown in FIG.2, and involves a stub build 110,
`a smooth build 112, and a robust build 114. The stub and
`smooth builds 110, 112 are optional, and are described only in
`broad terms. Their implementation is a design choice, as will
`be clear to those of skill in the art, and is discussed herein
`merely for the purposes of illustrating an embodiment of a
`white-box application development flow according to the
`present invention.
`[0029]
`Inthe stub build 110, the user adds white-box func-
`tion calls to the appropriate white-box cryptography APIs to
`add functionality such as symmetric encryption, asymmetric
`encryption and hashingto create an input sourcefile 100. The
`user compiles andlinks (step 116) their program against stub
`implementations of the white-box calls, defined in a white-
`boxstub library 118, to generate a stub executable 120, which
`can then be tested (step 122) to check for compilation and
`linking errors, as well as basicerrors in the key flow. The stub
`encryption functions, implementedin the stub library 118 are
`simple, but constructed in such a waythat it is unlikely for
`decryption and encryption to be inverses of one another
`unless matching parameters are passed to both functions. For
`example, dynamic-key decryption must use the same key as
`dynamic-key encryption in order to recoverthe original mes-
`sage. If these keys are not the same, due to a codingerror, a
`stub decryption is unlikely to properly decrypt the result of a
`stub encryption to producethe original message.
`[0030]
`Inthe smooth build 112, the user makes someinitial,
`functionality-related choices to parameterize each call, and
`creates a white-box parameterizationfile 124 detailing those
`choices. The user then applies a code generation tool (step
`126) to apply the choices made, and compiles and links(step
`128) their program against smooth implementations of the
`white-boxcalls defined in a smooth version of the white-box
`library 130. The smooth version of the white-box library 130
`simply refersto a library which implements the same API as
`the true white-box library, but which is smooth. The resulting
`smooth executable 132 can then be tested (step 134) to ensure
`basic functionality is working properly.
`[0031] At the robust build 114, the user makes choices
`regarding size, speed and security trade-offs in their protected
`application. The user applies white-box cryptography tools
`(step 136), which are detailed below, to generate robust trans-
`formed code 138. The robust transformed code 138 is then
`compiled and linked (step 140) to secure implementations of
`the white box calls in a white-box library 144 to generate a
`protected executable 146. This protected executable can then
`be tested (step 147) to ensure both functionality and security.
`The user then optionally generates (step 148) many diverse
`instances 149 of data for the purposes of individualization,
`using a more lightweight process.
`[0032] The robust build process and components will now
`be described in greater detail, having referring to FIG. 5 and
`FIG. 6. FIG. 5 provides a simplified overview of the robust
`build, while FIG. 6 shows an embodimentof a detailed imple-
`mentation, which is described in detail below.
`[0033] The embodiment of FIG. 5 includes three modules
`for producing a protectedfile, for example a software appli-
`cation file, namely a white-box code generation tool (wbco-
`
`10
`
`10
`
`

`

`US 2011/0067012 Al
`
`Mar. 17, 2011
`
`fixed keys. Certainly, all keys can be treated as dynamic, but
`where keys can betreated as fixed, there is a security advan-
`tage in doing so.
`[0036] Once the above decisions have been made, the user
`application code can be written to invoke the API appropriate
`to that selection. The user application, which is the input
`sourcefile 100, consists of source code (such as in C or C++)
`containing invocations of cryptographic operations such as
`key scheduling, encryption, decryption, etc, using a very
`minimal API. Key user-provided data such as ciphertext,
`plaintext, iv, etc., are passed as parameters to these invoca-
`tions, along with a numeric constant ID parameter whichis
`used to group related calls into a single cryptographic
`domain. In a preferred embodiment, the user application-
`code will be required to include an includefile 170: xc/xe_
`wb.h, which defines white-box types and macros. All crypto-
`graphic operations can be invoked using macros from this
`include file 170. Preferably, the white-box includefile 170
`(xc/xc_wb.h) provides a single macro definition for each of
`the cryptographic operationsforall cipher types. The macros
`take as parameters the minimum set of user-supplied param-
`eters (typically application data such as plaintext/ciphertext),
`a single ID parameter (to identify the cryptographic domain
`of the operation), and an options parameter. For example, a
`block cipher encrypt call is shown below. Note that the macro
`invocation (XC_Fixed_Key_Block_Cipher_Encrypt)is very
`abstracted, and specifies only the actual application data
`required for the cryptographic operation.
`
`1,
`
`plain,
`
`16,
`
`#include “xe/xc__wb.h”
`
`XC__Octet plain[1 6];
`XC_Octet cipher[16];
`int csize;
`int ret;
`/* Load plaintext into plain */
`tet
`= XC_Fixed_Key_Block_Cipher_Encrypt(
`cipher, &csize, NULL,
`0, NULL);
`if (ret != XC_OK){
`/* issue error */
`
`}/
`
`* Process ciphertext */
`
`[0037] The white-box includefile 170 (xc/xc_wb.h)defines
`the entire white-box API from the perspective of the user’s
`application code. This API is in the form of function-like
`macros that define all the abstract cryptographic operations
`available for use in application code. Moreover, this include
`file 170 describes the contents of the white-box glue files,
`described below, again in the form of macro definitions. The
`following exemplary code snippets show the high-level
`details of a single abstract API, for the Fixed-Key, Block-
`Cipher Encrypt operation:
`
`degen) 150, a data transformation engine (xcode) 152, and a
`white-box data generation tool (wbdatagen) 154.
`In the
`white-box cryptography context,
`the data transformation
`engine 152 is used to protect the boundary betweenthe cryp-
`tographic operation and the surrounding code. In particular,
`the data transformation engine 152 is used to apply data
`transformationsto the inputs to and outputs from the crypto-
`graphic operations. If the user specifies that transformations
`are required via the white-box parameterization file 124,
`whcodegen 150 puts the information specified by the user into
`a form the data transformation engine 152 understands,
`namely as qualifiers on data variables and function proto-
`types. The data transformation engine 152 then applies the
`specified transformations, and passes information to whdat-
`agen 154 regarding what transformations were chosen.
`[0034] The data flow to achievethis is shownat a high level
`in FIG. 5. The white-box code generation tool 150 receives at
`least one input sourcefile 100 (userCode) including applica-
`tion source code andabstracted white-box function calls, and
`a parameterizationfile 124 containing cryptographic domain
`parameters for each abstracted white-box function call. The
`white-box code generation tool 150 processes these inputs to
`generate white-box call definition data 156 (wb_glue.c)
`defining each abstracted white-box function call in accor-
`dance with its cryptographic domain parameters and in a
`mannerthat will be understood by the data transformation
`engine 152. The data transformation engine 152 then applies
`one or more data transformations to the input sourcefile 100
`and the white-boxcall definition data 156 to generate a trans-
`formed source file 160 and transformed white-boxcall defi-
`
`nition data 158 (wb.xwbm).Thedata generation tool 154 then
`generates data initializations 162 (wb-glue data) containing
`instance-specific data for each white-box function call in
`accordance with the transformed white-box call definition
`data 158. The data initializations 162 and the transformed
`
`sourcefile 160 can then be compiled using a native compiler,
`and linked to a white-boxlibrary.
`
`White-Box API
`
`Oncethe userhasidentified a need for cryptography
`[0035]
`in their application, they have two choices for each call to the
`API they will make. These choices will determine the basic
`key flow of their application. (1) What is the cryptographic
`operation to be performed? Possible operations include
`encryption, decryption, signature,
`signature verification,
`hashing,etc. (2) Will the key for this call only be available at
`run-time, or will it be available before? Keys such as session
`keys or content keysare usually either generated dynamically,
`or are computed as the result of an asymmetric decryption.
`Webroadly call such keys dynamic. Keys which are known at
`build-time, or which can be obtained through someoff-line
`subscription/renewal process, on the other hand, are called
`
`#ifdef XC_WB_INFO
`// Definitions common to Smooth and Robustinvocations:
`#define XC_Fixed_Key_Block_Cipher_Encrypt—D, PLAIN, PLAINSIZE, CIPHER,
`PCIPHERSIZE,
`IV,
`IVSIZE, OPTIONS) \
`<XC__Fixed_Key_Block_Cipher_Encrypt> \
`_XC_TCGEN(_XC_GLUE,ID, MAIN,cat(XC_Fixed_Key__Block_Cipher_Encrypt__,ID), \
`_XC_TCGEN(_XC_ASSERT,\
`FunctionType=BlockCipher\
`KeyLocation=Fixed \
`
`11
`
`11
`
`

`

`US 2011/0067012 Al
`
`Mar. 17, 2011
`
`KEY,
`
`KEY,
`
`KEY,
`
`-continued
`
`Operation=Encrypt\
`
`yA
`XC_Block_Cipher_Glue(ID,) \
`
`define XC_Block_Cipher_Glue(ID, SUBOP) \
`XC__Block_Cipher_Externs(ID, SUBOP)\
`int MangledName cat(XC_Block_Cipher_Op__Prefix(SUBOP),Prototype) { \
`retum XC_Block_Cipher_Main_Invocation(ID, SUBOP) (\
`cat(XC__Block_Cipher_Op__Prefix(SUBOP),Base__Params)(ID) \
`XC_Block_Cipher_Additional_Params(ID, SUBOP) \
`
`y\
`
`)#
`
`}
`#ifdef XC_WB_SMOOTH
`// Definitions of such sub-macros as XC__Block_Cipher__Externsetc.
`// for a Smooth implementation
`#else /* not XC_WB_SMOOTH*/
`// Definitions of such sub-macros as XC__Block_Cipher__Externsetc.
`// for a Robust implementation
`// All_Params macros generated by XC__Robust*__Prefix are defined here:
`#include “xc_wb__bc_dk__aes__keysched_tables.h”
`#include “xc_.wb__bc_fk__aes_tables.h”
`#include “xc_.wb__bc_dk__aes_tables.h”#endif /* XC_WB_SMOOTH */
`#Hendif /* XC_WB_SMOOTH*/
`#else /* not XC_WB_INFO */
`// This section is for normal macro-expansion
`// xeWBCodeGenis not in play, and thus _XC_TCGEN( ) operators may not
`appear
`#ifdef XC_WB_STUB
`/ Stub build
`
`XC_Dynamic_Key__Block__Cipher_Encrypt_Key__Schedule(ID,
`#define
`KEYSIZE, PRKS, OPTIONS) \
`
`XC_Dynamic_Key_ Block_Cipher_Encrypt_Key_ Schedule_Stub(ID,
`KEYSIZE, PRKS, OPTIONS)
`#e