The main purpose of the tutorial is get people familiarized with the main concepts and motivation of ENS security architecture, design and functionality. Building ENS community alongside with the emergence of more and more security technologies nowadays calls for the need of designing a security architecture scalable to addressing security and trust aspects in a scalable and flexible way.
The main goal of the architecture is to allow ENS users establish trusted and secure communications for using ENS core services as well as establish trust and security aspects within ENS community itself, that is, between users themselves and between users and third party ENS service providers.
Over the last decade we have seen the emergence of digital certificates-based security models, with corresponding Public Key Infrastructure (PKI) models, as a means of establishing trusted and secure communications in a decentralized manner.
OKKAM project has adopted the concept and use of digital certificates with a corresponding PKI as the underlying security model. That means that trust in ENS (and community) is based on certificate authorities that qualify ENS, third party ENS service providers and ENS users by means of digital certificates. Authentication and access control processes are based on digital certificates attesting users’ access rights. Digital certificates are well suited for decentralized peer-to-peer identification and authorization. Management of digital certificates as well as privacy of their usage is a key issue in ENS.
The standard and certificate format adopted and fully compliant with is X.509 v3. A user registers to ENS either via a dedicated ENS Web front-end or via a proxy component. Upon registration, a user obtains its registration data in a file (with a special format according to PKCS#12 standard) which contains all necessary user registration data and supporting certification authorities for building trusted communications with other ENS users or ENS service providers, or the ENS.
Figure 1 shows the high-level security architecture and message flows of ENS entities. The figure illustrates the different types of communications where security and trust interactions take place:
- Between Users and ENS services (proxy-based security)
- Between Users and ENS third party services (https/ssl secure communications)
- Between Users and Users (any cert-based technology, including https)
- Between ENS third party services and ENS (proxy-based security)
To facilitate users, developers, and third-party ENS service providers, the OKKAM project has adopted the use of a security proxy component that abstracts all necessary security management and technological aspects from application-level development. Later below we recall the main issues of the proxy component.
End-users in the figure form those community users that use lightweight means to interact and use ENS services, for example using dedicated ENS Web-front ends toolkits, as the Web entity creator toolkit.
The main drivers for adoption of certificate-based security:
- Scalability for building secure Web Services-based communications ensuring confidential (authentic not faked) communications
- Flexibility for establishing trust in a distributed environment (like ENS community) even in “offline” mode between users and third party service providers, by means of common trust to ENS certificate authorities
- Availability of several certificate-based secure communication technologies widely used now-a-days and adopted by ENS community: HTTPS (SSL/TLS), WS-Security and related standards, Secure e-mail communications such as PGP, Web-of-trust.
- Decouple security aspects from application aspects,
- Transparent management of security settings from application level,
- Independent certificates and trust management from application level,
- Allow even thin WS applications, such as ENS plug-ins for MS Word, Firefox etc, to achieve a good level of security with ENS.
- Encapsulate authentication and access control logic:
- Intelligent (on the fly) negotiation-based authorization process,
- Establish access control process only when necessary by ENS,
- Protect users’ certificates from unauthorized disclosure,
- Efficient and scalable security with ENS by deploying the proxy counterpart at any ENS core (in a cluster),
- Provide secure user registration to ENS via a dedicated proxy interface and functionality
- Business-driven/user-centric security: customizable security settings and certificates protection level.
Proxy-based Security Communications with ENS:
Figure 2 shows the proxy high-level architecture and its integration with ENS-enabled applications connecting to ENS cluster, in particular a single-core view.
There are two types of APIs: public accessible, and protected with controlled access. Respectively, ENS allows direct or indirect via proxy communications with the ENS APIs. The proxy component replicates all ENS WS APIs as locally accessible to provide transparant access by external ENS-enabled applications. Those APIs with no protection the proxy just forwards requests/responses. It is mainly provided for compatibility issues.
Proxy functionality is available as a library or as a service on localhost WS connections. The proxy establish secure end-to-end message-level communications with local network firewall traversal, and WS (http) load balancer traversal.
User Regiatration Information and Technical Means:
Upon successful registration, a user obtains his/her registration data in a single file encrypted with the specified password in the registration form. The obtained registration data includes: (i) user’s public-key certificate (also known as identity certificate, or identity token) digitally signed by a Project’s trusted certification authority, and (ii) a set of the Project’s trusted certification authorities, forming a trust chain of certificates to the user’s public-key certificate. The user’s public-key certificate includes user’s distinguished name, user’s public key, and the distinguished name of the issuing certification authority.
A user is identified by its distinguished name, which is a composition of its personal information, such as first and last names, country of residence, organization of current employment, e-mail address and username.
The use of username is only for convenience of users when using their registration data. The username has no special role, and it is not necessary to be unique (in contrast to classical username/password authentication systems). Technically, the username is only used to refer to users’ private key information (also called alias of key entry) inside the obtained registration file.
The e-mail address, a mandatory part of the registration data, is used as a unique identifier in order to avoid registration of duplicate records. The e-mail address provides the only means the Project communicates with a user.
Users select a password, which is confidential and used only at users’ side to protect and verify the integrity of their registration data. The ENS system does not store users’ passwords. No person should disclose, or knowingly expose his/her passwords.
The data obtained from the registration process and stored in the Project’s system includes a user’s public-key certificate, and, if a user explicitly agrees, the private key information corresponding to the user’s public-key certificate. In case of forgotten password or lost registration data, the user can recover its registration data by using the Project’s registration data recovery service, only if the user’s private key information is stored in the ENS system.
The user account information contains enough information for the Project to have reasonable confidence that its subsequent usage is by the user only, or by someone with access to the information the user provided (including the password).
ENS Access Management Based on User Certified Privileges:
The ENS community grants users with special attribute-based privileges (also called credentials) for well-being of ENS and its community growth. An attribute certificate contains the user’s distinguished name (the same as indicated in the user’s public-key/identity certificate), the attribute the user possesses, and the issuer’s distinguished name that signed the attribute certificate.
All users wishing to obtain an attribute certificate must be registered ENS users. Attribute certification is a non-automated process, and depending on the attribute one wishes to obtain, it requires a specific authorization process by a dedicated ENS community user.
There is a trusted authorization manager user (qualified as “ENS Public Authorization Manager”) elected by the ENS management consortium that has the authority to grant (promote) administrator privileges to ENS users. This is a non-automated process including (whenever necessary) proofs supporting the decision of granting the administrator privilege.
ENS users with an administrator privilege have a high level of service access to any ENS service and any private identifiable information except users’ private key data. The administrator users have the authority to identify who is the author of a given public act of creating or modifying ENS entities. ENS users who have the administrator privilege have also the authority to grant to ENS users the trusted ENS entity creator privilege. This is a non-automated process including (whenever necessary) proofs supporting the decision of granting the trusted entity creator privilege.
For example, if a registered user wishes to become an administrator of ENS, the same has to contact the ENS authorization manager, and via a proof of authenticity and ability to be such, the authorization manager may grant the user the right to be administrator. In turn, any administrator user can delegate to other registered users the right of being “ENS Public Trusted Entity Creator” service providers. A user needs to contact an administrator user (via a dedicated service on the official ENS site), and upon successful communication between the user and an ENS administrator with a proof of user legitimacy to become a trusted ENS entity creator service provider, the user will be granted (normally given by e-mail) an attribute certificate attesting him/her as a trusted entity creator service provider.
ENS users with a trusted ENS entity creator privilege have the right to (i) create ENS entities (in the ENS) on behalf of ENS users, and as such, have the authority to make users as authors of such public act (of ENS entity creation) in the ENS system; and (ii) store locally users’ identity information in their own log data. ENS users with a trusted ENS entity creator privilege are given permissions to provide ENS entity creation process as a third-party ENS service to ENS users.
Snapshots of Proxy Usage and Configuration:
