Framework for Design Validation of Security Architectures Page: 10
The following text was automatically extracted from the image on this page using optical character recognition software:
Table 3: Example Application and Attack Script for Eavesdropping and Spoofing Attack using Interrupt
Application with TSM (TSMapp)
Regl - DRK DeriveKey(TTP KeyID)
Ciphertext Encrypt(Regl, &SecureMem, sz)
NetworkSend(TTP, Ciphertext, sz)
Application without TSM (Unsaf eApp)
// No SP protection
Regl - App Generate Key(TTP KeyID)
TSP Notify(App Keygen, Regl)
Ciphertext ~ Encrypt(Regl, Data, sz)
NetworkSend(TTP, Ciphertext, sz)
5 Testing of SP
As we have shown in the previous section, it is possible
to use our new testing framework to perform a wide
range of tests and attacks on the SUT and the security
architecture it emulates. We now look more closely at
how we can use the framework to validate the security
properties of the SP architecture in particular through
a range of tests.
SP claims to provide a number of security properties,
of particular importance are the confidentiality and in-
tegrity of: master secrets (DRK & SRH), TSM execu-
tion, secure data, and usage policies. We must demon-
strate that each security property is enforced through
the combination of trusted and verified TSM software
and trusted SP hardware.
The main goal of the remote key-management TSM is
to enforce policies on secure data, as dictated by the Au-
thority, in an SP device. The following steps establish
the trust chain of the architecture:
1. The authority binds the TSM code to the SP device
EXECUTE(TSMapp, params) // or UnsafeApp
// Wait for key generation
EVT +- WAIT()
ACCESSREG(SP, r, SPRegs)
SPKey <- SPRegs.DerivedKey
AppKey -- EVT.paraml
// Trigger an interrupt
EVT <- WAITFOR(Interrupt)
// Attack confidentiality of general registers (GRs)
ACCESSREG(GR, r, GRegs)
if SPKey = GRegs.R1 OR AppKey = GRegs.R1 then
print "Register Confidentiality Attack Succeeded"
print "Register Confidentiality Attack Failed"
// Attack integrity of general registers (GRs)
ACCESSREG (GR, w, KnownKey); CONT()
if EVT = SPFaultRegIntegrity then
print "Register Integrity Attack Failed"
print "Register Integrity Attack Succeeded"
(and its master secrets, which cannot leave the de-
vice) and provides secret data to the TSM on that
2. The TSM executes in Concealed Execution Mode.
3. The TSM binds security policies and secure data
to the keys derived from SP's master secrets on the
We need to verify each of these steps by launching at-
tacks to test the SP's trust chain.
In Table 4 we show a list of attacks which test these
aspects of the architecture, using our framework, the
emulated SP hardware, and our TSM. Each row in the
table indicates a specific attack we have implemented,
where 'PASS' indicates that the architecture success-
fully protected against the attack.
When the authority provides secret data, it needs to be
sure that it can only be used on the designated device
and only using the TSM it provided which is trusted
to enforce its security policies. Therefore it must not
be possible to replace that TSM with another, even
Here’s what’s next.
This report can be searched. Note: Results may vary based on the legibility of text within the document.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Report.
Dwoskin, Jeffrey Scott, 1980-; Gomathisankaran, Mahadevan & Lee, Ruby Bei-Loh. Framework for Design Validation of Security Architectures, report, November 17, 2008; [Princeton, New Jersey]. (digital.library.unt.edu/ark:/67531/metadc130192/m1/10/: accessed April 28, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.