Trustworthy services from untrustworthy components overview
Download
1 / 23

- PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on

Trustworthy Services from Untrustworthy Components: Overview. Fred B. Schneider Department of Computer Science Cornell University Ithaca, New York 14853 U.S.A. Joint work with Lidong Zhou and Robbert van Renesse. . Servers. Client. Fault-tolerance by Replication. The “fine print” …

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '' - omer


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Trustworthy services from untrustworthy components overview l.jpg

Trustworthy Servicesfrom Untrustworthy Components:Overview

Fred B. Schneider

Department of Computer Science

Cornell University

Ithaca, New York 14853

U.S.A.

Joint work with Lidong Zhou and Robbert van Renesse.


Fault tolerance by replication l.jpg

Servers

Client

Fault-tolerance by Replication

The “fine print” …

  • Replica failures are independent.

  • Replica coordination protocol exists.

  • No secrets stored in server’s state.


Trustworthy services l.jpg
Trustworthy Services

A trustworthy service…

  • tolerates component failures

  • tolerates attacks

  • might involve confidential data

    N.b. Cryptographic keys must be kept confidential and are useful for authentication, even when data is not secret.


Revisiting the fine print l.jpg
Revisiting the “Fine Print”

  • Replica failures are independent.

  • Replica Coordination protocol exists.

  • No secrets stored in server’s state.


Revisiting the fine print5 l.jpg
Revisiting the “Fine Print”

  • Replica failures are independent.

    • But attacks are not independent.

  • Replica Coordination protocol exists.

  • No secrets stored in server’s state.


Revisiting the fine print6 l.jpg
Revisiting the “Fine Print”

  • Replica failures are independent.

    • But attacks are not independent.

  • Replica Coordination protocol exists.

    • But such protocols involve assumptions, and assumptions are vulnerabilities.

      • Timing assumptions versus Denial of Service

  • No secrets stored in server’s state.


Revisiting the fine print7 l.jpg
Revisiting the “Fine Print”

  • Replica failures are independent.

    • But attacks are not independent.

  • Replica Coordination protocol exists.

    • But such protocols involve assumptions, and assumptions are vulnerabilities.

      • Timing assumptions versus Denial of Service

  • No secrets stored in server’s state.

    • But secrets cannot be avoided for authentication

      • Replicating a secret erodes confidentiality.


Compromised components l.jpg
Compromised Components

Correct component satisfies specification.

Compromised component does not.

  • Adversary might control a compromised component.

  • Component is compromised if adversary knows secrets being stored there.

    A recovery protocol transforms component: compromised  correct


Component correlation l.jpg
Component Correlation

Components are correlated to the extent that one attack suffices to compromise all.

Correlation arises from:

  • Dependence on the environment

  • Vulnerabilities in shared design / code

  • Shared secrets

    Goal: Eliminate sources of correlation.


Correlation environment vulnerabilities l.jpg
Correlation:Environment Vulnerabilities

Vulnerabilities = Assumptions

  • Weaker assumptions are better.

    • “Synchronous system” assumption:

      • Bounded message delivery delay

      • Bounds on process execution speed

    • violated by denial of service attacks

    • needed for “agreement protocols” in deterministic systems [FLP]


Correlation towards weaker assumptions eschewing synchronous systems l.jpg
Correlation > Towards Weaker Assumptions:Eschewing Synchronous Systems

Asynchronous system model is weaker but requires making “sacrifices”:

  • Sacrifice determinacy:

    • Use “randomized protocols” (requires randomness)

  • Sacrifice liveness but preserve safety.

  • Sacrifice state machine replication

    • Use quorums or other weaker mechanisms

    • Some service semantics cannot be implemented.


Component correlation12 l.jpg
Component Correlation

Correlation arises from:

  • Dependence on environment

  • Vulnerabilities in shared design / code

  • Shared secrets


Correlation eschewing shared design code l.jpg
Correlation:Eschewing Shared Design / Code

Solution: Diversity!

  • Expensive or impossible to obtain:

    • Development costs

    • Interoperability risks

      Still, what diversity does exist should be leveraged.


