A Secure Cloud Gateway based upon XML and Web Services

A Secure Cloud Gatewaybased upon XML and Web Services

1

PhD Symposium, ECOWS ’112011-09-16

Sebastian Grafsupervised by Prof. Marcel WaldvogelDistributed Systems GroupUniversity of [email protected]

Sonntag, 18. September 11

mailto:[email protected]


Problem StatementWhat approaches support secure storage of data in the cloud ?

2


Problem StatementWhat approaches support secure storage of data in the cloud ?

2

Availability:• access to data • no unauthorized deletion

Integrity:• System Integrity• Data Integrity

Confidentiality:• closure of private data

Accountability:• traceability of changes

G. Stoneburner: Underlaying technical models for information technology security

National Institute of Standards and Technology


Security and Cloud Storage

3

Web Services

Web Services

Web Services

Integrity Auditing

Web Services

Rev25

Rev874


How to provide…

4

Security

(Availability

Accountability

Confidentiality

Integrity

Cloud-based Service)

Goals Measurements

R1: How can integrity be ensured within a distributed environment

with focus on fast processing?

R3: How can current versioning approaches be adapted to fit a

distributed environment?

R2: How can key handling be adapted to support collaborative

use cases?


Integrity

5

‣Data must be consistent while→ in transfer

→ in process

→ in storage

‣Data is handled in decrypted form within client but stored encrypted into the cloud

→ Consistency check must guard data in all representations


Dual Integrity

Decrypted Data

‣ Data is wrapped in XML

‣ Tree-structure to offer recursive checksums

6

Encrypted Data

‣ XML is mapped to pages

‣ Pages are encrypted

‣ Pages are ordered within hierarchy to offer versioning and consistency checks


Decrypted Integrity Check

7

<?xml version="1.0" encoding="UTF-8"?>...<country id='f0_404' name='Switzerland' capital='f0_1627' population='7207060' datacode='SZ' total_area='41290' ...>...</country>... 345v1117234g56bd mbkl

19aksl24

lr9c3

4

5 6

7

8 967

345v1117234g56bd mbkl

19aksl24

lr9c3

4

5 6

7

8 967

345v1117234g56bd

19ak8h5y997d3

4

5 6

7

8 9



7

<?xml version="1.0" encoding="UTF-8"?>...<country id='f0_404' name='Switzerland' capital='f0_1627' population='7207060' datacode='SZ' total_area='41290' ...>...</country>... 345v1117234g56bd mbkl

19aksl24

lr9c3

4

5 6

7

8 967

345v1117234g56bd mbkl

19aksl24

lr9c3

4

5 6

7

8 967

345v1117234g56bd

19ak8h5y997d3

4

5 6

7

8 9

R. Merkle: A digital signature based on a conventional encryption function

Advances in Cryptology, ’86



8

!

!

!

!

!

!

!!

!

!!

!!

!!

!!

!!

5 10 15

5e+0

15e

+02

5e+0

35e

+04

5e+0

5

xmark factor[f*0.001]

Tim

e[m

s]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

! Merkle−HashIncremental ChecksumNo Hashing



8

!

!

!

!

!

!

!!

!

!!

!!

!!

!!

!!

5 10 15

5e+0

15e

+02

5e+0

35e

+04

5e+0

5

xmark factor[f*0.001]

Tim

e[m

s]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

! Merkle−HashIncremental ChecksumNo Hashing

S. Graf, S. K. Belle, and M. Waldvogel, Rolling boles, optimal XML structure integrity for updating operations, in Poster on the 20th International Conference on World Wide Web


Encrypted Integrity Check

9

J. Bonwick, M. Ahrens, V. Henson, M. Maybee, and M. Shellenbaum, “The zettabyte file

system,” in FAST 2003: 2nd Usenix Conference on File and Storage Technologies.

Uber

Indirect

Indirect

RevRoot,0

Nam

e

Node,1

Indirect

Indirect

Node,2

Uber

Indirect

Indirect

RevRoot,0

Nam

eNode,1

Indirect

Indirect

Node,2

Indirect

Indirect

RevRoot,1

Nam

e

Node,1

Indirect

Indirect

Node,3


Summary of archiving integrity

10

Security

Integrity Dual Integrity

Goals Measurements

✓ Checks of decrypted data on XML within Treetank

✓ Checks of encrypted data in the cloud and within the transfer based on pages

✓ All integrity structures are persisted


Confidentiality

11

‣ Achieved due to encryption of the data

→ Straightforward

‣ Supporting collaborative workflows

→ Key-Management must take place on a trusted third-party


Versakey

12

M. Waldvogel, G. Caronni, D.Sun, N. Weiler, B. Plattner: “The VersaKey framework: Versatile

group key management” IEEE Journal on Selected Areas of Communication 1999

