CHAINIAC: Proactive Software-Update Transparency via Collectively - - PowerPoint PPT Presentation

chainiac proactive software update transparency via
SMART_READER_LITE
LIVE PREVIEW

CHAINIAC: Proactive Software-Update Transparency via Collectively - - PowerPoint PPT Presentation

CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds 1 Kirill Nikitin , 1 Eleftherios Kokoris-Kogias, 1 Philipp Jovanovic, 1 Linus Gasser, 1 Nicolas Gailly, 2 Ismail Kho ffi , 3 Justin Cappos, 1


slide-1
SLIDE 1

CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds

1Kirill Nikitin, 1Eleftherios Kokoris-Kogias, 1Philipp Jovanovic, 1Linus Gasser, 1Nicolas Gailly, 2Ismail Khoffi, 3Justin Cappos, 1Bryan Ford

1École polytechnique fédérale de Lausanne (EPFL) 2University of Bonn 3New York University

slide-2
SLIDE 2

Software Updates

2 Hilary Mason's Twitter A program tape for the 1944 Harvard Mark I,

  • ne of the first digital computers. Wikipedia.
slide-3
SLIDE 3
  • Softwares updates are used to patch disclosed vulnerabilities, add new

features, and improve security posture

  • If you do not update your system, things can go bad…

3

The Sun Forbes The Verge

Software Updates

slide-4
SLIDE 4
  • But even if you do update your system regularly, things can go wrong too…
  • Software-update systems are a lucrative attack target due to their

centralized design and potential impact on users

4

Software Updates

How can we make software-update systems more secure and transparent?

slide-5
SLIDE 5

Software Release Pipeline

5

Development/Review – Building release binaries – Sign-off – Release distribution </CODE>

Developers Distribution center Users

slide-6
SLIDE 6

Software Release Pipeline

6 ⚙ ⚙

Development/Review – Building release binaries – Sign-off – Release distribution </CODE>

Build server Developers Users Distribution center

slide-7
SLIDE 7

Software Release Pipeline

7

Development/Review – Building release binaries – Sign-off – Release distribution

⚙ ⚙

</CODE>

Build server Developers Users Distribution center

slide-8
SLIDE 8

Software Release Pipeline

8

Development/Review – Building release binaries – Sign-off – Release distribution </CODE>

Build server Developers Users Distribution center

slide-9
SLIDE 9

Challenges

9 9 9

</CODE>

  • 1. Make software-update process resilient to partial key compromise

Build server Developers Users Distribution center

slide-10
SLIDE 10

Challenges

10 10 10

</CODE>

  • 1. Make software-update process resilient to partial key compromise

Build server Developers Users Distribution center

slide-11
SLIDE 11

Challenges

11

  • 1. Make software-update process resilient to partial key compromise

11 11

</CODE>

Build server Developers Users Distribution center

slide-12
SLIDE 12

Challenges

12 12 12 Talos report on Petya/NotPetya attacks Mashable

  • 1. Make software-update process resilient to partial key compromise

Kaspersky Securelist

slide-13
SLIDE 13

Challenges

13

  • 2. Prevent malicious substitution of a release binary during building process

13 13

</CODE>

Build server Developers Users Distribution center

slide-14
SLIDE 14

Challenges

14

  • 2. Prevent malicious substitution of a release binary during a build process

14 14 ⚙ ⚙

</CODE>

Build server Developers Users Distribution center

slide-15
SLIDE 15

Challenges

15

  • 2. Prevent malicious substitution of a release binary during a build process

15 15

</CODE>

Build server Developers Users Distribution center

slide-16
SLIDE 16

Over 90% of the source packages included in Debian 9 will build bit- for-bit identical binary packages

16

Challenges

  • 2. Prevent malicious substitution of a release binary during a build process
slide-17
SLIDE 17

17

Challenges

How many of you have reproducibly built software binaries for personal use?

slide-18
SLIDE 18

Building the Tor Browser bundle takes 32 hours on a modern laptop

18

Challenges

  • 2. Prevent malicious substitution of a release binary during a build process

Closed-source software?

slide-19
SLIDE 19

Challenges

19

  • 3. Protect users from targeted attacks by coerced or bribed developers

19 19

Build server Developers Users Distribution center

slide-20
SLIDE 20

Challenges

20

  • 3. Protect users from targeted attacks by coerced or bribed developers

20 20

Build server Developers Users Distribution center

slide-21
SLIDE 21

Challenges

21

  • 3. Protect users from targeted attacks by coerced or bribed developers

21 21

</CODE> </CODE’>

⚙ ⚙

Build server Developers Users Distribution center

slide-22
SLIDE 22

Challenges

22

  • 3. Protect users from targeted attacks by coerced or bribed developers

