> 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/linux/gestor_claves.md). # Key management ## Introduction 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, Editran has incorporated a reliable and secure management system to automate the exchange process, avoiding the weakness mentioned, preventing the display of plain-text keys and facilitating 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 supports multiple keys with versions 01 to 99 (when they reach that position they wrap around), keeping the last 3. The exchange with the entities will be carried out from an Editran session adapted for that purpose. ## Definitions and screens When running **editrangc** in the Editran directory, the main menu of the Editran/GC manager shown below will be activated: ![assets/image3.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-d34cab7278d1b4a90ee7ae2177b3d5ec85c31c4e%2Fimage3.png?alt=media) * **Management of own RSA keys**. RSA keys can be exchanged with different remotes without risk, since what is exchanged is the public key. The private key remains only in the system where it was created, so there is no possibility that the data could be decrypted by a third party. > For this reason there are the ***RSA Own Keys*** of Editran/GC. Through Own RSA Keys, a number of features common to all remotes that use that key are managed, such as: * Generation of new key versions (new public-private key pairs) * Activation of one version or another. * **Association of own RSA keys**. An own RSA Key cannot be used if it has not been exchanged with a remote. For this purpose, there is the option to associate 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. In addition, other common administration tasks will be performed from this option: modification, consultation and deletion of the subsystem. * **Association of remote RSA keys**. As recipients of remote public keys, we define ***Remote RSA Subsystems***. Creating a subsystem implies knowing the identifier that the remote assigned to it when defining it, since it must match in both entities. Once created, the new keys are incorporated by processing the received exchange files. ### Management of own RSA keys (administration and generation) It is accessed with option 1 and presents the following menu: ![assets/image4.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-6bd339deee5d325d5b2b24097fcd6018fd388662%2Fimage4.png?alt=media) * **Option**. Mandatory field. > **Subsystem**. Accepts values A-Z and 0-9. It is the name of the RSA subsystem that we are going to register. For example, we may have test or production subsystems, monthly or annual exchange subsystems, subsystems for one group of entities or another, etc. This field is optional except in the add option. > > **Local environment**. Editran code for the main local environment. It may be left unspecified when it is not an add operation. If any field has been selected in a generic way, a screen appears listing the subsystems that meet the proposed selection criterion, where the user can choose the record they are looking for: ![assets/image5.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-57dd21ccc48192f1017e9bea0b1078aed721b81a%2Fimage5.png?alt=media) The selected subsystems appear for each local code selected. If RSA keys (private -- public) have been generated, the active version and the generation and last modification dates are shown. If a record is selected or if the selection was specific from the previous menu, the following screen is shown (some fields may appear differently depending on the access option, add-delete-generation, modification or consultation): In the case of consultation: ![assets/image6.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-cb4c13d4227d3301e0fe642dd67e51015e10aee8%2Fimage6.png?alt=media) In the case of modification: ![assets/image7.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-d27d63903400e7f237f9c3ed6af826f98364cb4e%2Fimage7.png?alt=media) * **Subsystem description.** This is purely an informational field * **Service Editran/G application**. Name of the Editran/G application that will be used for key exchange. Default value: TELEGC. Although it can be modified, it is recommended to use this name since it also affects the Editran configuration. * **Label.** Label used to identify the public key. It is recommended not to modify this value unless you are fully aware of the problems that may arise. When registering the subsystem, the system shows the default value it sets for these fields. The administrator may modify its value at this time, always ensuring that it does not match that of another subsystem * **Key list**. Next, information about the last three generated versions is shown. For each version, its order number, creation and last modification dates, and its status (selected or not selected) are detailed. The selected version is the one currently being sent to the remotes. When a new version is generated, it becomes the selected key. From the modification option, the user, in addition to being able to change other fields, can set which of the versions shown is the one they want to exchange. To do this, they must enter an **A (activate)** in the line of the chosen version. In the case of consultation, if a version (S) has been selected, the public key is shown in hexadecimal (in the *label* the selected version is included). This information allows the user to manually verify whether a key has been exchanged correctly with a remote. To do this, it is necessary to check that the value is identical to the one that will appear to the remote when consulting the RSA remote key after incorporating the corresponding exchange file. ![assets/image8.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-f11cb13185178795cbedad150e21f5fefd316024%2Fimage8.png?alt=media) In the generation option, an intermediate confirmation screen is shown. The option to choose the key size length 1024, 2048, 4096 bits, seen in the help, is added. When confirming, the menu will remain locked while the operation is carried out. In case it may take some time, the user will be warned with an informational message: ![assets/image9.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-797f651ad002f7676738c5cda5075bf52769fb5a%2Fimage9.png?alt=media) In the case of deletion, a confirmation screen is shown. Own RSA records cannot be deleted if there is any remote associated with them. ![assets/image10.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-90b96f2f792d3d8dd4aca17744fa96a443ca91a3%2Fimage10.png?alt=media) ### Association of own RSA keys (administration, export and sending). To access this option, an appropriate RSA (option 1) record of own keys must exist. That is, with the same local code and subsystem. It is accessed with option 2 and the following screen is shown: ![assets/image11.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-2bc1cb2a72605f59f53c75fa57dbb5c2b1f88cd5%2Fimage11.png?alt=media) * **Option**. Mandatory field. * **Subsystem**. Accepts values A-Z and 0-9. It is the own keys RSA subsystem that we are going to associate with a certain remote entity. This identifier is the one we will notify to the remote so that it can register it as a "remote subsystem" and, under that name, incorporate the key we send it. * **Local environment**. Editran code for the main local environment. If it is not filled in, the list of possible local codes will be displayed (multi-environment licenses). * **Remote environment**. Editran code for the remote entity. If it is not filled in, the list of existing remote codes will be displayed. In the option ***ADD*** all fields must be filled in. In the remaining options, if they are not filled in, a screen will appear showing the list of found subsystems that match the given search criterion. The user can select one by typing **S** in the column **SEL**: On the selection screen, only if the subsystem has an active key with the remote, the version number and generation and last modification dates are shown. When selecting a record or if the selection was specific from the previous menu, the following screen is shown (some fields may appear differently depending on the access option, add-delete-export, modification or consultation): ![assets/image12.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-1e48493a790e5bfc08257588c946f27a415a6d97%2Fimage12.png?alt=media) In the case of modification: ![assets/image13.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-d21f79e3ba6326b0b673423f6b4bf8ec218bce24%2Fimage13.png?alt=media) * **Subsystem description.** This is purely an informational field * **Editran/G application**, through which we will send our public key to the remote. * **Label**. It is protected. It is the label of the corresponding own RSA key. * **RSA subsystem for signing**. It may be the same one (if keys have been exchanged through it) or different (if keys have been exchanged through another). If keys have not been exchanged with the remote entity, this field must not be filled in. * **Key list**. Next come the versions that have been exchanged with that remote and their status (active, canceled, operational, etc.). There can only be one "active" key. A key sent to a remote becomes active when confirmation is received from the remote that it has been correctly incorporated; if there was already one active, it becomes operational. Exceptionally, keys can be activated and canceled manually by the user from the modification menu. The consultation and deletion options work in the same way as mentioned in the previous section. A local RSA subsystem can only be deleted when it is not being used to sign key exchanges from other subsystems. The option ***EXPORT NEW KEY***, "associates" the key currently *selected* from the subsystem's RSA own-keys record to the remote entity and creates a file with the corresponding local public key (it may be signed if there has been a successful RSA key exchange with that remote). This file will be sent by Editran automatically if so indicated. When selecting this option, the following intermediate confirmation screen is shown. ![assets/image14.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-acded2ed2435ae963cabb5d0332536fffac6cee1%2Fimage14.png?alt=media) In the field *Export File* the system shows the name of the file that will be created to send the new key to the remote. The default file name follows a standard that allows the content of the information to be identified. It can be modified if the user wants to use another naming convention. The key exported to the exchange file will be the one in status "*selected"* of the three own RSA keys. A new exchange file will not be allowed to be generated if another key exchange is in the process of being finalized. Once the exchange file has been generated and if the user requests it with the field *Do you want to send now*, the file will be attempted to be sent by Editran. To chain the sending process, it is necessary that a control session has previously been configured in Editran with the same local and remote codes, and with the Service Application name or TELEGC. Depending on whether or not the Editran send is requested in the export window, several situations may arise: * If everything goes well, and if the user did not chain the sending through Editran, the status of the key will be: ![assets/image15.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-be5993521f06ac95952b55e3d99b5341e427c4bb%2Fimage15.png?alt=media) * If sending is requested and Editran is not correctly configured, an error message will appear and the status of the key will not change. Once the problem is solved, you can try the export again. ![assets/image16.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-138473e8bfa83543f3780b7fcca4c8b1d2730335%2Fimage16.png?alt=media) * If sending is requested and an error occurs during transmission, the message displayed will indicate the reason. In this case, the status of the key will be *"Error sending the key file"* ![assets/image17.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-5f6dc8446069d5aff9c7f613d2159c2488b3be20%2Fimage17.png?alt=media) At this point, if we try to export a new key again, the system will display an error message (*"No key prepared for export"*) because there is a key pending to be sent. When the transmission problem is resolved, you can try sending again from the Editran menu. Another option is to cancel the pending key manually from the option of **Modification** and repeat the exchange from the beginning. ### Association of remote RSA keys (administration). A remote subsystem can be generated in two ways: **√** Automatically using the Editran/G post-reception user program. No action is necessary before receiving the remote entity's key. **√** Manually through the graphical interface as shown below. In this case, it is necessary to know in advance the name the remote entity gave to the subsystem. Select the option **4** from the main menu and in the RSA remote keys association menu select the option **ADD**. In this option it is mandatory to specify local code, remote code and subsystem. ![assets/image18.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-68f8847bb2b82b4db5ba1a84ee051927ac2709b1%2Fimage18.png?alt=media) Once the subsystem to be created has been selected and as long as another one with the same data does not already exist, the following screen is shown: ![assets/image19.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-6f88967d6c20d39db6ff25a21f42ca53f8fdaff6%2Fimage19.png?alt=media) There the user will optionally fill in the description and may modify the labels that the system assigns by default, although it is recommended not to modify them since working with the default values ensures that there are no repeated "labels". The Editran/G service application is used if confirmations are to be sent through Editran. It is recommended to use the Editran/G TELEGC application. In the field *Signing RSA Remote Subsystem* the subsystem with which the remote signed the last incorporated exchange file is shown to the user. It is purely informational and cannot be modified. By pressing F3, the new remote RSA subsystem will be generated. However, the public key needed is not yet available. It will have to be added automatically using Editran/G automation or manually from the option **IMPORT NEW KEY**. As seen in the previous sections, for the rest of the administration options (delete, consultation, modification) the same screen appears, where in addition to the information related to the subsystem, the data of the last three received keys (version, status, and creation and modification dates) are shown. In **DELETE**, after asking for the user's confirmation, pressing ENTER will delete the displayed subsystem. Remote RSA subsystems that are being used to authenticate the sending of any other subsystem are not allowed to be deleted. ![assets/image20.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-43dd2b42ea3d541e2b67965a0b20c7332ecdf8a1%2Fimage20.png?alt=media) In **VIEW**, using the cursor keys the user can select the version for which they want to see the public key. In **MODIFICATION**, using the tab key the user moves through the subsystem fields that can be modified. In addition, in the list of versions the user can modify the status of the key, by entering **A** (activate) or **C** (cancel) in the corresponding line. ![assets/image21.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-a159a5718fce3d97c2fda9607b15a21adc3e4fa7%2Fimage21.png?alt=media) In **IMPORT NEW KEY**, the received exchange file must be selected and the operation confirmed. ![assets/image22.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-1695dd62fb653a4a42a53ec0144bbc412f92166e%2Fimage22.png?alt=media) Editran/GC first checks the signature of the exchange file, then checks that the subsystem in the file matches the subsystem shown on the screen. If it matches, the public key is incorporated; otherwise the error message shown is *Subsystem not found*. ## Operation example This section summarizes the steps the user must follow to exchange RSA keys using Editran/GC. Let us assume that the 2 entities are identified by the codes: L9991 (local) and R9991 (remote). Assuming that both agree to exchange their keys using the TELEGC service application, they must have an Editran/G presentation defined for those codes and that application. ### RSA key exchange #### Generation and sending of a local RSA key * **Generate an RSA key pair:** * Select option **1**: Management of Own RSA Keys * Select **A**: ADD by entering in SUBSYSTEM **T** (or the identifier you want) and its LOCAL ENVIRONMENT. In the example. ![assets/image23.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-add9b4451708cd877b5c13c2a9d0a2ecc06cef7d%2Fimage23.png?alt=media) * Complete the rest of the fields on the next screen, which includes the size of the key to be generated, and press Enter to generate version 1 of the key. By default the key will be generated at 2048, but you can select 1024 or 4096 if required. ![assets/image24.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-46a581d4f243b00b457515079981d54f81695b5e%2Fimage24.png?alt=media) * Check by selecting **C**: VIEW that the generated key is the one that remains as *selected*. ![assets/image25.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-3c956138494d3c46b8aa7d906c11661c0b636155%2Fimage25.png?alt=media) * **Associate and send local keys to the remote** * Select option **2** from the main menu: *Association of own RSA keys*. * Select **A** (ADD) by entering in SUBSYSTEM **T**, LOCAL ENVIRONMENT **L9991** and REMOTE ENVIRONMENT **R9991** to establish that we want to exchange the previously generated key with that remote. * Note that on the screen that appears, the field *"LABEL"* cannot be modified since it must match the one given during generation. If we had already exchanged some RSA key with this remote, we could sign the sending of the following keys. ![assets/image26.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-0126b1c210ba258ef31267302c51f8bee77d7e47%2Fimage26.png?alt=media) * Check by selecting **C** (View) that the key for that remote has been updated with the associated own key. The status of the key at this time is *"Generated Key"*. ![assets/image27.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-36eebb73ff29e6786ab4dca9c5202c7b65f06d19%2Fimage27.png?alt=media) * Select **E** (Export new key) to generate and/or send the exchange file for the remote. If sending is requested, and as recommended throughout this manual, the entities have Editran configured so that the exchange process is automatic, what you will observe is that in a few minutes, when consulting the subsystem, the key will appear as "*Active Key*". ![assets/image28.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-082337b9f59c7ca1d0b792ed7c0b9fdc4ac714c8%2Fimage28.png?alt=media) * If the remote entity had any problem sending its confirmation file, it will need to request reception from Editran to complete the next step. * **Receipt of the confirmation file** Once the remote has inserted our public key, it will send us a confirmation file. This file indicates that the remote incorporated the key correctly and that it can be used with that remote. If we are using Editran and have the post-reception automation of Editran/GC, then upon receiving the confirmation, the key will be automatically activated. #### Generate and send a new version of the key To generate a new key pair for this subsystem, enter the menu ***Management of own RSA keys*** and select the option **G** (Generation). Once the operation has been confirmed, enter consultation and verify that the key list shows the new version as the currently selected key. ![assets/image29.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-46020ab237bc16e636db4a2aa878028f5025aa18%2Fimage29.png?alt=media) To send this new version, enter the menu ***Association of own RSA keys*** and select the option **E** (Export), filling in or choosing the desired subsystem. In this case, before generating the exchange file, the subsystem key will automatically be updated with the selected version from the list of own keys. In the name of the file to be exported you can see the version that will be sent in the extension. In this case **v02.** ![assets/image30.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-4f4209dfb0936a05bc243539ed458a21f927fbc5%2Fimage30.png?alt=media) From here on, the export process is the same as explained in the previous section. Once the new key has been sent, it will appear in the subsystem's version list as the active key, and the previous one will remain as operational. ![assets/image31.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-31d0aa7e0ff7402b3be2436ccaa0c5e04903a137%2Fimage31.png?alt=media) #### Incorporating and confirming remote RSA keys * **Generate remote RSA subsystem.** This section explains how to register a new remote subsystem from the Editran/GC menu. It is important to emphasize that this step is not necessary in the automatic exchange process. * Select the option **4** from the main menu: RSA remote keys association. * Select **A** (Add). The data that identify this subsystem are decided by the remote, so before registering it we must know this information. If we assume that the remote tells us that it has defined subsystem 2, in the add fields we will enter: ![assets/image32.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-af6fcb0eec547c2e3ed30a10fec00297e12777d4%2Fimage32.png?alt=media) * Complete the editable fields on the next screen and press F3 to generate the new subsystem. ![assets/image33.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-33ed41bbef4cd4c1ee1fa7aa25fe8b12b077cfdc%2Fimage33.png?alt=media) * **Incorporate new key.** To do this, the received key file must be processed. As mentioned earlier, this can be done in two ways: using a user program or from the graphical interface. * The user program is explained in [PSTRECGC](#pstrecgc). Keep in mind that when processing the file, the subsystem contained in the file would be generated automatically if it did not already exist. * From the graphical interface, once the subsystem for which you want to incorporate the key has been registered, select the option **I** (Import) for that subsystem and enter the path of the file to be processed on the confirmation screen. In this case, it will be validated that the subsystem data in the file match those specified by the user. * If everything goes well, go to **C** (View) to display the key list once it has been incorporated. * **Confirm the key incorporation** After incorporating the remote RSA public key, a confirmation file must be generated and sent to the remote so that it can verify that the incorporation process was carried out correctly and thus move the key to status *"Active"* so that it can be used by Editran. The generation and sending of the confirmation file is done automatically when the key is received, provided that the Editran/G presentation has the PSTRECGC post-reception user program configured. ## Key exchange in Onesait Editran Using Editran as the means of transmitting the exchange file facilitates the necessary operation of Editran/GC. There are fundamentally two key advantages when using Editran: * Possibility of automatic sending and receiving, from the Editran/GC interface, of confirmation and key files. * Possibility of automatic incorporation from Editran, through a post-reception user procedure, of the exchange 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 #### Local Subsystem For a transfer file that contains an RSA key, that is, a file generated by Editran/GC when creating a new version of a key in a local subsystem, to be sent automatically, it is only necessary to add the Editran/G Service Application parameter. In addition, it will be necessary to register the presentation and session in Editran, taking into account that the local code and remote code of Editran/G must match the local code and remote code of the Editran/GC subsystem. #### Remote Subsystem For a confirmation file, that is, a file generated by Editran/GC when inserting a new version of a key in a remote subsystem, to be sent automatically, it is only necessary to add the Editran/G Service Application parameter in the Remote subsystem. In addition, it will be necessary to register the presentation and session in Editran/G, taking into account that the local code and remote code of Editran/G must match the local code and remote code of the Editran/GC subsystem. #### Onesait Editran/G profiles The exchange files to be transmitted, both the key file and the confirmation file, have the same format that must be registered in the Editran/G Presentations. Below, a table is added showing the configuration parameters of the Presentation: *** | Direction | Concept | Value | | ------------ | ------------------------- | ----- | | Transmission | Compression | If | | 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 Procedures 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. If automatic incorporation of the files is to be used, the "Post" user programs must be modified and those delivered in the product specifically for Editran/GC must be used. ![assets/image34.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-49cefbb62d6fa8335afcf72010afb7855e378959%2Fimage34.png?alt=media) Therefore, in the Editran/G Presentation, with local code and remote code the same as those registered in Editran/GC, and with the TELEGC Application, it must be modified as shown on the screen. #### PSTRECGC It is a special procedure that processes the received exchange file. If it is a Key file, it incorporates the RSA key, associating it with the corresponding subsystem, and confirms its receipt to the remote end so that it can be used in the next transmission. If a confirmation file is received, the status of the corresponding key is updated to "Active". In the reception post there is the call to the command **insertgc\_r** from Editran/GC that performs these actions. #### PSTEMIGC It is a special procedure that processes the issued exchange file and updates the status of the corresponding key. If it is a Key file the status will be *"Key File Sent"*, and if it is a Confirmation file the new status will be *"Active Key"*. In this post the command is called **insertgc\_e** from Editran/GC that performs this task. ### Utility for managing keys #### gc\_config command To make RSA key exchange easier for the user, there is a utility that allows the entire process to be carried out without needing to use the graphical interface and follow the steps that have been described in this manual. With the command **gc\_config** it is possible both to create and send your own RSA key and to receive someone else's key. In both cases, the command controls the status of the exchange and performs the necessary steps to complete it. See the quick guide AES/RSA Configuration for details on how to use this utility. 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 Reception 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 ``` #### 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 ``` ### Encryption parameters in Onesait Editran The keys exchanged through Editran/GC are used in Editran for the transmission of protected data. Specifically, they are used in transmissions configured with RSA authentication. You can consult detailed information on the cryptography parameters in the Editran/G and Editran/P User Manuals. As an example, the screen of a Presentation configured to use Editran/GC subsystems is shown. ![assets/image35.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-639ae77bf7dd0a69c65314ed09b94932654f79a4%2Fimage35.png?alt=media) ## 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 the 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: ![assets/image36.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-c55d73bcc89cf862d623bfd1360c1b234a0e982f%2Fimage36.png?alt=media) #### Local Key ![assets/image37.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-1e7802a065a864a450681f55a3c253067d2bf71e%2Fimage37.png?alt=media)State sequence diagram for a Local RSA key: #### Remote Key State sequence diagram for a Remote RSA key: ![assets/image38.png](https://2807498471-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F2W4cn5C1WDTJzDOR25es%2Fuploads%2Fgit-blob-1032fef31f0f17f2731b6492130592e8e0443259%2Fimage38.png?alt=media) *Contact person* Brussels Ave. 35\ 28108 Alcobendas,\ Madrid, Spain\ T +34 91 480 50 00\ F +34 91 480 50 80 [www.minsait.com](http://www.minsait.com) --- # 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/linux/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.