3

2

1

001

TEK23 3

2

001'

TEK'

23

E0(010)

E010(TEK 0)

E23(TEK 0)


Key Management on the Data

0

01DEK

1

01DEK

2

23DEK

3

23DEK

Key Manager3

2

1

0

23

01

DEK



0

01DEK

1

01DEK

2

23DEK

3

23DEK

E0(010)

E010(DEK 0)

E23(DEK 0)

Key Manager3

2

1

0

23

01

DEK E0(010)

E010(DEK 0)

E23(DEK 0)

Key Manager Key Trails3

2

0

23

01'

DEK'


15


0

01'DEK'

1

01DEK

2

23DEK'

3

23DEK'

E0(010)

E010(DEK 0)

E23(DEK 0)

E0(010)

E010(DEK 0)

E23(DEK 0) Key Manager3

2

0

23

01'

DEK'


Summary of archiving confidentiality

16

Security

Confidentiality VersaKey

Goals Measurements

✓ Encryption itself straightforward

✓ Key handling supports changing client-sets

✓ Exposing & supporting versioning

✓ Different handling of keys (within Key Manager) and updates (within the cloud storage)


Accountability

‣Achieved due to versioning the data→ Tracing of insertions, deletions and modifications

‣Together with signatures on the action

→ Non-Repudiation of modifications

17

“Accountability is the requirement that actions of an entity may be traced uniquely to that entity.”

G.Stoneburner: Underlaying technical models for information technology security

National Institute of Standards and Technology


18

Classic ApproachesDifferential

4

3

2

1

0

Differential

5

4

4

…

0


18

Classic Approaches

Incremental

4

3

2

1

0

Incremental

6

5

4

…

0

Differential

4

3

2

1

0

Differential

5

4

4

…

0


19

Paging the data

Uber

Indirect

Indirect

RevRoot,0

Nam

e

Node,1

Indirect

Indirect

Node,2

Uber

Indirect

Indirect

RevRoot,0

Nam

eNode,1

Indirect

Indirect

Node,2

Indirect

Indirect

RevRoot,1

Nam

e

Node,1

Indirect

Indirect

Node,3

J. Bonwick, M. Ahrens, V. Henson, M. Maybee, and M. Shellenbaum, “The zettabyte file

system,” in FAST 2003: 2nd Usenix Conference on File and Storage Technologies.


Summary of archiving accountability

20

Security

Accountability Adaptive Pagelayer

Goals Measurements

✓ Each modification on the data results in one subtree

✓ Versions consists out of modifications & injected full-dumps

✓ Robustness and consistent read-write-effort


Putting everything together

21

Server

Key Manager

PaaS-Implementation

Client

Treetank

XML

node layer

page layer

storage layer

NoSQL File

Key Trail Propag.

StorageData Store

Key Trails

Data Interf.

Key Mgmt.

Key Trail Propag.

Access Ctrl.

Local Keys

0

01DEK


Workflow of Change on Clientset

22

Ext.Tigger Cloud Storage Key Mg

DeleteClient "1"

POSTKey Trails E

0(010)

E010 (DEK

0 )

E23(D

EK

0 )

3

2

1

0

23

01

DEK


Workflow of Storage

23

Client Cloud StorageSessionbegin

KeycheckChallenge

KeycheckH(H(DEK) ⊕ Challenge)

Validate Hash

[Keys differ]Send Key Trails

Key SyncRecompute Keys

DataSend read/write request

Validate Request

[Hashs differ]Request resend

Data

Sessionclose


XMark, Time

24

Treetank, Designing AVersioned XML Storage

10

EvaluationTreetank is implemented in Java and an ongoing project within the Distributed Systems Group ofthe University of Konstanz. It acts as a platform for multiple concluded and ongoing projects. Forextensibility reasons, Treetank works with flat files as well as with the Berkeley DB Java Edition[bdb]which is also used as the transaction-log for the WriteTransactions.

Our evaluation is divided into two benchmarks. For the first benchmark, we insert XMark[xma02]instances of two different sizes multiple times in our system. Each insertion results in a version. Tokeep the number of nodes per version constant, we remove the data from the old version before startingthe new insertion operation.

Figure 7. Shredding and Serializing of XMark

0 20 40 60 80 100

5e+0

32e

+04

5e+0

42e

+05

revisions

[ms]

XMark serialize, f=0.1XMark serialize, f=1.0XMark shredding, f=0.1XMark shredding, f=1.0

Figure 7 shows the result. The shredding represents the insertion process while the serializing standsfor the retrieval process where the entire tree of one version is retrieved. We see that our systemsscales with the size of the data as well as with the insertion and retrieval time. The write-operationtakes always approximately the same time regardless of the version in which the data is inserted.Regarding the serialization of each version, the page-layer is touched in the same manner which offerssimilar retrieval performance within all versions. The reason for these scalings regarding insertion andretrieval time is our layered architecture which offers the same insert- and access time regardless ofthe requested version.

