IT Security - Software and Systems Engineering

Transcription

Workshop Hot-Spots der Software-Entwicklung
IT Security
19. Februar 2013
Technische Universität München
Institut für Informatik
Software & Systems Engineering
Prof. Dr. Dr. h.c. Manfred Broy
Florian Deißenböck
Daniel Méndez Fernández
BICC-NET
Bavarian Information and
Communication Technology Cluster
Inhaltsverzeichnis
1 Einleitung
3
2 Teilnehmerliste
4
3 Programm
5
4 Das Sicherheitsnetzwerk München
Peter Möhring
6
5 Sicherer Browser – Schutz des Einfallstors
Reto Weber
21
6 Einsatz von Zertifikatssystemen im Internet
Jamshid Shokrollahi
42
7 Chipkartenbetriebssysteme – Gefahrenpotentiale und Gegenmaßnahmen
Helmut Scherzer
51
8 Cybersecurity-as-a-Service: strategische und technische Herausforderungen
Philipp Müller, PeterRehäusser
66
2
1 Einleitung
Durch die fortschreitende Digitalisierung und Vernetzung von Software-intensiven Systemen und
Diensten sowie die daraus resultierende Bedrohung durch Angriffe nimmt das Thema IT Security eine immer zentralere Rolle ein. Ein besonderes Augenmerk gilt dabei der Sicherstellung der
Verfügbarkeit, Integrität und Vertraulichkeit von Software-Systemen und deren Infrastruktur. Diese
Aspekte müssen in allen Phasen des Software-Entwicklungsprozesses unter Einsatz geeigneter
Methoden und Verfahren berücksichtigt werden. Betroffen hiervon sind nicht nur klassische betriebliche Informationssysteme, wie sie beispielsweise im Finanzdienstleistungssektor vorzufinden
sind, sondern auch eingebettete Systeme, z.B. in den Bereichen Automobil und Avionik.
Ziel dieses Workshops ist es, zum besseren grundsätzlichen Verständnis des Themas IT Security beizutragen und konkrete Erfahrungen aus der Praxis bzgl. des erfolgreichen Einsatzes
unterschiedlicher Verfahren auszutauschen, aber auch über Erfahrungen mit dem Einsatz von
Verfahren, die sich als weniger geeignet erwiesen.
Themen sind unter anderem:
Strategische und technische Herausforderungen der IT Security
Überblick über Konzepte und Methoden zur Lösung derselben
Einsatz von Zertifikatssystemen
Cybersecurity & Zugangskontrolle
3
2 Teilnehmerliste
Josef Wernke, Eurocopter Deutschland GmbH
Helmut Scherzer, Giesecke & Devrient GmbH
Stefan Finkenzeller, BLB
Dr. Jamshid Shokrollahi, Bosch GmbH
Thomas Mey, Münchner Rück
Peter Möhring, BICCNET-Clusterbüro I&K
Dr. Florian Deißenböck, Technische Universität München
Dr. Philipp Müller, CSC
Reto Weber, Consecom AG
Thomas Schön, Software Tomography
Dr. Claudia Salazar Dorn, NTT Data Deutschland
GmbH
Martin Luy, ESG GmbH
Roman Kochanek, Audi
Helga Stephan-Dreinhoff, IBM
Stefan Kassal, MaibornWolff et al GmbH
Stefan Prechtl, ESG GmbH
Jakob Tewes, MaibornWolff et al GmbH
Alexander Bluhm, Gesellschaft fŸr Netzwerk- und
Unix-Administration mbH
Kurt Meindl, Lorenz Software GmbH
Norman Thomson, ATOSS
Olaf Kaudelka, EADS
Gabriele Käsberger-Hoschek, EADS
Dr. Heinrich Hördegen Ingenieurbüro Guttenberg &
Hördegen
Dr. Martin Wechs, BMW Group
Jan Philipps, Validas AG
Manuel Then, Technische Universität München
Bertram Janositz, CIBOteam eSolutions AG
Ovidiu Stan, ATOSS
Dr. Philipp Guttenberg, Ingenieurbüro Guttenberg &
Hördegen
Bernhard Weber, msg systems ag
Carsten Genth, ASM Assembly Systems
Michael Spreng, Arcor AG & Co. KG
Prof. Dr. Reiner Hüttl, Fachhochschule Rosenheim
Michael Schulz, EADS
Walter Trapa, BMW Group
Michael Greulich, Interface AG
Rainer Bitzer, Bosch GmbH
Dr. Oscar Slotosch, Validas AG
Ümit Kusdogan, ABSC GmbH
Klaus Lochmann, Technische Universität München
Carsten Tauss, ABSC GmbH
Nils Oppermann, Audi Electronics Venture GmbH
Peter Rehäusser, CSC
Dr. Daniel Méndez, Technische Universität München
Christine Rittinger, Münchner Rück
Christopher Schulz, SYRACOM Consulting AG
Tomas Benes, OSD Open Systems Design GmbH
4
3 Programm
13:30
Begrüßung
Manfred Broy, Technische Universität München
13:45
Das Sicherheitsnetzwerk München
Peter Möhrung, Sichernetzwerk München
14:30
Sicherer Browser – Schutz des Einfallstors
Reto Weber, Consecom AG
15:15
Kaffee-Pause
15:30
Einsatz von Zertifikatssystemen im Internet
Jamshid Shokrollahi, Robert Bosch GmbH
16:15
Chipkartenbetriebssysteme – Gefahrenpotentiale und Gegenmaßnahmen
Helmut Scherzer, Giesecke & Devrient
17:00
Kaffee-Pause
17:15
Cybersecurity-as-a-Service: strategische und technische Herausforderungen
Philipp Müller, PeterRehäusser, CSC
18:00
Abschlussdiskussion
18:30
Empfang
5
4 Das Sicherheitsnetzwerk München
Peter Möhring
Sicherheitsnetzwerk München
Peter Möhring
19. Februar 2013, TU München, Garching
6
Vorgeschichte
•
•
•
•
•
•
•
•
BMBF Spitzenclusterwettbewerb 2011
AISEC & G&D initiieren Netzwerk
Skizze und Strategie
Nominierung scheitert Januar 2012
Positive Netzwerkeffekte, Relevanz der Thematik
Fortsetzung des Clusters
Unterstützung durch Bay. Wirtschaftsministerium
Einrichtung einer Geschäftsstelle am 1. Oktober 2012
Sicherheitsnetzwerk München, 19. Februar 2013
Forschung
7
Forschung
Industrie
Forschung
Industrie
Anwender
8
Bündelung von Innovationskompetenzen
Warum dieses Netzwerk?
• IKT als Innovationstreiber
• IT-Sicherheit ist ein Wirtschaftsfaktor und schafft neue Märkte
• IT-Sicherheit unterstützt relevante Exportindustrien
• Vertrauenswürdigkeit, Manipulationsschutz, Wahrung der
Privatsphäre, Verläßlichkeit in den Anwendungen notwendig
• München hat höchstes Wirtschafts- und Forschungsniveau in
Deutschland und Europa im Bereich IT-Sicherheit
• Sicherheitstechnologien „Made in Germany“ als langfristiger
Wettbewerbsvorteil deutscher Anbieter
9
Warum dieses Netzwerk?
• IKT als Innovationstreiber
• IT-Sicherheit ist ein Wirtschaftsfaktor und schafft neue Märkte
• IT-Sicherheit unterstützt relevante Exportindustrien
• Vertrauenswürdigkeit, Manipulationsschutz, Wahrung der
Privatsphäre, Verläßlichkeit in den Anwendungen notwendig
• München hat höchstes Wirtschafts- und Forschungsniveau in
Deutschland und Europa im Bereich IT-Sicherheit
• Sicherheitstechnologien „Made in Germany“ als langfristiger
Wettbewerbsvorteil deutscher Anbieter
10
Industriegetrieben mit wirtschaftlichem Fokus
• Integrierte Erforschung, Entwicklung und schnelle
Vermarktung innovativer Sicherheitstechnologien und
Produkte „Made in Germany“
• Ausbau von Weltmarktstellung der beteiligten
Unternehmen
• Deutschland mit München zum weltweit führenden
Standort
im Bereich IT-Sicherheit entwickeln
11
Umfeld des Clusters
• Politik
• IT Gipfel
• Underground economy
• Digitale Gesellschaft
• Mobilgeräte und Vernetzung
• Neue Geschäftsmodelle
• Sicherheitskonferenz
12
Geschäftsstelle: Schwerpunktziele
• Aufstellung und Koordinierung von F&E
Kooperationsprojekten
• Standort- und Branchenstärkung
• Netzwerkarbeit
• Übergreifende Themen: Forschung, Fachkräfte, Trends,…
Maßnahmen 2013
• Clusterkonferenz: Ermittlung neuer Kooperationspotenziale
• Kompetenzübersicht aller Mitglieder
• Anbahnung von Fördervorhaben, Konsortienbildung
• Platzieren von Themen in Förderprogrammen
• Bildung von Arbeitskreisen
• Schaffung einer Kommunikationsplattform
• Neue Partnerschaften (auch international)
• Schaffung informeller Austauschmöglichkeiten
• Beeinflussung politischer Gestaltungsaufgaben
• Gewinnung neuer Mitglieder
13
Projektvorhaben
Verbundprojekte
1.
2.
3.
4.
5.
6.
7.
SIBASE
ICEMAN
SIKOMFAN
Ambient security (neu)
Trust ME
Secure Appstore (neu)
Lagebild (neu)
14
Schwerpunkt Mobile Endgeräte
Mobile werthaltige Dienste
15
Eisattacke (cold boot)
TEE
16
Sichere eingebettete Systeme
Schutz kritischer Infrastrukturen
17
Sicheres Cloud Computing
Anwendungsorientierte Technologien
18
Verbundprojekte: Zukünftige Fördermöglichkeiten
LANDESEBENE
• Hoher Freiheitsgrad, Direktbeantragung auch ohne calls
• Kleine, effiziente Konsortien, geringeres Projektvolumen
• Industrieorientiert (wenn von Bay. WiMi gefördert)
BUNDESEBENE
• Geringerer Freiheitsgrad durch vorgebene calls
• Größere Konsortien mit höherem Projektvolumen möglich
• Eher forschungsorientiert (speziell BMBF)
EU-EBENE
• Horizon 2020
• Internationale Konsortien, hohes Projektvolumen möglich
Verbundprojekte: Organisation, Rolle der Geschäftsstelle
ORGANISATION
• Konsortien mit eigener Projektkoordination
• Konsortien sind für Beantragung und Durchführung der
Verbundprojekte selbst verantwortlich
ROLLE DER GESCHÄFTSSTELLE
• Unterstützung in Anbahnung, Beantragung und Durchführung
• Schaffung von Projekttransparenz für alle Mitglieder
• Plattform und Drehscheibe für Mitgliederkoordination, sowohl
inhaltlich als auch organisatorisch
19
Fragen
20
5 Sicherer Browser – Schutz des Einfallstors
Reto Weber
Bleicherweg 64a, CH-8002 Zürich, +41-44-515-0000
21
Experienced IT Risk/Security Professional
Consecom AG
Senior Security Consultant
Reto Weber
[email protected]
+41 44 515 00 03
Employment History
IT Risk Officer, Credit Suisse AG
CERT Analyst, Credit Suisse AG
IT Security Engineer, UBS AG
Education
CAS in Risk Management, University of Zürich
eMBA in International Management, Kalaidos Zürich
Master in Information Technology, Bond University Australia
19.02.2013
Consecom AG -- We Secure Your Solutions
Slide 2
Consecom – your partner for securing technology
Clients
Main clients: SME, and major Swiss/international enterprises and organization of
all sectors.
Location of work: primarily in Switzerland and neighboring countries.
Design
Services
History
19.02.2013
Build
Review
concepts, strategies, policies, organization, processes, secure
solutions
programming, integration, special engineering
audits, security reviews, risk assessments, penetration tests,
technology assessments, organizational and process reviews
Founded in 2007 as a management buy out.
Privately owned, substantial growth to seven employees today.
Slide 3
22
Agenda
 Problem
 Method
 Analysis
 Solution
 Experience
