{"id":22096152,"url":"https://github.com/blessedrebus/advanced-web-face-authentication","last_synced_at":"2025-10-30T09:39:46.071Z","repository":{"id":156810758,"uuid":"574626053","full_name":"BlessedRebuS/Advanced-Web-Face-Authentication","owner":"BlessedRebuS","description":"Web authentication based on RSA keys and BLS elliptic curve as signatures","archived":false,"fork":false,"pushed_at":"2023-04-26T23:22:36.000Z","size":3568,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"bls","last_synced_at":"2025-01-29T07:30:32.486Z","etag":null,"topics":["blockchain","bls","rsa","security","web"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/BlessedRebuS.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-12-05T18:12:55.000Z","updated_at":"2023-08-17T13:35:11.000Z","dependencies_parsed_at":null,"dependency_job_id":"e3b637d2-5672-4fb0-857d-ac36639edd5c","html_url":"https://github.com/BlessedRebuS/Advanced-Web-Face-Authentication","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/BlessedRebuS%2FAdvanced-Web-Face-Authentication","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/BlessedRebuS%2FAdvanced-Web-Face-Authentication/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/BlessedRebuS%2FAdvanced-Web-Face-Authentication/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/BlessedRebuS%2FAdvanced-Web-Face-Authentication/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/BlessedRebuS","download_url":"https://codeload.github.com/BlessedRebuS/Advanced-Web-Face-Authentication/tar.gz/refs/heads/bls","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245191636,"owners_count":20575248,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blockchain","bls","rsa","security","web"],"created_at":"2024-12-01T04:09:48.517Z","updated_at":"2025-10-30T09:39:45.969Z","avatar_url":"https://github.com/BlessedRebuS.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Advanced Face Authentication System: Ensuring Security and Robustness\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"img/trust_network.png\" width=\"700\" height=\"700\"/\u003e\n\u003c/p\u003e\n\n\n# Demo\nThe project aims to implement a prototype of facial authentication via the web, using the confirmation of multiple servers to sign requests and authenticate the user on the site. The signature mode implemented is both with RSA keys and BLS encryption. The entire project is deployable with kubernetes.\n\nRequirement: [Minikube](https://minikube.sigs.k8s.io/docs/start/) or another Kubernetes cluster to test the enviroment.\n\nThe project is divided in branch RSA that uses RSA keys to validate the token and BLS that uses instead the BLS digital signature.\nInside **kubernetes/deployment_bls.yaml** there is the required deployment to launch a demo.\nYou can set up the Trust Servers configuring the **trusted-servers** in the configmap and specify the threshold of the signature based on the security of the system. An example configuration for the servers is the following, defined at the beginning of the deployment.\n\n```\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trust-configuration-bls\ndata:\n  trusted-servers: |\n    - http://tsbls1:5000\n    - http://tsbls2:6000\n    - http://tsbls3:7000\n  threshold: \"2\"\n```\n\nThen you can apply the deployment with the following:\n\n`kubectl apply -f deployment_bls.yaml`\n\nAnd to reach the server using port-forwarding:\n\n`kubectl port-forward deployment/spbls 1111:5000`\n\nThen, visiting\n\n`http://127.0.0.1:1111/loginface`\n\nThe login page can be reached. Inserting `user1` as the Username and taking a picture of the face, the login will proceed and your access will be denied. This is because first you have to insert the encoding of your face inside the database. Using my face from [my LinkedIn account](https://www.linkedin.com/in/patrick-di-fazio/) will let you log in with the user `user1`.\n\nThen what's the purpose of this if you can log-in with a simple photo? Well, this is a Proof of Concept. The aim of the project is to extend the **Biometric Authentication** with some hardware module (fingerprint reader, infrared sensor, etc) and keep the signature logic with RSA or BLS keys.\n\n---\n\n# Introduction\n\nIn passwordless authentication systems, the user no longer needs to remember and use the login credentials. The password in this case would be nonexistent and therefore impossible to steal. The end user benefits from this simplicity, being able to use this system as a Single-Sign-On or as a secure method of logging in to a service. Despite using a nontraditional login system, at the application level there will be complete transparency with respect to the authentication system used. There are various modes of passwordless authentication, such as authentication through QR-Code (i.e. scanning a QR code), Magic Links (accessing static pre-made links) or through Biometrics. This project will study passwordless access via facial biometrics, although it is possible to extend the project to any type of biometrics.\n\nPasswordless authentication has many benefits, but it also has many critical points to be analyzed and on which we must pay attention. Implementation of such an approach must be done following a cost-benefit analysis. In particular, with facial authentication, the access system must maintain stringent constraints to ensure the minimum level of security. \n\n- **Accuracy**: Access to the system with a user's identity must not be possible, so there must be a high degree of reliability of access. \n- **Security**: Facial recognition systems can be bypassed by an attacker using false images or videos, so it is important to use a system with low recognition confidence or a system that is not capable of performing three-dimensional scans.\n\nIn the case of an implementation using three-dimensional biometrics, the cost of the system and feasibility decreases, as each user should have adequate hardware to perform the scan. The most important details in this text are the security issues associated with facial unlocking, the accessibility of the application, and the use of a webcam for authentication. Privacy is important, as it should not be possible to reproduce or reconstruct a face from the known string. Accessibility is also important, as the end user must make use of a webcam to use the application properly. Special hardware components are used to project a matrix of lights onto the user's face, which can then be analyzed by a special camera to produce a fingerprint of the user. Using only the webcam, on the other hand, ensures greater availability of the service at the expense of security.\n\n---\n\n# Architecture\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"img/network_details.png\" width=\"50%\" height=\"50%\"/\u003e\n\u003c/p\u003e\n\n- Client: Provides for client access to the service, starting with the individual user and ending with the organization that chooses to adopt the passwordless methodology. Here, clients connect to the service according to the level of security they wish to maintain. A client that needs numerous servers to sign its face will choose a higher level of security. To access less critical services, it will also be possible for the client to choose a lower level of security, which will benefit from faster signing and less bandwidth occupancy. The client connects through the browser to the Service Provider's address, enters its Username and takes the picture. After a few milliseconds he receives a response from the server: if the photo is valid and the encoding matches the one saved on the Identity Provider, the user accesses the Service Homepage, otherwise he will receive HTTP error 401 (Unauthorized).\n- Server: This part is responsible for receiving the user's request, generating the face encoding and sending it to a controller that will handle the signature request by forwarding the encoding to the trust servers. This is where we deliver the service to the user and generate the token that will then be used within the service and uniquely identify the user on the Web site. The first step the Service Provider takes is to receive the request from the Clients and process the face encoding locally. After the processing is finished it turns the request made to the Identity Provider who prepares the request for the Trust Controller, if the user is registered in the system and waits for response. The Trust controller in turn, knowing the list of signing servers, has the logic to make a request to each server and merge the signatures.\n- Signature: At this level, the signature servers come in and compare the encoding of the previously sent face with the one saved by the users' identity manager. Trust Servers do an array comparison operation that will return a positive result only if the generated encoding falls within a confidence interval specified at runtime. In other words, if the encoding is similar enough to the saved encoding, they will sign the packet and return it to the client. Trust Servers, depending on the type of signature the system will have, will differ greatly. In fact, the service can use two different systems to sign and generate the tokens: one is based on the RSA algorithm and one uses BLS signatures, better described later. Deployment is done parametrically, using the same container but changing the environment variables for each new server. The Trust Controller needs to be aware of all the servers signing the picture, to better manage the security of the system.\n\n# Signature \n\nIn the diagram in the figure we can see how the first step in requesting an identity from the client to the server or Service Provider. Here the Service Provider is then contacted by specifying the user's username. It is in the Service Provider that the deployment of the client reachable webserver is done and it is he who is in charge of processing the client face to generate the encoding.\nOnce the encoding generation is complete, an identity request is sent to the Identity Provider that contains the previously generated encoding and the user's username as parameters. If the username matches an existing one, the request formed by the encoding just received and the encoding saved for that user, concatenated with the username, is forwarded. This packet is sent to the Trust Controller.\nThe Controller retrieves the server number configured at runtime, according to the required security level, and prepares a cyclic request for each Identity Server or Trust Server present, which includes the two received encodings and the user's username. Each server is responsible for producing a boolean indicating whether the two arrays are similar. If the result is positive, each server produces a piece of the token which is then sent to the Trust Controller as a response. If one of the servers is unreachable it is skipped.\nThe generated response, which includes all the pieces of the tokens created, is then sent back to the Identity Provider who provides the identity and the JSON Web Token to the client who will be identified on the Web site until he logs out. Finally, the application can use two different signature modes: the List mode and the mode with BLS. Regardless of the signature type, the operation of the service will appear transparent to the user, who will always be validated and identified via a JWT.\n\n## Type of Signature: RSA vs BLS\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"img/screen_list.png\" width=\"30%\" height=\"30%\"/\u003e\n  \u003cimg src=\"img/screen_bls.png\" width=\"30.2%\" height=\"30.2%\"/\u003e\n\u003c/p\u003e\n\n### RSA Mode\nIn this mode, each Trust Server signs the response with its public key and sends the packet to the Trust Controller, which will collect the signatures and send them to the Service Provider via the Identity Provider. At this point the Server may encrypt a session key with the public key retrieved from the Trust servers' signatures and send it to the various Trust Servers. If each of them responds with the correct decryption of the session key, through its own private key, then that server is registered as valid and the number of servers that have signed the session token is increased by one. When the number of signatures is greater than the desired security limit for the specific Service Provider, the session token is considered valid and the user is free to browse the Web site until he logs out, where the signatures are invalidated.\nConsidering the implementation side, an asymmetric encryption mode is used for this type of signature, using an RSA library on Python.\n\n### BLS Mode\nThis signature mode, implements a multi-signature widely used in the Blockchain to reduce the size of transactions, where to verify a set of signatures, the verificator must have an *aggregate()* function of the signatures, it must maintain only a reduced aggregation of all the signers' public keys. Doing so reduces the number of computed elements which then results in faster signature verification by having less computational effort.\nIn the case of Trust Servers, each server generates its own token through the bls signature() function, encrypting the encoding and username. This information will be concatenated to the Proof of Possession of the private key and sent to the Trust Controller. Here the aggregate() is created, which will merge all server signatures and send them to the Service Provider through the Identity Provider. When receiving the packets to be validated, the Server Principal will verify the signature with *verify_aggregate()* which compares the set of generated signatures with the Proof of Possession list of public keys retrieved from each Trust Server.\n\n## Performances\n\nIn this section we distinguish the different type of signature from the performance point of view. Wireshark was used to produce the graphs. The tests performed consider a single login via facial registration (and then sending the photo, generating the encoding and signing servers) followed by the user's logout.\nTo analyze network traffic with Wireshark, we can hook a probe to the loopback interfaces of the system. This is possible because it is used Minikube, which is a method of running Kubernetes locally, on localhost interfaces and enabling port forwarding to reach the Service Provider service on port 1111 with the browser. This way the webserver can be reached and communications between the internal servers can be intercepted. Thanks to the statistics section of Wireshark it is then possible to create meaningful graphs for bandwidth usage, packet size, and on the TCP statistics of the connection.\nWe can see the first graph representing the total number of packets computed and then forwarded between servers to accomplish a signature, with an analysis on the average bandwidth consumed. The second and third show the total network throughput and the percentage of outgoing and incoming packets in the servers, over the 5 seconds of usage. In the figures we see that in 2 seconds there is a peak in network utilization: this is due to the sending, processing of the picture and the request and then subsequent sending of the signatures by the trust servers. The graph continues with a smaller peak indicating user logout. The I/O graphs represent the same situation, but include both server input and output data.\nDuring the system usage, a user performing the same login and and logout action, has different bandwidth usage. This is because the two signature modes employ different resources, both in terms of network usage and computing resources. In list mode we note that for the same actions there are **342** packets used, compared to **340** in BLS mode. On the other hand, analyzing the bitrate of both, the **163** Kbit/s of the list mode stands out, against the **152** Kbit/s of the BLS mode: a reasonable result given that the Average packet size of a BLS packet is **316** Bytes, against the **342** of the list mode. We thus note that BLS has about **0.6**% fewer packets used, about a **6.7**% less Kbit/s exchanged during signing, and a **7.6**% smaller Average packet size than the list mode.\n\n\u003cp align=\"center\"\u003e\n\u003ch3\u003eRSA\u003c/h3\u003e\n  \u003cimg src=\"img/list_graph.png\" width=\"50%\" height=\"50%\"/\u003e\n  \u003cimg src=\"img/list_io.png\" width=\"50%\" height=\"50%\"/\u003e\n  \u003cimg src=\"img/list_packets.png\" width=\"50%\" height=\"50%\"/\u003e \n\u003ch3\u003eBLS\u003c/h3\u003e\n  \u003cimg src=\"img/bls_graph.png\" width=\"50%\" height=\"50%\"/\u003e\n  \u003cimg src=\"img/bls_io.png\" width=\"50%\" height=\"50%\"/\u003e\n  \u003cimg src=\"img/bls_packets.png\" width=\"50%\" height=\"50%\"/\u003e\n\u003c/p\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fblessedrebus%2Fadvanced-web-face-authentication","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fblessedrebus%2Fadvanced-web-face-authentication","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fblessedrebus%2Fadvanced-web-face-authentication/lists"}