22 22

</CODE> </CODE’>

Build server Developers Users Distribution center

slide-23
SLIDE 23

Challenges

23

  • 3. Protect users from targeted attacks by coerced or bribed developers

23 23

</CODE> </CODE’>

Build server Developers Users Distribution center

slide-24
SLIDE 24

Challenges

24

  • 4. Enable developers to securely rotate their signing keys in case of renewal
  • r compromise

24 24 24

Build server Developers Users Distribution center

slide-25
SLIDE 25

Challenges

25 25 25 25

  • 4. Enable developers to securely rotate their signing keys in case of renewal
  • r compromise

Developers Users Distribution center Build server

slide-26
SLIDE 26

Challenges

26 26 26 26

  • 4. Enable developers to securely rotate their signing keys in case of renewal
  • r compromise

Developers Users Distribution center Build server

slide-27
SLIDE 27

Challenges

27 27 27 27

  • 4. Enable developers to securely rotate their signing keys in case of renewal
  • r compromise

Developers Users Distribution center Build server

slide-28
SLIDE 28

Design of CHAINIAC

28

slide-29
SLIDE 29

Roadmap to CHAINIAC

29

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-30
SLIDE 30

Decentralized Release-Approval

30

Policy

  • 1. Make software-update process resilient to partial key compromise

Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-31
SLIDE 31

31

Policy

  • 1. Make software-update process resilient to partial key compromise

Decentralized Release-Approval

Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-32
SLIDE 32

32

Policy

Release <source code> Release <binary>

Decentralized Release-Approval

  • 1. Make software-update process resilient to partial key compromise

Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-33
SLIDE 33

33

Policy

Release <source code> Developers’ signatures Release <binary>

Decentralized Release-Approval

  • 1. Make software-update process resilient to partial key compromise

Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-34
SLIDE 34

34

Policy

Developers’ signatures Release <binary>

Decentralized Release-Approval

  • 1. Make software-update process resilient to partial key compromise

Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-35
SLIDE 35

35

Policy

Developers’ signatures Release <binary>

Decentralized Release-Approval

  • 1. Make software-update process resilient to partial key compromise

Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-36
SLIDE 36

Background

  • Collective Authority (Cothority), Collective Signing (CoSi), and BFT-CoSi

36

1 record 2 record 3 record

Authority Witness Cosigners each statement collectively signed by both authority and all or most witnesses Authoritative statements: e.g. log records

References

  • Ewa Syta, Iulia Tamas, Dylan Visher, David Isaac Wolinsky, Philipp

Jovanovic, Linus Gasser, Nicolas Gailly, Ismail Khoffi, and Bryan Ford. Keeping Authorities “Honest or Bust” with Decentralized Witness

  • Cosigning. In 37th IEEE Symposium on Security and Privacy, May 2016.
  • Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi,

Linus Gasser, and Bryan Ford. Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing. In Proceedings of the 25th USENIX Conference on Security Symposium, 2016.

slide-37
SLIDE 37

Verified Builds

37

Policy

Developers’ signatures Release Tree <source code> <binaries>

Cothority

  • 2. Prevent malicious substitution of a release binary during building process

Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-38
SLIDE 38

38

Policy

Developers’ signatures Release Tree <source code> <binaries> ⚙ ⚙

  • 2. Prevent malicious substitution of a release binary during building process

Verified Builds

Cothority Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-39
SLIDE 39

39

Policy

Co-signature Release Tree <source code> <binaries> ⚙ ⚙

  • 2. Prevent malicious substitution of a release binary during building process

Verified Builds

Cothority Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-40
SLIDE 40

40

Policy

Co-signature Release Tree <source code> <binaries> ⚙ ⚙

  • 2. Prevent malicious substitution of a release binary during building process

Verified Builds

Cothority Distribution center Developers User

Download & Verify

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-41
SLIDE 41

41

Release Policy File

  • List of individual

developer public keys

  • Signing threshold
  • Cothority public key
  • Supported platforms for

verified builds

Verified Builds

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-42
SLIDE 42

Anti-equivocation Measures

  • 3. Protect users from targeted attacks by coerced or bribed developers

42

Policy

⚙ ⚙ Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Developers’ signatures Release Tree

<source code> <binaries> <previous head>

Transparency Release Log Cothority Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-43
SLIDE 43

43

Policy

⚙ ⚙ Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

  • 3. Protect users from targeted attacks by coerced or bribed developers

Anti-equivocation Measures

Transparency Release Log Cothority Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-44
SLIDE 44

44

Policy

⚙ ⚙ Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

  • 3. Protect users from targeted attacks by coerced or bribed developers

Anti-equivocation Measures

Transparency Release Log Cothority Distribution center Developers User

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-45
SLIDE 45