Objectives
 Present lesson learned from a joining development with a
University
 Exchange of experience of product development lifecycle
 Show result: a secure browser solution
19.02.2013
Slide 4
Global news about virus infections
Unbekannte haben einem Bericht von
Amorize zufolge zahlreiche Onlineshops mit
einer veralteten Version von osCommerce
zur Verbreitung von Schadcode missbraucht.
Die Angreifer nutzten mindestens drei
bekannte Schwachstellen in der Version 2.2.
heise.de 08/2011
Earlier this month, security researchers
discovered a new piece of malware had
infected more than half a million Apple
computers in what was the largest-scale
attack on Apple’s Mac OS X operating
system to date. Nytimes, 04/2012
A serious flaw in the Java software found on
most personal computers could expose the
machines to being taken
over by malicious attacks over the internet,
the US agency responsible for policing such
vulnerabilities warned on
Thursday. ft, 01/2013
A new piece of Mac malware has been
discovered on a Web site linked to the Dalai
Lama, using a well-documented Java exploit to
install a Trojan on visitors' computers and steal
personal information. cnet.com 12/2012
Hackers are increasingly targeting childfocused gaming websites, according to a
leading anti-virus firm. Avast says it detected
malware threats at more than 60 sites that
contained "game" or "arcade" in their title, in
the 30 days running up to 12 January.
01/2012 bbc.co.uk
It’s a scenario security researchers have
long worried about, a man-in-the-middle
attack that allows someone to
impersonate Microsoft Update to deliver
malware disguised as legitimate Microsoft
code to unsuspecting users. wired.com
06/2012
19.02.2013
Slide 5
23
Malware is today one of the major threats and frequently used to attack
Threat Agent:
 No clear pictures of attacking agents.
 Educated guesses possible e.g. profit driven, organized crime.