Correlation leveraging extant diversity adversary structures l.jpg
Correlation > Leveraging Extant Diversity:Adversary Structures

t-resilience: Service is not compromised unless more than t components are.

  • Known as a threshold structure.

    FS-resilience: If FS = {F1, F2, … Fr} then service not compromised provided the set C of compromised components satisfies

    C  Fi

    for some i.

  • Select FS according to dimensions of diversity.

  • Known as an adversary structure.


Component correlation15 l.jpg
Component Correlation

Correlation arises from:

  • Dependence on environment

  • Vulnerabilities in shared design / code

  • Shared secrets


Correlation eliminating shared secrets l.jpg
Correlation:Eliminating Shared Secrets

  • (n,t) secret sharing [Shamir, Blakley]:

    • Secret s is divided into n shares.

    • Any t or more shares suffice for reconstructing s.

    • Fewer shares convey no information about s.

    • Can be adapted for arbitrary adversary structures.

  • Threshold cryptography:

    • Perform cryptographic operations piecewise using shares of private key; result is as if private key was used.

      Example: Threshold digital signatures


Proactive recovery l.jpg
Proactive Recovery

When is recovery protocol run?

  • After an attack is detected.

    • Not sufficient to reboot from good system image.

      • Must get system state (or have stateless service).

      • Must also “refresh” secrets.

  • Periodically, even if an attack is not detected.

    • Not all attacks are detected, proactive recovery defends against undetected attacks.

    • Adversary strategy: Increase the window of vulnerability, interval between proactive recovery executions.


Proactive recovery secret refresh l.jpg
Proactive Recovery:Secret Refresh

  • Refresh secret shares: PSS and APSS

  • Refresh symmetric keys:

    • Revisit KDC.

    • Force new password choices.

  • Refresh public / private key pairs:

    • Invent new server private key

    • Must disseminate new server public key.


  • Proactive recovery secret refresh refresh private public keys i l.jpg
    Proactive Recovery > Secret Refresh:Refresh Private / Public Keys I

    Approach: Tamper proof hardware.

    • Key material stored in tamper-resistant hw.

      • Key cannot be read or modified.

      • Attacker can still instigate crypto operations with key. Protocols must accommodate such possible rogue behavior.


    Proactive recovery secret refresh refresh private public keys ii l.jpg
    Proactive Recovery > Secret Refresh:Refresh Private / Public Keys II

    Approach: Use off-line private keys.

    • New public keys are propagated through a secure out-of-band channel.

      • Use off-line private keys to sign the new public keys.

      • Components storing off-line keys can be connected to network using a one-way channel (e.g. “pump”).


    Proactive recovery transparency and change i l.jpg
    Proactive Recovery:Transparency and Change I

    Scalability concerns dictate that clients be shielded from changes due to proactive recovery.

    • Service public / private key:

      • Proactive secret sharing changes private key shares without changing private key (or public key).

    • Server identities:

      • A single contacted server operates as a delegate.

      • Service key signs responses to client.

      • Self-verifying messages impede rogue delegates from spoofing as clients.


    Proactive recovery transparency and change ii l.jpg
    Proactive Recovery:Transparency and Change II

    • Server public keys. If client must know…

      • Local certificate:

        • <Server name, New server public key, Epoch number>

        • Signed by server using server’s off-line key

      • Global certificate:

        • Local certificate signed by service private key

          • Service signs only if local signature on certificate is valid

          • Use t+1 threshold crypto for service signature

        • Stored at 2t+1 servers. (Out of 3t+1)

      • Client obtains current public key for server i:

        • Retrieve global certificate for all servers from 2t+1 servers

        • epoch numbers in t+1 sets will be the same---that is current


    Research programme trajectory l.jpg
    Research Programme Trajectory

    • Cornell On-line Certification Authority (COCA)

    • Asynchronous Proactive Secret Sharing (APSS)

    • Distributed Blinding Protocol

    • Codex Secret Store

      Key ideas:

      • Weak computational models (asynchronous)

      • Thresholdization [sic] / “multi-party computation”

      • Proactive protocols (vs Transparency)


    ad