Demonstrating Remote Attestation

In the following example, four windows are opened to facilitate the demonstration.

Window 1

If the AS mode is used, you can start the Attestation Service in Window 1.

Prepare the database for the Attestation Service.

dnf install openldap-devel postgresql-server
cd kunpengsecl/attestation/quick-scripts/
bash prepare-database-env.sh

Configure the certificate.
```
cd kunpengsecl/attestation/tas/cmd/
openssl genrsa -out aspriv.key 4096
openssl req -new -x509 -days 365 -key aspriv.key -out ascert.crt
```
You need to enter some configuration information for the certificate. The configuration information is not contained in the demo.

Edit the config.yaml file.

Open the file.
```
vim config.yaml
```

Press i to enter the insert mode and modify the file based on the following comment and your specific requirements. In the demo, you only need to change basevalue.

tasconfig:
  # Service ports opened by default
  port: 127.0.0.1:40008
  rest: 127.0.0.1:40009
  # Private key and certificate configured for the Attestation Service
  akskeycertfile: ./ascert.crt
  aksprivkeyfile: ./aspriv.key
  huaweiitcafile: ./Huawei IT Product CA.pem
  # The following configuration is used only for testing. Update the content to ensure security.
  DAA_GRP_KEY_SK_X: 65a9bf91ac8832379ff04dd2c6def16d48a56be244f6e19274e97881a776543c65a9bf91ac8832379ff04dd2c6def16d48a56be244f6e19274e97881a776543c
  DAA_GRP_KEY_SK_Y: 126f74258bb0ceca2ae7522c51825f980549ec1ef24f81d189d17e38f1773b56126f74258bb0ceca2ae7522c51825f980549ec1ef24f81d189d17e38f1773b56
  # QTA base value, which can be obtained from the itrustee_sdk/build/signtools/hash_e08f7eca-e875-440e-9ab0-5f381136c600.txt file used during QTA compilation in step 4. The format of basevalue is img_hash mem_hash.
  basevalue: "8c6faf44d8d1fa9f83977e405caadd7d9b1194839d6034d5412fe00f5f294976 0f474ebc56dc5502f7fba2a26d983b3a6cf2da84ce44730f60d4c660d42634a6"
  authkeyfile: ./ecdsakey.pub

Press Esc to exit the insert mode. Type :wq! and press Enter to save the file and exit.

Start the Attestation Service.
```
go run main.go -T; go run main.go
```

Window 2

In Window 2, start the RA Service to receive remote attestation requests from the RA client.

Deploy the application.
The QCA server execution path is specified in the QTA source code in 5. Therefore, you need to deploy the QCA server to the corresponding directory.
```
cp kunpengsecl/attestation/tee/demo/pkg/qcaserver /vendor/bin/
```

Start the RA Service.

cd kunpengsecl/attestation/tee/demo/qca_demo/cmd/

This directory provides the default config.yaml file of the QCA server. You can modify the file as required. The default value is used for the demonstration.

qcaconfig:
  server: 127.0.0.1:40007      # Service port opened by default.
  akserver: 127.0.0.1:40008    # Port for the Attestation Service.
  scenario: 0
  nodaaacfile: ./nodaa-ac.crt  # Path to the certificate in as no daa mode.
  daaacfile: ./daa-ac.crt      # Path to the certificate in as with daa mode.

Start the RA Service. Select a proper scenario based on your requirements. -C specifies the remote attestation scenario. The values 0 to 3 indicate the following scenarios: 0: no as; 1: as no daa; 2: as with daa.
```
/vendor/bin/qcaserver -C 1
```
In AS mode, the QCA server proactively connects to the Attestation Service to obtain the certificate.

Window 4

In Window 4, start the target TA as the TA to be tested.

You can run the demo CA and TA or your own applications. See Loading the TA and CA.

/vendor/bin/rsa_demo

When the RA client initiates an invocation request, the target TA must be running. Otherwise, the "uuid invalid" error is reported. To ensure successful demonstration, the test CA and TA must run for a sufficient period of time. After the CA pulls the TA, make the CA sleep for a period of time to prevent the TA from being uninstalled.

Window 3

In Window 3, start the RA Client to initiate remote invoking.

Go to the RA Client directory, which contains the configuration files required for starting the RA Client.
```
cd kunpengsecl/attestation/tee/demo/attester_demo/cmd
```

Edit the config.yaml file

Open the file.
```
vim config.yaml
```

Press i to enter the insert mode and modify the file as follows: In the demo, change the UUID of the TA to be tested.

attesterconfig:
  server: 127.0.0.1:40007           # Port for the RA Service.
  basevalue: "./basevalue.txt"      # Base value of the TA to be tested.
  mspolicy: 2                       # Verification policy. The value 1 indicates comparing the img-hash value only, 2 indicates comparing the mem-hash value only, and 3 indicates comparing both values.
  uuid: 435dcafa-0029-4d53-97e8-a7a13a80c82e   # UUID of the TA to be tested.

Press Esc to exit the insert mode. Type :wq! and press Enter to save the file and exit.

Configure the base value of the target TA. The config.yaml file specifies the base value configuration file of the TA to be tested.
1. Open the file.
```
vim basevalue.txt
```
2. Press i to enter the insert mode and modify the file as follows:
  The base value can be obtained from the hash_{test TA UUID}.txt file generated during TA compilation and test. For an iTrustee SDK version earlier than 1.4.0, the file is stored in the itrustee_sdk/build/signtools directory. For version 1.4.0, the file is stored in the TA compilation directory. The format of basevalue.txt is uuid img_hash mem_hash. The following is an example:
```
435dcafa-0029-4d53-97e8-a7a13a80c82e a1ef720498a93a36df8c3b1ea58058485de5b8146d399e837b0b709b53224542 ad36fdf631f1fdd6dc47c8d80bdf08fb752d1e93bd97ed534abbde797bf68b8b
```
3. Press Esc to exit the insert mode. Type :wq! and press Enter to save the file and exit.
If the AS mode is used, copy the Attestation Service certificate to the current directory.
```
cp ../../../../tas/cmd/ascert.crt TAS\ Root\ Cert.pem
```
Initiate a remote attestation request.
```
go run main.go
```
If the verification fails, the following error information is displayed in the tlogcat. The possible cause is that the TA to be tested has exited when the RA Client initiates the request.

Restart the CA and TA and send the request again. Therefore, you are advised to prolong the CA and TA execution duration to reserve sufficient time for the operation.

Parent topic: Examples