Threat Facts:
 Malware shows an exponential growth since years.
 Various method of infection vectors: mail, USB, social engineering, remote exploit,
web-browsing.
Impact:
 Massive infection rate on end-user desktop environments.
 Key question, are you at risk or not (large unreported cases)?
Results:
 Breaches in Confidentiality, Integrity and Availability
 Multiple second order effects
19.02.2013
Slide 6
Most infections come through the browser channel
Infected systems: Web
technologies are
mostly used to place
malware.
Source Microsft.com
19.02.2013
Slide 7
24
Drive – By – Infection is a common issue
1 Open page
2 Send Exploit
3. Compromise
19.02.2013
Slide 8
25





Problem
Methods
Analysis
Solution
Experience
19.02.2013
Slide 10
Multiple areas with limited influence
Measure
Feasibility / Applicability
Reduce complexity in web-pages
No governance; not applicability
Improve security with web-pages
No governance; limited reach
Extend to cloud-AV solutions
Partial success; confidentiality breach
Change user-behavior
Only partially applicable
Reduce EuP flexibility and usability
Change in working model; limited reach
Myth: Keyboard encryption
There is no keyboard encryption!
EuP: End-user Platform
19.02.2013
Slide 11
26
Where can we start
Conclusion: Start with the web-browser
 Browsers, an integral part of the operating system.
 Provide a platform based on international standards/languages (HTML, http, CSS,
JavaScript, …).
 Having a super secure browser would reduce the risk of infection dramatically.
19.02.2013
Slide 12
27





Problem
Methods
Analysis
Solution
Experience
19.02.2013
Slide 14
The security product has multiple dimentions
Dimensions
Criteria
Trust
 Administrator and manufacturer trust (prerequisite)
 Life-cycle trust (deployment and update)
Threat
Coverage
 On-line (in-bound): Vulnerabilities in applications
 Off-line threats: Malicious host
 At run-time
 At rest
Protection
 Methods to protect from infected hosts
Isolation
 Methods to isolate applications from infected hosts
Integration
 Capabilities to integrate into standard work process
Deployment
 Method and scalability
Maintenance
 Patch and update capabilities, and scalability
Usability
 Technological user support
Weaknesses
 Limitations and weaknesses
19.02.2013
Slide 15
28
Overview Secure Browser
Browser on USB Stick, Hardened Web-browsers
Browser Sandbox, Hardened Web-browsers
Browser on Native Boot-Platform
Browser in VM
VM
19.02.2013
Slide 16
A USB stick or «wrapper» approaches
 Design Paradigm
 Run on shared commodity platform
Hardened
Web-Browser
Interrupt Vectors

Memory Map
 Exemplary implementation variants
Application
Commodity Operating System
 Share of central operating system tables

