Extension of LCT V1 developed by Pedro Matias
- Introduction
- Benefits of LCT
- Main Components
- Extra Components
- Structure
- Source Prerequisites
- Generate a CA.key and CA.crt
- Generate Keys and Certificates for Each Module
- Initialize and Run the Postgresql Database for the Ledger or Monitor
- Run Modules
- Authors
Location Certificate Transparency (LCT) is a framework of logs, monitors, and auditors created to help mobile users and location-based service providers oversee location certificates (LCerts) issued or provided to them. LCerts bind locations, at specific time, to users (provers). Similar to Certificate Transparency (CT) that improves the web PKI (Public key infrastructure), LCT provides an easy way to find misissued or rogue LCerts and strengthens the location certification systems by creating publicly auditable records of certificate issuance. All issued LCerts should be published to public LCT logs.
- Earlier Detection
- LCT helps detect unauthorized certificates faster.
- Users can identify any certificate issued without express approval or outside their policy.
- Faster Mitigation
- Using LCT helps users identify which certificate requires revocation, allowing them to quickly communicate and shortening the revocation process of a certificate.
- Better Insight
- LCT provides public insight into the location certification systems, giving anyone the ability to observe and verify the system's health and integrity.
- Strong Security
- LCT strengthens the chain of trust on location certification systems.
- Verifying identities and issuing high-assurance location certificates.
The following are the main components of the LCT framework:
- Certificate Log: Certificate logs maintain records of all issued certificates. Multiple independent logs are required to allow for backups in case of a log failure or log operator is compromised and also to guarantee consensus on log’s activities and avoid collusion. The certificate log is:
- Append only: Certificates can only be added to the log; they can’t be deleted, modified, or retroactively inserted.
- Cryptographically assured: Log uses Merkle Tree Hash to prevent tampering.
- Publicly auditable: Anyone can query the log and look for misused or rogue certificates. All certificate logs must publicly advertise their URLs and public key.
-
Certificate Monitor: A certificate monitor is a service that watches the certificate logs for suspicious activities and can fetch information from the logs.
-
Certificate Auditor: Certificate auditors check the log to verify that its consistent with other replicated logs, that new entries have been added, and that the log has not been corrupted (e.g., inserting, deleting, or modifying a certificate). Auditors could be a standalone service or could be a secondary function of a monitor.
- Demo Prover: Example of a Prover, that can create Location Claims and can submit them to a Verifier. It can also ask for Audit Proofs to a Certificate Auditor.
- Demo Verifier: Example of a Verifier that can create Location Certificates and can store them in a Certificate Log. It can also use a Certificate Monitor to get stored Location Certificates from the Certificate Log.
- CA: CA that is responsible for signing Certificate Signing Requests.
- CertificateRequester: CertificateRequester is a module that allows the generation of Keys and Certificates for a module.
Directory | Description |
---|---|
CA | CA Module |
CertificateRequester | CertificateRequester Module |
Ledger | Ledger Module |
Monitor | Monitor Module |
Auditor | Monitor Module |
Verifier | Verifier Module |
- Java Development Kit (JDK) = 11
- Maven >= 3.8
- Postgresql >= 14.2
- Module specific Prerequisites (See Readme in specific Module)
From the root of the repository go to the resources of CA
cd CA/src/main/resource
Give execute permissions to the script (responsible for creating the key and a self signed certificate for the CA)
chmod +x newCA.sh
Execute the script
./newCA.sh
Add CA Certificate to Java Trusted Certificates. (You will need the password. (Default=changeit))
keytool -importcert -trustcacerts -cacerts -file CA.crt -alias LedgerCA -storepass changeit
Note: If you had previously done this step, then you need to delete first the LedgerCA certificate.
keytool -delete -alias LedgerCA -trustcacerts -cacerts -storepass changeit
From the root of the repository go to the CA
cd CA
Give execute permissions to the script (responsible for creating a certificate for a module)
chmod +x newCA.sh
Run CA
mvn spring-boot:run
From the root of the repository go to the CertificateRequester
cd CertificateRequester
Give execute permissions to the scripts (responsible for creating the key and the certificate signed request to give to the CA for each module):
chmod +x src/main/resource/newCSR.sh
chmod +x src/main/resource/newKeyStore.sh
Run CertificateRequester for the modules you want to run in order to get their keys and certificates ${ModuleName} = Ledger, Verifier, Monitor, Auditor, MaliciousLedger
mvn spring-boot:run -Dspring-boot.run.arguments="--requester.name=${ModuleName}"
${ModuleName} = Ledger Or Verifier Or Monitor
From the root of the project go to the ${ModuleName}:
cd ${ModuleName}
Give execute permissions to the initialization script:
chmod +x ./newDb.sh
Execute the initialization script (responsible for creating and populating the tables):
./newDb.sh
Ledger must be deployed before Monitor, Auditor and Verifier. Prover can only run after Monitor, Auditor, Verifier and Ledger are deployed.
From the root of the project go to the ${ModuleName}:
cd ${ModuleName}
Run Module:
mvn spring-boot:run
From the root of the project go to the Prover:
cd Prover
mvn exec:java
Name | University | More info |
---|---|---|
Pedro Matias | Instituto Superior Técnico | |
Rafael Figueiredo | Instituto Superior Técnico |