a framework for iterative signing of graph data on the web

A Framework for Iterative Signing ofGraph Data on the Web

May 27, 2014

Andreas Kasten, [email protected]

Ansgar Scherp, [email protected]

Peter Schauß, [email protected]

1 University of Koblenz-Landau, Koblenz, Germany

2 Kiel University and Leibniz Information Centre for Economics, Kiel, Germany

◦ ◦ ◦ ◦ ◦

Outline

Motivation

Signing and Verification Process

Signing Framework

Configurations

Conclusion

A. Kasten et al. – A Framework for Iterative Signing of Graph Data on the Web 2 / 21

• ◦ ◦ ◦ ◦

Outline

Motivation


Signing Framework

Configurations

Conclusion


• ◦ ◦ ◦ ◦

Use Case: Signing Medical Data


◦ • ◦ ◦ ◦

Outline

Motivation


Signing Framework

Configurations

Conclusion


◦ • ◦ ◦ ◦

Signing a Graph: Security Requirements

• authenticity

• integrity


◦ • ◦ ◦ ◦

Signing a Graph: Data

input graph + private key

output graph signature


◦ • ◦ ◦ ◦

Signing a Graph: Process

AssemblyStep 5

CanonicalizationStep 1

SerializationStep 2

HashStep 3

SignatureStep 4


◦ • ◦ ◦ ◦


Graph signing

AssemblyStep 5


SerializationStep 2

HashStep 3

SignatureStep 4


◦ • ◦ ◦ ◦


AssemblyStep 5


SerializationStep 2

HashStep 3

SignatureStep 4


◦ • ◦ ◦ ◦


AssemblyStep 5

SerializationStep 2

HashStep 3

SignatureStep 4


• normalize the graph

• rename blank nodes


◦ • ◦ ◦ ◦


AssemblyStep 5

SerializationStep 2

HashStep 3

SignatureStep 4


_:a ex:hasName "Jay" ._:a ex:hasChild _:b ._:b ex:hasName "Bob" .

_:g1 ex:hasChild _:g2 ._:g2 ex:hasName "Bob" ._:g1 ex:hasName "Jay" .


◦ • ◦ ◦ ◦


AssemblyStep 5


HashStep 3

SignatureStep 4

SerializationStep 2

• transform graph into serial form


◦ • ◦ ◦ ◦


AssemblyStep 5


SerializationStep 2

SignatureStep 4

HashStep 3 • compute hash value of serial form


◦ • ◦ ◦ ◦


AssemblyStep 5


SerializationStep 2

HashStep 3

SignatureStep 4

• sign hash value

• use private key


◦ • ◦ ◦ ◦



SerializationStep 2

HashStep 3

SignatureStep 4

AssemblyStep 5

• add signature to graph

• add metadata to graph


◦ • ◦ ◦ ◦

Verifying a Signature: Data

input signed graph + public key

output yes or no


◦ • ◦ ◦ ◦

Verifying a Signature: Process

ExtractionStep 1


SerializationStep 3

HashStep 4

VerificationStep 5


◦ • ◦ ◦ ◦


VerificationStep 5

ExtractionStep 1

identical tosigning process


SerializationStep 3

HashStep 4


◦ ◦ • ◦ ◦

Outline

Motivation


Signing Framework

Configurations

Conclusion


◦ ◦ • ◦ ◦

Signing Framework: Characteristics

• formally specifies signing process

• supports different configurations

• implementation-independent


◦ ◦ • ◦ ◦

Signing Framework: Features

• signing of named graphs

• signing of distributed graphs

• iterative signing

• signature is encoding-independent


◦ ◦ • ◦ ◦

Signing Framework: Formalization

• defines input & output of each step

• guideline for new algorithms

canonicalize κ : G→ G, κ(G) := G

serialize ν : G→ 2{0,1}∗, ν(G) := G

hash λ : {0, 1}∗ → {0, 1}d , λ(b) := h

% : 2{0,1}d

→ {0, 1}d , %({h1, . . . , ho}) := h

λG : 2{0,1}∗→ {0, 1}d , λ(G) := %({λ(b1), . . . , λ(bo)})

sign ε : K× {0, 1}d → {0, 1}d′, ε(k, b) := s

assemble ς : K× 2G → G,ς(k, {G1, . . . ,Gm}) := (aS , S , {G1, . . . ,Gm})


◦ ◦ ◦ • ◦

Outline

Motivation


Signing Framework

Configurations

Conclusion


◦ ◦ ◦ • ◦

Configurations: Overview

Configuration Approach

Carroll [Car03]

sort all statementsrename blank nodesadd statements for difficult blank nodes

Tummarello et al. [TMPP05]

sign sub-graphs separately

Fisteus et al. [FGFK10]

sort all statements based on hash valuerename blank nodes

Sayers & Karp [SK04]

add statements for all blank nodescompute hash incrementally


◦ ◦ ◦ • ◦



Carroll [Car03] sort all statementsrename blank nodesadd statements for difficult blank nodes

Tummarello et al. [TMPP05]

sign sub-graphs separately






◦ ◦ ◦ • ◦




Tummarello et al. [TMPP05] sign sub-graphs separately






◦ ◦ ◦ • ◦





Fisteus et al. [FGFK10] sort all statements based on hash valuerename blank nodes




◦ ◦ ◦ • ◦





Fisteus et al. [FGFK10] sort all statements based on hash valuerename blank nodes

Sayers & Karp [SK04] add statements for all blank nodescompute hash incrementally


◦ ◦ ◦ • ◦

Configurations: Theoretical Analysis

Configuration Runtime Space Signature Overhead

Carroll [Car03] O(n log n) O(n) bh + metadata

Tummarello et al. [TMPP05] O(n log n) O(n) bh + r metadata

Fisteus et al. [FGFK10] O(n log n) O(n) metadata

Sayers & Karp [SK04] O(n) O(n) b + metadata

n number of triples

b number of blank nodes

bh ≤ b number of difficult blank nodes

r ≤ n number of sub-graphs


◦ ◦ ◦ ◦ •

Outline

Motivation


Signing Framework

Configurations

Conclusion


◦ ◦ ◦ ◦ •

Best-Practice Guidelines

• use Sayers & Karp for graphs with few blank nodes

• use Carroll for graphs with many blank nodes

• only use Tummarello et al. with fast signing functions


Get the Java R© API from

https://github.com/akasten/signingframework

https://github.com/akasten/signingframework

◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Appendix Outline I

Iteratively Signing Graph Data

Reasoning on Signed Data

XML Signature Syntax

Java R© Implementation

Signature Verification

Complete Formalization


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Appendix Outline II

Blank Nodes & Canonicalization Functions

Tummarello et al.

Security

Semantic Web Layer Stack

Provenance Tracking

Evaluation


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Appendix Outline IIIReferences


• ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦



◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Reasoning on Signed Data


◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Signed Data

• signature covers original data

• any modification will invalidate the signature


◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Inferred Data

• inferred data is additional data

• inferred data modifies original data

• inferred data invalidates signature

. . . if stored in the same graph


◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Solution

• store signed data separately from inferred data

• sign inferred data again if desired


◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

XML Signature Syntax


◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

XML Signature Syntax: Goals [BBF+08]

• support signatures for any digital content

• define signing process

• define verification process

• specify signature format


◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

XML Signature Syntax: Syntax [BBF+08]

<Signature ID?>

<SignedInfo>

<CanonicalizationMethod/>

<SignatureMethod/>

(<Reference URI? >

(<Transforms>)?

<DigestMethod>

<DigestValue>

</Reference>)+

</SignedInfo>

<SignatureValue>

(<KeyInfo>)?

(<Object ID?>)*

</Signature>


◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

XML Signature Syntax: Signing RDF?

• signing RDF is possible

• signature will only cover specific serialization

• signature can only be verified having this serialization

• signature becomes fragile


◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

XML Signature Syntax: Example

<rdf:RDF ...>

<ex:Person rdf:about="http://www.example.com#Shakespeare">

<ex:diedIn>1616</ex:diedIn>

<ex:wrote rdf:resource="http://www.example.com#Hamlet" />

<ex:hasFriend rdf:nodeID="a" />

</ex:Person>

<rdf:Description rdf:nodeID="a">

<ex:hasAge>42</ex:hasAge>

</rdf:Description>

</rdf:RDF>


◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦


<rdf:RDF ...>



</rdf:Description>





</ex:Person>

</rdf:RDF>


◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦



◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦


• proof-of-concept

• contains 4 configurations

• foundation for evaluation

• usable as API or stand-alone application


◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Signature Verification


◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Verifying a Signature: Data

input signed graph + public key

output yes or no


◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦


1. extract

2. canonicalize

3. serialize

4. hash

5. verify


◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦


1. extract

2. canonicalize

3. serialize

4. hash

5. verify

• extract signature value

• extract metadata


◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦


1. extract

2. canonicalize

3. serialize

4. hash

5. verify

• re-create signature value

• compare with hash value


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Complete FormalizationGraphs and Named GraphsGraph Signing FunctionCanonicalization FunctionSerialization FunctionHash Function for GraphsSignature FunctionAssembly FunctionSignature Verification FunctionVerification Function


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Graphs and Named Graphs

set of triples T = (R ∪B)×P× (R ∪B ∪ L)

graph G

set of graphs G = 2T

named graph NG = (a,A, {C1,C2, . . . ,Cl})set of named graphs GN = ((R ∪B)×G× 2GN ) ∪ {(ε, ∅,G )}


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦

Graph Signing Function

σN : Ks × 2GN → {0, 1}d ′

σN(ks , {NG1, . . . ,NGm}) := s

σN(ks , {NG1, . . . ,NGm}) := ε(ks , λ(νN(κN(NG1))·. . .·νN(κN(NGm))))


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦

Canonicalization Function

κ : G→ G

κ(G ) := G

κN : GN → GN

κN(NG ) := NG

κN(NG ) :=

