hack-proof drone, what is it?secuinside.com/archive/2017/2017-1-1.pdf(sommerville, i.:...

고려대학교정보보호대학원

마스터 제목 스타일 편집


Hack-Proof Drone, What is it?




Weapons Systems and Cyber Security



3

Who am I?


마스터 제목 스타일 편집CyKoR @ DEFCON CTF 2015(Advisor : Seungjoo Kim)



(Founder & Board Member : Seungjoo Kim, 2011)

(사)HARU & SECUINSIDE


마스터 제목 스타일 편집사이버무기시험평가연구센터 (CW-TEC)



8

Are Weapons Systems Secure?



9

Smart TV Hacking "Hackers to Target Smart TV Sets After

Phones, Kaspersky Predicts", (Bloomberg, 2015)



10(☞ MBC Newsdesk)

Smart TV Hacking



11

Smart TV Hacking



12

Smart TV Hacking



13

Smart TV Hacking

CIA and MI5 developed “Weeping Angel” to infect Samsung Smart TVs.



14

Samsung Smart TVs have been sued by the CIA's hacking code.

Smart TV Hacking



15

Smart Car Hacking



16

Smart Car Hacking



17

Smart Car Hacking



18

Smart Car Hacking



19

Airplane (IFE) Hacking

(☞ IOActive, “In Flight Hacking System”, December 20, 2016)



20

?



21

Left of Launch



22

☞ John Blackburn on Integrated Force Design: The Case of IMAD(Integrated Missile & Air Defence)

Left of Launch



23



24

Left of Launch



25

Left of Launch



26



27

Recent suggestions that the fleet is vulnerable have sometimes been met with complacency and claims that the isolated 'air-gapped' systems cannot be penetrated. Whilst we recognise that it is important not to be alarmist, these claims are false.



28

Malware injection during manufacturing(a.k.asupply chain), mid-life refurbishment or software updates and data transmission interception allow potential adversaries to conduct long-term cyber operations.



29

Cybersecurity Test and Evaluation



30



31

Then... Ours?



32

사이버작전수행에 직접 운용되거나훈련용으로 운용하는 장비, 부품, 소프트웨어 등으로서, 사이버영역의감시·정찰, 사이버작전 지휘통제 및 능동적대응을 위한 장비·부품·소프트웨어 또는사이버전 훈련을 위해 운용되는모의공격체계, 모의훈련모델, 훈련용장비·시설 등

(출처 : 국방사이버안보훈령)

사이버무기란?



33

네트워크와 연결된 모든 무기체계

C4I 등의 전술지휘자동화체계, 무인기(UAV : Unmanned Aerial Vehicle) 및 군 위성통신체계, 위성전군방공경보체계, 해상작전위성통신체계등과 같은 통신체계, 그리고전술용전자식교환기, 야전용전화기, 휴대용·차량용 FM/AM 무전기 등 각종 유·무선통신장비 및 연습훈련용·분석용· 획득용 워게임모델 및 전술훈련모의장비 등이 모두 이에포함됨.

(출처 : 국방사이버안보훈령의 사이버무기체계 세부분류)

다른 말로, 사이버무기란?



34



35

Weapons Systems &

Cyber Security



36



37

The key strategy is to upgrade weapon systems to qualify as High-Assurance Cyber Military Systems (HACMS),

strategically designed to better withstand a cyber attack.



38



39

Hack-Proof Drones Possible with DARPA’s HACMS(High Assurance Cyber Military

Systems) Technology



40



41

Robustness

Strength

Assurance

Assurance (in a narrow sense)



42

Physical Security Era

Communication Security (COMSEC) Era

Computer Security (COMPUSEC) Era (Early 1960s~)

Information Security (INFOSEC) Era (1980s~)

Information Assurance (IA) Era (1998 ~)

Etc : Operational Security (OPSEC)

Assurance (in a broader sense)



43

The first standardized definition of IA was published in U.S. DoD Directive 5-3600.1 in 1996.

The 1991 Gulf War has often been called the first information war. In many ways, the Gulf War was the harbinger of IA.




44



45

Communications are disrupted by hacking?



46

Communications are disrupted by dust storm??



47☞ Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on Dependable and Secure Computing, VOL.1, NO.1, 2004.

(Trustworthiness)




48

Trustworthiness (or Dependability) is assurance that a system deserves to be trusted - that it will perform as expected despite environmental disruptions, human and operator error, hostile attacks, and design and implementation errors. Trustworthy systems reinforce the belief that they will continue to produce expected behaviourand will not be susceptible to subversion.


☞ The "Trust in Cyberspace" report of the United States National Research Council



49☞ Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, “BasicConcepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on Dependable and Secure Computing, VOL.1, NO.1, 2004.

(Trustworthiness)

Independent? No, Interdependent!




50




51

Security by Designto cope with complexity!




52

Embedded Security!




53

[Note] High-Confidence



54




55




56




57

Considering security as early as the design phase of the software development process.

Security by Design (in a narrow sense)

☞ Michael Waidner, Michael Backes, Jörn Müller-Quade, "Development of Secure Softwarewith Security By Design", Fraunhofer SIT Technical Reports, July 2014



58

Systematically organized and methodically equipped framework that is applied over the lifecycle of secure software.

(e.g.) Embedding of secure SW development at governance level, individual security processes for the SW's lifecycle phases, and security analyses of SW components integrated from other manufacturers.

Security by Design (in a broader sense)

☞ Michael Waidner, Michael Backes, Jörn Müller-Quade, "Development of Secure Softwarewith Security By Design", Fraunhofer SIT Technical Reports, July 2014



59

Security engineering is about building dependable (or trustworthy) embedded systems.

Security Engineering (보안공학)

☞ ‘Dependability’ is interchangeably used for ‘trustworthiness’(Sommerville, I.: "Software Engineering", Addison-Wesley, 6. edn., 2001, ISBN 0-201-39815-X)

(Trustworthiness)



60

Financial System High security + Medium reliability + No safety

DB of Medical Records Medium security + Medium reliability +

Medium safety

Air Traffic Control System Medium security + High reliability + High safety

Automobile Low (but now medium!) security +High reliability + High safety




61

Security Engineering



62

”Our company has recruited a lot of hackers and done lots of

pentesting, but we do not know if the quality of our product is

really improving.”



63

”Our company has recruited a lot of hackers and done lots of

pentesting, but we do not know if the quality of our product is

really improving.”Can't Guarantee Coverage!



64

Cryptography v.s Cryptanalysis

Cryptology :science of secret communication

Cryptography :design secret

systems

Cryptanalysis :break secret

systems



65

Security Engineer : Like to fix systems. Security engineers are more intend on building robust security solutions (Firewalls, IDS, etc.).

Similar Jobs : Information Assurance Engineer, Information Security Engineer, Information System Security Engineer

Security Analyst : Try to break them. Security analysts are more concerned with probing for risks and weaknesses (Pentesting, Auditing, etc.).




66




67

(☞ Paul Curran, “Cyber Security Today: Career Paths, Salaries and In-Demand Job Titles”, Aug 30, 2016)




68

1. Define "goals" or "properties" (i.e., what you want the program to satisfy)

2. Design algorithms/protocols

3. Make standards

4. Generate source code

5. Compile to machine code (i.e., what actually runs)

5 Steps for Developing Dependable S/W



69

☞ "Cost Effective Use of Formal Methods in Verification and Validation"



70


Policy (= a set of requirements) Assurance

Design Assurance

Implementation/Operational Assurance




71



Design Assurance



Chain of Evidence!



72

☞ Daniel Jackson et al., "Software for Dependable Systems: Sufficient Evidence?"


Design Assurance



Then, don’t need pentesting?



73


Design Assurance



Testing is indispensable, and no software system can be regarded as dependable if it has not been extensively tested, even if its correctness has been proven mathematically.




74


Design Assurance



Testing may find flaws that elude analysis because it exercises the system in its entirety, whereas analysis must typically make assumptions about the execution platform, the external environment, and operator responses, any of which may turn out to be unwarranted.




75


Design Assurance



At the same time, it is important to realize that testing alone is rarely sufficient to establish high levels of dependability. It is erroneous to believe that a rigorous development process, in which testing and code review are the only verification techniques used, justifies claims of extraordinarily high levels of dependability.




76


How to identify and define goals correctly?

By using “Threat Modeling” & “Security Policy Modeling (SPM)”

Problems for STEP 1.



77

MS’s STRIDE Threat Modeling Tools



78

LINDDUN Modeling



79

Other Methodologies and Tools

TARA : Intel's Threat Agent Risk Assessment

OWASP https://www.owasp.org/index.php/Application_T

hreat_Modeling

WASC Threat Classification http://projects.webappsec.org/Threat-

Classification

Trike http://octotrike.org

ThreatModeler http://threatmodeler.com



80



81

“Pentesting cannot replace threat modeling! Pentesting should be used as

an adjunct to threat modeling.”



82



83



84



85


How to check if your algorithm or protocol satisfy the goals of STEP 1?

By “hand-proof” or “machine-checked proof”




86

Needham-Schroeder public-key authentication protocol (1978), which was believed secure for 17 years before Lowe discovered it was affected by a flaw such as replay attack (1995).

[Note] Why Design Assurance?


마스터 제목 스타일 편집How to Get Design-Proof



88

Originated from the seminal paper by Dolev and Yao (1983), and was developed mainly in the formal methods community

Better automaton

However, more complex to relate to real world security goals

[Note] Symbolic Analyses

☞ Dolev D, Yao ACC (1983) On the security of public key protocols. IEEE Trans Inf Theory 29(2):198–208



89

Originated from the papers by Goldwasser and Micali (1984) and by Yao (1982), and is based on more detailed computational models, involving complexity and probability theories

Difficulty in proof automation

But gives more realistic security assurance

[Note] Computational Analyses

☞ Goldwasser S, Micali S (1984) Probabilistic encryption. J Comput Syst Sci 28(2):270–299

☞ Yao AC (1982) Theory and application of trapdoor functions. In: 23rd FOCS, pp 80–91



Both symbolic and computational approaches provide rigorous proofs based on abstract models.

→ A large gap still exists between these models and a real-world protocol implementation :

Design << Implementation



91

[Note] Abstract Model

☞ Aaron Tomb (Galois, Inc), "Assuring Crypto Code with Automated Reasoning",QCon, London, March 2017



92

[Note] Abstract Model


Soundness : If the model is proved free from certain attacks under some assumptions, then the program is alsofree from the same attacks under some corresponding assumptions.



Both symbolic and computational approaches provide rigorous proofs based on abstract models.

→ Recently, some researchers have started investigating techniques that bring automatedformal proofs closer to real implementations.(explain in later…)



94

How to Get Design-Proof



95

How to Get Design-Proof



97

3. Make standards

There might be specification mismatch between STEP 2 and STEP 3.

We need equivalence proof to address the "gap" between the abstract algorithm/protocol and more concrete standard specification




98

4. Generate source code and compile it into machine code

Problems for STEP 4 ~ STEP5.

Program might incorrectly implement the standard of STEP 3.

Also, we can’t be sure about the compiler!

By using machine-checked proof tools such as “Verified Software Toolchain”.



99

[Note] Why Implementation Assurance?



100

How to Get Code-Proof



101

How to Get Code-Proof (in CGC case)



102


☞ Symposium Celebrates Ed Clarke and Model Checking, CMU, September 2014



103





104


☞ 차상길, "바이너리 분석을 통한 자동 익스플로잇 생성: 과거, 현재, 그리고 미래", SECUINSIDE 2016



105





106





107


(☞ Aaron Tomb, "Automated Verification of Real-World Cryptographic Implementations“)



108


DES standard DES binary code

- Equivalence-checking- Safety-checking

(e.g.) SAW with ABC (which uses SAT)Z3 (which uses SMT)Verified Software Toolkit (VST)

(Reference Model)

(☞ Aaron Tomb, "Automated Verification of Real-World Cryptographic Implementations“)

Symbolic Execution (for constructing mathematicalmodels of SW)

(e.g.) Cryptol, Z, etc.



109

Equivalence-Checking : Checks whether two functions, f and g, agree on all inputs

Safety-Checking : Checks run-time exceptions. Given a function f, we would like to know if f's execution can perform operations such as division by zero or index out of bounds.


☞ David A. Ramos and Dawson R. Engler, "Practical, Low-Effort Equivalence Verificationof Real Code", CAV 2011 : This shows a technique for performing a semantic equivalenceverification of new implementations vs reference implementations using a modified version of KLEE.



110

[Note] How to Link Model with Prog.

☞ Matteo Avalle, Alfredo Pironti, Riccardo Sisto, "Formal Verification of Security ProtocolImplementations: a Survey", Formal Aspects of Computing, January 2014.



111

Several famous theorems (particularly Gödel’s incompleteness theorem and Rice’s theorem) imply that it’s impossible to write a program that can always construct a proof of some arbitrary theorem (or some arbitrary property of a piece of software). Because of these theoretical limits, automated proof is no panacea.

In practice, however, cryptographic code contains characteristics that make many of its properties easier to prove.

[Note] The Limits of Automated Proof



112

Haskell based DSL (Domain-Specific Language) for writing crypto-algorithms

DSL : Programming language targeted at producing solutions in a given problem domain by enabling subject-matter experts to design solutions in terms they are familiar with and at a level of abstraction that makes most sense to them

Cryptol

☞ Lewis JR, Martin B., "Cryptol: High-Assurance, Retargetable Crypto Development and Validation", MILCOM 2003



113

Created by Galois Inc. with support from NSA

Cryptol specifications can be used to verify various implementations

C code, VHDL, etc.

Cryptol

☞ Lewis JR, Martin B., "Cryptol: High-Assurance, Retargetable Crypto Development and Validation", MILCOM 2003



114



115(☞ "Verified correctness and security of OpenSSL HMAC", Usenix Security Symposium 2015)



116



117



118



3. Make standards



Assurance Levels

In many cases, "provable security in cryptography" means only "design assurance"!i.e., the proposed algorithm/protocol satisfies certain security requirements



119



3. Make standards



Assurance Levels

Common Criteria, even at EAL7, relies on testing (not mathematical proof!). There is no proof that security properties hold for the actual implementation (i.e., code proof).



120



3. Make standards



Assurance Levels

We call this as “High-Assurance (End-to-End Provably) Dependable Systems” (e.g.) DARPA’s HACMS(Hisg-Assurance Cyber Military Systems) Program, NICTA’s seL4 Microkernel, etc



121

NICTA’s seL4 Microkernel



122

Mathematical proofs are best! But if it is not achievable, we should follow the well-defined software development processes!!

(e.g.) Microsoft’s SDL(Security Development Lifecycle)

If It is Not Provable…



123

If It is Not Provable…


마스터 제목 스타일 편집CC (Common Criteria) Evaluation



126

Green Books

1989

IT-Security

Criteria

1989

Blue-White-Red

Book

1989

Orange Book

(TCSEC) 1985미 국

영 국

독 일

프랑스

Canadian Criteria

(CTCPEC) 1993

U.S. Federal Criteria

Draft 1993

캐나다

European

ITSEC (1991)

※ 1999년 : ISO/IEC 15408 국제 표준으로 제정

v1.0 1996v2.0 1998v2.1 1999v2.2 2004v2.3 2005v3.1 R1 2006.9v3.1 R2 2007.9

Netherlands

Criteria

1989네덜란드

CC (Common Criteria) Evaluation



127

기능 요구사항

보안 문제

보안목적

기능명세

설계 설명

구현 표현

구현

TOE 요약명세

정책 모델

A B

A B

A가 B에 대응 (요구사항에 따라)

A가 B로 상세화

ASE_TSS

ADV_SPM

APE/ASE_OBJ

APE/ASE_REQ

ADV_FSP

ADV_TDS

ADV_IMP

ALC_CMC.5 ATE_AVA

모든 설계 분해 단계에서수행된 상호 보완적인 분석

구현 시 수행된 기능 시험및 침투 시험

보안문제, 보안기능요구사항(SFR)과

보안목적 간 일치성에 대한요구사항을 정의

TOE 요약명세에 대한 요구사항을정의

시험클래스와 취약성 평가 클래스에서시험된 TSF가 개발 클래스의 분해 단계에서

모두 서술된 사항임을 검증

선택된 SFR을 정형화하여모델링하고, 이 정형화된 모델과기능명세간의 일치성 제공에 대한

요구사항 정의

기능명세, 설계, 구현에 해당하는 각표현을 기능요구사항에 정의




End-to-End Proof

High-AssuranceCyber System

Scope, Depth,Rigor




129

NSTISSP #11 Guidance IA & IA-Enabled Products

NSA Involvement inProduct Evaluation

NSA Evaluated Product List

NIAP - CertifiedCCTL Evaluations

FIPS evaluatedunder CMVP

(FIPS 140-1 or 140-2)

Validated Product Listhttp://csrc.nist.gov/cryptval

Type 1 Cryptofor Classified

Leve

l 1

Leve

l 2

Leve

l 3

Leve

l 4

EAL

Basicrobustnessproducts

Mediumrobustnessproducts

Highrobustnessproducts

4

7

6

5

3

2

1

0

4+

CMVP Labs• Atlan• Cygnacom (CEAL)• CoACT• EWA• Domus• InfoGard

NIAP Labs• Booz Allen

Hamilton• Cable & Wireless• CoACT• Criterian

Levels OfRobustness

Crypto Modules and Algorithms

• CSC• Cygnacom• InfoGard• SAIC

IT Products and PP




130




131



132

However…

Are provable secure schemes unbreakable?



133

Model does not cover all real world attacks!

Model



134

Reality

Model does not cover all real world attacks!



135

However…

Are provable secure schemes unbreakable?

It depends on the threat model!



136

References



137

References



138

References



139

References


마스터 제목 스타일 편집ICCC (International CC Conference)


마스터 제목 스타일 편집ICMC (InternationalCryptoModuleConf)




Hack-Proof Drone, What is it?

hack-proof drone, what is it?secuinside.com/archive/2017/2017-1-1.pdf(sommerville, i.:...

Documents