Interoperability Challenge of Certified Communication Systems via Internet Marina Buzzi, IIT-CNR, marina.buzzi@iit.cnr.it Francesco Gennai, ISTI-CNR, francesco.gennai@isti.cnr.it Claudio Petrucci, Agid, petrucci@agid.gov.it egose 2017, 4-7 Sept, ITMO University, St.Petersburg
Agenda Introduction Motivation Certified Communication Systems (CCS) Related Work The Model: Generic CCS (GCCS) Idea Logical scheme Main functions Conclusion
Motivation Developing the full potential of Information and Communication Technology (ICT) can greatly innovate society in a number of sectors ecommerce, egovernment, ehealth, Lack of interoperability and adherence to international standards heavily impacts on economic growth and competitiveness
Certificated Communication Systems (CCS) Several countries have adopted systems to certify communications via Internet CCSs (Certified Communication Systems): Certified Electronic Mail (CEM) systems based on smtp protocol (simple message transfer protocol) Certified systems based on the Hypertext Transfer Protocol (HTTP)
CCS Systems European CCS systems rely on different protocols and formats Interoperability is necessary to enable the exchange of messages between users of different domains Certified/Registered Electronic Mail (CEM/REM) systems (SMTP) PEC (Posta Elettronica Certificata, Italy) DE-MAIL (German DeMail) SI Post (Moja.posta.si Slovenia) AU-DSS (Austrian Document Delivery System) Digital Post in Denmark Sikker Digital Post in Norway Mina meddelanden in Sweden Web-based systems: 1) Universal Postal Union (UPU) developed Postal Registered Electronic Mail Prem 2) PEPPOL (Pan-European Public eprocurement On-Line), for document exchange between Public Administrations, funded by EU
Generic CCS model Challenge: to build worldwide interoperability between certified communication systems The Generic CCS model (GCCS): an open solution to redefine closed CCS systems
CCS CCS systems certify the source of a message Today this is also possible thanks to standard mechanisms available on the Internet SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance), Requirements of certification often address also specific needs internal to countries (governmental) "closed" CCSs are different from each other, although solve exactly the same class of problems
CCS identification of the source not of the sender (satisfied by EIDAS specification, eidas electronic IDentification, Authentication and trust Services for electronic transactions) server-user acceptance notification delivery notification server-server notification email communications moving between different providers in the same CCS infrastructure
Generic CCS Idea: to publish a generic specification for describing CCS systems usable as common rules for immediate interoperability between worldwide Providers To illustrate this model we focus on Certified Email Systems (CEM)
GCCS Model Open, interoperable and scalable solution while minimizing the impact on existing infrastructure To this aim the DNS (Domain Name System) is used to store information for the GCCS functioning common practice to take advantage of the attributes of the TXT record of the DNS SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance) specifications Advantage: DNS technology can be used to immediately spread protocol information without the need to define new DNS records, keeping the current DNS structure
Related Work Certified e-mail systems showed usability problems (use of public/private key, certificates, etc.) In 2001, to simplify user interaction and reduce costs, a centralized approach has been proposed to provide cryptography as a network service (Dean et al.) client must trust the cryptoserver (which keeps users private keys) Garfinkel et al. (2005) surveyed 400 vendors via Amazon most participants did not know secure email Segeberg (2009) created plugin for making a certified email system easy to interact Bobba et al. (2009) developed a secure mailing list (Secure Email List Services) providing encryption via proxy
Related Work The European Commission supported the creation of a gateway between different Certified Delivery systems Previous actions for reaching cross-border interoperability have mainly focused on bridging existing systems Within this framework the European Telecommunications Standards Institute (ETSI) defined the Technical Specification Registered Electronic Mail (REM) An ETSI Task Force was set up REM Interchange: e-mail Interchange between Registered E-Mail (REM) systems based on different transmission protocols (2011) To assure the conformity to the eidas Regulation, a new document "Rationalized structure for Electronic Signature Standardization" has been published (2015)
Related Work A comparison of policies to fuel certified communication between public sector and citizens in the Scandinavian countries has been carried out by Jansen et al (2016) Similar solutions in comparable contexts Three countries applied different degrees of coercion ranging from mandatory (Denmark), to nudging (Norway), to voluntary (Sweden) Member States have the possibility of applying more or less restrictive policies Voluntary base was adopted slowly while the mandatory achieved better results fast very important since digitalization of communication lowers costs and improves efficiency
Challenge How to solve CCS interoperability problem without referring to any specific systems in a way that is general enough to redefine any certified communication system
Trusted third party Existing Certified e-mail Providers deliver systems that rely on a trusted third party unsuitable for cross-border application, limit the interoperability (Jansen et al.) Paulin & Welzer propose a certified e-mail system that does not rely on a trusted third party for fair non-repudiation of receipt a protocol splits an encrypted message into a chain of parts, which the recipient gradually acquires, generating proof-of-receipt for each individual part It covers only a part of the problem, since it misses the description of a mechanism for abstracting the specific CEM systems in a general public profile
Generic CCS (GCCS) Conceptual openness it specifies a generic model and attribute language to redefine the current CCS functionally equivalent in terms of functions, reliability and degree of security to the original taking advantage of IETF standards Each CEM system could be described by a specific CCS profile It is necessary to create a set of public standard Generic CCS profiles profiles A, B, C, etc. with different levels of security and functions Any provider adopting one of these public profiles can interoperate with any providers adopting the same level of profile without any agreement
GCCS A set of properties that CEM systems would satisfy to be incorporated in the GCCS policy are (Tauber): Non-repudiation of origin (NRO) if the protocol offers evidence against the false denial of having originated the message Non-repudiation of receipt (NRR) if the protocol provides evidence against the false denial of having received the message Non-repudiation of submission (NRS) if the protocol provides evidence against the false denial of having submitted the message Non-repudiation of delivery (NRD) if the protocol provides evidence against the false denial of having delivered the message
GCCS We propose to define a specification using simple language to define a list of attributed value pairs and by adding the definition of some email headers These pairs (attribute, value) are added into TXT records of DNS systems, according to RFC 1464
GCCS Taking advantage of Internet "mechanisms (DNSSec, TXT DNS records, etc.) is possible to define a set of generic abstract rules to describe the behavior of each existing CCS system By using the GCCS (Generic Certified Communication System) rules it is possible to define a generic interface to each of the worldwide CCS systems (national/ government) enabling interoperability between them In the case of two generic ISPs, the independent adoption (not coordinated) of a system compliant with a GCCS profile would mean that the communication between users belonging to these providers would be of the CCS type
GCCS The GCCS defines the technical rules through which each provider declares (via DNS TXT record) Features, level of security (X.509 certificates, CA, DNSSec, etc.), protocols (SMTP, HTTP), timeouts, etc. Profiles establish a minimum level (of functionality, security, etc.) that a particular provider must support in order for a communication to be considered belonging to this CCS type existing CCS systems may be "mapped" on GCCS systems, through the definition of their own functional and security profile
Old CCS CCS DNS Old CCS GCCS Gateway... Old CCS GCCS communication Record MX, TXT National CCS attributes Certificates, public keys CCS Internet GCCS communication Old CCS DNS Record MX, TXT National CCS attributes Certificates, public keys CCS Old CCS CCS GCCS Gateway... Old CCS
GCCS New CCS servers conforming to a GCCS profile are able to communicate directly Old CCS servers (governmental) communicate through a GCCS gateway All CCS servers perform DNS Queries and rely on standard Internet Communications The gateway is able to convert email formats and notifications between a national CCS and external GCCS In alternative it would be possible to identify a common GCCS profile able to try to incorporate all CEM systems
Sender s PEC domain Func,onal schema of PEC 1 message wri,ng, connec,on to the provider 2 user iden,fica,on, formal and security check 4 envelope and sending Receiver s PEC domain 5 origin, integrity, formal and security check 3 Acceptance no,fica,on 7 delivery in the mailbox (electronic address of the receiver) 6 take in charge receipt 8 sent delivery receipt 9 message reading
GCCS A policy can be defined with attributes, defining conditions in incoming and outgoing flows some degree of degradation can be accepted according to the organization/user needs and communicated to the end users The profile can incorporate this policy to establish which one of the declared features and functions (TTP, what TTP certifies, time-outs, etc.) are mandatory or optional and what actions the server has to perform in case one of the mandatory features is not present in the destination or originator GCCS system
Trusted third party (TTP) In the trusting models a "trusted third party (TTP) certifies the participating parties and ensure compliance with common management and operation policies Certification Authority Technology behind the trusting model of a CA -- consisting of public-key signature algorithms, X509 certificates and other technical specifications -- can work even in the absence of the Certification Authority (TTP), obviously with different results from a semantic point of view (trusting) Technology is a basis on which to optionally activate a system of electronic signatures "trusted" throughout the introduction of a CA In the same way, the GCCS model can run without the need of a TTP in a less trusting fashion
Generic CCS system Each provider publishes its working profile (including the security policy) on the DNS (txt record) The GCCS server would be able to: Determine whether a destination domain is a GCCS or standard Internet email Identify the provider of a GCCS domain Identify the profile of the GCCS Provider (working attributes of timeouts, message and notification format) Obtain public keys of any other GCCS provider Obtain any e-mail addresses needed for operational purpose (e.g., e-mail addresses for server-to-server acceptance notifications)
Generic CCS system Each CCS must publish its own public key in the DNS The provider must publish their list of managed CCS domains (record TXT) These functions could be certified by TTPs to add stronger security features (NRO, etc.). This assures flexibility in the interoperability of non-homogeneous CCSs, i.e., one belonging to a TTP and one not All Providers belonging to the same TTP realize a CEM system, according to the TTP specification The TTP publishes the working profile (including the security policy) of the CCS system on the DNS (txt record) In this case the attributes published by TTP overwrite those published by the provider
Conclusion This study suggests a conceptual model to support and fuel worldwide interoperability of Internet Certified Communication Systems (CCSs) worldwide The proposed model has to be validated two different CCSs have to share their technical specifications in order to define a common profile
Questions? Thanks