Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The next section presents the same steps, but at more functional level, with interaction among various EVE microservices.

Module Level Interaction -

...

Startup Sequence (

...

Reboot with no change) - No EVC connectivity required 

...

Image Added


Fig.  Module Module Level Interaction in EVE - Startup Sequence (OnboardingReboot with no change; works without EVC connectivity)

  1. Device-steps starts client.go (the provisioning client) which will check and do the following:
    1. First fetches EVC Certificates
    2. Registers the device certificate
      1. If EVC is not reachable, uses certificates from the last download
      2. If EVC is not reachable, uses UUID already present in /config/uuid
    3. Retrieves UUID from EVC
    4. Device-steps starts Vault Mgr
      1. Vault Mgr
    5. creates new vault:
      1. retrieves the master decryption key from TPM with Unseal operation. Unseal is successful since the PCR values are the same since last reboot.
      2. Unlocks /persist/vault
    6. Seals
      1. with the master-key
    7. into TPM with PCR values
      1. .
      2. Publishes vault status (unlocked)
    8. Waits for Integrity-Token from zedAgent
    9. Once received, copies the new Integrity-Token to /persist/vault/itoken file
    10. Device-steps starts TPM mgr
      1. TPM manger retrieves the attestation certificate and publishes to Zedagent
      2. Waits for Quote requests on pubsub channel from Zedagent
    11. Device-steps starts
    12. Zedagent (and Zedagent starts 3 concurrent tasks: attest,
    13. Zed Manager, Domain Mgr microservices - these services are responsible for launching the Edge App Instances
    14. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
        Attest
        1. Configuration task,
      1. picks up the attestation certificate
        1. since EVC is not reachable, uses the configuration from the last download, and publishes to
      2. EVC
      3. requests for a nonce from EVC (to prepare PCR quote)
      4. sends the nonce back to TPM Mgr and waits for PCR quote
      5. Once notified about the quote readiness, creates a random nonce value for Integrity-Token
      6. Sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
      7. EVC, if master-key is not found for the EVE, approves the PCR quote as the baseline
        1. If Location-Lock is enabled, location is also approved as baseline (provided the EVE device is not in manufacturing account)
      8. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through)
      9. Attest task, once attestation request is approved, gets the master-key and Integrity-Token and passes it to Vault Mgr
      10. Config task now picks up the right Integrity-Token and Config request is now accepted by EVC, and full configuration is sent back
      11. Info task reports the encrypted master-key back to EVC, for backup purposes

      Module Level Interaction - Startup Sequence (Reboot with no change) - No EVC connectivity required 

      Image Removed

      Fig. Module Level Interaction in EVE - Startup Sequence (Reboot with no change; works without EVC connectivity)

      1. Device-steps starts client.go (the provisioning client) which will check and do the following:
        1. If EVC is not reachable, uses certificates from the last download
        2. If EVC is not reachable, uses UUID already present in /config/uuid
      2. Device-steps starts Vault Mgr
        1. Vault Mgr retrieves the master decryption key from TPM with Unseal operation. Unseal is successful since the PCR values are the same since last reboot.
        2. Unlocks /persist/vault with the master-key.
        3. Publishes vault status (unlocked)
      3. Device-steps starts TPM mgr
        1. TPM manger retrieves the attestation certificate and publishes to Zedagent
        2. Waits for Quote requests on pubsub channel from Zedagent
      4. Device-steps starts Zed Manager, Domain Mgr microservices - these services are responsible for launching the Edge App Instances
      5. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
        1. Configuration task, since EVC is not reachable, uses the configuration from the last download, and publishes to Zed Mgr and Domain Mgr
        2. Since the Vault is unlocked, Domain Mgr can access Edge App Images, and hence launches the app instances.

      Module Level Interaction - EVE Startup Sequence (Reboot with a change)

      Image Removed

      Fig. Module Level Interaction in EVE - Startup Sequence (Reboot with differing PCR values)

        1. Zed Mgr and Domain Mgr
        2. Since the Vault is unlocked, Domain Mgr can access Edge App Images, and hence launches the app instances.

      Module Level Interaction - EVE Startup Sequence (Reboot with a change)

      Image Added

      Fig. Module Level Interaction in EVE - Startup Sequence (Reboot with differing PCR values)

      1. Device-steps starts client.go (the provisioning client) which will check and do the following:
        1. If certificates from EVC are not yet fetched,  fetches them 
        2. Retrieves UUID from EVC
      2. Device-steps starts Vault Mgr
        1. Vault Mgr tries to retrieve the master decryption key from TPM with Unseal operation, and Unseal operation fails since the PCR values have changed
        2. Publishes vault status (as "locked")
        3. Waits for Integrity-Token and/or master-key from EVC - it will block here forever
      3. Device-steps starts TPM mgr
        1. TPM manger retrieves the attestation certificate and publishes to Zedagent
        2. Waits for Quote requests on pubsub channel from Zedagent
      4. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
      5. Device-steps starts Edge App microservices - e.g. Domain Mgr 
        1. Attest task requests for a nonce from EVC (to prepare PCR quote)
        2. Attest task sends the nonce back to TPM Mgr and waits for PCR quote
        3. Attest task, once notified about the quote readiness, creates a random nonce value for Integrity-Token
        4. Attest task sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
        5. EVC, since the quote is different, tries to compare EventLog entries with its known hashes against the version reported. Since the PCR values are different, there will not be match, unless Admin has uploaded measurements for this new version. Assuming that Admin is yet to upload, attestation request will fail here.
      6. EVC sends an error back to EVE, to retry attestation.
      7. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through).
        1. EVC replies to configuration request with HTTP Error Code 403 - Forbidden. Indicates attestation failure (due to no or invalid Integrity Token)
        2. Config task communicates to Attest Task to re-trigger attestation
      8. Admin uploads measurements for the new image version
      9. The next attestation request is matched successfully against the uploaded measurements
      10. EVC approves the attestation request, and responds back with the master-key (encrypted with TPM key) for the EVE node, and also saves the Integrity-Token supplied in the attestation request
      11. Vault Mgr 
        1. picks up the master-key
        2. unlocks vault
        3. populates Integrity-Token approved by EVC inside /persist/vault/itoken
        4. Publishes new vault status (unlocked) to all the microservices
      12. The next configuration request picks up the new Integrity Token, and sends configuration request along with this Integrity-Token
      13. EVC verifies that Integrity-Token matches with its copy, and approves configuration request and responds with the latest configuration.
      14. Domain Mgr notices the new vault status (unlocked) from Vault Mgr , and latest configuration from ZedAgent, and starts the Edge Apps
      15. Info task reports the encrypted master-key back to EVC, for backup purposes

      Module Level Interaction - EVE Startup Sequence (Initial Onboarding)

      Image Added

      Fig. Module Level Interaction in EVE - Startup Sequence (Onboarding)

      1. Device-steps starts client.go (the provisioning client) which will check and do the following:
        1. First fetches EVC Certificates
        2. Registers the device certificate
        3. Retrieves UUID from EVC
      2. Device-steps starts Vault Mgr
        1. Vault Mgr creates new vault: /persist/vault
        2. Seals the master-key into TPM with PCR values
        3. Publishes vault status (unlocked)
        4. Waits for Integrity-Token from zedAgent
        5. Once received, copies the new Integrity-Token to /persist/vault/itoken file
      3. Device-steps starts TPM mgr
        1. TPM manger retrieves the attestation certificate and publishes to Zedagent
        2. Waits for Quote requests on pubsub channel from Zedagent
      4. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
      5. Attest task,
        1. picks up the attestation certificate and publishes to EVC
        2. requests for a nonce from EVC (to prepare PCR quote)
        3. sends the nonce back to TPM Mgr and waits for PCR quote
        4. Once notified about the quote readiness, creates a random nonce value for Integrity-Token
        5. Sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
      6. EVC, if master-key is not found for the EVE, approves the PCR quote as the baseline
        1. If Location-Lock is enabled, location is also approved as baseline (provided the EVE device is not in manufacturing account)
      7. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through)
      8. Attest task, once attestation request is approved, gets the master-key and Integrity-Token and passes it to Vault Mgr
      9. Config task now picks up the right Integrity-Token and Config request is now accepted by EVC, and full configuration is sent back
      10. Device-steps starts client.go (the provisioning client) which will check and do the following:
        1. If certificates from EVC are not yet fetched,  fetches them 
        2. Retrieves UUID from EVC
      11. Device-steps starts Vault Mgr
        1. Vault Mgr tries to retrieve the master decryption key from TPM with Unseal operation, and Unseal operation fails since the PCR values have changed
        2. Publishes vault status (as "locked")
        3. Waits for Integrity-Token and/or master-key from EVC - it will block here forever
      12. Device-steps starts TPM mgr
        1. TPM manger retrieves the attestation certificate and publishes to Zedagent
        2. Waits for Quote requests on pubsub channel from Zedagent
      13. Device-steps starts Zedagent (and Zedagent starts 3 concurrent tasks: attest, info and config)
      14. Device-steps starts Edge App microservices - e.g. Domain Mgr 
        1. Attest task requests for a nonce from EVC (to prepare PCR quote)
        2. Attest task sends the nonce back to TPM Mgr and waits for PCR quote
        3. Attest task, once notified about the quote readiness, creates a random nonce value for Integrity-Token
        4. Attest task sends { Quote, Location, Event Log, Integrity-Token, Image Version } to EVC
        5. EVC, since the quote is different, tries to compare EventLog entries with its known hashes against the version reported. Since the PCR values are different, there will not be match, unless Admin has uploaded measurements for this new version. Assuming that Admin is yet to upload, attestation request will fail here.
      15. EVC sends an error back to EVE, to retry attestation.
      16. In the mean time, configuration task keeps requesting config from EVC (expected to fail till attestation goes through).
        1. EVC replies to configuration request with HTTP Error Code 403 - Forbidden. Indicates attestation failure (due to no or invalid Integrity Token)
        2. Config task communicates to Attest Task to re-trigger attestation
      17. Admin uploads measurements for the new image version
      18. The next attestation request is matched successfully against the uploaded measurements
      19. EVC approves the attestation request, and responds back with the master-key (encrypted with TPM key) for the EVE node, and also saves the Integrity-Token supplied in the attestation request
      20. Vault Mgr 
        1. picks up the master-key
        2. unlocks vault
        3. populates Integrity-Token approved by EVC inside /persist/vault/itoken
        4. Publishes new vault status (unlocked) to all the microservices
      21. The next configuration request picks up the new Integrity Token, and sends configuration request along with this Integrity-Token
      22. EVC verifies that Integrity-Token matches with its copy, and approves configuration request and responds with the latest configuration.
      23. Domain Mgr notices the new vault status (unlocked) from Vault Mgr , and latest configuration from ZedAgent, and starts the Edge Apps
      24. Info task reports the encrypted master-key back to EVC, for backup purposes

      ...