> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/open-v5.2.1-en/windows/gestor_claves.md).
# Key management
Editran makes it possible for the user to use several ways to exchange protected data through the following cryptography modes:
Mode 2.2. Cryptography with authentication and confidentiality using DES algorithm with single 8-byte keys. Key exchange is performed automatically.
Mode 3.0. Authentication cryptography with DES or RSA (1024 bits) algorithm and with DES and TDES confidentiality (with double or triple keys).
In mode 3.0, the keys for authentication must be exchanged between the endpoints before they can be used.
Mode 4.0 Cryptography with RSA authentication keys of 1024, 2048, or 4096 bits.
The algorithms for data encryption are: DES, TDES (with double and triple keys) and AES with 128, 192 and 256-bit keys.
Except in mode 2.2, the entities need to exchange their respective RSA keys, that is, the exchange is external to the Editran protocol. This exchange has been carried out in various ways: external applications to Editran, email, telephone, etc., which in many cases reveals the "weakness of the exchange".
Starting with version 4.1.5, Editran has incorporated a reliable and secure management system to automate the exchange process, avoiding the weakness mentioned, avoiding the display of keys in plain text, and facilitating a reliable incorporation and exchange in both entities.
When new RSA public keys are exchanged, all transmissions (except the initial one) may be signed with a private key for which we know that the corresponding associated public key has been sent to the remote side. In other words, in the second exchange, at least the initial one can be used for signing; in the third, the initial one or the second one, and so on.
In addition, all management has been structured into "subsystems". A subsystem is a group of exchanged keys for a given remote system, group of remote systems, or applications.
Each subsystem allows keys to vary with versions from 01 to 99 (when they reach that position they wrap around) while keeping the last 3. The exchange with the entities will be carried out from an Editran session adapted for this purpose.
## Graphical interface organization
The graphical interface is divided into several clearly identified components:
* (1) Subsystem type selection tree
* (2) Subsystem list or lists
* (3) Toolbar
* (4) Menu
As the branches of the tree (1) are expanded, the content of the list (3) is updated with the corresponding subsystems. By selecting a subsystem from the list and right-clicking the menu button, the options that can be performed on the subsystem appear.
Next, we will detail each component of the interface.
### Subsystem type selection tree
 The tree contains some 'fixed' branches that always exist and other variable branches that are immediately below them and depend on the subsystems that have been registered.
The 'fixed' branches have the following appearance:
* ***RSA Keys*** (Shows all RSA subsystems)
* ***Non-Own*** (Shows remote RSA subsystems)
* ***Own*** (Shows local RSA subsystems)
* ***Remotes*** (Shows the remotes registered in editran/G and the subsystems associated with each remote.
For example, if we click on ***RSA Key*** the list of subsystems is automatically updated to show all RSA subsystems. If below RSA we click ***Own*** the local environments we have registered with local subsystems appear. Clicking on a subsystem we will see the associated remote in the list.
### Subsystem list or lists
In this part of the interface, a list appears with the subsystems that meet the requirements selected in the tree, except when RSA Own Keys are selected.
In that case, two lists appear instead of one. The list in the upper part shows the Own Keys, that is, keys that have not yet been assigned to remotes (see section [**Generation and Sending of a Local RSA Key**](#generación-y-envío-de-una-clave-local-rsa)), and the list in the lower part the local RSA subsystems, that is, the keys that have already been assigned to remotes.
### Toolbar
The toolbar contains buttons that perform practically all the operations that can be carried out on the subsystems:
Depending on the selection in the tree and the subsystem in the list, some of the buttons will appear disabled.
Next, the functionality of each toolbar button will be briefly described and the section where the effect it triggers is explained in depth will be indicated.
#### Modify Subsystems
Clicking it opens the dialog of the *Subsystem Properties* selected in the list.
#### Delete Subsystems
The button is active only when a Subsystem is selected. Clicking it will delete, after confirmation, the subsystem selected in the list.
#### Sending the own public key
The button is active only when a Local RSA Subsystem is selected. Clicking it generates an exchange file with the key that has just been generated (in state ***Generated***) and it will be sent automatically by the Editran TELEGC application.
#### Update the key of a Local RSA Subsystem
The button is active only when a Local RSA Subsystem is selected. Clicking it will update the subsystem key with the active version of the associated Own Key.
#### Insert Remote File
Clicking the button opens a dialog where the Editran/G Presentation for which receipt is requested is indicated:
The file, received from a remote system, may be:
* An RSA public key from a Remote.
* A confirmation resulting from the incorporation of an RSA key in a remote system.
#### Create new Own key
The button is active only when an Own Key is selected. Clicking it shows the New Own Key dialog.
#### Show RSA Own Keys
Clicking the button automatically places the tree selection on RSA Own Keys. This way we can see the Own Keys in the upper list and the Local RSA subsystems in the lower list.
#### Modify an Own Key
The button is active only when an Own Key is selected. Clicking it shows the Own Key Properties dialog.
#### Delete an Own Key
The button is active only when an Own Key is selected. Clicking it will delete, after confirmation, an RSA Own Key. If there are Local RSA subsystems associated with that Own Key, the Own Key cannot be deleted.
#### Generate a new Version of the Key
The button is active only when an Own Key is selected. Clicking it will generate an RSA key pair and the version stored in the Own Key will be increased.
#### Data update and refresh
Clicking the button will refresh all the information in the tree and the list(s).
## RSA key exchange
RSA keys are asymmetric cryptographic keys. Asymmetric cryptography is, by definition, that which uses two different keys for each user: one for encryption, called the public key, and another for decryption, which is the private key. The emergence of asymmetric cryptography came from the search for a more practical way to exchange symmetric keys.
Currently, asymmetric cryptography is widely used; its two main applications are symmetric key exchange and digital signatures.
In this section we will see how to exchange an RSA public key with a remote and how to insert an exchange file generated by another remote using Editran/G.
### Generation and Sending of a Local RSA Key
RSA keys, being asymmetric keys, can be exchanged with different remotes without danger, since what is exchanged is the public key. The private key remains only in the system where it was created and thus there is no possibility that the data can be deciphered by a third party.
For this reason there are the ***RSA Own Keys*** of Editran/G. Through the RSA Own Keys, a series of common functions are managed for all remotes that use that key, such as:
* Generation of new key versions (new public-private key pairs)
* Activation of one version or another.
* Management of the Local Code and Subsystem.
An Own Key cannot be used if it has not been exchanged with a remote. For that there is the possibility of associating an Own Key with a Remote, creating a ***Local RSA Subsystem***. Once associated, the exchange file can be generated and sent to the remote so that it incorporates our public key.
Next, all the steps needed to generate and send an RSA key will be described in detail.
#### Local RSA Key
As noted in the previous section, a Local RSA Key serves to manage functions independent of the remotes and to generate new RSA keys.
**Creation of an RSA Own Key**
To create a new Local Key, use the menu *RSA Own Keys/New Own Key*:
The configuration dialog for **New Own Key**:
The fields that appear are:
* **Description**: It is merely an informational field.
* **Local**: You must enter the Local Environment assigned to Editran.
* **Subsystem**: Single-character identification of the key type. For each Local Environment, it can have different subsystems to achieve simpler operation (test subsystem, production subsystem, etc.)
* **Service Application**: Editran/G application that will be used to send the exchange file. It is recommended to use the 'TELEGC' application.
* **Key length:** You can select the size from 1024 to 2048 or 4096,
* **Key file labels**: Label under which the public key will be stored. It is recommended not to modify this value unless the problems that may appear are thoroughly understood.
Once all the fields have been filled in and OK is pressed, a public-private key pair will be automatically created, which will be version 1 of the newly configured Local Key.
**Modification, Consultation and Deletion of an Own Key**
To consult or modify an own key, first we must position ourselves so that we see the list of own keys, simply by clicking in the tree *RSA Keys/Own* or through the menu *RSA Own Keys/Show Own Keys:*
We will see two lists. The upper one contains the RSA Own Keys and the lower one the Local RSA Subsystems (the Own Keys associated with a Remote).
By double-clicking the Own Key we want to Modify/Consult, the Own Key properties dialog will appear with the data we previously entered (see section [**Creation of an RSA Own Key**](#creación-de-una-clave-propia-rsa)), in addition to information about the generated RSA key and different buttons to consult the generated public key and generate a new version of the key:
From this dialog some of the parameters we previously entered when creating the Own Key can be modified. It is not recommended to modify the 'TELEGC' service application.
Also, from the same dialog the following operations can be performed on the public key:
* Consult the generated public key.
* Generate a new RSA key pair that will constitute a new version of the Own Key.
**Consultation of the generated public key**
By pressing the button *Consult* in a version of the Own Key dialog we will see its public key:
This functionality is useful to compare the local own key, which we have generated and remains in our system, with the RSA Remote Key that the remote will have inserted into its system, incorporating the exchange file that we will have generated.
**Generation of a new version of an RSA Key**
There are three ways to generate a new version of an RSA Key:
* By clicking the button *Generate New Version* in the Own Key consultation dialog.
* By selecting the menu: *Own Keys/Generate New Version of the Key* after selecting the own key in the list.
* By right-clicking the Own Key for which we want to generate a new version and selecting *Generate New Version of the Key*.:
After confirming that you want to generate a new version, a process begins to create a new RSA key pair. A new version will be assigned to the new key pair and it will show us the version that has been assigned, making it possible to keep or increase the key size.
After asking us to confirm the changes in the generation of the new key, we will finally be able to see that there are two versions:
Up to three versions of a key can be stored and the list shows the versions that are currently being stored. We see that in the first key version 1 is stored and in the second version 2. Also, we see an 'A' in parentheses; this indicates that version 2 is the active version.
* **Active Version of an Own Key**
An own key can store up to three versions (three RSA key pairs); however, only one of them can be active. The active version is the version that will be exported when the key is associated with a remote. When a key is activated, the other two (if they exist) will be automatically deactivated.
Exceptionally, the operator can manually activate a version of the key. To do this, from the Own Key management dialog, click on the *Button* of the key version you want to activate.
**Associating Keys with Remotes**
Once we have an Own Key, we will need to create the Local RSA Subsystem that associates that key with a Remote Code. The same key can be sent to different remotes; each Local Subsystem records with which entities it has been exchanged, and in case there are multiple versions, which one is active with each remote entity.
To associate an Own Key with a remote we must select the own key from the list of Own Keys we want to assign and, using the right button, select *Assign a Remote*.
The dialog for assigning Remotes to Own Keys appears:
In the drop-down list of Editran/G Remotes, the registered remote codes appear. If the remote code has not yet been registered, you can fill in the '*Selected Remote*' field with the remote code you want to assign to the Own Key.
Once the remote is assigned, a new Local RSA Subsystem will be automatically generated.
Next, you are given the option to send the key to the remote at that moment:
Press *No* if you do not want to continue with the key exchange at that moment. You can resume it whenever you want. If we press *Yes* the sending steps will continue.
#### Local RSA Subsystem
As explained earlier, a local subsystem is created by associating an RSA Own Key with a remote.
In this section we will see how to send the generated key to the remote and what other actions can be performed on the subsystem.
**Own key exchange**
The exchange of an own key can be started in several ways:
* When assigning a remote to an Own Key, as indicated in **Associating Keys with Remotes**
* At any time using the toolbar, as indicated in the section **Sending the own public key**
* Selecting the RSA local subsystem from the list and with the right button choose in the context menu that appears:
In any of the cases, when this option is selected, the program performs the steps that apply to the state in which the subsystem is. On the screen, state ***Generated*** (G) corresponds to a key associated with a remote and pending sending. In this case the first step is the *generation of the own key export file*:
> 
The dialog shows the information of the exported key: information about the subsystem and the file that will be transmitted to the remote entity. Press *Generate* to create the file in the indicated path. If the action ends successfully the next step will be the *transmission through Editran*:
If you press *Cancel* the transmission is not carried out, and the local subsystem will reflect that the state is *"Sending Key File Generated (F)"*.
In this state, if the option *"Own key exchange"*is selected again in the context menu, the transmission dialog is shown again indicating the Editran/G Presentation and the file to be sent. If we now press "Send", the dialog will show the transmission status carried out by Editran.
If the transmission fails, the reason for the error can be consulted in the dialog:
And the key will remain in state *"Error sending Key File (E)"*.
Once the problem has been solved, the sending can be retried again by selecting *"Own key exchange"*. The next window shows an example of a transmission completed successfully. In this case the key state in the list will change to *"Key File Sent (S)"*.
In the *Subsystem Properties* dialog we will see the state and the creation date of the key and the state modification date:
**Receive confirmation from remote entity**
Once the remote has received our public key it will send us a confirmation file. This file indicates that the remote correctly incorporated the key and thus activates the key so that it can be used with that remote.
When using Editran as the transmission mechanism, receipt of the confirmation is automatic, and normally after a few minutes the key will appear as "*Active* without having to do anything.
However, if after some time the subsystem is still in state *"Key file sent (S)"* it is possible that the remote entity has some problem connecting to its Editran. In these cases, the confirmation can be received from Editran/GC. This can be done in two ways:
With the local subsystem selected, choose the option *"Own key exchange"* in the context menu. Given the state of the key, this dialog will appear to confirm whether you want to request receipt of the confirmation:
When pressing *"Yes"* the request is sent to Editran and its progress is shown in the Transmission dialog
If it is received correctly, the dialog shows the details of the received information, where you can see the full path of the received file and the type of exchange: confirmation in this case.
Now you have a key *"Active"* for that subsystem with that remote. This means that subsequent exchanges could already be signed, since, having exchanged the public key, it can be used to sign future key sends.
In this case the subsystem should be modified so that it is signed with subsystem 'L':
Another possibility for receiving the confirmation would have been to select in the menu *"Systems > Receive Remote Key/Confirmation File"*and select in the transmission window the Presentation associated with that subsystem.
**Subsystem key update**
If a new version of an Own Key has been created, the subsystems associated with that Own Key will need to be updated.
There are three ways to update the version of a local subsystem. Remember that it must be previously selected in the list:
* By clicking the button *"Update the local key of the Local RSA Subsystem"*.
* Selecting the menu *"Subsystems > Update the version of the own key"*.
* Select "*Update the version of the own key"* in the context menu that appears when you right-click on the list of local RSA subsystems.
When updating, the version of the key that is active within the Local Key will be copied to the subsystem. Then the exchange file will have to be generated and sent to the remote.
**In-flight Key Version**
Only one key version can be in flight within the same subsystem. Therefore, as long as there is a key in flight, the creation of more key versions will not be allowed.
A key is considered *in flight* when it is in the activation process, that is, when the key already exists, but it has not yet been sent to the remote and the confirmation file from it has not been received. Once confirmed, the key changes to state "*Active*" and stops being in flight, allowing new versions to be generated.
A version of the key that is *in flight* can cease to be so *By activating it* or *By cancelling it* manually.
### Generation of an RSA Remote Subsystem and sending the confirmation
Remote subsystems are created automatically when receiving keys from other Editran entities. They are generated with the data indicated by the remote in the key exchange file.
Normally the remote key exchange is initiated from the owning entity, so from Editran/GC you only need to check that the received keys appear in the "Non-Own" subsystem list.
Another possibility is that the remote tells you that it already has it generated and that it requests receipt from its Editran/GC. Below, this case is described.
#### Receive Remote Key File
When selecting the menu *"Systems > Receive Remote Key/Confirmation File"* the dialog will appear to choose the remote entity to which the receipt request is made:
In the transmission window, the progress of the receipt is notified, and if it finishes correctly, the information of the incorporated file appears:
Editran/GC when processing the remote key file:
* checks the signature of the exchange file (if applicable). The first time a subsystem is exchanged with a remote, the file is not signed because there is no key available to verify its signature. In successive exchanges of key versions, the exchange file may come signed.
* if the subsystem that comes in the file does not exist, it is automatically generated with the received data.
* the remote public key is extracted and saved in the key repository.
* Editran transmission is automated to automatically generate and send the confirmation to the remote.
Since key exchange is an automated process, the most common thing is that at this point in the list of *"Non-Own Keys"* the received key appears as "Active (A)".
When the remote subsystem is created from the exchange file, some field such as "Description" is not completed. The user can edit the subsystem to modify it.
If the automated process of a remote key exchange fails, the received key may remain in one of these states:
* *Remote Key Inserted (I)*: The key has been received and the generation of the confirmation file has failed.
* *Confirmation File Generated (F):* The sending of the confirmation has not been requested.
* *Error sending Confirmation File (E):* the confirmation transmission has not been completed.
In all cases, as long as the exchange has not been completed successfully, it can be retried from the point where it was left off. The Editran/GC application will resume the operation taking into account the state in which the subsystem is. The next section explains the operation in these cases with an example.
#### Remote key exchange
The complete exchange of a remote key consists of incorporating the received key file and generating a confirmation file that will be sent to leave the key *"Active"*. Occasional failures in the automatic process can leave the key in an intermediate state. In the example we have caused an error to leave the key in state "*Remote Key Inserted (I)*".
In these cases, once the reason that caused the error has been analyzed and resolved (possibly some configuration error in Editran), the exchange can be resumed from the graphical interface. To do this, in the context menu of the remote subsystem select the option *"Remote key exchange".*
In our case, given the current state, the application knows that the next step is to generate the confirmation, so the information of the file to be created is shown. Press *"Generate"* to confirm.
If it is generated correctly, the exchange will continue with the sending of the file:
And when the transmission ends you will see that the key appears in the list as *"Active (A)"*.
### Other common operations on subsystems
Next, common functionalities of Local and Remote RSA subsystems will be detailed.
#### Modification, Consultation and Deletion of a Local RSA subsystem
To see all local RSA subsystems we can select the appropriate branch in the tree or click on the *Show RSA Own Keys* button in the Toolbar.
To delete a subsystem, select it from the list and press \ or \.
To modify or consult a subsystem, double-click on the list line. The *Subsystem Properties*:
From here the following operations can be performed:
* Change properties and ***modify the subsystem***, by pressing the *"OK"*
* ***Consult a version of the key***, by pressing the *"Consult"* button for the key version.
* ***Activate a version of the ke***y, by pressing the *"Activate"* button for the key version you want to activate.
* ***Cancel a version of the key***, by pressing the *"Cancel"* button for the key version you want to cancel.
#### RSA key consultation
By pressing the button *Consult* from a version of the dialog of *Subsystem Properties* its public key will be displayed:
This functionality is useful to compare the local own key, which we have generated and remains in our system, with the RSA Remote Key that the remote will have inserted into its system, incorporating the exchange file that we will have generated.
#### Manual modification of the state of an RSA key
Manually changing the state of a key can be a dangerous operation, since it can leave the subsystem to which the change is applied unstable. It is recommended not to manually modify the state of a key unless you know exactly the effect that the modification may produce.
The Editran/GC application is designed so that the options for *"Own or remote key exchange"* adapt to the state the key is in, and resume the process from that point.
If there are situations that block the exchange, you can contact the product support team so they can guide you on the actions to take.
#### Activation and Cancellation of an RSA key
Through the dialog of *Subsystem Properties* you can activate or cancel a version of a subsystem key.
There can only be one version of a key in state *"Active (A)"* in a subsystem. When a key is activated, either automatically or manually, if another key was previously *"Active (A)"*, then it will change to state *"Operational (O)"*. To activate a version of the key, you must press the button *"Activate"* of the dialog of *Subsystem Properties*.
A version of a key can also be canceled. Canceling the key ensures that the key cannot be used. To cancel a version of the key, you must press the button *"Cancel"* of the dialog of *Subsystem Properties*.
## Using Onesait Editran/GC
Using Editran as the means of transmitting the exchange file greatly facilitates the operations required by Editran/GC.
There are basically two key advantages:
* Possibility of automatic sending and receiving, from the Editran/GC interface, of confirmation and key files.
* Possibility of automatic incorporation from Editran, through specific user programs, of the key file or the received confirmation file.
Next, we will explain how to take advantage of each of the advantages mentioned.
### Automatic sending and receiving using Onesait·Editran
Key exchange requires that in Editran there be a communication channel with the remote dedicated to this purpose. Editran/GC is responsible for creating the session and presentation based on the subsystem data (local code + remote code + service application or TELEGC).
The only requirement for it to be created correctly is that there already be another session with that remote that can serve as a template to configure the destination IPs.
#### Onesait Editran/G profiles
The exchange files to be transmitted, both the RSA key file and the confirmation file, have the same format. A table is then added showing the Presentation configuration parameters. These are the values with which Editran/GC creates the Presentation and must not be modified:
***
| Direction | Concept | Value |
| ------------ | ------------------------- | ----- |
| Transmission | Compression | Yes |
| Transmission | Alphabet | ASCII |
| Transmission | Application File Format | Fixed |
| Transmission | ASCII/EBCDIC translation | No |
| Transmission | Application record length | 00823 |
| Transmission | Delimiter | None |
| Reception | Translate on reception | ASCII |
| Reception | Delimiter | None |
***
### Automatic Procedure for Onesait Editran
The second advantage is the automatic incorporation of the key exchange and confirmation files sent by the remote.
Editran has the ability to add user programs that run before and after transmissions. This feature is what is used to automate key exchanges. The product provides specific user programs for these tasks, which are set when Editran/GC creates the presentation configuration, and which must not be modified.
## Utilities for managing keys
### gc\_config command
With the **gc\_config** command, you can both create and version your own RSA key as well as create the TELEGC session/presentation to receive the other party's key. In both cases, the command controls the state of the exchange and performs the necessary steps to complete it.
The program syntax is as follows:
```
gc_config. Editran/GC utility for key exchange.
Usage: gc_config [-k] [-v] [-l] -r -s
gc_config -R [-l] -r
Sending options:
-k : Generate a new key of length (4096 by default).
-v : Generate a new version of the subsystem.
-l : Editran code of local entity. Mandatory if multi-environment.
-r: Editran code of remote entity
-s : New Editran/GC subsystem
Receiving options:
-R : Mandatory to indicate that the key is going to be received.
-l : Editran code of local entity. Mandatory if multi-environment.
-r: Editran code of remote entity
```
**Example 1**\
Generation of a 4096-bit RSA key pair (Private + Public) for the local code **P00000020** and subsystem **N**. In addition, we associate the remote **L0009991099**:
```bash
gc_config -lP00000020 -rL00099910 -sN
```
If the command works correctly, the following message will appear:
```bash
gc_config -lP00000020 -rL00099910 -sN
[L] [Key 0] [Version 1] [Status Key Send File Generated]
```
**Example 2**\
Automatic generation of the session and presentation P00000020-L00099910-TELEGC
```bash
gc_config -R -lP00000020 -rL00099910
```
### gc\_vclaves command
Displays the information of the versions of an Editran/GC subsystem.
```
gc_vclaves. Displays the keys of an Editran/GC subsystem.
Usage: gc_vclaves [-L | -R] [-l] [-r] [-s]
Where:
-L : Own subsystem
-R : Remote subsystem
-l : Editran code of local entity
-r: Editran code of remote entity
-s : Editran/GC subsystem
```
Example:\
The command `gc_vclaves` invoked without parameters displays the information of all existing subsystems and their active version.
```
gc_vclaves
T Local Remote Sub Active_V
R L00000010 W00000010 N 15
L L00000010 W00000010 N 13
L L00000010 W00000110 N 13
R L00000010 W00000110 A 5
```
## Appendices
### Subsystem states
Below is a list of all possible states of subsystem keys:
***
| Id | State | Text |
| -- | ----------------------------------- | ---------------------------------- |
| 1 | CLAVE\_GENERADA | Generated Key |
| 2 | CLAVE\_OPERATIVA | Operational Key |
| 3 | CLAVE\_ACTIVA | Active Key |
| 4 | GENERADO\_FICHERO\_ENVIO\_CLAVE | Key Send File Generated |
| 5 | ENVIANDO\_FICHERO\_CLAVE | Sending Key File |
| 6 | ERROR\_ENVIO\_FICHERO\_CLAVE | Error Sending Key File |
| 7 | FICHERO\_CLAVE\_ENVIADO | Key File Sent |
| 8 | RECIBIDA\_CONFIRMACION | Confirmation Received |
| 9 | CONFIRMACION\_INVALIDA | Invalid Confirmation File Received |
| 10 | CLAVE\_REMOTA\_INSERTADA | Remote Key Inserted |
| 11 | GENERADO\_FICHERO\_CONFIRMACION | Confirmation File Generated |
| 12 | ENVIANDO\_FICHERO\_CONFIRMACION | Sending Confirmation File |
| 13 | ERROR\_ENVIO\_FICHERO\_CONFIRMACION | Error Sending Confirmation File |
| 14 | FICHERO\_CONFIRMACION\_ENVIADO | Confirmation File Sent |
| 15 | CLAVE\_CANCELADA | Canceled Key |
| 17 | CLAVE\_NO\_SELECCIONADA | Key Not Selected |
| 18 | CLAVE\_SELECCIONADA | Key Selected |
***
The table will be useful for locating, by identifier, each of the states in the following diagram.
### State Diagram
#### Own RSA key
State sequence diagram for an RSA key of an own subsystem:
#### Local Key
State sequence diagram for a Local key, both RSA and DES: 
#### Remote key
State sequence diagram for a Remote key, both RSA and DES: 
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.editran.onesait.com/documentacion-editran/open-v5.2.1-en/windows/gestor_claves.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.