Supporting authorize-then-authenticate for wi-fi access based on an electronic identity infrastructure

Federated electronic identity systems are increasingly used in commercial and public services to let users share their electronic identities (eIDs) across countries and providers. In Europe, the eIDAS Regulation and its implementation-the eIDAS Network-allowing mutual recognition of citizen’s eIDs in various countries, is now in action. We discuss authorization (before authentication), named also authorize-then-authenticate (AtA), in services exploiting the eIDAS Network. In the eIDAS Network, each European country runs a national eIDAS Node, which transfers in other Member State countries, via the eIDAS protocol, some personal attributes, upon successful authentication of a person in his home country. Service Providers in foreign countries typically use these attributes to implement authorization decisions for the requested service. We present a scenario where AtA is required, namely Wi-Fi access, in which the service provider has to implement access control decisions before the person is authenticated through the eIDAS Network with his/her national eID. The Wi-Fi access service is highly required in public and private places (e.g. shops, hotels, a.s.o.), but its use typically involves users’ registration at service providers and is still subject to security attacks. The eIDAS Network supports different authentication assurance levels, thus it might be exploited for a more secure and widely available Wi-Fi access service to the citizens with no prior registration, by exploiting their national eIDs. We propose first a model that discusses AtA in eIDAS-based services, and we consider different possible implementation choices. We describe next the implementation of AtA in an eIDAS-based Wi-Fi access service leveraging the eIDAS Network and a Zeroshell captive portal supporting the eIDAS protocol. We discuss the problems encountered and the deploy-ment issues that may impact on the service acceptance by the users and its exploitation on large scale

Design, modeling, and simulation of secure X.509 certificate revocation

TLS communication over the internet has risen rapidly in the last seven years (2015--2022), and there were over 156M active SSL certificates in 2022. The state-of-the-art Public Key Infrastructure (PKI), encompassing protocols, computational resources, and digital certificates, has evolved for 24 years to become the de-facto choice for encrypted communication over the Internet even on newer platforms such as mobile devices and Internet-of-Things (IoT) (despite being low powered with computational constraints). However, certificate revocation is one sub-protocol in TLS communication that fails to meet the rising scalability demands and remains open to exploitation. In this dissertation, the standard for X.509 revocation is systematically reviewed and critically evaluated to identify its limitations and assess their impact on internet security. Because of fragmented revocation information and limited scalability, even the latest version of the X.509 revocation standard is susceptible to Man-in-the-Middle (MiTM) attacks. Blockchain technology can provide a decentralized and peer-to-peer distributed ledger to enable a unified, tamper-proof platform for X.509 certificate authorities to collaborate securely in a trustless environment. To understand blockchain technology\u27s capabilities and limitations in distributing X.509 revocation information, different blockchain platforms are explored and compared in terms of scalability, degree of decentralization, and cost of operation. Moreover, the unification of the revocation lists leads to a massive expansion in the number of revoked certificates to query by a verifying client thus increasing the latency during revocation lookup. And, to minimize revocation-status lookup times, cryptographic constructions and approximate set-membership data structures are prototyped and analyzed. The key contributions of this dissertation are twofold: 1) the novel design of a secure and robust system for distributing X.509 certificate revocation information; and, 2) the prototype, experimentation, and optimization of cascading XOR filter, fuse filter, and cuckoo filter for quick lookup with zero false positives (and zero false negatives). The Secure Certificate Revocation as a Peer Service (SCRaaPS) is designed using the Lightweight Mining consensus algorithm-based Scrybe blockchain protocol to store and distribute certificate revocation lists. And, the cascading fuse filter (demonstrating the highest space efficiency and fastest build time) is applied to minimize the revocation lookup time with zero false positives

CTng: Secure Certificate and Revocation Transparency

In this work, we study Certificate Transparency (CT), an important standardized extension of classical Web-PKI, deployed and integrated into major browsers. We evaluate the properties of the published design of CT-v1 (RFC 6962), and identify five major concerns, which persist in drafts for CT-v2. Most significantly, CT-v1 fails to achieve the main goal of the original CT publications, namely security with No Trusted Third Party (NTTP) and it does not ensure transparency for revocation status. Several recent works address some of these issues but at the cost of significant, non-evolutionary deviation from the existing standards and ecosystem. In response, we present CTng, a redesign of CT. CTng achieves security, including transparency of certificate and of revocation status, with No Trusted Third Party, while preserving client’s privacy, allowing offline client validation of certificates, and facilitating resiliency to DoS. CTng is efficient and practical, and provides a possible next step in the evolution of PKI standards. We present a security analysis and an evaluation of our experimental open source prototype shows that CTng imposes acceptable communication and storage overhead

Is the Web Ready for OCSP Must-Staple?

TLS, the de facto standard protocol for securing communications over the Internet, relies on a hierarchy of certificates that bind names to public keys. Naturally, ensuring that the communicating parties are using only valid certificates is a necessary first step in order to benefit from the security of TLS. To this end, most certificates and clients support OCSP, a protocol for querying a certificate's revocation status and confirming that it is still valid. Unfortunately, however, OCSP has been criticized for its slow performance, unreliability, soft-failures, and privacy issues. To address these issues, the OCSP Must-Staple certificate extension was introduced, which requires web servers to provide OCSP responses to clients during the TLS handshake, making revocation checks low-cost for clients. Whether all of the players in the web's PKI are ready to support OCSP Must-Staple, however, remains still an open question.In this paper, we take a broad look at the web's PKI and determine if all components involved---namely, certificate authorities, web server administrators, and web browsers---are ready to support OCSP Must-Staple. We find that each component does not yet fully support OCSP Must-Staple: OCSP responders are still not fully reliable, and most major web browsers and web server implementations do not fully support OCSP Must-Staple. On the bright side, only a few players need to take action to make it possible for web server administrators to begin relying on certificates with OCSP Must-Staple. Thus, we believe a much wider deployment of OCSP Must-Staple is an realistic and achievable goal