Application
Hardened
Web-Browser
 USB-stick based web-browser
Application
Application
Windows
 Hardened web-browser by platform extension, e.g. Trusteer Rapport®
19.02.2013
Slide 17
29
Main weakness is a shared platform
Dimensions
Criteria
Details
Trust
 Life-cycle trust
 High trust for stick rollout, common otherwise
Threat
Coverage
 On-line (in-bound)
 Off-line threats: Malicious
host
 At run-time
 At rest
 Gradual improvement against known threads
 (Low) gradual improvement
 Only if stored on read-only medium
Protection
 Capabilities
 Application internal only
Isolation
 Method
 None
Integration
 Capabilities
 Stick: limited; Platform: full
Deployment
 Stick: shipment; Platform: software
Maintenance
 Stick: replacement, both: incremental updates
Usability
 Support by technology
 Stick: non-IE; browser independent
Weaknesses
 Limitations
 Shared platform
 Web-browser only protection
19.02.2013
Slide 18
A USB stick or CD boot systems
 Design Paradigm

Requires respective interface
Isolation
Controlled
Application 1
Controlled
Application 2
Isolation
LPS
 Boot-off clean OS from dedicated media
Controlled
Application 3
Hardened OS User Space
SELinux Mandatory Access Control

Provides conceptual improvement only with
trusted read-only media
Minimal Linux Kernel
stateful
firewall
 Exemplary implementation variants
 c’t bankix: Linux Knoppix (Debian)-based boot-CD
 Lightweight Portable Solution (LPS) by US DoD: Hardened Linux for remote access
19.02.2013
Slide 19
30
Usability and mobile technology makes it harder to use
Dimensions
Criteria
Details
Trust
 No protection of image at download
Threat
Coverage
 Off-line threats: Malicious
host
 At run-time
 At rest
 Platform hardening
Protection
 Capabilities
 Hardened Linux platform
 Firewall
Isolation
 Method
 Native boot
Integration
 Capabilities
 None (remote access only)
Deployment
 CD image download
Maintenance
 None, full image deployment
Usability
 Base-installation too complicated
Weaknesses
 Limitations
 No integration, no incremental maintenance
 no image-protection
19.02.2013
 No exposure.
 If stored on read-only medium
Slide 20
A VM system to browse resolves a lot problems.
 Design Paradigm
 Run web-browser in a VM
Application 1
(Browser)
 Isolate web-browser from host
Application 2
(PDF-Reader)
Application 3
(Flashplayer)
Debian Linux
Virtual Machine

constrained
disk access
Virtualization layer
Isolation
Windows

Separate OS
 Exemplary implementation
 BitBox – Browser in the Box – by German BSI/Sirrix AG
19.02.2013
Slide 21
31
Generally OS independent
Dimensions
Criteria
Details
Trust

Life-cycle trust

Update-only
Threat
Coverage


On-line (in-bound)
Off-line threats: Malicious
host
 At run-time
 At rest

Technical improvement (Standard Linux)


Gradual improvement
Only if stored on read-only medium
Protection

Capabilities

Isolation by VM, controlled read-write
Isolation

Method

Platform virtualization by VMs
Integration

Capabilities


Integrated for default-browser launch
Constrained data exchange
Deployment

Method and scalability

Full image deployment
Maintenance

Method and scalability

Standard Debian update mechanisms
Usability

Support by technology

Base-installation too complicated
Weaknesses

Limitations


Protection by standard Linux combined with
Oracle VirtualBox abstraction
19.02.2013
Slide 22
32





Problem
Methods
Analysis
Solution
Experience
19.02.2013
Slide 24
Security Enhanced – Linux the answer to the web-infection problem
Objective
Protect a system against unauthorized access/execution
Function
A technical policy enforcement framework. Any operation executed is validated
by a security filter prior to execution.
A kernel module is compiled into the machine with predefined rules. The
Implementation kernel’s security filter preforms the checks. No one can overwrite the rules at
run-time (since denied by the security filter) and compiled into the system.
History
SELinux was originally a development project by the National Security Agency
(NSA). It is an implementation of the Flask operating system security
architecture. The Flask architecture defines MAC with focus on providing an
administratively-defined security policy that can control all subjects and objects,
basing decisions on all security-relevant information. Flask was then renamed
to SELinux.
Ref
www.nsa.gov/research/selinux/
19.02.2013
Slide 25
33
A combination of methods into a browsing platform
SEBPS
Controlled
Application 2
(Acroread)
Isolation
SEBPS
Controlled
Application 1
(Firefox)
Isolation
Trusted
Update
Server
SEBPS
Controlled
Application 3
(Flashplayer)
Scalable Trusted Maintenance
Hardened OS User Space
SELinux Mandatory Access Control
Minimal Linux Kernel
stateful
firewall
Virtual Machine
constrained
disk access
Isolation
Commodity Operating System
19.02.2013
Slide 26
Multiple benefits and usability for end users are important
 Deployment
 Web-Installer abstracts installation
complexity
 Prepare the platform: pre-required tools
 Reduce the installation to the minimally
needed steps: “Two Clicks to
secureBrowse”
 Use
 Support the user

Launch the Web-browser
 Support system hibernate and standby
 Logout shuts down secureBrowse
 Administration
 Relieve the user from interfering with
administrative tasks
19.02.2013
Slide 27
34
secureBrowse -- the answer to the web-infection problem
Dimensions
Criteria
Details
Trust
•
Threat
Coverage
 Off-line threats: Malicious host
 At run-time
 At rest
• Platform hardening (MAC)
Protection
 Capabilities
•
Hardened Linux platform (MAC)
Isolation
 Method
