> 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.3-en/linux/gestor_claves.md). # Key Management ## Introduction Editran gives the user the possibility of using several ways to exchange protected data through the following cryptography modes: **Mode 3.0** Authentication cryptography with DES or RSA (1024 bits) and confidentiality TDES (triple key). 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: TDES (triple key) and AES with 128-, 192- and 256-bit keys. In all modes, 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, phone, etc., which in many cases reveals the "weakness of the exchange". Starting with version 4.1, Editran has incorporated reliable and secure management to automate the exchange process, avoiding the weakness mentioned, preventing the display of keys in clear text, 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 some private key for which we know that the corresponding associated public key has been sent to the remote side. That is, in the second exchange, at least the initial one can be used to sign; in the third, the initial or the second, and so on. In addition, all management has been structured into "subsystems". A subsystem is a group of keys exchanged for a certain remote, group of remotes, or applications. Each subsystem supports several keys with version 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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-e476433b28d4cc414af8121316ca234f4952ff75%2Fimage3.png?alt=media) * **Management of own RSA keys**. RSA keys can be exchanged safely with different remotes, since what is exchanged is the public key. The private key remains only on the system where it was created, so there is no possibility that the data can be decrypted by a third party. For this reason there are the ***RSA Own Keys*** of Editran/GC. Through Own RSA Keys, a series of functions common to all remotes that use that key are managed, such as: * Generation of new versions of the key (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 there is the possibility of associating an Own Key with a Remote, creating a ***RSA Local Subsystem***. Once associated, the exchange file can be generated and sent to the remote so that it incorporates our public key. In addition, this option will perform other common administration tasks: modification, consultation and deletion of the subsystem. * **Association of remote RSA keys**. As receivers of remote public keys, we define ***Remote RSA Subsystems***. Creating a subsystem implies knowing the identifier that the remote gave 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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-a4666c44c46cb5939313897dc1d81302169f7b8a%2Fimage4.png?alt=media) * **Option**. Required field. * **Subsystem**. Accepts values A-Z and 0-9. It is the name of the RSA subsystem 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 registration option. * **Local environment**. Editran code of the main local environment. It may be omitted when this is not a registration. If any field has been selected in a generic way, a screen appears listing the subsystems that meet the proposed selection criterion and where the user can choose the record they are looking for: ![assets/image5.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-1f712b2ee67fc58f56be670afd6ed2ac6eadb1db%2Fimage5.png?alt=media) The selected subsystems appear for each selected local code. If RSA keys (private -- public) have been generated, the active version and the creation 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-remove-generation, modification or query): In query mode: ![assets/image6.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-2e57b4356371e3639f0815daf082cd2672be7fda%2Fimage6.png?alt=media) In modification mode: ![assets/image7.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-283739cd9aa484db0c38d503dcb45dee03afbd2d%2Fimage7.png?alt=media) * **Subsystem description.** It is purely informational * **Editran/G service application**. Name of the Editran/G application that will be used for key exchange. Default value: **TELEGC**. > Although it is allowed to modify it, it is recommended to use **TELEGC** 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 default value established by the system for these fields is shown.\ 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 sequence number, creation and last modification date, and its status (selected or not selected) are detailed. The selected version is the one that is 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 put an **A (activate)** on the line of the chosen version. In query mode, if a version has been selected (S), the public key is shown in hexadecimal (in the *label* the selected version is included). This information allows the user to manually check whether a key is correctly exchanged with a remote. To do this, it must be verified that the value is identical to the one that will appear to the remote when querying the remote RSA key after incorporating the corresponding exchange file. ![assets/image8.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-9d750b265d222a382870477c22411c8ee2fde530%2Fimage8.png?alt=media) In the generation option, an intermediate confirmation screen is shown. The option is added for the key size: 1024, 2048, 4096 bits, as seen in the help. When confirmed, the menu will remain blocked while the operation is carried out. If it may take some time, the user will be warned with an informational message: ![assets/image9.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-74be08b447a34b41fd03376345894d91687e97a8%2Fimage9.png?alt=media) In case of removal, a confirmation screen is shown. OWN RSA records cannot be removed if there is any remote associated with them. ![assets/image10.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-1665dfb8cd0951b06597dbc8901fc7495f416e17%2Fimage10.png?alt=media) ### Association of own RSA keys (administration, export and sending). To access this option, there must be an appropriate RSA (option 1) record of own keys. 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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-086f64df79dbee2b6e4ef05f5e21e3f6bd2a1467%2Fimage11.png?alt=media) * **Option**. Required field. * **Subsystem**. Accepts values A-Z and 0-9. It is the own-key RSA subsystem that we are going to associate with a given remote entity. This identifier is the one we will notify the remote about so that it registers it as a "remote subsystem" and under that name incorporates the key we will send it. * **Local environment**. Editran code of the main local environment. If left blank, the list of possible local codes (multi-environment licenses) will be shown. * **Remote environment**. Editran code of the remote entity. If left blank, the list of existing remote codes will be shown. In the ***ADD*** option, all fields must be filled in. In the other options, if they are not filled in, a screen will appear showing the list of subsystems found that match the given search criterion. The user can select one by typing **Y** in the column **SEL**: On the selection screen, only if the subsystem has an active key with the remote, the version number and creation 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-remove-export, modification or query): ![assets/image12.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-0950ad17fbc359a5853981ec72de3125019b8159%2Fimage12.png?alt=media) In modification mode: ![assets/image13.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-0e38edb63b6ce0bd2b203291a4035076ba91f61d%2Fimage13.png?alt=media) * **Subsystem description.** It is purely informational * **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 (if keys have been exchanged through it) or different (if they have been exchanged through another). If keys have not been exchanged with the remote entity, this field does not need to be filled in. * **Key list**. Next, the versions that have been exchanged with that remote appear, along with their status (active, canceled, operational, etc.). Only one key can exist as "active". A key sent to a remote becomes active when confirmation of its correct incorporation is received from the remote; 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 operation of the query and removal options is the same as described in the previous section. A local RSA subsystem can only be deleted when it is not being used to sign the key exchanges of other subsystems. The option ***EXPORT NEW KEY***, "associates" the 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 any successful RSA key exchange with that remote). This file will be sent by Editran automatically if indicated. When this option is selected, the following intermediate confirmation screen is shown. ![assets/image14.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-fa6e2f09292a31bc825cd3f7908cf62259bcd68b%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 sent 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 state "*selected"* of the three own RSA keys. A new exchange file will not be allowed to be generated if there is another key exchange 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 via Editran. To be able to chain the sending, it is necessary that an Editran control session with the same local and remote codes, and with the name of the Service Application or TELEGC, has previously been configured in Editran. Depending on whether or not sending via Editran is requested in the export window, several situations may occur: * If everything goes well, and if the user did not chain the sending via Editran, the key status will remain: ![assets/image15.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-b5cbeeb2a8882acaa0eb0dfd38fdffeb1298c717%2Fimage15.png?alt=media) * If sending is requested and Editran is not correctly configured, an error message will appear and the key status will not change. Once the problem is solved, the export can be tried again. ![assets/image16.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-138473e8bfa83543f3780b7fcca4c8b1d2730335%2Fimage16.png?alt=media) * If sending is requested and an error occurs during transmission, the message shown will indicate the reason. In this case the key status will be *"Error Sending the Key File"* ![assets/image17.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-5f6dc8446069d5aff9c7f613d2159c2488b3be20%2Fimage17.png?alt=media) At this moment, if we try to export a new key again, the system will return an error message (*"No key ready to 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 by manually canceling it from the **Modification** option and repeating the exchange from the beginning. ### Association of remote RSA keys (administration). A remote subsystem can be created in two ways: **√** Automatically using the post-reception Editran/G user program. No action is needed 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 that the remote entity has given to the subsystem. Select the option **4** from the main menu, and in the remote RSA key association menu select the option **ADD**. In this option it is mandatory to specify local code, remote code and subsystem. ![assets/image18.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-60059589142d749a571f991cfd1947f021e3344f%2Fimage18.png?alt=media) Once the subsystem to be created has been selected and as long as no other one with the same data already exists, the following screen is shown: ![assets/image19.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-20c854e0b86467dee186367db001c81ac1a8ae2d%2Fimage19.png?alt=media) In this one, the user will optionally fill in the description and can modify the labels assigned by the system by default, although it is advisable not to change 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 via Editran. It is recommended to use the TELEGC Editran/G application. In the field *Signing Remote RSA Subsystem* the user is shown the subsystem with which the remote signed the last incorporated exchange file. 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 through the Editran/G automations or manually from the option **IMPORT NEW KEY**. As seen in the previous sections, for the rest of the administration options (removal, query, modification) the same screen appears, in which, 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 **REMOVAL**, after asking for user confirmation, pressing ENTER will delete the displayed subsystem. Remote RSA subsystems that are being used to authenticate the sending of another subsystem cannot be deleted. ![assets/image20.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-52db014e9d3c3004812156a6029c0eb1368b8cb3%2Fimage20.png?alt=media) In **QUERY**, using the cursor keys the user can select the version for which they want to view the public key. In **MODIFICATION**, using the tab key the user moves through the subsystem fields that are editable. In addition, in the list of versions they can change the key status by putting **A** (activate) or **C** (cancel) on the corresponding line. ![assets/image21.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-ae7d010483554fec7ff135a941481abbe5e44a66%2Fimage21.png?alt=media) In **IMPORT NEW KEY**, the exchange file received from the remote must be selected and the operation confirmed. ![assets/image22.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-4b0a69fee6e7ca4e75e2970e27e730eccd9c1668%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. Suppose the 2 entities are identified with the codes: L00000010 (local) and W00000010 (remote). Assuming both agree to exchange their keys through the TELEGC service application, they must have a presentation in Editran/G 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**: Own RSA key management * Select **A**: ADD by entering in SUBSYSTEM **T** (or the identifier desired) and its LOCAL ENVIRONMENT. In the example. ![assets/image23.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-a4bce4c4c2cb0d96331b64264b16d49417baaecb%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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-69d32829621f11e7ba847fad61e7eeb2e6b96e6b%2Fimage24.png?alt=media) * Check by selecting **C**: QUERY that the generated key is the one that remains as *selected*. ![assets/image25.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-d194197e8115674f6d690b65851eb29421eab789%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 **L00000010** and REMOTE ENVIRONMENT **W00000010** 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 in the 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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-ad48eff7cd4622e1fe64f74e65c3d45b3dc25b03%2Fimage26.png?alt=media) * Check by selecting **C** (Query) that the key for that remote has been updated with the associated own key. The status of the key at this moment is *"Generated Key"*. ![assets/image27.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-91391d5e302c58277be753e1876377d3bd45c540%2Fimage27.png?alt=media) * Select **E** (Export new key) to generate and/or send the exchange file for the remote. See the section explaining the different cases. 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 you query the subsystem the key will appear as "*Active Key*". ![assets/image28.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-3e413bd1075ed851555455dbf4cc4f28be3c5ea5%2Fimage28.png?alt=media) * If the remote entity had any problem when sending you its confirmation file, it must request the reception from Editran to complete the next step. * **Confirmation file reception** Once the remote has inserted our public key, it will send us a confirmation file. This file tells us that the remote correctly incorporated the key and that it can be used with that remote. If we are using Editran and have the Editran/GC post-reception automation, 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 query mode and check that the key list shows the new version as the currently selected key. ![assets/image29.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-8f518bee5120ceda2afefa69f4a7efdd5f9e9bf8%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 selecting the desired subsystem. In this case, before generating the exchange file, the subsystem key will be automatically 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 to be sent in the extension. In this case **v02.** ![assets/image30.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-1fb1b73bf00909e48831cf753030c5487e66fd23%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 be shown in the subsystem's version list as the active key, and the previous one will remain operational. ![assets/image31.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-c76c0d3ef1e170014c4f5b989789d478ff234dc5%2Fimage31.png?alt=media) #### Incorporate and confirm remote RSA keys * **Generate remote RSA subsystem.** At this point it is explained 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: Remote RSA key 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 it has defined subsystem 1, in the fields of the registration we will enter: ![assets/image32.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-f4775b25d68edccd74e366817dd9da9f3fd5a552%2Fimage32.png?alt=media) * Fill in the editable fields of the next screen and press F3 to generate the new subsystem. ![assets/image33.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-d3fa314a79786f2f2d68ef537a40460541f4797a%2Fimage33.png?alt=media) * **Incorporate new key.** To do this, the received key file must be processed. As mentioned before, this can be done in two ways: by means of a user program or from the graphical interface. * The user program is explained in the section [PSTRECGC](#pstrecgc). It must be taken into account that when the file is processed, the subsystem in the file would be generated automatically if it did not exist. * From the graphical interface, once the subsystem for which the key is to be incorporated 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 matches those specified by the user. * If everything goes well, enter **C** (Query) to view the list of keys once 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 set the key to state *"Active"* so that it can be used by Editran. The generation and sending of the confirmation file is done automatically upon receiving the key as long as the Editran/G presentation has the PSTRECGC post-reception user program configured. ## Key exchange in Onesait Editran Using Editran as the transmission medium for the exchange file facilitates the required operation of Editran/GC. There are fundamentally two key advantages when using Editran: * Ability to automatically send and receive confirmation and key files from the Editran/GC interface. * Possibility of automatic incorporation from Editran, via a post-reception user procedure, of the exchange file or the received confirmation file. Below, each of the aforementioned advantages will be explained. ### Automatic sending and receiving using Onesait Editran #### Local Subsystem For an exchange file containing 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, you simply need to add the Editran/G Service Application parameter. In addition, the presentation and session must be registered 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, you simply need to add the Editran/G Service Application parameter in the Remote subsystem. In addition, the presentation and session must be registered 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 Presentation configuration parameters: | 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 Procedures for Onesait Editran The second advantage is the automatic incorporation of the key exchange and confirmation files that the remote sends us. Editran has the ability to add user programs that run before and after transmissions. If you want to use automatic incorporation of the files, you must modify the "Post" user programs and use those provided in the product specifically for Editran/GC. ![assets/image34.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-352095934036f5b72e242396785c07a084e2f03d%2Fimage34.png?alt=media) Therefore, in the Editran/G Presentation, with the 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 handles the received exchange file. If it is a key file, it incorporates the RSA key associating it with the corresponding subsystem and confirms its reception 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 post-reception there is the call to the command **insertgc\_r** of 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 *"Sent Key File"*, and if it is a Confirmation file the new state will be *"Active Key"*. In this later step the command is called **insertgc\_e** from Editran/GC that performs this task. ### 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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-87b69287dcd27ebd3a36080347834ce6dcba216f%2Fimage35.png?alt=media) ### Utilities for managing keys #### gc\_config command To make RSA key exchange easier for the user, there is a utility that allows them to carry out the entire process without needing to use the graphical interface and follow the steps that have been described in this manual. With the command **gc\_config** you can both create and send your own RSA key and receive another party's key. In both cases, the command controls the state of the exchange and performs the necessary steps to complete it. See the quick guide AES/RSA Configuration for detailed instructions on how to use this utility. The program syntax is as follows: ``` gc_config. Editran/GC utility for key exchange. Use: 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 the local entity. Required if multi-environment. -r: Editran code of the remote entity -s : New Editran/GC subsystem Reception options: -R : Required to indicate that the key will be received. -l : Editran code of the local entity. Required if multi-environment. -r: Editran code of the remote entity ``` #### gc\_vclaves command Shows the version information of an Editran/GC subsystem. ``` gc_vclaves. Shows the keys of an Editran/GC subsystem. Use: gc_vclaves [-L | -R] [-l] [-r] [-s] Where: -L : Own subsystem -R : Remote subsystem -l : Editran code of the local entity -r: Editran code of the remote entity -s : Editran/GC subsystem ``` Example: The command `gc_vclaves` invoked without parameters shows the information for 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 ``` #### introsec command (for Triple DES 3.0 cryptography) Adds a new application key to the file `/cfg/ckds.des`. Usage: `introsec [-g]` * `-g`: generates the keys randomly; only the label is requested. * Without `-g`: requests the label and keys manually. When run, the command asks for: * **Label**: label of exactly 14 characters to identify the key (e.g.: `LABEL_LOCALC01`). * **Key #1**: 16 hexadecimal characters (only 0–9 and A–F), for example `A1F1A7C1B2B2A4B2`. * **Key #2**: 16 hexadecimal characters, to use a double key, in the example `A1F1A7C1B2B2B3B4`. Example — manually entered key: ``` $ introsec introsec [-g]. Incorporation of an Application Key into ckds.des. Enter the LABEL of the Application Key (14 characters): LABEL_LOCALC01 Type the APPLICATION KEY #1 (16 hex digits): A1F1A7C1B2B2A4B2 Type the APPLICATION KEY #2 (16 hex digits): A1F1A7C1B2B2B3B4 The new Application Key [LABEL_LOCALC01] has been saved correctly in 'ckds.des'. ``` Example — randomly generated key (`-g`): ``` $ introsec -g introsec [-g]. Incorporation of an Application Key into ckds.des. Enter the LABEL of the Application Key (14 characters): LABEL_LOCALC02 APPLICATION KEY #1 (hex): 3170EF4F5BDC5DF2 APPLICATION KEY #2 (hex): 9E6E64B5DAF7130D The new Application Key [LABEL_LOCALC02] has been saved correctly in 'ckds.des'. ``` #### EDItranCript.jar utility (for Triple DES 3.0 cryptography) This utility is a graphical interface for managing the keys in the file `/cfg/ckds.des`. To run it, the server must have Java 21 and a graphical environment. To run it, from the directory `/bin` run: ``` java -Djava.library.path=./lib -jar ./jar/EDItranCript.jar ``` The following window will appear: ![editrancript](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-5891d3aaabc6bf2fd733458b6ad59647983c299a%2Fimage39.png?alt=media) ## Appendices ### Subsystem states Below is a list of all possible states of subsystem keys: | Id | State | Text | | -- | ---------------------------------- | ---------------------------------- | | 1 | KEY\_GENERATED | Generated Key | | 2 | KEY\_OPERATIONAL | Operational Key | | 3 | KEY\_ACTIVE | Active Key | | 4 | KEY\_SEND\_FILE\_GENERATED | Key Send File Generated | | 5 | SENDING\_KEY\_FILE | Sending Key File | | 6 | ERROR\_SENDING\_KEY\_FILE | Error Sending Key File | | 7 | KEY\_FILE\_SENT | Key File Sent | | 8 | CONFIRMATION\_RECEIVED | Confirmation Received | | 9 | INVALID\_CONFIRMATION | Invalid Confirmation File Received | | 10 | REMOTE\_KEY\_INSERTED | Remote Key Inserted | | 11 | CONFIRMATION\_FILE\_GENERATED | Confirmation File Generated | | 12 | SENDING\_CONFIRMATION\_FILE | Sending the Confirmation File | | 13 | ERROR\_SENDING\_CONFIRMATION\_FILE | Error Sending Confirmation File | | 14 | CONFIRMATION\_FILE\_SENT | Confirmation File Sent | | 15 | KEY\_CANCELLED | Key Cancelled | | 17 | KEY\_NOT\_SELECTED | Key Not Selected | | 18 | KEY\_SELECTED | Key Selected | The table will be useful for locating each of the states in the following diagram by its identifier. ### State Diagram #### Own RSA Key State sequence diagram for a key of an own RSA subsystem: ![assets/image36.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-c55d73bcc89cf862d623bfd1360c1b234a0e982f%2Fimage36.png?alt=media) #### Local Key ![assets/image37.png](https://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%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://780925830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiQfLim2uDaLOZRkgWkOk%2Fuploads%2Fgit-blob-1032fef31f0f17f2731b6492130592e8e0443259%2Fimage38.png?alt=media) --- # 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.3-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.