Evolution of Developer Keys

  • 4. Enable developers to securely rotate their signing keys

45 ⚙ ⚙ Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Developers’ signatures

Release Tree

<source code> <binaries> <previous head>

Cothority Distribution center Developers User

Policy

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-46
SLIDE 46

Evolution of Developer Keys

46 ⚙ ⚙ Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Developers’ signatures

Release Tree

Cothority Distribution center Developers User

Policy dev keys

  • 4. Enable developers to securely rotate their signing keys

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-47
SLIDE 47

Evolution of Developer Keys

47 ⚙ ⚙ Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Cothority Distribution center Developers User

  • 4. Enable developers to securely rotate their signing keys

Developers’ signatures

Release Tree

Policy dev keys

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-48
SLIDE 48

Evolution of Developer Keys

48 ⚙ ⚙ Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Cothority Distribution center Developers User

  • 4. Enable developers to securely rotate their signing keys

Developers’ signatures

Release Tree

Policy dev keys

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-49
SLIDE 49

49 ⚙ ⚙ Cothority key config I Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Evolution of Cothority Configuration

Cothority Distribution center Developers User

  • 4. Enable cothority to securely rotate its collective key

Developers’ signatures

Release Tree

Policy co-config

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-50
SLIDE 50

50 ⚙ ⚙ Cothority key config I Cothority key config II Release 4

Co-signature

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Evolution of Cothority Configuration

Cothority Distribution center Developers User

  • 4. Enable cothority to securely rotate its collective key

Developers’ signatures

Release Tree

Policy co-config

Decentralized Release Approval Anti-equivocation Key Evolution Verified Builds

slide-51
SLIDE 51

Skipchains

slide-52
SLIDE 52

Skipchains

  • Novel data structure: blockchain + skip lists
  • Blocks have multi-hop two-way links:
  • Backward links - hashes of past blocks
  • Forward links - (collective) signatures
  • Secure and efficient traversal of arbitrary long timelines

52

slide-53
SLIDE 53

Skipchains

53

Cothority configuration

Skipblock Backward link (hash) Forward link (co-signature)

slide-54
SLIDE 54

Implementation and Evaluation

slide-55
SLIDE 55

Implementation

  • CHAINIAC is implemented in Go
  • Using the DEDIS Kyber crypto library and Onet networking framework
  • Available open-source at https://github.com/dedis/paper_chainiac

55

slide-56
SLIDE 56

Evaluation Methodology

What is the cost effect of CHAINIAC on cothority nodes and on clients?

  • Cothority-node CPU cost of validating releases and maintaining

transparency release log

  • The average values for six Debian packages over two years

56

slide-57
SLIDE 57

Evaluation

  • 1. Cothority-node CPU cost of validating releases and maintaining release log

57 3 15 127

Number of nodes

10-3 10-2 10-1 100 101 102 103 104 105

Time spent on each node per package (sec)

Wall-total over all nodes CPU / Wall Dev-signature verification Creating timestamp Collective signing Reproducible build

⚙ ⚙

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Cothority ⚙

slide-58
SLIDE 58

Evaluation

  • 1. Cothority-node CPU cost of validating releases and maintaining release log

58 3 15 127

Number of nodes

10-3 10-2 10-1 100 101 102 103 104 105

Time spent on each node per package (sec)

Wall-total over all nodes CPU / Wall Dev-signature verification Creating timestamp Collective signing Reproducible build

10$/month server is sufficient to validate and maintain the log of Debian-security repository

⚙ ⚙

Release 1

Co-signature

Release 2

Co-signature

Release 3

Co-signature

Cothority ⚙

slide-59
SLIDE 59

Evaluation Methodology

What is the cost effect of CHAINIAC on cothority nodes and on clients?

  • Cothority-node CPU cost of validating releases and maintaining transparency release log
  • The average values of six required Debian packages
  • CPU cost of reproducing packages on cothority nodes
  • From 1.5 to 30 minutes to reproduce a package
  • Skipchain effect on communication cost
  • Reducing the cost by the factor of 30 on 1.5 million update-requests from the PyPI repository
  • CPU and bandwidth cost of securing a multi-package distribution
  • ~20 sec to create a snapshot of >50k-packages Debian repository

59

slide-60
SLIDE 60

Conclusion

  • CHAINIAC decentralizes each step of the software-update process to

increase trustworthiness and to eliminate single points of failure

  • Skipchain structure for efficient logging and secure key evolution;

See https://bford.github.io/2017/08/01/skipchain/ for more applications

  • Verified builds as an improvement over reproducible builds
  • Role-based architecture, multi-package Chainiac and more are in the paper

60

Kirill Nikitin kirill.nikitin@epfl.ch @ni_kirill