•
Virtualized platform
Integration
 Capabilities
•
Cut-and-Paste between host and
platform
Deployment
•
Trusted web-based Installer
Maintenance
•
Trusted incremental updates
Usability
•
Straightforward web-supported installer
Standard applications
Weaknesses
 Limitations
•
Limited integration
19.02.2013
Full trust: Deployment, Maintenance
• Separate OS-addr- space, separate IVT
• If stored on read-only medium
Slide 28
35
36
37
Problem is reality, solution is around.
Companies are daily in the
news because of incidents
with malware. Moreover,
old browsers are still used.
Where and when infections
happen really, remains
undiscovered.
The main entry gate, the
Web-Browser, can be
secured.
Non of the frequently used
standard products proves
complete protection.
A VM with Mandatory
Access Control Browser is
very secure approach.
A solution is around and
free to use.
http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
19.02.2013
Slide 35
38





Problem
Methods
Analysis
Solution
Experience
19.02.2013
Slide 36
Solving a problem doesn't make you millionaire but the knowledge brings you forward
 Product never reached the mass market (by now)
 Generally users and companies still accept the risk by drive-by infections.
 Windows / iOS look and feel is absolutely essential.
 Usability change require a large investment and are not accepted.
 Nish market
 Forensic Investigators, Fraud Analyzers (Analyze Dangerous Websites).
 Selective usage for untrusted web-pages (i.e. all).
 Highly secured areas (Nuclear Power Plants, Military).
 New business by knowledge gain
 Expert in secure platforms.
 Providers of secure platform for Web Entry Systems.
 Provider of secure appliances for major financial institutes.
19.02.2013
Slide 37
39
40
41
6 Einsatz von Zertifikatssystemen im Internet
Jamshid Shokrollahi
Certificates: How to Build Trust in the
Internet
J
Jamshid
hid Sh
Shokrollahi,
k ll hi
Corporate Research (CR/AEA)
Robert Bosch GmbH
1
Jamshid Shokrollahi, CR/AEA3 | 2/19/2013 | © Robert Bosch GmbH 2013. All rights reserved, also regarding any disposal, exploitation,
reproduction, editing, distribution, as well as in the event of applications for industrial property rights.
42
Certificates: How to Build Trust in the Internet
Overview
2

Solved problem (Public Key Infrastructure and Certificates)
 Symmetric Key Cryptography
 Public
P bli kkey C
Cryptography
t
h
 Man in the Middle attack
 X.509 Certificate

Not Completely solved problem (Secure Deployment)
 Different levels of realization
 Potential Vulnerabilities
Department | 2/19/2013 | © Robert Bosch GmbH 2013. All rights reserved, also regarding any disposal, exploitation, reproduction, editing,
distribution, as well as in the event of applications for industrial property rights.
Mission
Alice and Bob want to securely communicate in
the presence of Eve and Mally!
Eve: eavesdropping
Mally: read, write, and modify the messages
3
43
Bob shops in the Internet!
What can go
wrong?
4
Eavesdropping
Eve sees Bob’s credit card number
and uses it next time for shopping!
What is the solution?
5
44
Symmetric Encryption is a solution
Enc. /
Enc.
Dec..
Dec
103
40...
Enc..
1034 Enc
Dec..
0... /Dec
Communication partners
have the secret common
key
6
Public Key Cryptography (PKC)
Bob and the Server can establish the secret Key using asymmetric
Encryption
Bob can encrypt its symmetric key using
Server’s public key, but only the server has the
private key to decrypt itit. In practical
realizations there are more details which are
ignored here
7
45
Verifying Public Keys
How can Bob be sure that Mally is not
performing “man in the middle” attack?
Mally’s public
key
8
Server’s
public key
Public Key Infrastructure
CA(Certification
(
Authority)
CA’s public key is
embedded into most of
browsers
Secure Connection
• Signed by CA
Server’s
private ke
ey
• Server’s identity
• Server’s
S
’ public
bli kkey:
Certificate, e.g., X.509
User‘s browser
9
46
Example: X.509 Certificate Structure
(1)
• Version
• ...
• Serial Number
• Certificate Signature Algorithm
• Algorithm
Al ith ID
•C
Certificate
tifi t Signature
Si
t
• Issuer (E.g. Certificate Authority)
• Validity
• Not Before
• Not After
• Subject (E.g., server)
• Subject Public Key Info
• Public Key Algorithm
• Subject Public Key
• Issuer Unique Identifier (optional)
• Subject Unique Identifier (optional)
• Extensions (optional)
1) Source: Wikipedia
10
Server Authentication and Key Exchange (simplified)
8)
Ensures
the
security
by
seeing
https
11
Browser
2) Provides
the certificate
4) Generates a random 128 bit key,
encrypts
t using
i the
th public
bli kkey iin th
the
certificate and send to the server
7) XORes the two
sequences to
generate the
symmetric key
5) Generates a random 128 bit key
and sends to the browser (client) in
plain
6) De
ecrypts the
e received packet,
XOR
Res the two
o sequences to
gene
erate the syymmetric key
1) https: request a
secure connection
3) Verifies the
signature of the
certificate, and if the
subject matches the
server
47
Realization Aspects
Issuer’s Infrastructure
API Level
Digital Signatures
12
Digital Signature
Hash
Function
• Nonlinear mapping
pp g
to compress large
messages
• Must be collision
resistant
Padding
md mod N
Adding
g
specific
patterns to
the
compressed
message
The
fundamental
and most
time
consuming
operation
Nonlinearity cancels the multiplicative
property of the exponentiation
13
48
Digital Signatures, lessons learned
•
•
•
•
14
Do not use hash functions like MD4 with known collisions
Always use large modulo numbers N which are generated according to
th standards
the
t d d
The parameters and functions get obsolete. Never issue the certificate for
very long time
Always choose the functions and parameters according to the most recent
standards, e.g., BSI – Technische Richtlinie, BSI TR-02102, Version
2013.02
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Te
chnischeRichtlinien/TR02102/BSI-TR02102_pdf.pdf?__blob=publicationFile
Vulnerabilities in using API
•
Always verify if the certificate matches the identity of the provider
(server)? Even consider the possibility of having '\0' in the identity of the
provider
id off certificate
tifi t who
h wants
t to
t impersonate
i
t a famous
f
identity
id tit
•
SSL and several other software also provide the PKI verification as
f
functions.
Always read the documentation carefully
f
to enable the
verification of the signatures
Several examples of to dos and not to dos can be found in „Georgiev et
al., The Most Dangerous Code in the World: Validating SSL Certificates in
Non-Browser Software, In proceedings of ACM CCS '12, pp. 38-49, 2012“