The second benchmark is the random access adaption of an incremental growing structure:ElementNodes are randomly inserted in the tree either as first-childs or as right-siblings. After eachinsertion, a random move to a node is performed where the next insertion takes place. A commit isperformed after the insertion of a fixed number of nodes (250, 500 and 1000). This operation continuesuntil 1000 revisions are created. This scenario represents the worst-case since no assumption can bemake where the next modification will occur and how it will affect the overall structure. Therefor wechose to use a differential versioning approach within this benchmark to exalt the worst-case scalingwithin the test of our architecture.


Random Insert, Time

25


11

Figure 8. Performing random insert, Time

0 200 400 600 800 1000

100

200

500

1000

2000

5000

2000

0

revisions

[ms] 250 nodes per commit

500 nodes per commit1000 nodes per commit

Figure 8 shows the insertion time. Since the insertion takes place on a constant increasing structure,the dereferencing of the sibling- and parent nodes for adaption and the storage of the new and modifiedpages needs logarithmic effort (since the y-axis is scaled in a logarithmic manner). This fits ourarchitecture since we adapt only the neighborhood of a node and its ancestors for reconstructing thehashes. However, our system is getting more stable over time with an increasing number of versions.

Figure 9. Performing random insert, File

0 200 400 600 800 1000

5e+0

32e

+04

1e+0

55e

+05

2e+0

6

revisions

[byt

es] 250 nodes per commit


The space consumption scales in a similar manner. The append-only approach results as well in alogarithmic adaption of the data regarding each version. This is based on our page-layer which storeson the one hand all pages with nodes where the pointers have to be adapted and on the other handthe corresponding IndirectPages of new and modified NodePages. Since this random-insert operation


Random Insert, Space

26


11

Figure 8. Performing random insert, Time

0 200 400 600 800 1000

100

200

500

1000

2000

5000

2000

0

revisions

[ms] 250 nodes per commit


Figure 8 shows the insertion time. Since the insertion takes place on a constant increasing structure,the dereferencing of the sibling- and parent nodes for adaption and the storage of the new and modifiedpages needs logarithmic effort (since the y-axis is scaled in a logarithmic manner). This fits ourarchitecture since we adapt only the neighborhood of a node and its ancestors for reconstructing thehashes. However, our system is getting more stable over time with an increasing number of versions.

Figure 9. Performing random insert, File

0 200 400 600 800 1000

5e+0

32e

+04

1e+0

55e

+05

2e+0

6

revisions

[byt

es] 250 nodes per commit


The space consumption scales in a similar manner. The append-only approach results as well in alogarithmic adaption of the data regarding each version. This is based on our page-layer which storeson the one hand all pages with nodes where the pointers have to be adapted and on the other handthe corresponding IndirectPages of new and modified NodePages. Since this random-insert operation


Next Steps

27

Dual Integrity✓Implementation of XML-check

‣ Improving performance within cryptographic checksums

‣ Extending with signatures

‣ Introducing page-based integrity-check

VersaKey✓Implementation of encryption

✓Versakey implementation

‣ Access to old revisions within new client-joins


Next Steps, .cont

28

Versioning✓Implementation and first results

✓Analysis of read-/write-effort

‣Working directly on Versioning

Framework✓ Client partly released

✓ Key Management

‣ Server


Thanks for your attention…Questions?

(or even better: Suggestions!)

29

Sebastian GrafDistributed Systems GroupUniversity of [email protected]




Publications1. S.Graf, M.Kramis, M.Waldvogel, "Distributing XML with Focus on Parallel

Evaluation" in Proceedings of the 6th Workshop on DBISP2P2. S. Graf, L. Lewandowski, and M. Waldvogel, “Integrity assurance for

RESTful XML,” in Proceedings of the 7th Workshop on Web Information Systems

3. S. Graf, M. Kramis, and M. Waldvogel, “Treetank: Designing a versioned XML storage,” in XMLPrague’11, 2011.

4. S.Graf, V.Zhouldev, L. Lewandowski, and M. Waldvogel, “Hecate, managing authorization with restful xml,” in Proceedings of the 2nd Workshop on RESTful Services,

5. S. Graf, S. K. Belle, and M. Waldvogel, “Rolling boles, optimal XML structure integrity for updating operations,” in Poster on the 20th International Conference on World Wide Web, ser. WWW ‘11.2011

6. Trailing Versioning (joint work with Marc Kramis, in progress)7. Versakey on distributed storage (in planning)

30


Date post:	13-Dec-2014
Category:	Technology
Upload:	ecows2011
View:	905 times
Download:	1 times