Setting upΒΆ

  1. Set up the Root CA and intermediate CA chain. The Certificate chain structure is shown in Certificates

  2. Clone Guardian on some branch onto ${top_dir}

    $ git clone https://github.com/s-fifteen-instruments/guardian.git -b branch_name $top_dir
Cloning into ...
...
...
$ cd $top_dir

  3. Change permission on the branch with

    $ ./scripts/init_permissions.sh branch_name

    This will require the root password.

  4. Copy .example files in ${top_dir}/common/ to working files and change ROOT_CA_PASSWORD in CERTAUTH_SECRETS file to the one used to encrypt the kme-ca.key.pem [1]

  5. link key, cert and chain into common folder.

    $ ln -s /path/to/keys.pem $top_dir/common/kme-ca.key.pem
$ ln -s /path/to/cert.pem $top_dir/common/kme-ca.cert.pem
$ ln -s /path/to/cachain.pem $top_dir/common/full-chain.cert.pem

  6. Also in the common/ directory are the config files used in Guardian

    1. In the global_config.py file are the settings that are used in setting up Vault used in Guardian. The value that one may consider changing here can be found in Global Configuration

    2. The CERTAUTH_CONFIG file holds information presented when issuing the CSR.

    3. log.env holds the default logging level for the docker services. More description here

    4. The settings to Guardian Rest API can be found in rest_config.py. More description of each variable can be found here

    5. If the unsealer service is running, then some config settings are located in the Unsealer Client Configuration.

    6. vault_init_config.py has the configuration for the initializing the Vault server. More descriptions can be read here

    7. The watcher_config.py holds the configuration for the watcher service. Some explanation can be found here

    8. The qkd_config.py and notifier_config.py are configurations for operating Guardian without any attached QKD hardware. These services simulate the keys as generated by the QKD devices.

  7. The ${top_dir}/Makefile needs to be edited to reflect the local KME address and location of the code for guardian.

    ##########################
##### CAN CHANGE ME ######
## OR SET ME IN THE ENV ##
##########################
# - Choose "kme1" or "kme2" for the local KME identity.
#   kme1 => local, kme2 => remote
export KME ?= kme1
# - Location of Local KME's guardian git repository
export LOCAL_KME_ADDRESS ?= s15qkd-f.internal
export LOCAL_KME_DIRPATH ?= kme1@$(LOCAL_KME_ADDRESS):/home/kme1/code/guardian
# - Location of Remote KME's guardian git repository
#   TODO: Verify currently only used to transfer keys (to be handled by qcrypto) and
#         transfer certs (to replace full-chain authentication with int+root ca-chain)
export REMOTE_KME_ADDRESS ?= s15qkd-g.internal
export REMOTE_KME_DIRPATH ?= kme2@$(REMOTE_KME_ADDRESS):/home/kme2/code/guardian

# NOTE:
# - Set to <username>@<hostnameORip>:<path/to/guardian/repository>
# - It is expected that passwordless SSH access is set up to this location.
# - Use a full absolute path. Do not use env variables or tilde (~) as
#   they will not necessarily expand correctly in a remote context.
##########################
##########################
##########################

  8. After going through the configuration, the build process is called via

$ make init

  1. Once initialised, Guardian service can be brought up with

$ make rest

  1. Sensitive data in $top_dir/volumes/certificates/production/admin/ should be removed once distributed to the relevant parties. Once the vault/SECRETS file is removed, the unsealer service can no longer be used. The secrets in $top_dir/common/CERTAUTH_SECRETS should also be removed

    Ideally, no other user should be able to log in to and access the operating system, but it is good to not leave around potentially sensitive secrets accessible nonetheless.