Strangely enough, the Semantic Web has fallen behind the rest of the Web in terms of security. TLS is not in use currently for the majority of URIs on the Semantic Web, and this leads to a number of potential attacks on the network, web, and even semantic level. After explaining the necessity and arguments over the TLS on the Semantic Web, we point out security and privacy aws in WebID+TLS and recent other proposed Semantic Web standards at the W3C. We propose a new kind of attacker, a semantic attacker, that attacks inference procedures. Lastly, we propose alternatives, including the use of modern cryptography that prevent attacks by virtue of using TLS, and how W3C standards such as the W3C Web Cryptography API and IETF OAuth can solve the use-cases needed by the Semantic Web.
is almost no academic work on security in terms of the Semantic Web [
First, we review related literature on security, showing how this is the rst
work to look at the security of the Semantic Web itself in Section 2. Then
security is de ned in Section 3 via the classical de nition of semantic security from
provable security, and we introduce the symbolic model for protocol analysis [
In general, the dependency of data retrieval and inferences based on insecure Semantic Web data can lead to attacks on trusted semantics of the Semantic Web itself. In Section 7, we demonstrate that this does not have to be the case: A number of standards from the IETF and W3C can be used to upgrade the Semantic Web to modern security-best practices, leading to a secure Semantic Web. 2
There has been a large amount of previous research on the security of the Semantic Web, yet none of it looks at the security properties of the Semantic Web infrastructure itself. In general, there have been three streams of research on security on the Semantic Web: Semantic Web policy languages for access control, Semantic Web ontologies for cybersecurity, and problems with privacy in publishing Semantic Web data.
should not be used also for encryption in general without changes to the underlying algorithms, as it introduces vulnerabilities [26]. 2.1
By far the largest amount of research has been done on access control languages
for the Semantic Web, such as Rei [
Another approach is to classify the kinds of attacks and security vulnerabilities
into a traditional OWL-based Semantic Web ontology [
While publishing open data using Semantic Web standards may appear to be
a public good, even innocuous public data such as road data may serve to
deanonymize users and so reveal personal or sensitive data, ranging from whether or
not a property is abandoned to enabling the discovery of sexual preference [
2.4
Although previous research has noted on a very high-level \securing RDF is
much more challenging" than traditional XML and HTML-based infrastructure
as \we also need to ensure that security is preserved at the semantic level" [29],
so far there is no research in this direction that go beyond the mere \idea of
semantic web security standardization" [
What is security? Security is de ned in terms of an attacker(or \threat model").
Informally, if a message is encrypted, an attacker can not discover the original
message without a secret key that the attacker does not have. The original
message is called the \cleartext" (M ) and the message encrypted by the secret
key is called the \ciphertext" (C). In terms of encryption and decryption, it is
E(M ) ! C and D(C) ! M . To de ne this more precisely involves de ning the
property of semantic security, as de ned by Goldwasser and Micali: \Whatever is
e ciently computable about the cleartext given the ciphertext, is also e ciently
computable without the ciphertext" [
Separable from security and less rigorously de ned is privacy. Privacy is typically de ned relative to an anonymity set, i.e. requiring the entity not being identi able within a set of entities (the anonymity set) by an adversary. Privacy can be phrased in terms of unlinkability, namely that an entity can not be linked to their actions (in this context \link" means a information-theoretic reduction of the anonymity set, an entirely di erent notion than a hyperlink or link between RDF documents). On the Web, users are entities whose primary action is visiting a web-site, where a website is de ned by an origin, where the origin is the domain name without the scheme, i.e. origin.org without the http scheme. The linking (i.e. \tracking") of users between origins violates their privacy. On the Web, the privacy and security boundary is given by the same origin policy : Any code or data on the user's browser is restricted by origin. So a cookie
from http://origin.org should be accessible from https://origin.org and any subpages such as http://origin.org/page.html, but should not be accessible from http://origin2.org, and a user visiting the latter should not be connected by a third party (such as the website themselves are a third-party advertising bureau). The same goes for any state changes in the browser, including information in localStorage in the browser. 4
Transport Layer Security (TLS) is the well-known IETF standard for encrypting content transmitted over HTTP.5 In addition to encrypting data sent over HTTP, the server that delivers the HTTP message can be authenticated with a certi cate (a public key attached to its domain name), so that the origin can be proven to have sent the message.6 Users do not authenticate to servers using TLS as speci ed by the IETF, but only the web site authenticates.
This means that resources hosted on URIs without TLS are vulnerable to having their content intercepted, which is equivalent to the adversary visiting the site rather than the user. Note the adversary can remove any additional messages (such as HTTP headers or certi cates that are in plaintext) and replay the message without those messages. Worse, the content could be altered by an attacker without the possibility of a user knowing that this is the case, giving the user a fake resource.
Why not use TLS on the Semantic Web to preserve security and privacy?
When a URI is enabled with TLS, the URI uses HTTPS as its scheme in the URI
rather than HTTP. TLS was called informally \SSL" (Secure Sockets Layer), and
HTTP with TLS enabled adds a \S" for historical reasons to become HTTPS.
Unfortunately, the RDF speci cation states that HTTP and HTTPS URIs are
not the same: \Two IRIs are equal if and only if they are equivalent under
Simple String Comparison ... further normalization MUST NOT be performed
when comparing IRIs for equality" [
One could claim a Semantic Web URI is only a name and so the usage of
TLS is not required. If there is no access to the content of the URI, URIs are the
same as any other arbitrary string in a knowledge representation language, and so
using HTTP or HTTPS has no e ect on the formal semantics that determine the
inferences that result from a Semantic Web reasoning engine. There would hold
5 TLS 1.2 is available at https://tools.ietf.org/html/rfc5246, with TLS 1.3 being under
development at https://tlswg.github.io/tls13-spec/.
6 In reality, the server proves it has a key validated by a Certi cate Authority that
the browser accepts. There is a long-standing issue that Certi cate Authorities can
create certi cates for domains they do not own.[
If TLS is not used on a origin, a network attacker may perform a number of attacks. The goal of the network attacker is to gain access to the plaintext of the resource retrieved from an origin. The rst attack is trivial: If all data is sent over using HTTP, then the attacker can intercept the HTTP tra c. Also, an attacker can deliver whatever data they want to the unsuspecting user without detection due to the origin not being authenticated. For example, if one is retrieving open government data in Linked Data about the expenses given by the French government for the upkeep of the Ei el Tower and the revenue created by tourists visiting the Ei el Tower, and an attacker wanted to maliciously to prove to the French government that the Ei el Tower was a bad investment, then the attacker could simply intercept the HTTP tra c hosted at the website and so change the numbers in the government data. It would be impossible for a user, such as a journalist, to tell if their HTTP tra c was tampered with by an attacker. This is a very easy attack that can be done using open-source tools such as wireshark 7 and sslstrip.8
Opportunistic encryption that automatically upgrades HTTP to HTTPS can
be done by using the W3C Upgrade Insecure Requests speci cation where a
server requests that a HTTPS URI be used if possible via a HTTP Header
[33]. The server can then use a HSTS header to prevent any downgrade attacks
that stripped the `S' o the HTTPS in a URI [
However, the attack is that the Upgrade Insecure Requests headers are delivered over HTTP, any attacker actively watching the unencrypted HTTP redirection can simply strip those headers to prevent upgrade to HTTPS and allow the HTTP content to be attacked by sending the same request, but stripped of the header. This allows the attacker to impersonate the user and intercept the unencrypted resource. So to just keep using HTTP URIs and hope for the best does not solve the problem. 4.2
So why should Linked Data use HTTPS rather than HTTP URIs? URIs are also
exposed to HTML links, and thus Tim Berners-Lee is rightfully worried that a
switch to HTTP violates his principle that \Cool URIs Don't Change"11 and
so the adoption of HTTPS would break existing links. Berners-Lee goes even
further:\Put simply, the HTTPS Everywhere campaign taken at face value
completely breaks the web. In a way it is arguably a greater threat to the integrity
for the web than anything else in its history"[
Unfortunately, even if TLS is used correctly on the network level, there may be
attacks on the level of the Web application by a Web attacker [
RDF URIs in 2017 (Retrieved on May 15th 2017). 14 https://www.wired.com/2017/01/half-web-now-encrypted-makes-everyone-safer/ in detail at WebID+TLS in detail and then give an overview of security issues in a wider emerging stack of standards for distributed social networking from the W3C based on the Semantic Web. 5.1
Background There has been some awareness of TLS in the Semantic Web
community due to the WebID+TLS e ort to use URIs as identi ers for people, with
the evocative goal of creating decentralized social networking applications [27].
The goal of WebID is that each person can have their own personal URI that
maintains their identity on the Web and from which their personal data, given
by RDF statements, can be retrieved. Variations on WebID+TLS have tried
adding access control in order make sure that personal data can only be given to
explicitly authorized agents rather than given to absolutely anyone who issues a
HTTP request [30]. In WebID+TLS, a user generates a client certi cate using
asymmetric cryptography (which contains a signature given by a private key
stored in TLS keystore, as well as a link to their WebID URL) that is stored by
the browser.15 The public key can then be posted to the URI of their WebID
URI. When a user wishes to authenticate themselves and authorize the transfer
of their own personal RDF data from a site (called the identity provider on a
distinct origin, following the terminology used in OAuth [
If an attacker wants to track a user, the attacker can query and ask for a client certi cate. A malicious attacker from one origin who wanted to re-identify a user on another origin could simply install a client certi cate on the malicious origin and ask for the certi cate again on another origin. Worse, the current userexperience around both generating and selecting client certi cates is confusing, and neither the installation nor usage of client certi cates by HTML is standardized, so the usage of client certi cates in HTML depends on ad-hoc browser behavior dependent on a particular idiosyncratic per-browser interpretation of a MIME-type. 16
WebID+TLS is also based on out-of-date browser cryptography that is being deprecated by the browsers themselves. Even if the user does end up successfully identifying themselves with a client certi cate, current browsers use the insecure MD5 hash function in the signed client certi cate. MD5 has proven to not be collision resistant, which means that an attacker can generate a fake client certi cate whose signature can be veri ed using the public key of a user even though the attacker does not have private key of the user [31]. In this way, a user can be impersonated by an attacker.
Defenses Due to these security and privacy issues, browser vendors are currently deprecating keygen from HTML and client certi cates handling from the application layer, which will mean WebID+TLS will stop working. Although the Semantic Web community has yet to engage with it, modern cryptographic 16 https://groups.google.com/a/chromium.org/forum/#!msg/blink
dev/pX5NbX0Xack/kmHsyMGJZAMJ
primitives are now provided by the W3C Web Cryptography API.17 Getting
rid of passwords can be done via authentication by hardware tokens (or other
authenticators) by the W3C Web Authentication API, which is designed both
to not violate the same-origin policy (i.e. keys di er per origin) and use modern
cryptographic primitives such as ECDSA [
Part of the problem is a confusion over the layers of the Web: TLS is a network-level protocol, not an application level protocol. For example, interrupting a network-level TLS handshake in order to start a user-centric identity and authentication protocol in WebID+TLS is bad design insofar as it mixes the application-level concept of an \a person's identity" with the network level that just ships bits around. To some extent, the problems with the use of TLS on th e Semantic Web is that network level information (whether a HTTP connection is encrypted using TLS or not) is exposed on the level of a URI used in a Semantic Web applications, including but not limited to WebID+TLS. Web applications should use TLS to access origins but not use messages in the TLS ow such as certi cates outside the network layer.
Instead, messages should be sent on the application level, as done in modern
authorization protocols such as OAuth [
Although a complete analysis of these standards would require more space, the precedent set by WebID+TLS is troubling insofar as other W3C Semantic Web standards and proposed standards do not take into account adversaries or modern cryptography as well. To continue our analysis of Solid, Solid allows a user after authentication via WebID+TLS to read and write data using HTTP GET and POST verbs with additional. However, again if a local POST is done to a HTTP origin rather than a HTTPS origin, all the attacks in Section 4 apply as the request and any Link headers will be unencrypted. Solid uses W3C Linked Data Noti cations18 to share RDF data using either the Linked Data Platform or a publish-subscribe model following the W3C WebSub Recommendation.19
While Linked Data Noti cations requires signing data and a whitelist, but
does not specify how either can be done. In terms of signatures, proposed
stan17 https://www.w3.org/TR/WebCryptoAPI/
18 https://www.w3.org/TR/ldn/
19 https://www.w3.org/TR/websub/
dards such as Linked Data Signatures 20 repeat the mistakes of XML Digital
Signatures: There is a complex canonicalization algorithm that does not specify
how to resolve problems noted by earlier research [
WebSub claims to support digital signatures for authentication to prevent Sybil attacks (an attack where, due to lack of mutual authentication in publishsubscribe, server is overwhelmed by client requests or a server overwhelms a client with requests), but does not use asymmetric digital signatures, instead relying on a shared secret to create a HMAC (i.e. symmetric cryptography). Yet the shared secret is simply sent along optionally with the rst message, and given a server must accept re-requests (possibly with new shared secrets), unless TLS connections are used on both the client and server in WebSub, the shared secret may be intercepted or re-set at any time. WebSub has only the callback URL of the subscriber require HTTPS, and the initial shared secret is sent back not with the callback URL but by the rst subscription request. Lastly, the broken SHA-1 hash function is supported for calculation of the HMAC. These problems of authentication in scalable pub-sub systems are known to the research community, and solutions have been proposed relying on identity-based cryptography that are not used in WebSub [28]. Thus, it can be shown that the problems of authentication and the failure to use well-known cryptographic techniques continues to be a problem in further proposed Semantic Web standards. 6 6.1
While earlier attacks are generic results of either the lack of network-level encryption in TLS or bad protocol design, the Semantic Web enables a new class of attacker speci c to RDF. In detail, this Semantic attacker has the goal of altering inference procedures. This kind of if the Semantic attacker builds on attacks on the network, and possibly the Web level, to compromise the RDF triples that an inference procedure depends on and so maliciously alter them, therefore changing results of the inference procedure. An attack is semantic insofar as it depends on the semantics of an inference procedure, although it may 20 https://w3c-dvcg.github.io/ld-signatures/ 21 https://json-ld.github.io/normalization/spec/ 22 https://tools.ietf.org/html/rfc7515 but does not have to alter the semantics of the inference procedure itself.23 Due to the distributed nature of resources on the Semantic Web.only gets worse if the Semantic Web application uses the \follow your nose" algorithm used in some Linked Data applications. 6.2
At any point data was retrieved from RDF statements given by a HTTP URI that does not use TLS, then the attacker can simply change the data and so in uence the Semantic Web inference engine. An inference procedure I is given as depending on a set of x triples R = R1 ^ R2 ^ :::Rx such that new triples S are produced by the inference procedure (I(R) ! S). If an attacker knows the plaintext, they can alter it arbitrarily, such that plaintext R1 ! Ra. Therefore, one or more malicious triples can be inserted R2 = R1 ^ Ra ^ :::Rx and the inference procedure will produce a result that is at least partially under the control of the attacker, I(R2) ! S2 where S1 6= S2.
For example, if a Linked Data-aware application was trying to determine if a person belonged to a particular class, such as the class of all terrorists. If a malicious semantic attacker noticed that one of the resources that the inference procedure depended on did not use TLS, as would be the case if the de nition of a terrorist was hosted in a RDF Schema given by non-TLS website (such as the majority of non-W3C Semantic Web vocabularies). In this case, the semantic attacker would intercept and alter the de nition of terrorist in the OWL le by removing a triple that stated that the crime must be classi ed as political by virtue of a certain list of government-approved de nitions. In this way, a person who did a simple robbery could be classi ed as a terrorist by Semantic Web inference engine operating o of insecure resources in a FBI Fusion Center. If further triples were removed, all sorts of people could be mistakenly classi ed as a terrorists by a correctly operating inference engine using poor data. 6.3
Given that Semantic Web reasoning in Linked Data depends on having trusted information, the entire process of reasoning and information retrieval must use TLS for every URI if the Semantic Web application is to be trusted. The only exception to this is that if the URI is not accessed, but merely used as an identi er. However, in this case the only trusted Semantic Web inference process is one that does not depend on the HTTP infrastructure. If any triples are derived from Web-level protocols, these protocols should also maintain their security properties and use TLS properly to prevent attacks. 23 Note that this is out of scope, as an adversary could simply add a triple to make a previously-valid OWL inference invalid, and so leaving only an RDF(S) inference possible.
Network and semantic attacks on the Semantic Web could be xed if TLS was
used on the Semantic Web. The only problem is outdated Semantic Web
speci cations. Shouldn't W3C Recommendations, rather than being considered as
religious texts, be xed to keep up with modern security? Although the RDF
speci cation lack a way to discuss URIs themselves [
The future of HTTPS is also bright: TLS has improved and became easier
to deploy as well, with certi cates available for free and the protocol itself faster
and more secure. For example, TLS version 1.3 24 corrects a number of problems
in TLS 1.2 such as an unclear state machine and attacks on TLS
authentication [
Simply using the modern standards used by the rest of the Web such as
OAuth [
Given that TLS certi cates are free and that the Semantic Web has still not reached widespread usage enough to argue that moving from HTTP to HTTPS would break real-world applications, Semantic Web tools and Semantic Web vocabularies should switch as soon as possible to using TLS-encrypted HTTPS URIs. There is no excuse not to use encryption if you want users to trust the Semantic Web. Luckily, most of the attacks described here as potential attacks as the underlying W3C standards used in the Semantic Web still have not been widely deployed and remain mostly in the realm of academia, and thus there are limited real-world incentives to attack Semantic Web-based infrastructure. Regardless, both open data and personal data require security, and personal data in addition also requires privacy. The building block for both security and privacy is proper usage of (at least) TLS and more complex cryptographic protocols on the level of applications. Otherwise, the use of the Semantic Web will likely be replaced by technology, such as blockchains, that takes security on board in its design. 8
This work is funded in part by the European Commission H2020 European Commission through the NEXTLEAP Project (Grant No. 6882). 25. Sylvia Osborn. Mandatory access control and role-based access control revisited.
In Proceedings of the second ACM workshop on Role-based access control, pages 31{40. ACM, 1997. 26. Kenneth Paterson, Jacob Schuldt, Martijn Stam, and Susan Thomson. On the joint security of encryption and signature, revisited. Advances in Cryptology{ ASIACRYPT 2011, pages 161{178, 2011. 27. Henry Story, Bruno Harbulot, Ian Jacobi, and Mike Jones. FOAF+SSL: Restful authentication for the social web. In Proceedings of the First Workshop on Trust and Privacy on the Social and Semantic Web (SPOT2009), 2009. 28. Muhammad Adnan Tariq, Boris Koldehofe, and Kurt Rothermel. Securing brokerless publish/subscribe systems using identity-based encryption. IEEE transactions on parallel and distributed systems, 25(2):518{528, 2014. 29. Bhavani Thuraisingham. Security standards for the semantic web. Computer
Standards & Interfaces, 27(3):257{268, 2005. 30. Sebastian Tramp, Henry Story, Andrei Sambra, Philipp Frischmuth, Michael Martin, and Soren Auer. Extending the WebID protocol with access delegation. In Proceedings of the Third International Conference on Consuming Linked DataVolume 905, pages 99{111. CEUR-WS. org, 2012. 31. Xiaoyun Wang and Hongbo Yu. How to break MD5 and other hash functions. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 19{35. Springer, 2005. 32. K Krasnow Waterman and Samuel Wang. Prototyping fusion center information sharing; implementing policy reasoning over cross-jurisdictional data transactions occurring in a decentralized environment. In Technologies for Homeland Security (HST), 2010 IEEE International Conference on, pages 63{69. IEEE, 2010. 33. Mike West. Upgrade Insecure Requests, 2015. https://www.w3.org/TR/upgradeinsecure-requests/.