15
49
Issuer's
Issuer
s Infrastructure
•
•
•
•
16
Certificates are your identity and their security depends on the private
key of the issuer
If th
the private
i t kkey iis nott stored,
t d or used,
d iin th
the right
i ht way, attackers
tt k
can
impersonate you
Revocating certificates and the lost reputation can cause high costs!
Always think about the reputation off the issuer and iff possible ensure
that they have enough security in the processes
Conclusion
•
•
•
17
For the selection and the realization of digital signatures always use the
most recent standards and follow them carefully
Wh verifying
When
if i signatures,
i
t
always
l
b
be careful
f l about
b t th
the id
identities,
titi
and
d
also variables and flags if you use verification functions from others'
libraries
When buying the certificates
f
think about the reputation and history off the
provider!
50
7 Chipkartenbetriebssysteme – Gefahrenpotentiale und Gegenmaßnahmen
Helmut Scherzer
SmartCard Operating Systems
Potential Risks and Security Measures
Helmut Scherzer
Giesecke & Devrient
[email protected]
51
Standards and Specifications
P Standards
< ISO 7816/1..9
< CEN TC224/EN726
< GSM 11.xx
< ETSI
< JAVA 2.x
P Specifications
< JAVA
< EMV
< Mondex
< Multos
< SECCOS(ZKA)
< ...and others
P Platform
< ST Microelectornics
< Infenion
< Philips
< Samsung
< Sharp
< Renesas
< Atmel
< ... and others
P “Hidden Agenda”
< Security Features
< Attacks
< Countermeasures
< Programming Tricks
< Performance Optimization
< Memory Optimization
< Algorithms
PIN Attack
Attack
P Cut Off Power before updating the PIN error
counter
Correct PIN- Entry
Wrong PIN-Entry
PIN - Check
Update of PIN error counter
Attack: Detection and interruption
52
PIN Attack
Countermeasures
P Update PIN error counter prior to PIN
verification
Cnt = 2
PIN - Check
Cnt = 3
Power Break
Attack or Accident ...
P Power Drop in the SmartCard
< Unintentionally (Accident)
–
–
–
–
Withdraw SmartCard
Functional misbehaviour in Terminal
Bad Contacts
Environmental Factors (Vibration in Car etc...)
< Intentionally (Attack)
– Data manipulation
53
Power Break
Intention of the attack
EEPROM Write Cycle
EEPROM
1.) Delete EEPROM cell
EEPROM
.................
.................
0010 0110
.................
.................
.................
2.) Write new value
.................
.................
0000 0000
.................
.................
.................
EEPROM
.................
.................
1111 1110
.................
.................
.................
Best possible moment of power cut
Power Break
Pseudo Random Attack
EEPROM
EEPROM
Random
No.
EEPROM
00 00 00 00 00 00 00 00
New Random No.
Random No.
35 BC 01 A7 48 D5 3B 1C
Old Random No.
DES
New Random No. is
written to EEPROM
EEPROM
Random No.
AB 33 2F 8E 46 7A 29 FD
New Random No.
54
Power Break
Countermeasures
P Limited Transaction Protection
< Recognition and Indication of Power Breaks
< Protection of sensitive data
< Card Blocking
P Full Transaction Protection
< Backtrace / Write Ahead Buffer
< Atomized Transaktionens
< Data Committment
P Countermeasures : “Absolutely
MANDATORY”
Power Break
Command Message
“.. ..03 45 .. ..”
Target Data
Backtrace Buffer
01 23
01 23
01 23
01 23
Full
Transaction Protection
?? ??
01 23
00 00
03 45
01 23
01 23
01 23
03 45
03 45
01 23
55
Memory Defragmentation
Defragmentation by multiple file deletion
EEPROM
P Creation of files by
EF
< Additional Applications
< JAVA - Applets
< Version Control/Update
< Application Deletion
< Application Buy and Run
< Temporary Files
EF
EF
EF
EF
EF
EF
EF
EF
EF
EF
EF
1.) Initialization
Free Memory
EF
2.) Erase
EEPROM
EF
EF
EF
EF
EF
EF
EF
EF
Free Memory
EF
EF
3.) New layout
EEPROM
EF
EF
Memory Full !
EF
EF
EF
EF
EF
EF
EF
EF
Memory Defragmentation
Defragmentation Process
EEPROM
EEPROM
EF
EF
EF
EF
EF
EF
EF
EF
EF
Defrag ...
EF
EF
EF
EF
EF
EF
EF
EF
EF
EF
EF
P Difficulties
< References must be recorded
< Defragmentation (up to 10 Sec.) must be 100 %
Power Break resistant
P Solution
< Atomic operations with wear-leveling mechanism
– Defragmentation possible very effectively
– New Application Perspectives for SmartCards
Smart Card Development
P Auto-Defrag
< 100 % Power brk.Prot.
< High Performance !
< “on Auto-Demand” only
P 100 % Fail resistant
< Theoretically proovable
56
EEPROM Errors
Few Bits dropping
P Chip Mfg.Guaranty : 10 Years Data
retension
EEPROM
< Credible and proven value
< Very seldom, accidential drops have
been reported
1111 1111 1111 1111 1111 1111
1111 1111 1111 1111 1111 1111
1111 1111 1111 1111 1111 1111
1111 1111 1101 1111 1111 1111
1111 1111 1111 1111 1111 1111
1111 1111 1111 1111 1111 1111
1111 1111 1111 1111 1111 1111
1111 1111 1111 1111 1111 1111
1111 1111 1111 1111 1111 1111
11111
1110111
11111
P Bit Drop Situation
< Most embarassing situation as no
obvious reason available
< Murphy’s Law: “Always the most
crucial bit drops"
P Countermeasures
< CheckSum on any EEPROM boundary
< Update of Checksum must also be
power break resistant
Timing Attack
PIN/Key Verification
P Time pattern of
current samples
// Compare PIN
for (i = 0; i<length(PIN); i++)
{
if (PIN[i] != Correct_PIN[i])
return(1);
}
return(0);
Reference Point
) t Difference Measurement
57
Timing Attack
The Square-Multiply 'always' problem
P New programming
styles
rlc r2
; r2 = exponent
jnc NoSwap
xchg r0,r1
NoSwap:
ret
SmartCard
StoneAge
2013 Coding
// evaluate exponent bit
if (ExpBit == 1)
Swap(Source,Target);
else
Keep(Source,Target);
return(0);
push
push
push
mov
r0
r1
r0
bp,sp
rlc
addc
mov
inc
mov
r2
; r2 = exponent
bp,#0
r0,[bp]
bp
r1,[bp]
add
ret
sp,#3
; <- bp
;
; remove '3 x push'
Differential Fault Analysis
The “DES” Bellcore Attack
P Assumption:
< “Bits in RAM may be altered intentionally”
P Attack by comparison of output
0
Key: 0100 1010 1110 0111 1011 1111 0011 0110 ... .. ...
“Alice is pretty”
1.) “Xy202 01aM b201”
2.) “Xy202 01aM b201”
DES
“a839 x15k b7fm”
58
Reaction of the market
Decrease of Orders since June 1998 !!!
100
80
DPA-Attack !
60
40
20
0
January
March
May
July
September
November
SmartCard Orders
Single Power Analysis
Direct Evaluation of Current Samples
P Direct evaluation of Current Samples
< Insider knowledge required
< Program Code must be locally known
P Countermeasures
< No bit operation with sensitive data
< Source Code “ CONFIDENTIAL “
< Support by
Chip Hardware
59
Differential Power Analysis
Attack Scenario
P Statistical Attack
Key Shift
< Many DES Calculations
required !
< No Source Code Knowledge
required !
S-Box
Output Perm.
DES Round # n
The Final Attack
Correlate Signed Samples
P If the hypothized key was correct,
each calculation will contribute a
deterministic part to the final signal
P If the hypothized key was wrong,
only 'noise' will be added and no
singularity will be found
Signal
P For each n of 64 possible subkeys a
particular hypothesis on the signal
signs exist.
P For each n of 64 possible subkeys
the addition (correlation) of the N
samples will be performed
+
-
+
Signal
Signal
+
+
+
Noise
+
-
=
N
Noise
Noise
=
3
=
/N
60
Attack Scenario
High number of samples
required !
Key Shift
S-Box
Output Perm.
DES Round # n
Subkey Subkey Subkey Subkey Subkey Subkey Subkey Subkey
Key : 48 bits 010110 011101 110110 001011 010110 101110 001111 110001
Data 0110
S-Box
S-Box
S-Box
S-Box
S-Box
S-Box
S-Box
S-Box
1101
0010
1011
0010
0101
1001
1000
0110
S-Box being attacked
Attacked bit
Finding the Key ...
Maximum Evaluation
P In one of 64
correlation signals
we will find a
significant
maximum
P This maximum
confirms our 'guess'
for the subkey.
P We may confirm
the guess by
evaluation of the
other three bits on
the same S-Box
....
....
Subkey 17/64 : wrong hypothesis
Subkey 20 : CORRECT HYPOTHESIS !
61
Countermeasures
P System Level
< Limited Usage of Error Counters
< Logging of Error Counters in Host System
P Hardware Level
< Bus Scrambling
< Power Noise
< Redundant Clock Cycles
P Software Level
< Relative Protection
– Make the Alignment 'impossible'
– Nonsens Statements
< Absolute Protection
– Theoretical Proove of Effectiveness
– ITSEC Evaluation possible !
– IBM DPADES9 : “Excellent Protection !”
P Critical Factor: “PERFORMANCE”
Table compression
Partitioning attack
ROM
CPU
256 Bytes page
256 Bytes page
256 Bytes page
...
; 512
db
db
db
byte table
01,45,62,F3, 8F,7B,2A,3F,
....
....
P Address and value of a (EEP)ROM table may
leak DPA information
P Addressing another (EEP)ROM page may
leak SPA information
P Countermeasures (srambled RAM table)
requires too much memory (here 512 bytes)
62
Table compression
Partitioning attack
ROM
CPU
256 Bytes page
256 Bytes page
256 Bytes page
...
P Address and value of a (EEP)ROM table may
leak DPA information
P Addressing another (EEP)ROM page may
leak SPA information
P Countermeasures (srambled RAM table)
requires too much memory (here 512 bytes)
Table compression
Large Table attack countermeasures
ROM
128 Bytes page
data + index masking
RAM
128 Bytes
128 Bytes page
128 Bytes page
...
P Overlay ROM table entries in RAM
P index/value mask 'on the fly'
P Decoding can only be done with help
of the original ROM table, but this can
be achieved in a well protected way.
63
Table compression
Large Table attack countermeasures
ROM
Encode
Generate rand1..rand4 [each 0..127]
for (i = 1 to 128)
{
RAM[i] = ROM[i r rand1] r
ROM[i r rand2 + 128] r
ROM[i r rand3 + 256] r
ROM[i r rand4 + 384]
}
256 Bytes page
256 Bytes page
256 Bytes page
...
Decode (e.g. value from 0..127)
j = i r rand1
Decode (e.g. value from 128.255)
j = (i-128) r rand2
ROM[i] = RAM[j] r
ROM[j r rand2 + 128] r
ROM[j r rand4 + 384]
ROM[i] = RAM[j] r
ROM[j r rand1] r
ROM[j r rand4 + 384]
RAM
128 Bytes
End
Potential Risk
and
Security Measures
64
65
8 Cybersecurity-as-a-Service: strategische und technische Herausforderungen
Philipp Müller, PeterRehäusser
Cybersecurity-as-a-Service
Dr. Philipp Müller
Peter Rehäußer
CSC Proprietary and Confidential
66
Hackerangriffe sind allgegenwärtig.
Was nun?
March 25, 2013
2
Unsere Welt heute
Zunehmende Digitalisierung
von Geschäftsprozessen
Die neue Art von Bedrohungen:
Gezielter, strukturierter und mit uneingeschränkten Ressourcen für Angriffe
Private und geschäftliche IT verschmelzen:
Cloud, ByoD, Social Media, …
Wachsende Anzahl an Regularien
und Compliance-Vorschriften
March 25, 2013
3
67
Wie denken wir Sicherheit auf
der Vorstandsebene?
Wie denken wir Sicherheit
gesamtgesellschaftlich?
March 25, 2013
4
March 25, 2013
5
Sicherheit ganzheitlich angehen:
der Cybersecurity Stack
Ebene 4: Nationale
Sicherheitsstrategie
Bedrohungsalarm
Nation/Staat
Ebene 3: Situationsbewusstsein
EventKorrelation
Organisation
Ebene 2:
Sicherheitsschicht
Klassisches Vorgehen:
Vorbeugen-AufdeckenReagieren
Perimeter
& Gateway
Ebene 1: Sichere
Infrastruktur
LAN-WANApplikationen
und -Daten
Einzelne
Systeme
68
Den Security-Live-Cycle komplett abdecken
Awareness Trainings
IT Security Principles
Methodology Coaching
Security Policy
IT Security Concepts
IT Security Organisation
IT Risk Management
Implementation Standards
Business Continuity Planning
Cyberconfidence Check
Controlling
Coordination
Communication
Compliance with Security Policies
Identity Management
IT Security for Outsourcing
Comprehensive Audits
Managed Security Services
Penetration Test
Common Criteria Evaluations
IdM Prequalification Checks
March 25, 2013
6
March 25, 2013
7
Warum Cybersecurity-as-a-Service?
Cost
69
The CSC Cybersecurity Demonstration Center
March 25, 2013
8
March 25, 2013
9
Storyline der Live-Demo
Der Feind beauftragt
einen Hacker, …
… die Daten eines
Großprojektes zu
löschen und dem
Unternehmen
damit Schaden
zuzufügen …
… und fortwährend
zu überprüfen, ob die
Organisation am Ende
des Projektes in der Lage
war, die Informationen
wieder herzustellen.
70
Wie gehen Hacker vor?
von Netzwerken
1 Analysieren
• Potentielle Opfer?
der potenziellen Opfer
2 Beobachtung
• Wo kann man am einfachsten eindringen?
3 Angriff
• Ausnutzen von Unachtsamkeit
4
Illegale Tätigkeit
• Löschen von Projektdaten
• Installation eines maßgeschneiderten Trojanischen Pferdes,
das alle neu erstellten Dokumente sofort an den Hacker sendet
5 Escape
• Der Remote-Zugriff wird unterbrochen
March 25, 2013
10
March 25, 2013
11
The CSC Cybersecurity Demonstration Center
• Global Learning
• Situational Awareness
Threat Alerting
Nation /
States
Event Correlation
Organization
• Real-time Detect and Respond
• Data-loss prevention
• End-point security
Classical
Prevent- Detect-Respond
Perimeter &
Gateway
• Ongoing Vulnerability Analysis
• Identity Management
LAN-WAN-Applications
and Data
Single
Systems
71
VIELEN DANK FÜR IHRE
AUFMERKSAMKEIT!
HABEN SIE FRAGEN?
March 25, 2013
12
March 25, 2013
13
72

IT Security - Software and Systems Engineering

Transcription

Similar documents

Belzona 1111 Super Metal

Munich Airport, Terminal 2

enterprise - content - sharing - The Digital Collections System

In ihren Bildern und Fotografien friert Mercedes Helnwein schöne

Picturing family matters

Flyer Minting - Sack und Kiesselbach

QUICK INSTALLATION GUIDE SPECIFICATIONS

Scooter Soundboards - WilTec Wildanger Technik GmbH

TB-CDP02-TX/RX

V2_Programm_Bremerhaven__englisch_2.