SlideShare a Scribd company logo
Deliberately Un-Dependable Applications:
the Role of Dependability Metrics in
Fault-Based Cryptanalysis
Alfonso De Gregorio
C & A S.r.l.
www.com-and.com
8th
August 2003
K.U.Leuven, COSIC-ESAT,
Kasteelpark Arenberg 10,
3001 Leuven-Heverlee
Agenda 
Introduction
¡
Fault Attacks
¡
The Model
 
Definitions and Background
 
Deliberately Un-Dependable Applications
 
Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics
 
The Impact on Security Policies
 
The Impact on Standards
 
Conclusions
Introduction
"Why erect majestic walls if comfortable
underpasses will always remain wide open?"
Silvio Micali and Leonid Reyzin
Physically Observable Cryptography
<http://eprint.iacr.org/2003/120.pdf>
Essentially related to the way the attacker can interact with the
target device and to the respective “observation” techniques
available to the opponent:
¢
Local Scenario: Unsupervised physical access to one
or more instances of cryptographic equipment:
£
Analysis of Sounds Given off by Rotor Machines
£
Timing Attacks
£
Power Analysis
£
Electromagnetic Emissions Analysis
£
Fault Attacks (injectable faults – e.g., optically)
¢
Black-box Scenario: Access to a remote device
through a crypto protocol:
£
Fault Attacks (random occurring faults)
Introduction:
Feasibility of Physical Attacks
Fault Attacks: How faults interacts with
security problems
Fact 1: Active faults jeopardize security
¤
Data errors: Erroneous cryptographic values enables
an attacker to expose the secret crypto key material,
without breaking the underlying algorithms
¤
Code errors: Single-bit control flow errors can
completely change the result of decision procedures
in many security context (e.g., authorization,
authentication, rounds in iterated algorithms)
Fault Attacks: How faults interacts with
security problems (ctd.)
Fact 2: Their inherent availability threaten the very
relevance of the schemes that are provably
secure by a complexity-theoretic point of view
Fault Attacks: exploiting them
Local Scenario / Induced Faults:¥
Goal: to augment the occurrences of erroneous
computations passed back to the user (i.e., fail-silent
violations in f.t.s.)
¥
Note: inducing faults locally has been the only approach
to increase the occurrences of fail-silent violations!
¥
Feasibility: the feasibility of inducing faults in
diligently designed cryptographic modules
is questioned by D.P. Maher and remains the
significant challenge for the opponent:
“Fault Injection Attacks, Tamper Resistance, and Hostile Reverse
Engineering in Perspective”, FC97
¥
Partially addressed in security standards: FIPS 140-2 (EFP
and EFT), ISO 7816/{1,2} – ISO 7810, CC (FPT_PHP)
Fault Attacks: exploiting them (ctd)
Black-box model / Random occurring faults:
The probability of observing them is
conditioned on the black-box dependability
metrics and on the (standard) environmental
conditions (e.g., SEU rates)
Fault Attacks: a first question
Is it possible to augment the occurrences of
erroneous computations passed back
to the user interface, in “diligently engineered”
cryptographic modules, without inducing
faults locally?
The Model
¦
A cryptographic module contains some cryptographic
secret
§
The module interacts with the outside world following
a cryptographic protocol
§
From time to time the module is affected by a random
fault causing it to output erroneous values
The Model (ctd.)¨
The cryptographic module has been designed to be
evaluated by trusted third parties (e.g.,
evaluation/certification bodies) according to actual
engineering standards at the highest assurance levels
and the correctness of the implementations of its
cryptographic algorithms has been formally verified
The Model (ctd.)
©
But it is still possible either to increase the
occurrences of erroneous computations (resp.
fail-silent violations for f.t.s.), or maximize the risks
associated with the occurrence of faults by carefully
augmenting the probability of observing naturally
occurring and dormant faults at standard
environmental conditions
Hence, to facilitate the feasibility of fault attacks
Overview of the Talk
Introduction

Definitions and Background

Deliberately Un-Dependable Applications

Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics

The Impact on Security Policies

The Impact on Standards

Conclusions
Definitions and Background:
Dependability Impairments
Definitions and Background:
Transient Faults on Hardware

Bit-flips (a form of transient faults) happen more
in memory then in the processor (Rad Project)

In RISC processors (Furtado and Madeira):

60% cause data errors;
30% cause code errors;
!
In CISC processors:

18% cause data errors;
#
77% cause code errors;
$
20% of software failures are hw related (Iyer)
Definitions and Background:
Design Faults on Hardware
Reported Design Faults in x86 µPs
%
Silber, Porras, and Lindell, “The Intel 80x86 Processor Architecture”
IEEE C.S. Symposium on Research in Security and Privacy, May, 1995

Donald MacKenzie, “Mechanizing Proof – Computing, Risk, Trust”, MIT Press
Definitions and Background:
Dormant Faults on Software
(an example dated 09 July 2003)
'
Cryptlib Cryptographic Toolkit:
(
On Sat 12 July the author, following an bug report dated
09 July, announce that due to a problem in the RSA
implementation in some rare occasions the toolkit
computes erroneous RSA signatures
)
Cryptlib was computing 0.3% of erroneous signatures
0
Its RSA implementation uses the Chinese Remainder
Theorem
1
The bug was present also in OpenSSL (some time ago)
Outside our Model
Definitions and Background:
Dormant Faults on Software
(an example dated 09 July 2003 - ctd.)
Outside our Model
Int rsaDecrypt( CRYPT_INFO *cryptInfo,
BYTE *buffer, int noBytes )
{ /* ... snip ... */
/* computing:
* p2 = ((C mod p) **exponent1) mod p;
* q2 = ((C mod q) **exponent1) mod p;
* ... */
/* p2 = p2 - q2; if p2  0 then p2 =
p2 + p */
CK( BN_sub( p2, p2, q2 ) );
if( p2-neg )
CK( BN_add( p2, p2, p ) );
/* ... */
}
int rsaDecrypt( CRYPT_INFO *cryptInfo,
BYTE *buffer, int noBytes )
{ /* ... snip ... */
/* p2 = p2 - q2; if p2  0 then p2 =
p2 + p. In some extremely rare
cases (q2 large, p2 small) we have
to add p twice to get p2 positive
*/
CK( BN_sub( p2, p2, q2 ) );
while( p2-neg )
{
CK( BN_add( p2, p2, p ) );
if( bnStatusError( bnStatus )
return(
getBnStatus(bnStatus ) );
}
/* ... */
}
Incorrect Correct
Overview of the Talk2
Introduction
3
Definitions and Background
4
Deliberately Un-Dependable Applications
5
Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics
6
The Impact on Security Policies
7
The Impact on Standards
8
Conclusions
DUDA
9
A class of malware
@
A twofold phenomenological cause of faults
A
Absence of additional (malicious) logics
B
Embedded at design time
C
Aimed at facilitating fault attacks
D
By maximizing either the probability of observing
faults, or the risks associated to the
occurrences/activation of them
DUDA (ctd.)
Overview of the Talk
E
Introduction
F
Definitions and Background
G
Deliberately Un-Dependable Applications
H
Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics
I
The Impact on Security Policies
P
The Impact on Standards
Q
Conclusions
Facilitating the Practicality of Fault Attacks
by Exploiting Workload Characteristics
R
Dependability metrics has often been observed to
correlate with workload characteristics. In
particular with either:
S
Computational load of the system
T
Memory or CPU utilization
U
Or the characteristics of its application code:
V
Read/write ratio
W
Memory allocation schemes / Access patterns
X
For instance, failure rates increase with workload
(and mission times resp. decreases)
{De,In}creasing the Probability of
Observing Faults: the case of memory
Y
The possible consequences of memory faults:
1. The (target) software is not affected
2. The fault affects the code part producing a crash
3. The fault affects the code part causing an erroneous state that
may be (or not) corrected by the handling mechanism in
software, if any.
4. The data part gets affected in a fatal way
5. The data part gets affected but not in a fatal way. The
erroneous memory value(s) causes a “drift” in subsequent
computations
6. The data part gets affected but the error is masked
{De,In}creasing the Probability of
Observing Faults: the case of memory (ctd.)
`
Some results from the reliability engineering
community:
a
Workload characteristics have a major impact on
memory reliability (Meyer, Wei)
b
Different memory allocation schemes produce
different increments in failure rates in the range of
32% to 53% (Bowen, Pradhan)
A first instance of DUDA
c
When a system runs at a low load
d
The programs are able to execute with the amount of
dead blocks they requested to the “memory manager”
e
A considerable amount of errors do not cause failures
because of the increased probability of hitting a dead
block
A first instance of DUDA
{De,In}creasing the Probability of
Observing Faults: the case of memory (ctd.)
f
As the workload increase:
g
The operating system becomes resource constrained
and thus trims away many of the dead block leaving
each job with a much higher percentage of live blocks
h
This increases the probability that a fault affects a live
block and thus the observed failure rate increases
A first instance of DUDA
{De,In}creasing the Probability of
Observing Faults: the case of memory (ctd.)
{De,In}creasing the Probability of
Observing Faults: the case of memory (ctd.)
P U
i
MemFail
p
Pr # dead-block fault
q
1 Pr # in-use block faults
r
0
Pr # total-block faults = 1
stuv
wxxy€v
‚u
ƒ„
‚yt
…u
†u‡
u
‚‚ˆ‰
…
ˆt‡
‚
†u
‘
v
u
tu
‰€
u
’“‰
”
ˆ€
wx
v
xy€
‚ˆy‰
•—–
••˜
™•—–
••˜
d
•—–
••˜
e•—–
••˜
f•—–
••˜
g•—–
••˜
h•—–
••˜
i•—–
••˜
j•—–
••˜
k•—–
••˜
™••—–
••˜
lmn
opqrs
q
t
uopqrs
q
t
Overview of the Talkv
Introduction
w
Definitions and Background
x
Deliberately Un-Dependable Applications
y
Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics
z
The Impact on Security Policies
{
The Impact on Standards
|
Conclusions
The Impact on Security Policies:
Selecting Key-Lifetimes
}
Definition 1: Cryptographic Scheme Failure-Tolerance
Informally: The maximum number of erroneous
computations that a cryptographic black-box
implementing the cryptographic scheme
~
can output
before the key-material get exposed by a fault attack
The Impact on Security Policies:
Selecting Key-Lifetimes (ctd.)

Consider to compare three similar cryptographic device
€‚
ƒ
and
„
implementing the cryptographic scheme
…
†
‡
= reference implementation
ˆ
‰
= modeled considering the
workload with max. un-observability,
Š
= workload with min.
un-observability
‹
They have more operational states. The service is given only while
at a particular state denominated service.
Œ
Each of them takes γ

hours before entering the service state
Ž
The time of occurrence of the failures in the system is considered
to be a random variable with the corresponding distribution being
exponential with two-variables with rates respectively equal to λ1,
λ2, λ3 and γ = γ

The Impact on Security Policies:
Selecting Key-Lifetimes (ctd.)

The reliability of the system at time t is expressed as:
‘
The system is considered to be functioning as long as the
key material has not been exposed (i.e., as long as the
number of failure is less than or equal to the CSFT value
of the cryptographic scheme implemented)
’
While providing service, the error probability must be
kept less than or equal to ε
R sys
“
e
”
•
t –
—
The Impact on Security Policies:
Selecting Key-Lifetimes (ctd.)
˜
Hence the lifetime of the key-material should
NOT exceed the exponential reliable life (i.e.,
mission time) defined as:
where is the desired reliability goal.
KeyLifetime
™
t R
š
›œ
ln 1
ž
Ÿ
F
 
1
¡
1
¢
£
F
¤
1
The Impact on Security Policies:
Selecting Key-Lifetimes (ctd.)
∆%
¥¦¨§
©«ª
¬
­§®
¦¨¯
°
±³²
¬µ´
­·¶®
¶
¸¹
¶
ª
º
»¼
º²¹½
¾¿
»
»À
À
²¹
À
¾¿
»
»À
¹
²
Á
Â
¾¿
»
»À
º
º
ò
Ä
ÃÀ
²½
Å
Æ
‚
¸
Ã
»¹
º¼
¹
²À
Á
¾¿
»
»
Ä
ò
Á
Â
¾¿
»
»
Ä
ò
Ä
Ä
¾¿
»
»
Ä
¹
º
½
¹
ò
Á
º
ÃÀ
²
Á¹
¬´
­·ÈÉ
¯¯
Ê·Ë
°
±³²
̯É
©
É
¸¹
¶
ª
º
»¼
À
²
Å
Á
¾¿
»
»
Ä
¹
²
Â
º
¾¿
»
»
Ä
¹
²
ÄÀ
¾¿
»
»
Ä
º
»¹
Å
Ų¹
Ä
ÃÀ
²
ÁÀ
Í
ÎϝÐ
Ñ
ÍÒ
ÓÕÔ
Ö
Ö×Ð
Ö
Ö
Ó
ÓÕÔ
Ö
Ö×Ð
Ö
Ö
Ó
ÓÕÔ
Ö
Ö×Ð
Ö
Ö
Ó
Ö
Ö
Ï
×
Î
ÓØÙ
ÏÚÚÛ
Ü
Ý
Ó
ÞÔ
ßØ
×Ð
Ö
Öà
à
ÔØ
ß×Ð
Ö
Öà
áÔ
ßâ
×Ð
Ö
Öà
Þ
Ù
à
áÔ
ÖØ
Ó
áÔâ
Ø
Ï
×
Î
ÓØÙ
ÏÚÚÛ
Ü
ÝØ
ÓÕÔàÙ
×Ð
Ö
Ö
Þ
ÓÕÔ
ÓØ
×Ð
Ö
Ö
Þ
ãÔ
ß
ã×Ð
Ö
Öà
Ó
Þà
Ó
ãÔ
ÞØ
Ó
áÔâ
Ø
äåæ
ç
è·éê
ëì
íî
ïð
∆
ñóòôöõ
÷ø
ù
With ε = 2e-40, γ = 10 hours,
λ1 = 1.52e-05, λ2 = 2.0064e-05, λ3 = 2.32560e-05
MTTF1 = 65800 MTTF2 = 49851 MTTF3 = 43010
The Impact on Security Policies:
Selecting Key-Lifetimes (ctd.)
The Impact on Security Policies:
Selecting Key-Lifetimes (ctd.)
ú
The importance of dependability metrics should not be
overlooked. By exploiting them (e.g., increasing the f.r.
/ decreasing the MTTF) it's possible to facilitate fault
attacks.
û
Reliability modeling gives us a boundary for the
key-lifetimes of cryptographic schemes implemented in
real devices: the system reliable life
ü
RSA+CRT cannot be securely used in today systems
with mid-level failure rates, while requiring an
unreliability less than or equal to a negligible
probability error
Overview of the Talk
ý
Introduction
þ
Definitions and Background
ÿ
Deliberately Un-Dependable Applications
 
Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics
¡
The Impact on Security Policies
¢
The Impact on Standards
£
Conclusions
The Impact on Standards
¤
Claim 1: The presented class of attacks pass
unnoticed to the assessment techniques used in
today security standards
¥
Claim 2: It's necessary to support today standards
with additional and definite dependability
requirements
The Impact on Standards: FIPS 140-2
¦
Environmental failure protection (EFP):
protection against unusual environmental conditions or
fluctuations (accidental or induced) outside the module's
normal operating range that can compromise the security of
the module – with temperature and voltage mention explicitly
§
Environmental failure testing (EFT): combination of analysis,
simulation and testing of cryptographic module to provide
reasonable assurance that no compromise of the security is
possible due to environmental conditions fluctuations
¨
FIPS 140-2 do not address augmented failure rates at
standard environmental conditions
Security Level 4 Requirements
The Impact on Standards:
FIPS 140-2 (ctd.)
The Problem of the Correctness Notion:
or How Badly a “Correct” Implementation Can Behave?
©
Informal and formal proofs of correspondence between
different abstraction levels:

A formal model for the rules and characteristics of the cryptographic
module security policy, using a formal specification language

An informal proof of the correspondence between the formal model
and the functional specifications

For each component, function and procedure a description of its
behavior using {pre,post}conditions

Informal proof of the correspondence between the design and the
functional specification
The Impact on Standards:
FIPS 140-2 (ctd.)
However, using DUDAs it is possible to add malicious
behaviors without the need for additional logics

A formal proof of correspondence between the design
and the functional specification of a device is not
sufficient to rule out the presence of additional and
unexpected malicious behaviors.

Hence, relying parties are unable to build a trust
relationship with cryptographic module fully compliant
with today standard requirements.
The Problem of the Correctness Notion:
or How Badly a “Correct” Implementation Can Behave?
Overview of the Talk

Introduction

Definitions and Background

Deliberately Un-Dependable Applications
Facilitating the Practicality of Fault Attacks by
Exploiting Workload Characteristics
!
The Impact on Security Policies

The Impact on Standards
#
Conclusions
Conclusions$
Inducing fault locally is not the only way to
increase the occurrences of erroneous
computations in security devices
%
Augmenting the probability of observing natural
occurring and dormant faults is an alternative
Conclusions (ctd.)
A new class of malware has been introduced
'
Its nature is subtle and unique
(
The attack paradigm takes advantage of faults with a
twofold phenomenological cause
)
And enables manufacturers to add malicious behaviors
without additional logics
0
It gives us an attack model against security modules
1
A first instance of DUDA has been presented. It is
show how dependability metrics can be undermined
by exploiting workload characteristics
Conclusions (ctd.)2
Its possible to use any cryptographic scheme without
being afraid of fault attacks already known in literature,
if the reliability of the cryptographic module is carefully
modeled.
3
The exponential reliable life give us a boundary for
key-lifetimes
4
RSA+CRT cannot be securely used in today systems
with mid-level failure rates, while requiring an
unreliability less than or equal to a standard negligible
probability error for cryptographic context (2e-40)
Conclusions (ctd.)5
DUDA attacks passes unnoticed to the assessment
techniques used to evaluate today cryptographic modules
at the highest “security” levels
6
More importantly:
There is the need to support today standards with more
definite dependability requirements.
Conclusions: Further Works
7
Complete a first taxonomy of DUDA based
attacks on security systems
8
Provide a generalized framework to model the
reliability of complex cryptographic
infrastructures.
9
It will guide us in recommending key-lifetimes in
presence of faults.
@
Complete the analysis on the impact on standards
Thanks!
Any question?
Alfonso.DeGregorio@esat.kuleuven.ac.be
adg@com-and.com

More Related Content

What's hot

AI & ML in Cyber Security - Why Algorithms are Dangerous
AI & ML in Cyber Security - Why Algorithms are DangerousAI & ML in Cyber Security - Why Algorithms are Dangerous
AI & ML in Cyber Security - Why Algorithms are Dangerous
Raffael Marty
 
Hardware Trojan Identification and Detection
Hardware Trojan Identification and DetectionHardware Trojan Identification and Detection
Hardware Trojan Identification and Detection
ijcisjournal
 
SAST, CWE, SEI CERT and other smart words from the information security world
SAST, CWE, SEI CERT and other smart words from the information security worldSAST, CWE, SEI CERT and other smart words from the information security world
SAST, CWE, SEI CERT and other smart words from the information security world
Andrey Karpov
 
Infrastructure Attacks - The Next generation, ESET LLC
Infrastructure Attacks - The Next generation, ESET LLCInfrastructure Attacks - The Next generation, ESET LLC
Infrastructure Attacks - The Next generation, ESET LLC
Infosec Europe
 
Near-memory & In-Memory Detection of Fileless Malware
Near-memory & In-Memory Detection of Fileless MalwareNear-memory & In-Memory Detection of Fileless Malware
Near-memory & In-Memory Detection of Fileless Malware
Marcus Botacin
 
Malicious ELF Binaries: A Landscape
Malicious ELF Binaries: A LandscapeMalicious ELF Binaries: A Landscape
Malicious ELF Binaries: A Landscape
Marcus Botacin
 
Testbed For Ids
Testbed For IdsTestbed For Ids
Testbed For Ids
amiable_indian
 
Test versus security @ IEEE Concept
Test versus security @ IEEE ConceptTest versus security @ IEEE Concept
Test versus security @ IEEE Concept
kodela3
 
From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...
From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...
From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...
Priyanka Aash
 
2011-05-02 - VU Amsterdam - Testing safety critical systems
2011-05-02 - VU Amsterdam - Testing safety critical systems2011-05-02 - VU Amsterdam - Testing safety critical systems
2011-05-02 - VU Amsterdam - Testing safety critical systems
Jaap van Ekris
 
Iins practice questions
Iins practice questionsIins practice questions
Iins practice questions
teknik komputer ui
 
Application of machine learning and cognitive computing in intrusion detectio...
Application of machine learning and cognitive computing in intrusion detectio...Application of machine learning and cognitive computing in intrusion detectio...
Application of machine learning and cognitive computing in intrusion detectio...
Mahdi Hosseini Moghaddam
 
Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...
Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...
Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...
Jaap van Ekris
 
IRJET- SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...
IRJET-  	  SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...IRJET-  	  SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...
IRJET- SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...
IRJET Journal
 
zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]
zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]
zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]
Alex Pruden
 
A theoretical superworm
A theoretical superwormA theoretical superworm
A theoretical superworm
UltraUploader
 
44CON & Ruxcon: SDN security
44CON & Ruxcon: SDN security44CON & Ruxcon: SDN security
44CON & Ruxcon: SDN security
David Jorm
 
Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...
Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...
Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...
Daniel Fernando Pigatto
 
Variability, Bugs, and Cognition
Variability, Bugs, and CognitionVariability, Bugs, and Cognition
Variability, Bugs, and Cognition
Andrzej Wasowski
 
Malware Collection and Analysis via Hardware Virtualization
Malware Collection and Analysis via Hardware VirtualizationMalware Collection and Analysis via Hardware Virtualization
Malware Collection and Analysis via Hardware Virtualization
Tamas K Lengyel
 

What's hot (20)

AI & ML in Cyber Security - Why Algorithms are Dangerous
AI & ML in Cyber Security - Why Algorithms are DangerousAI & ML in Cyber Security - Why Algorithms are Dangerous
AI & ML in Cyber Security - Why Algorithms are Dangerous
 
Hardware Trojan Identification and Detection
Hardware Trojan Identification and DetectionHardware Trojan Identification and Detection
Hardware Trojan Identification and Detection
 
SAST, CWE, SEI CERT and other smart words from the information security world
SAST, CWE, SEI CERT and other smart words from the information security worldSAST, CWE, SEI CERT and other smart words from the information security world
SAST, CWE, SEI CERT and other smart words from the information security world
 
Infrastructure Attacks - The Next generation, ESET LLC
Infrastructure Attacks - The Next generation, ESET LLCInfrastructure Attacks - The Next generation, ESET LLC
Infrastructure Attacks - The Next generation, ESET LLC
 
Near-memory & In-Memory Detection of Fileless Malware
Near-memory & In-Memory Detection of Fileless MalwareNear-memory & In-Memory Detection of Fileless Malware
Near-memory & In-Memory Detection of Fileless Malware
 
Malicious ELF Binaries: A Landscape
Malicious ELF Binaries: A LandscapeMalicious ELF Binaries: A Landscape
Malicious ELF Binaries: A Landscape
 
Testbed For Ids
Testbed For IdsTestbed For Ids
Testbed For Ids
 
Test versus security @ IEEE Concept
Test versus security @ IEEE ConceptTest versus security @ IEEE Concept
Test versus security @ IEEE Concept
 
From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...
From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...
From Thousands of Hours to a Couple of Minutes: Automating Exploit Generation...
 
2011-05-02 - VU Amsterdam - Testing safety critical systems
2011-05-02 - VU Amsterdam - Testing safety critical systems2011-05-02 - VU Amsterdam - Testing safety critical systems
2011-05-02 - VU Amsterdam - Testing safety critical systems
 
Iins practice questions
Iins practice questionsIins practice questions
Iins practice questions
 
Application of machine learning and cognitive computing in intrusion detectio...
Application of machine learning and cognitive computing in intrusion detectio...Application of machine learning and cognitive computing in intrusion detectio...
Application of machine learning and cognitive computing in intrusion detectio...
 
Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...
Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...
Embedded Systems, Asset or Security Threat? (6 May 2014, (ICS)2 Secure Rotter...
 
IRJET- SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...
IRJET-  	  SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...IRJET-  	  SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...
IRJET- SDN Multi-Controller based Framework to Detect and Mitigate DDoS i...
 
zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]
zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]
zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]
 
A theoretical superworm
A theoretical superwormA theoretical superworm
A theoretical superworm
 
44CON & Ruxcon: SDN security
44CON & Ruxcon: SDN security44CON & Ruxcon: SDN security
44CON & Ruxcon: SDN security
 
Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...
Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...
Defesa de Doutorado: HAMSTER - healthy, mobility and security-based data comm...
 
Variability, Bugs, and Cognition
Variability, Bugs, and CognitionVariability, Bugs, and Cognition
Variability, Bugs, and Cognition
 
Malware Collection and Analysis via Hardware Virtualization
Malware Collection and Analysis via Hardware VirtualizationMalware Collection and Analysis via Hardware Virtualization
Malware Collection and Analysis via Hardware Virtualization
 

Similar to Deliberately Un-Dependable Applications: the Role of Dependability Metrics in Fault-Based Cryptanalysis

A Summary of Comparative Study of Software Reliability: A Review
A Summary of Comparative Study of Software Reliability: A ReviewA Summary of Comparative Study of Software Reliability: A Review
A Summary of Comparative Study of Software Reliability: A Review
IRJET Journal
 
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...
Jorge Cardoso
 
publication1
publication1publication1
publication1
Mauro Pellicioli
 
Approximating Attack Surfaces with Stack Traces [ICSE 15]
Approximating Attack Surfaces with Stack Traces [ICSE 15]Approximating Attack Surfaces with Stack Traces [ICSE 15]
Approximating Attack Surfaces with Stack Traces [ICSE 15]
Chris Theisen
 
The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...
The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...
The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...
Mark Underwood
 
MIT Bitcoin Expo 2018 - Hardware Wallets Security
MIT Bitcoin Expo 2018 - Hardware Wallets SecurityMIT Bitcoin Expo 2018 - Hardware Wallets Security
MIT Bitcoin Expo 2018 - Hardware Wallets Security
Charles Guillemet
 
An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...
An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...
An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...
Sebastiano Panichella
 
introduction to Embedded System Security
introduction to Embedded System Securityintroduction to Embedded System Security
introduction to Embedded System Security
Adel Barkam
 
Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...
Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...
Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...
IJECEIAES
 
Safety Integrity Levels
Safety Integrity LevelsSafety Integrity Levels
Safety Integrity Levels
Sandeep Patalay
 
Virtual Machines Security Internals: Detection and Exploitation
 Virtual Machines Security Internals: Detection and Exploitation Virtual Machines Security Internals: Detection and Exploitation
Virtual Machines Security Internals: Detection and Exploitation
Mattia Salvi
 
Stanford Cybersecurity January 2009
Stanford Cybersecurity January 2009Stanford Cybersecurity January 2009
Stanford Cybersecurity January 2009
Jason Shen
 
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
INSIGHT FORENSIC
 
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
INSIGHT FORENSIC
 
Effective Prioritization Through Exploit Prediction
Effective Prioritization Through Exploit Prediction Effective Prioritization Through Exploit Prediction
Effective Prioritization Through Exploit Prediction
Jonathan Cran
 
AktaionPPTv5_JZedits
AktaionPPTv5_JZeditsAktaionPPTv5_JZedits
AktaionPPTv5_JZedits
Rod Soto
 
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
Open Networking Perú (Opennetsoft)
 
Software security
Software securitySoftware security
Software security
Roman Oliynykov
 
httpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docx
httpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docxhttpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docx
httpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docx
pooleavelina
 
A Back Propagation Neural Network Intrusion Detection System Based on KVM
A Back Propagation Neural Network Intrusion Detection System Based on KVMA Back Propagation Neural Network Intrusion Detection System Based on KVM
A Back Propagation Neural Network Intrusion Detection System Based on KVM
International Journal of Innovation Engineering and Science Research
 

Similar to Deliberately Un-Dependable Applications: the Role of Dependability Metrics in Fault-Based Cryptanalysis (20)

A Summary of Comparative Study of Software Reliability: A Review
A Summary of Comparative Study of Software Reliability: A ReviewA Summary of Comparative Study of Software Reliability: A Review
A Summary of Comparative Study of Software Reliability: A Review
 
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...
Cloud Operations and Analytics: Improving Distributed Systems Reliability usi...
 
publication1
publication1publication1
publication1
 
Approximating Attack Surfaces with Stack Traces [ICSE 15]
Approximating Attack Surfaces with Stack Traces [ICSE 15]Approximating Attack Surfaces with Stack Traces [ICSE 15]
Approximating Attack Surfaces with Stack Traces [ICSE 15]
 
The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...
The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...
The Quality “Logs”-Jam: Why Alerting for Cybersecurity is Awash with False Po...
 
MIT Bitcoin Expo 2018 - Hardware Wallets Security
MIT Bitcoin Expo 2018 - Hardware Wallets SecurityMIT Bitcoin Expo 2018 - Hardware Wallets Security
MIT Bitcoin Expo 2018 - Hardware Wallets Security
 
An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...
An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...
An Empirical Characterization of Software Bugs in Open-Source Cyber-Physical ...
 
introduction to Embedded System Security
introduction to Embedded System Securityintroduction to Embedded System Security
introduction to Embedded System Security
 
Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...
Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...
Revealing AES Encryption Device Key on 328P Microcontrollers with Differentia...
 
Safety Integrity Levels
Safety Integrity LevelsSafety Integrity Levels
Safety Integrity Levels
 
Virtual Machines Security Internals: Detection and Exploitation
 Virtual Machines Security Internals: Detection and Exploitation Virtual Machines Security Internals: Detection and Exploitation
Virtual Machines Security Internals: Detection and Exploitation
 
Stanford Cybersecurity January 2009
Stanford Cybersecurity January 2009Stanford Cybersecurity January 2009
Stanford Cybersecurity January 2009
 
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
 
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)(120715) #fitalk   the era of cyber sabotage and warfare (case study - stuxnet)
(120715) #fitalk the era of cyber sabotage and warfare (case study - stuxnet)
 
Effective Prioritization Through Exploit Prediction
Effective Prioritization Through Exploit Prediction Effective Prioritization Through Exploit Prediction
Effective Prioritization Through Exploit Prediction
 
AktaionPPTv5_JZedits
AktaionPPTv5_JZeditsAktaionPPTv5_JZedits
AktaionPPTv5_JZedits
 
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
 
Software security
Software securitySoftware security
Software security
 
httpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docx
httpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docxhttpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docx
httpscdnapisec.kaltura.comindex.phpextwidgetpreviewpartner_.docx
 
A Back Propagation Neural Network Intrusion Detection System Based on KVM
A Back Propagation Neural Network Intrusion Detection System Based on KVMA Back Propagation Neural Network Intrusion Detection System Based on KVM
A Back Propagation Neural Network Intrusion Detection System Based on KVM
 

More from a001

The Vulnerability Supply Chain - HackIT Ukraine 2016, Kharkiv
The Vulnerability Supply Chain - HackIT Ukraine 2016, KharkivThe Vulnerability Supply Chain - HackIT Ukraine 2016, Kharkiv
The Vulnerability Supply Chain - HackIT Ukraine 2016, Kharkiv
a001
 
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
a001
 
Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...
Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...
Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...
a001
 
Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...
Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...
Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...
a001
 
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)
a001
 
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
a001
 
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit
illusoryTLS: Nobody But Us Impersonate, Tamper, ExploitillusoryTLS: Nobody But Us Impersonate, Tamper, Exploit
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit
a001
 
Auscert20150daymarket
Auscert20150daymarketAuscert20150daymarket
Auscert20150daymarket
a001
 
The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...
a001
 
illusoryTLS: Impersonate, Tamper, and Exploit
illusoryTLS: Impersonate, Tamper, and ExploitillusoryTLS: Impersonate, Tamper, and Exploit
illusoryTLS: Impersonate, Tamper, and Exploit
a001
 
Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...
Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...
Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...
a001
 

More from a001 (11)

The Vulnerability Supply Chain - HackIT Ukraine 2016, Kharkiv
The Vulnerability Supply Chain - HackIT Ukraine 2016, KharkivThe Vulnerability Supply Chain - HackIT Ukraine 2016, Kharkiv
The Vulnerability Supply Chain - HackIT Ukraine 2016, Kharkiv
 
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
 
Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...
Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...
Andy, the Polluters, Rick Deckard, and Other Bounty Hunters
Vulnerabilities a...
 
Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...
Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...
Vulnerabilities and their Surrounding Ethical Questions: A Code of Ethics for...
 
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit (DeepSEC 2015)
 
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja’s Ultimatum, and the Shadow of the Future: Extortion...
 
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit
illusoryTLS: Nobody But Us Impersonate, Tamper, ExploitillusoryTLS: Nobody But Us Impersonate, Tamper, Exploit
illusoryTLS: Nobody But Us Impersonate, Tamper, Exploit
 
Auscert20150daymarket
Auscert20150daymarketAuscert20150daymarket
Auscert20150daymarket
 
The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...
The Bazaar, the Maharaja's Ultimatum, and the Shadow of the Future: Extortion...
 
illusoryTLS: Impersonate, Tamper, and Exploit
illusoryTLS: Impersonate, Tamper, and ExploitillusoryTLS: Impersonate, Tamper, and Exploit
illusoryTLS: Impersonate, Tamper, and Exploit
 
Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...
Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...
Cryptographic Key Reliable Lifetimes - Bounding the Risk of Key Exposure in t...
 

Recently uploaded

Transforming Product Development using OnePlan To Boost Efficiency and Innova...
Transforming Product Development using OnePlan To Boost Efficiency and Innova...Transforming Product Development using OnePlan To Boost Efficiency and Innova...
Transforming Product Development using OnePlan To Boost Efficiency and Innova...
OnePlan Solutions
 
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA ComplianceSecure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
ICS
 
Ensuring Efficiency and Speed with Practical Solutions for Clinical Operations
Ensuring Efficiency and Speed with Practical Solutions for Clinical OperationsEnsuring Efficiency and Speed with Practical Solutions for Clinical Operations
Ensuring Efficiency and Speed with Practical Solutions for Clinical Operations
OnePlan Solutions
 
Modelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - AmsterdamModelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - Amsterdam
Alberto Brandolini
 
Assure Contact Center Experiences for Your Customers With ThousandEyes
Assure Contact Center Experiences for Your Customers With ThousandEyesAssure Contact Center Experiences for Your Customers With ThousandEyes
Assure Contact Center Experiences for Your Customers With ThousandEyes
ThousandEyes
 
Penify - Let AI do the Documentation, you write the Code.
Penify - Let AI do the Documentation, you write the Code.Penify - Let AI do the Documentation, you write the Code.
Penify - Let AI do the Documentation, you write the Code.
KrishnaveniMohan1
 
Building API data products on top of your real-time data infrastructure
Building API data products on top of your real-time data infrastructureBuilding API data products on top of your real-time data infrastructure
Building API data products on top of your real-time data infrastructure
confluent
 
如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样
如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样
如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样
gapen1
 
美洲杯赔率投注网【​网址​🎉3977·EE​🎉】
美洲杯赔率投注网【​网址​🎉3977·EE​🎉】美洲杯赔率投注网【​网址​🎉3977·EE​🎉】
美洲杯赔率投注网【​网址​🎉3977·EE​🎉】
widenerjobeyrl638
 
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...
Luigi Fugaro
 
Streamlining End-to-End Testing Automation
Streamlining End-to-End Testing AutomationStreamlining End-to-End Testing Automation
Streamlining End-to-End Testing Automation
Anand Bagmar
 
Computer Science & Engineering VI Sem- New Syllabus.pdf
Computer Science & Engineering VI Sem- New Syllabus.pdfComputer Science & Engineering VI Sem- New Syllabus.pdf
Computer Science & Engineering VI Sem- New Syllabus.pdf
chandangoswami40933
 
What is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdfWhat is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdf
kalichargn70th171
 
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdfSoftware Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
kalichargn70th171
 
Flutter vs. React Native: A Detailed Comparison for App Development in 2024
Flutter vs. React Native: A Detailed Comparison for App Development in 2024Flutter vs. React Native: A Detailed Comparison for App Development in 2024
Flutter vs. React Native: A Detailed Comparison for App Development in 2024
dhavalvaghelanectarb
 
一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理
一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理
一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理
kgyxske
 
ppt on the brain chip neuralink.pptx
ppt  on   the brain  chip neuralink.pptxppt  on   the brain  chip neuralink.pptx
ppt on the brain chip neuralink.pptx
Reetu63
 
Upturn India Technologies - Web development company in Nashik
Upturn India Technologies - Web development company in NashikUpturn India Technologies - Web development company in Nashik
Upturn India Technologies - Web development company in Nashik
Upturn India Technologies
 
Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...
Paul Brebner
 

Recently uploaded (20)

Transforming Product Development using OnePlan To Boost Efficiency and Innova...
Transforming Product Development using OnePlan To Boost Efficiency and Innova...Transforming Product Development using OnePlan To Boost Efficiency and Innova...
Transforming Product Development using OnePlan To Boost Efficiency and Innova...
 
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA ComplianceSecure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
 
Ensuring Efficiency and Speed with Practical Solutions for Clinical Operations
Ensuring Efficiency and Speed with Practical Solutions for Clinical OperationsEnsuring Efficiency and Speed with Practical Solutions for Clinical Operations
Ensuring Efficiency and Speed with Practical Solutions for Clinical Operations
 
Modelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - AmsterdamModelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - Amsterdam
 
Assure Contact Center Experiences for Your Customers With ThousandEyes
Assure Contact Center Experiences for Your Customers With ThousandEyesAssure Contact Center Experiences for Your Customers With ThousandEyes
Assure Contact Center Experiences for Your Customers With ThousandEyes
 
Penify - Let AI do the Documentation, you write the Code.
Penify - Let AI do the Documentation, you write the Code.Penify - Let AI do the Documentation, you write the Code.
Penify - Let AI do the Documentation, you write the Code.
 
Building API data products on top of your real-time data infrastructure
Building API data products on top of your real-time data infrastructureBuilding API data products on top of your real-time data infrastructure
Building API data products on top of your real-time data infrastructure
 
如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样
如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样
如何办理(hull学位证书)英国赫尔大学毕业证硕士文凭原版一模一样
 
美洲杯赔率投注网【​网址​🎉3977·EE​🎉】
美洲杯赔率投注网【​网址​🎉3977·EE​🎉】美洲杯赔率投注网【​网址​🎉3977·EE​🎉】
美洲杯赔率投注网【​网址​🎉3977·EE​🎉】
 
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...
 
Streamlining End-to-End Testing Automation
Streamlining End-to-End Testing AutomationStreamlining End-to-End Testing Automation
Streamlining End-to-End Testing Automation
 
Computer Science & Engineering VI Sem- New Syllabus.pdf
Computer Science & Engineering VI Sem- New Syllabus.pdfComputer Science & Engineering VI Sem- New Syllabus.pdf
Computer Science & Engineering VI Sem- New Syllabus.pdf
 
What is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdfWhat is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdf
 
bgiolcb
bgiolcbbgiolcb
bgiolcb
 
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdfSoftware Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
 
Flutter vs. React Native: A Detailed Comparison for App Development in 2024
Flutter vs. React Native: A Detailed Comparison for App Development in 2024Flutter vs. React Native: A Detailed Comparison for App Development in 2024
Flutter vs. React Native: A Detailed Comparison for App Development in 2024
 
一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理
一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理
一比一原版(sdsu毕业证书)圣地亚哥州立大学毕业证如何办理
 
ppt on the brain chip neuralink.pptx
ppt  on   the brain  chip neuralink.pptxppt  on   the brain  chip neuralink.pptx
ppt on the brain chip neuralink.pptx
 
Upturn India Technologies - Web development company in Nashik
Upturn India Technologies - Web development company in NashikUpturn India Technologies - Web development company in Nashik
Upturn India Technologies - Web development company in Nashik
 
Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...
 

Deliberately Un-Dependable Applications: the Role of Dependability Metrics in Fault-Based Cryptanalysis

  • 1. Deliberately Un-Dependable Applications: the Role of Dependability Metrics in Fault-Based Cryptanalysis Alfonso De Gregorio C & A S.r.l. www.com-and.com 8th August 2003 K.U.Leuven, COSIC-ESAT, Kasteelpark Arenberg 10, 3001 Leuven-Heverlee
  • 2. Agenda  Introduction ¡ Fault Attacks ¡ The Model   Definitions and Background   Deliberately Un-Dependable Applications   Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics   The Impact on Security Policies   The Impact on Standards   Conclusions
  • 3. Introduction "Why erect majestic walls if comfortable underpasses will always remain wide open?" Silvio Micali and Leonid Reyzin Physically Observable Cryptography <http://eprint.iacr.org/2003/120.pdf>
  • 4. Essentially related to the way the attacker can interact with the target device and to the respective “observation” techniques available to the opponent: ¢ Local Scenario: Unsupervised physical access to one or more instances of cryptographic equipment: £ Analysis of Sounds Given off by Rotor Machines £ Timing Attacks £ Power Analysis £ Electromagnetic Emissions Analysis £ Fault Attacks (injectable faults – e.g., optically) ¢ Black-box Scenario: Access to a remote device through a crypto protocol: £ Fault Attacks (random occurring faults) Introduction: Feasibility of Physical Attacks
  • 5. Fault Attacks: How faults interacts with security problems Fact 1: Active faults jeopardize security ¤ Data errors: Erroneous cryptographic values enables an attacker to expose the secret crypto key material, without breaking the underlying algorithms ¤ Code errors: Single-bit control flow errors can completely change the result of decision procedures in many security context (e.g., authorization, authentication, rounds in iterated algorithms)
  • 6. Fault Attacks: How faults interacts with security problems (ctd.) Fact 2: Their inherent availability threaten the very relevance of the schemes that are provably secure by a complexity-theoretic point of view
  • 7. Fault Attacks: exploiting them Local Scenario / Induced Faults:¥ Goal: to augment the occurrences of erroneous computations passed back to the user (i.e., fail-silent violations in f.t.s.) ¥ Note: inducing faults locally has been the only approach to increase the occurrences of fail-silent violations! ¥ Feasibility: the feasibility of inducing faults in diligently designed cryptographic modules is questioned by D.P. Maher and remains the significant challenge for the opponent: “Fault Injection Attacks, Tamper Resistance, and Hostile Reverse Engineering in Perspective”, FC97 ¥ Partially addressed in security standards: FIPS 140-2 (EFP and EFT), ISO 7816/{1,2} – ISO 7810, CC (FPT_PHP)
  • 8. Fault Attacks: exploiting them (ctd) Black-box model / Random occurring faults: The probability of observing them is conditioned on the black-box dependability metrics and on the (standard) environmental conditions (e.g., SEU rates)
  • 9. Fault Attacks: a first question Is it possible to augment the occurrences of erroneous computations passed back to the user interface, in “diligently engineered” cryptographic modules, without inducing faults locally?
  • 10. The Model ¦ A cryptographic module contains some cryptographic secret § The module interacts with the outside world following a cryptographic protocol § From time to time the module is affected by a random fault causing it to output erroneous values
  • 11. The Model (ctd.)¨ The cryptographic module has been designed to be evaluated by trusted third parties (e.g., evaluation/certification bodies) according to actual engineering standards at the highest assurance levels and the correctness of the implementations of its cryptographic algorithms has been formally verified
  • 12. The Model (ctd.) © But it is still possible either to increase the occurrences of erroneous computations (resp. fail-silent violations for f.t.s.), or maximize the risks associated with the occurrence of faults by carefully augmenting the probability of observing naturally occurring and dormant faults at standard environmental conditions Hence, to facilitate the feasibility of fault attacks
  • 13. Overview of the Talk Introduction Definitions and Background Deliberately Un-Dependable Applications Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics The Impact on Security Policies The Impact on Standards Conclusions
  • 15. Definitions and Background: Transient Faults on Hardware Bit-flips (a form of transient faults) happen more in memory then in the processor (Rad Project) In RISC processors (Furtado and Madeira): 60% cause data errors; 30% cause code errors; ! In CISC processors: 18% cause data errors; # 77% cause code errors; $ 20% of software failures are hw related (Iyer)
  • 16. Definitions and Background: Design Faults on Hardware Reported Design Faults in x86 µPs % Silber, Porras, and Lindell, “The Intel 80x86 Processor Architecture” IEEE C.S. Symposium on Research in Security and Privacy, May, 1995 Donald MacKenzie, “Mechanizing Proof – Computing, Risk, Trust”, MIT Press
  • 17. Definitions and Background: Dormant Faults on Software (an example dated 09 July 2003) ' Cryptlib Cryptographic Toolkit: ( On Sat 12 July the author, following an bug report dated 09 July, announce that due to a problem in the RSA implementation in some rare occasions the toolkit computes erroneous RSA signatures ) Cryptlib was computing 0.3% of erroneous signatures 0 Its RSA implementation uses the Chinese Remainder Theorem 1 The bug was present also in OpenSSL (some time ago) Outside our Model
  • 18. Definitions and Background: Dormant Faults on Software (an example dated 09 July 2003 - ctd.) Outside our Model Int rsaDecrypt( CRYPT_INFO *cryptInfo, BYTE *buffer, int noBytes ) { /* ... snip ... */ /* computing: * p2 = ((C mod p) **exponent1) mod p; * q2 = ((C mod q) **exponent1) mod p; * ... */ /* p2 = p2 - q2; if p2 0 then p2 = p2 + p */ CK( BN_sub( p2, p2, q2 ) ); if( p2-neg ) CK( BN_add( p2, p2, p ) ); /* ... */ } int rsaDecrypt( CRYPT_INFO *cryptInfo, BYTE *buffer, int noBytes ) { /* ... snip ... */ /* p2 = p2 - q2; if p2 0 then p2 = p2 + p. In some extremely rare cases (q2 large, p2 small) we have to add p twice to get p2 positive */ CK( BN_sub( p2, p2, q2 ) ); while( p2-neg ) { CK( BN_add( p2, p2, p ) ); if( bnStatusError( bnStatus ) return( getBnStatus(bnStatus ) ); } /* ... */ } Incorrect Correct
  • 19. Overview of the Talk2 Introduction 3 Definitions and Background 4 Deliberately Un-Dependable Applications 5 Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics 6 The Impact on Security Policies 7 The Impact on Standards 8 Conclusions
  • 20. DUDA 9 A class of malware @ A twofold phenomenological cause of faults A Absence of additional (malicious) logics B Embedded at design time C Aimed at facilitating fault attacks D By maximizing either the probability of observing faults, or the risks associated to the occurrences/activation of them
  • 22. Overview of the Talk E Introduction F Definitions and Background G Deliberately Un-Dependable Applications H Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics I The Impact on Security Policies P The Impact on Standards Q Conclusions
  • 23. Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics R Dependability metrics has often been observed to correlate with workload characteristics. In particular with either: S Computational load of the system T Memory or CPU utilization U Or the characteristics of its application code: V Read/write ratio W Memory allocation schemes / Access patterns X For instance, failure rates increase with workload (and mission times resp. decreases)
  • 24. {De,In}creasing the Probability of Observing Faults: the case of memory Y The possible consequences of memory faults: 1. The (target) software is not affected 2. The fault affects the code part producing a crash 3. The fault affects the code part causing an erroneous state that may be (or not) corrected by the handling mechanism in software, if any. 4. The data part gets affected in a fatal way 5. The data part gets affected but not in a fatal way. The erroneous memory value(s) causes a “drift” in subsequent computations 6. The data part gets affected but the error is masked
  • 25. {De,In}creasing the Probability of Observing Faults: the case of memory (ctd.) ` Some results from the reliability engineering community: a Workload characteristics have a major impact on memory reliability (Meyer, Wei) b Different memory allocation schemes produce different increments in failure rates in the range of 32% to 53% (Bowen, Pradhan) A first instance of DUDA
  • 26. c When a system runs at a low load d The programs are able to execute with the amount of dead blocks they requested to the “memory manager” e A considerable amount of errors do not cause failures because of the increased probability of hitting a dead block A first instance of DUDA {De,In}creasing the Probability of Observing Faults: the case of memory (ctd.)
  • 27. f As the workload increase: g The operating system becomes resource constrained and thus trims away many of the dead block leaving each job with a much higher percentage of live blocks h This increases the probability that a fault affects a live block and thus the observed failure rate increases A first instance of DUDA {De,In}creasing the Probability of Observing Faults: the case of memory (ctd.)
  • 28. {De,In}creasing the Probability of Observing Faults: the case of memory (ctd.) P U i MemFail p Pr # dead-block fault q 1 Pr # in-use block faults r 0 Pr # total-block faults = 1 stuv wxxy€v ‚u ƒ„ ‚yt …u †u‡ u ‚‚ˆ‰ … ˆt‡ ‚ †u ‘ v u tu ‰€ u ’“‰ ” ˆ€ wx v xy€ ‚ˆy‰ •—– ••˜ ™•—– ••˜ d •—– ••˜ e•—– ••˜ f•—– ••˜ g•—– ••˜ h•—– ••˜ i•—– ••˜ j•—– ••˜ k•—– ••˜ ™••—– ••˜ lmn opqrs q t uopqrs q t
  • 29. Overview of the Talkv Introduction w Definitions and Background x Deliberately Un-Dependable Applications y Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics z The Impact on Security Policies { The Impact on Standards | Conclusions
  • 30. The Impact on Security Policies: Selecting Key-Lifetimes } Definition 1: Cryptographic Scheme Failure-Tolerance Informally: The maximum number of erroneous computations that a cryptographic black-box implementing the cryptographic scheme ~ can output before the key-material get exposed by a fault attack
  • 31. The Impact on Security Policies: Selecting Key-Lifetimes (ctd.)  Consider to compare three similar cryptographic device €‚ ƒ and „ implementing the cryptographic scheme … † ‡ = reference implementation ˆ ‰ = modeled considering the workload with max. un-observability, Š = workload with min. un-observability ‹ They have more operational states. The service is given only while at a particular state denominated service. Œ Each of them takes 㠍 hours before entering the service state Ž The time of occurrence of the failures in the system is considered to be a random variable with the corresponding distribution being exponential with two-variables with rates respectively equal to λ1, λ2, λ3 and γ = 㠏
  • 32. The Impact on Security Policies: Selecting Key-Lifetimes (ctd.)  The reliability of the system at time t is expressed as: ‘ The system is considered to be functioning as long as the key material has not been exposed (i.e., as long as the number of failure is less than or equal to the CSFT value of the cryptographic scheme implemented) ’ While providing service, the error probability must be kept less than or equal to ε R sys “ e ” • t – —
  • 33. The Impact on Security Policies: Selecting Key-Lifetimes (ctd.) ˜ Hence the lifetime of the key-material should NOT exceed the exponential reliable life (i.e., mission time) defined as: where is the desired reliability goal. KeyLifetime ™ t R š ›œ ln 1 ž Ÿ F   1 ¡ 1 ¢ £ F ¤ 1
  • 34. The Impact on Security Policies: Selecting Key-Lifetimes (ctd.) ∆% ¥¦¨§ ©«ª ¬ ­§® ¦¨¯ ° ±³² ¬µ´ ­·¶® ¶ ¸¹ ¶ ª º »¼ º²¹½ ¾¿ » »À À ²¹ À ¾¿ » »À ¹ ² Á  ¾¿ » »À º º ò Ä ÃÀ ²½ Å Æ ¬Ç ¸ à »¹ º¼ ¹ ²À Á ¾¿ » » Ä Ã² Á  ¾¿ » » Ä Ã² Ä Ä ¾¿ » » Ä ¹ º ½ ¹ ò Á º ÃÀ ² Á¹ ¬´ ­·ÈÉ ¯¯ Ê·Ë ° ±³² Ì¯É © É ¸¹ ¶ ª º »¼ À ² Å Á ¾¿ » » Ä ¹ ²  º ¾¿ » » Ä ¹ ² ÄÀ ¾¿ » » Ä º »¹ ŠŲ¹ Ä ÃÀ ² ÁÀ Í ÎÏÐ Ñ ÍÒ ÓÕÔ Ö Ö×Ð Ö Ö Ó ÓÕÔ Ö Ö×Ð Ö Ö Ó ÓÕÔ Ö Ö×Ð Ö Ö Ó Ö Ö Ï × Î ÓØÙ ÏÚÚÛ Ü Ý Ó ÞÔ ßØ ×Ð Ö Öà à ÔØ ß×Ð Ö Öà áÔ ßâ ×Ð Ö Öà Þ Ù à áÔ ÖØ Ó áÔâ Ø Ï × Î ÓØÙ ÏÚÚÛ Ü ÝØ ÓÕÔàÙ ×Ð Ö Ö Þ ÓÕÔ ÓØ ×Ð Ö Ö Þ ãÔ ß ã×Ð Ö Öà Ó Þà Ó ãÔ ÞØ Ó áÔâ Ø äåæ ç è·éê ëì íî ïð ∆ ñóòôöõ ÷ø ù With ε = 2e-40, γ = 10 hours, λ1 = 1.52e-05, λ2 = 2.0064e-05, λ3 = 2.32560e-05 MTTF1 = 65800 MTTF2 = 49851 MTTF3 = 43010
  • 35. The Impact on Security Policies: Selecting Key-Lifetimes (ctd.)
  • 36. The Impact on Security Policies: Selecting Key-Lifetimes (ctd.) ú The importance of dependability metrics should not be overlooked. By exploiting them (e.g., increasing the f.r. / decreasing the MTTF) it's possible to facilitate fault attacks. û Reliability modeling gives us a boundary for the key-lifetimes of cryptographic schemes implemented in real devices: the system reliable life ü RSA+CRT cannot be securely used in today systems with mid-level failure rates, while requiring an unreliability less than or equal to a negligible probability error
  • 37. Overview of the Talk ý Introduction þ Definitions and Background ÿ Deliberately Un-Dependable Applications   Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics ¡ The Impact on Security Policies ¢ The Impact on Standards £ Conclusions
  • 38. The Impact on Standards ¤ Claim 1: The presented class of attacks pass unnoticed to the assessment techniques used in today security standards ¥ Claim 2: It's necessary to support today standards with additional and definite dependability requirements
  • 39. The Impact on Standards: FIPS 140-2 ¦ Environmental failure protection (EFP): protection against unusual environmental conditions or fluctuations (accidental or induced) outside the module's normal operating range that can compromise the security of the module – with temperature and voltage mention explicitly § Environmental failure testing (EFT): combination of analysis, simulation and testing of cryptographic module to provide reasonable assurance that no compromise of the security is possible due to environmental conditions fluctuations ¨ FIPS 140-2 do not address augmented failure rates at standard environmental conditions Security Level 4 Requirements
  • 40. The Impact on Standards: FIPS 140-2 (ctd.) The Problem of the Correctness Notion: or How Badly a “Correct” Implementation Can Behave? © Informal and formal proofs of correspondence between different abstraction levels: A formal model for the rules and characteristics of the cryptographic module security policy, using a formal specification language An informal proof of the correspondence between the formal model and the functional specifications For each component, function and procedure a description of its behavior using {pre,post}conditions Informal proof of the correspondence between the design and the functional specification
  • 41. The Impact on Standards: FIPS 140-2 (ctd.) However, using DUDAs it is possible to add malicious behaviors without the need for additional logics A formal proof of correspondence between the design and the functional specification of a device is not sufficient to rule out the presence of additional and unexpected malicious behaviors. Hence, relying parties are unable to build a trust relationship with cryptographic module fully compliant with today standard requirements. The Problem of the Correctness Notion: or How Badly a “Correct” Implementation Can Behave?
  • 42. Overview of the Talk Introduction Definitions and Background Deliberately Un-Dependable Applications Facilitating the Practicality of Fault Attacks by Exploiting Workload Characteristics ! The Impact on Security Policies The Impact on Standards # Conclusions
  • 43. Conclusions$ Inducing fault locally is not the only way to increase the occurrences of erroneous computations in security devices % Augmenting the probability of observing natural occurring and dormant faults is an alternative
  • 44. Conclusions (ctd.) A new class of malware has been introduced ' Its nature is subtle and unique ( The attack paradigm takes advantage of faults with a twofold phenomenological cause ) And enables manufacturers to add malicious behaviors without additional logics 0 It gives us an attack model against security modules 1 A first instance of DUDA has been presented. It is show how dependability metrics can be undermined by exploiting workload characteristics
  • 45. Conclusions (ctd.)2 Its possible to use any cryptographic scheme without being afraid of fault attacks already known in literature, if the reliability of the cryptographic module is carefully modeled. 3 The exponential reliable life give us a boundary for key-lifetimes 4 RSA+CRT cannot be securely used in today systems with mid-level failure rates, while requiring an unreliability less than or equal to a standard negligible probability error for cryptographic context (2e-40)
  • 46. Conclusions (ctd.)5 DUDA attacks passes unnoticed to the assessment techniques used to evaluate today cryptographic modules at the highest “security” levels 6 More importantly: There is the need to support today standards with more definite dependability requirements.
  • 47. Conclusions: Further Works 7 Complete a first taxonomy of DUDA based attacks on security systems 8 Provide a generalized framework to model the reliability of complex cryptographic infrastructures. 9 It will guide us in recommending key-lifetimes in presence of faults. @ Complete the analysis on the impact on standards