![All tasks completed
• T1.1 — Communication architecture [M1-M6]
• T1.2 —Vulnerability-tolerant channels [M1-30]
• T1.3 — Protected service provisioning [M1-30]
• T1.4 — Route monitoring [M1-30]
• T1.5 — Multi-path communication [M1-30]
WP1 — 2018-09 » 24](https://image.slidesharecdn.com/safecloudwp1overview-180927142702/85/SafeCloud-Secure-Communication-solutions-WP1-overview-24-320.jpg)
![All deliverables completed
• D1.1 — Private communication middleware
architecture [M6; IN-ID]
• D1.2 — First version of the private communication
middleware components [M18; IN-ID]
• D1.3 — Final version of the private communication
middleware [M30; IN-ID]
WP1 — 2018-09 » 25](https://image.slidesharecdn.com/safecloudwp1overview-180927142702/85/SafeCloud-Secure-Communication-solutions-WP1-overview-25-320.jpg)
Uploaded byMiguel Pardal
SafeCloud Secure Communication solutions (WP1 overview)
The document outlines the objectives and solutions for enhancing secure communication within the SafeCloud platform, focusing on middleware services that protect data privacy and security during cloud communications. It describes various secure communication solutions, including vulnerability-tolerant channels, protected channels, and route-aware channels, while emphasizing the importance of robustness against advanced adversaries. The achievements and scientific contributions of the SafeCloud project are also summarized, highlighting completed tasks, deliverables, and evaluations of implemented solutions.
More Related Content
Similar to SafeCloud Secure Communication solutions (WP1 overview)
SafeCloud Secure Communication solutions (WP1 overview)
- 1. September 2018 Miguel Pardal INESC-ID miguel.pardal@tecnico.ulisboa.pt WP1:Secure Communication
- 2. Outline • Objectives andsummary • Secure communication solutions • Achievements WP1 — 2018-09 » 2
- 3. WP1 — objectivesand summary • Provide middleware services to improve the privacy and security of cloud communications in the SafeCloud platform • Protect data when downloading (and uploading) from the cloud • Provide same properties as secure channels: confidentiality, integrity, authenticity • But assuming more powerful adversaries that may break some assumptions that make existing channels secure WP1 — 2018-09 » 3
- 4. Standard secure channel •The most adopted protocol is SSL/TLS • HTTPS = HTTP overTLS WP1 — 2018-09 » 4
- 5. How can aTLSchannel become insecure 1. A vulnerability appears in one component 2. An old vulnerability in one of the components is not fixed 3.There is an unknown (0-day) vulnerability in one of the components 4.There is a vulnerability that seems to be impossible to exploit, but that can be exploited by a strong adversary, e.g., a nation state WP1 — 2018-09 » 5
- 6. Specific threats • Weakcryptographic components • DES, RC4, MD5, SHA-1 • Service identification • Well-known ports are vulnerable to port scanning and fingerprinting • Route attacks • Man-in-the-middle attacks • Attacker intercepts communication • Route hijacking • Traffic may be deviated and then eavesdropped WP1 — 2018-09 » 6
- 7. Summary of securityrequirements • For the attacker to break the confidentiality, privacy or integrity of a secure channel, he must: (i) find a vulnerability in the channel (ii) gain access to the endpoint machines (iii) intercept communication path WP1 — 2018-09 » 7
- 8. SafeCloud solutions Secure Communication WP1— 2018-09 » 8
- 9. Middleware requirements • Twoforms of communication: • Machine-to-cloud and • Cloud-to-cloud • Unicast communication between two endpoints • Endpoints: clients, machines in clouds • We do not envisage the need to protect data privacy in multicast, anycast or broadcast communications • Connection-oriented • Similar to protocols likeTLS overTCP • Implemented at application layer of the OSI model • Difficult to deploy mechanisms at lower layers in the Internet WP1 — 2018-09 » 9
- 10. SafeCloud platform components WP1— 2018-09 » 10
- 11. Secure Communication Solutions •SC1: vulnerability-tolerant channels • vtTLS • Multiple cryptographic layers • SC2: protected channels • sKnock • Port knocking • SC3: route-aware channels • Premium (Machete + Darshana) • Multi-path and route monitoring WP1 — 2018-09 » 11
- 12. Core insight • Makesecure channels more robust by leveraging diversity in multiple ways: • SC1 • Cipher suites • Protocol implementations • SC2 • Access controls • SC3 • Communication paths • Route monitoring techniques WP1 — 2018-09 » 12
- 13. SC1: vulnerability-tolerant channels WP1— 2018-09 » 13 Combine several cryptographic suites
- 14. SC2: protected channels WP1— 2018-09 » 14 Add multiple layers of access control
- 15. SC3: route-aware channels WP1— 2018-09 » 15 Use multiple paths, monitor geo-bounds
- 16. Addressing security requirements withSafeCloud communication solutions Attacker must: SC1: vulnerability- tolerant channels SC2: protected channels SC3: route-aware channels (i) find a vulnerability in the channel (ii) gain access to the endpoint machines (iii) intercept communication flow SC – Secure Communication solution
- 17. Solutions can becomposed • Example: SC1 + SC2 = vulnerability-tolerant channels + protected channels = vtTLS + sKnock = vulnerability-tolerant, multiple protection channel WP1 — 2018-09 » 17
- 18. Server is protectedby a firewall WP1 — 2018-09 » 18
- 19. Client can openthe firewall with an authenticated packet WP1 — 2018-09 » 19
- 20. Add first layerof protection WP1 — 2018-09 » 20
- 21. Add additional layerof protection WP1 — 2018-09 » 21
- 22. Client and serverexchange data securely WP1 — 2018-09 » 22
- 23.
- 24. All tasks completed •T1.1 — Communication architecture [M1-M6] • T1.2 —Vulnerability-tolerant channels [M1-30] • T1.3 — Protected service provisioning [M1-30] • T1.4 — Route monitoring [M1-30] • T1.5 — Multi-path communication [M1-30] WP1 — 2018-09 » 24
- 25. All deliverables completed •D1.1 — Private communication middleware architecture [M6; IN-ID] • D1.2 — First version of the private communication middleware components [M18; IN-ID] • D1.3 — Final version of the private communication middleware [M30; IN-ID] WP1 — 2018-09 » 25
- 26. Scientific work • Graduations •5 students at INESC-ID • 10 students atTUM • Publications • 4 conference papers • 2 workshop papers • Credit to the students for all their great work! WP1 — 2018-09 » 26
- 27. • SC1: vulnerability-tolerantchannels • vtTLS evaluation • Evaluated: handshake, data transfer overhead • SC2: protected channels • sKnock • Evaluated: latency, scalability • SC3: route-aware channels • Premium (Machete + Darshana) • Evaluated: best number of multiple paths, multi-homing • Evaluated: thresholds, false positives, false negatives Testing and Evaluation WP1 — 2018-09 » 27
- 28. • github.com/safecloud-project/vtTLS • github.com/safecloud-project/sKnock •github.com/safecloud-project/Premium Contributions to open-source community WP1 — 2018-09 » 28
- 29.
- 30. Conclusion • SafeCloud madesecure channels more robust by leveraging diversity in multiple ways • Solutions can be combined • Better security: • Between endpoints and clouds • Between people and the services they use • Both for personal and corporate data WP1 — 2018-09 » 30
- 31. Thank you! WP 1:Secure Communication