{(ε, (∅, ∅), G ) if NG = (ε, (∅, ∅),G ), G ∈ G(a, A, {C1, . . . , Cl}) if NG = (a,A, {C1, . . . ,Cl})


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Serialization Function

ν : G→ 2{0,1}∗, ν(G ) := G

νN : GN → 2{0,1}∗

νN(NG ) := NG

νN(NG ) :=

{G if NG = (ε, (∅, ∅),G ), G ∈ G{a} ∪ A ∪ C 1 ∪ . . . ∪ C l if NG = (a,A, {C1, . . . ,Cl})


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦

Hash Function for Graphs

λ : {0, 1}∗ → {0, 1}d

λ(b) := h

% : 2{0,1}d → {0, 1}d

%({h1, h2, . . . , ho}) := hN

λN : 2{0,1}∗ → {0, 1}d

λN(NG ) := hN = %({λ(b1), λ(b2), . . . , λ(bo)})


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦

Signature Function

ε : Ks × {0, 1}d → {0, 1}d′

ε(ks , b) := s


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Assembly Function

ςN : Ks × 2GN → GN

ςN(ks , {NG1, . . . ,NGm}) := (aS ,S , {NG1, . . . ,NGm})


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦

Signature Verification Function

δ : Kp × {0, 1}d′ → {0, 1}d

δ(kp, s) := b


◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

Verification Function

h′ := λN(νN(κN(NG1)) ∪ . . . ∪ νN(κN(NGm)))

γN : Kp × 2GN × {0, 1}∗ → {TRUE ,FALSE}

γN(kp, {NG1, . . . ,NGm}, s) :=

{TRUE if δ(kp, s) = h′

FALSE otherwise


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Blank Nodes & Canonicalization FunctionsBlank NodesCanonicalization FunctionsExample Canonicalization


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Blank Nodes: Problem

• local IDs may change

• local IDs influence graph’s hash value

• local IDs influence graph’s signature


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Blank Nodes: Example

_:a foaf:name "A" .

_:a foaf:knows _:b .

_:b foaf:name "B" .

_:d foaf:name "A" .

_:d foaf:knows _:c .

_:c foaf:name "B" .


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Blank Nodes: Solution

• deterministically rename blank nodes

• apply canonicalization function


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦

Stability of Canonicalization Functions

• canonicalization normalizes graphs by renaming blank nodes

• canonicalization functions operate deterministically

• sorting statements not necessary for canonicalizationI may be part of serialization function or hash functions


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

Example Scenario: Using a Triple Store

1. sign RDF/XML document

2. load RDF/XML document into triple store

3. rename blank nodes in triple store

4. change order of statements in triple store

5. write data in triple store to RDF/XML document

6. verify signature?


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

Example Scenario: Signing Process

• signing requires canonicalization

• canonicalization renames blank node IDsI may use sorting the statements

• statement ordering irrelevant for canonicalizationI if relevant for hash value, hash function will cover it

• canonicalization is deterministical


◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

Example Scenario: Verification Process

• verification performs canonicalization

• result is identical to first canonicalization

• following hash value is also identical

• signature can be verified


◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Tummarello et al.


◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Disadvantages

• high signature overhead

• high runtime

• iterative signing (natively) not supported


◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Signing a Graph: Original Graph

ex:Fred foaf:knows _:a .

_:a foaf:age "42" .


◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Signing a Graph: 1. Signature Graph

_:b rdf:type rdf:Statement .

_:b rdf:subject ex:Fred .

_:b rdf:predicate foaf:knows .

_:b rdf:predicate _:a .

_:b dbin:PGPCertificate http://public.dbin.org/cont/238785872.asc .

_:b dbin:Base64SigValue "McwOPX...A7xcB5w==" .


◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Signing a Graph: Attaching the 1. Signature


_:a foaf:age "42" .








◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Signing a Graph: 2. Signature Graph

_:c rdf:type rdf:Statement .

_:c rdf:subject ex:Fred .

_:c rdf:predicate foaf:knows .

_:c rdf:predicate _:a .

_:c dbin:PGPCertificate http://public.dbin.org/cont/4565543215.asc .

_:c dbin:Base64SigValue "MAhiuad...HUAash==" .


◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦

Signing a Graph: Attaching the 2. Signature


_:a foaf:age "42" .







_:c rdf:type rdf:Statement .

_:c rdf:subject ex:Fred .

_:c rdf:predicate foaf:knows .

_:c rdf:predicate _:a .

_:c dbin:PGPCertificate http://public.dbin.org/cont/4565543215.asc .

_:c dbin:Base64SigValue "MAhiuad...HUAash==" .


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

SecuritySecurity RequirementsSecurity AnalysisKey ManagementTrust Model


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ • ◦ ◦ ◦

Security Requirements

• authenticity

• integrity


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Security Analysis: Attacker Model

• remove existing statements

• insert additional statements

• replace existing statements with different statements

• modify statements in the graph


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Security Analysis: Basic Idea

• analyze all cryptographic operationsI basic hash function λI combining function %I signature function ε

• analyze all configurationsI break down all steps into atomic operationsI distinguish between cryptographic and non-cryptographic

operations


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ • ◦

Key Management: Goal

• protects a key pair. . .I . . . from being compromisedI . . . from being misused by unauthorized parties

• ensures that. . .I . . . a signature key is only known to its ownerI . . . a verification key can be related to the owner of the key pair


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ • ◦

Key Management: Tasks

• secure creation of keys

• secure storing of keys

• secure destroying of old keys

• revoking compromised keys


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

Trust Model: Goal

• defines trustworthy management of public keys

• certificate authorities (CAs) sign public key certificates

• trustworthiness of public keys depend on trustworthiness of CAs


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

Trust Model: Models

• X.509 [CSF+08]I hierarchical modelI few trusted & pre-configured root CAs

• PGP [Zim95]I decentrally organized (web of trust)I all participants are both end users and CAs


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦



◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦ ◦


User Interface & Applications

Trust

Proof

Cry

pto

Unifying Logic

Ontology: OWL

RDF-S

RDFXML

URI/IRI

Rule:RIF

SPARQL

[Bra07]


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Provenance Tracking


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

Goals of Provenance Tracking

• document creation of (digital) objects

• document modification of (digital) objects


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

W3C PROV: Goal [GM13]

define a format for provenance tracking covering

• involved agents

• involved documents (entities)

• involved activities


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

W3C PROV: Types of Provenance [GM13]

agent-centered parties creating and/or modifying the data

object-centered origins of data and its parts

process-centered actions and/or steps producing the data


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦

W3C PROV: Signatures?

PROV − Signatures

• assertions can be forged

• assertions can bemanipulated

PROV + Signatures

• assertions are authentic

• assertions are integer


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦

Evaluation


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦

Input and Output

Variables

• different configurations

• 10K–250K statements

• 0%–50% blank nodes

Measured Values

• runtime

• memory usage

• signature overhead


Runtime of Canonicalization Function

105 106 2.5 · 106100

101

102

103

no. of statements

run

tim

e(m

s)

Carroll Tummarello et al. Fisteus et al. Sayers & Karp

Memory Usage of Canonicalization Function

105 106 2.5 · 106

10−3

10−1

101

103

no. of statements

mem

ory

(mb

)


Runtime of Hash Function

105 106 2.5 · 106

102

103

no. of statements

run

tim

e(m

s)


Memory Usage of Hash Function

105 106 2.5 · 106

102

103

no. of statements

mem

ory

(mb

)


Runtime of Carroll

105 106 2.5 · 106101

102

103

104

107

no. of statements

run

tim

e(m

s)

Canonicalization Hash Sign Assembly

Runtime of Tummarello et al.

105 106 2.5 · 106101

102

103

104

107

no. of statements

run

tim

e(m

s)

Canonicalization Split Hash Sign Assembly

Runtime of Fisteus et al.

105 106 2.5 · 106

102

103

104

107

no. of statements

run

tim

e(m

s)


Runtime of Sayers & Karp

105 106 2.5 · 106

101102103104

107

no. of statements

run

tim

e(m

s)


Overall Runtime (Fixed Blank Node Percentage)

105 106 2.5 · 106

102

103

104

105

106

no. of statements

run

tim

e(m

s)


Overall Memory Usage (Fixed Blank Node Percentage)

105 106 2.5 · 106

102

103

104

no. of statements

mem

ory

(mb

)


Overall Runtime (Varying Blank Node Percentage)

105 106 2.5 · 106

104

105

106

no. of statements

run

tim

e(m

s)


Overall Memory Usage (Varying Blank Node Percentage)

105 106 2.5 · 106

103

104

105

no. of statements

mem

ory

(mb

)


Overall Signature Overhead (Varying Blank NodePercentage)

105 106 2.5 · 106

101

103

105

107

% of blank nodes in graph

over

hea

d(t

rip

les)


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

References


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

References I

Mark Bartel, John Boyer, Barb Fox, Brian LaMacchia, andEd Simon.XML signature syntax and processing.W3C recommendation, W3C, 2008.http://www.w3.org/TR/xmldsig-core/.

Steve Bratt.Semantic web, and other technologies to watch, 2007.www.w3.org/2007/Talks/0130-sb-W3CTechSemWeb/.

Jeremy J. Carroll.Signing RDF graphs.In ISWC 2003, pages 369–384. Springer, 2003.


http://www.w3.org/TR/xmldsig-core/

www.w3.org/2007/Talks/0130-sb-W3CTechSemWeb/

◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

References II

David Cooper, Stefan Santesson, Stephen Farrell, Sharon Boeyen,Russell Housley, and Tim Polk.Internet X.509 public key infrastructure.RFC 5280, IETF, 05 2008.

Jesus Arias Fisteus, Norberto Fernandez Garcıa, Luis SanchezFernandez, and Carlos Delgado Kloos.Hashing and canonicalizing Notation 3 graphs.JCSS, 76(7):663–685, 2010.


◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

References III

Yolanda Gil and Simon Miles.Prov model primer.Working group note, W3C, 04 2013.http:

//www.w3.org/TR/2013/NOTE-prov-primer-20130430/.

Craig Sayers and Alan H. Karp.Computing the digest of an RDF graph.Technical report, HP Laboratories, 2004.

Giovanni Tummarello, Christian Morbidoni, Paolo Puliti, andFrancesco Piazza.Signing individual fragments of an RDF graph.In WWW, pages 1020–1021. ACM, 2005.


http://www.w3.org/TR/2013/NOTE-prov-primer-20130430/

http://www.w3.org/TR/2013/NOTE-prov-primer-20130430/

◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •

References IV

Philip R Zimmermann.The official PGP user’s guide.MIT press, 1995.


a framework for iterative signing of graph data on the web

Data & Analytics

medical data

andreas kasten

kiel university

university of koblenz

verication process

leibniz information

ansgar scherp

peter schau