# Self Encryption

In the previous section, Multiple Resource Identities, we demonstrated how different resources communicate with each other. However, there may be scenarios where multiple instances of the same resource need to communicate with each other using different passwords, as shown in the same section.

Similarly, numerous instances of the same resource identity, using either the same or different passwords, can be spawned to accommodate scalability scenarios. In such cases, these instances require a machine token (asymmetric shared keys) to encrypt information to be sent to the other instance.

To ensure secure communication, HexaEight Platform uses Perfect Forward Secrecy by generating machine tokens every 15 minutes. Therefore, every resource instance needs to fetch its own machine token to encrypt or decrypt messages. This process of using a machine token of its own identity to communicate securely with another instance is called Self Encryption.

Securing Communication between Instances

In the following sample, each instance of Resource-A fetches the machine token of itself for encrypting and decrypting messages

%%{init: { 'theme': 'forest' } }%%
erDiagram
    ResourceA-Instance2 ||--|| ResourceA-Instance1 : Fetch-Machine-Token-of-Resource-A
    ResourceA-Instance3 ||--|| ResourceA-Instance1 : Fetch-Machine-Token-of-Resource-A
    ResourceA-Instance4 ||--|| ResourceA-Instance1 : Fetch-Machine-Token-of-Resource-A

TimeCodes

Multiple instances of the same resource can securely communicate with each other by agreeing upon a specific Unix timestamp called Timecodes. This enables all instances to use the same machine token for encryption and decryption purposes until all instances agree to change the Unix timestamp. To utilize Timecodes, all instances need to retrieve their respective machine token using the predetermined Unix timestamp. This allows instances to use the same machine token for secure communication with each other.

Timecodes ensure that all instances of a resource identity use the same machine token for as long as they want which is very useful in Offline communication scenarios.

Each instance can use a JWT message for instant secure communication with another instance by using the IAT header field to represent the Time code.

%%{init: { 'theme': 'forest' } }%%
erDiagram
    ResourceA-Instance2 ||--|| ResourceA-Instance1 : Establish-Secure-Communication-using-TimeCode
    ResourceA-Instance3 ||--|| ResourceA-Instance1 : Establish-Secure-Communication-using-TimeCode
    ResourceA-Instance4 ||--|| ResourceA-Instance1 : Establish-Secure-Communication-using-TimeCode

Usage Of TimeCodes in a JWT Message

In the previous section about JWT messages, we demonstrated how two instances of different programs can communicate with each other using JWT. The IAT (Issued At) header field in JWT can be utilized to exchange time code information between multiple instances, ensuring that all instances fetch their own machine token based on the IAT value. This allows for secure communication between multiple instances using the same machine token

Summary

Mutiple Resource Instances can securely communicate with each other by fetching its own machine token in order to encrypt and decrypt information.

The unix timestamp used to fetch the machine token is called Time Code
The IAT header field can be represented as a Timecode when using JWT for secure message communication.