SE529774C2 - Method is for creation of binary key and its insertion in memory space for storage of keys in terminal - Google Patents

Abstract

An assigned application accesses a key from a standard file in the memory space through security functions allowing access to the key for use in a session. The security functions prevent access to the key by unauthorized users. A further step involves deletion of the key from the memory space. The terminal is a global system for mobile communication unit. The memory space is in a smart card in accordance with a subscriber identification module. The memory space can be an abbreviated dialling number file, a fixed dialling numbe file or a secondary directroy number file, and the keys are stored in one or more of such file entries. The binary keys are in an alphanumeric and/or hexadecimal form. They are encrypted. The keys are used for encrypting, decrypting, digitally signing for any required data.

Description

20 25 30 529 774 The popular 'PGP' encryption with public keys, and the 'RSA' encryption on which it is based use an 'asymmetric' key. The encryption key, 'the public key', differs significantly from the decryption key, 'the private key', in that an attempt to derive the private key from the public key involves hours of computer calculation, which at best makes it impractical.

In addition to encryption purposes, Public Key infrastructure (PKI) can be used for digital signatures. It is based on the fact that text that is encrypted with a user's unique private key can only be decrypted with the corresponding public key. In this way, it can be verified who the user who encrypted the text was because the public key can be used to review the encryption.

Since computers can be used for a number of tasks, such as communication, financial management, information retrieval, entertainment and games, it is a natural advance for the user to assume that these applications are also available on their mobile terminal.

Global System for Mobile Communication (GSM) is a standard for digital wireless communication. Today's GSM network of the second generation delivers both voice telephony and mobile voice and data services of high quality and security (such as SMS / Text messages) with global roaming capabilities. The development of GSM networks and terminals to support more advanced data carrier technologies has allowed the introduction of new data services. These technologies allow greater bandwidth and more capable environments for execution, and thus also allow the development of mobile applications. The applications are now used for a number of tasks, such as the "Universal Mobile Telecommunication System", UMTS represents an evolution in terms of services and data speeds from today's "second generation" mobile networks. As a key member of the “global family” of third-generation (3G) mobile technologies identified by the ITU, UMTS is the natural evolutionary choice for GSM network operators.

In mobile networks, people can be contacted by calling their mobile phone number or by, to that number, sending so-called text messages by, for example, using Short Message Service (SMS). Point-to-Point Short Message Service (SMS) provides tools for sending limited size messages to and from GSM mobiles. Detailed information can be found in the ETSI standard GSM 03.40 Version 5.3.0. 10 15 20 25 30 529 774 Subscriber Identity Module (SIM) inside GSM phones is a smart card that was originally designed to serve as a secure way to connect individual subscribers to the network. There is an ongoing development of SIM into a standardized and secure application platform for GSM and the next generation of networks.

ETSI (European Telecommunications Standards Institute) is a non-profit organization whose mission is to produce telecommunications standards for use in and outside Europe. The ETSI TS 100977 V8.2.0 (2000-05) standard describes the interface between the SIM and the Mobile Equipment, (ME), within the digital mobile telecommunications system.

The logical structure of files in SIM is hierarchical and there are three types of files, ie Elementary Files (EF, Elementary Files), Dedicated Files (DF, Dedicated Files) and Parent Files (MF, Master Files), the latter being the highest in the hierarchy.

EFADN is an elementary som l that contains Abbreviated Dialing Numbers (ADN) and / or additional strings for service control, Supplementary Service Control Strings (SSC). In addition, it contains identifiers of combined networks / carrier options and identifiers of extension registers. It can also contain a unified alpha tag, alpha tagging. The EFADN file is colloquially called the "phonebook" because the mobile phone user uses it to retrieve the correct phone number when trying to reach someone by calling or texting.

Other similar SIM files are the Fixed Dialing Number (FDN) file or the Secondary Directory Number (SDN) file. SDN is used to assign an additional (non-primary) telephone number to a terminal. More detailed information about elementary files can be found in the GSM standard 3GPP TS 11.11 V8 12.0 (2004-O3).

Keys to be used for encryption, decryption or signature purposes must be stored somewhere in the computer or mobile station. If the keys are stored in a computer's hardware, security issues may occur. The key can be accessed by anyone who has access to this computer in question.

Finnish patent 113 118 presents such a prior art solution in which a specially designed smart card is used to store the key in the card and a card reader for reading the key. This solution has the advantage that the key is more secure in, for example, a SlM card than in a computer's hardware, to which anyone has access.

OBJECT OF THE INVENTION The object of this invention is a solution in which standard devices can be used to store keys for encryption purposes.

SUMMARY OF THE INVENTION The method according to the invention uses keys in a terminal, in which method a binary key is created and inserted in a memory space of said terminal. The method is mainly characterized in that only a specified application can access said key from a standard file in said memory space through security functions which allow access to said key for use of it in a session. The security features prevent unauthorized users from accessing the key.

The terminal of the invention has another binary key stored in a memory space therein.

Said memory space is a standard file, in which the key (s) are protected by security functions and they are exclusively available for specified applications.

The advantageous embodiments of the invention have the features of the subclaims, some of which are presented in the following.

The security keys and / or their security features are preferably stored in the directory (also known as abbreviated dialing numbers or ADN) by a SlM card in the Fixed Dialing Number (FDN) file or the Secondary Directory Number (SDN) file. These security keys can be symmetrical or asymmetrical keys. 10 15 20 25 30 529 774 Binary keys would be stored in alphanumeric form if they were stored in, for example, the ADN 'name' field, and would be presented as numeric numbers if they were stored in the ADN 'number' field.

Depending on the needs, a combination of ADN name and number fields can be used either exclusively or in combination.

To minimize the user's visual confusion, the first character of the ADN name can be set so that the phonebook insert is placed at the bottom of a typical alphabetically descending search order of a mobile phone.

In case the size of the security key and / or its properties is greater than the capacity of a directory entry (ADN), it can be spread over several directory entries. In this scenario, there would be a cursor in either the ADN 'name' or 'number' field to indicate the total number of directory entries used for each security object, and the sequence number / flow to enable precise reconstruction of the security keys and / or their properties. A review fee may also be included to verify the integrity of the recovered data.

The keys stored in the ADN fields can also be encrypted with either a different key or password for a different level of security (in addition to the usual PIN1 that guards access to the SIM).

ADN has been specially chosen to store the keys because they are universally the same on all SIM cards. With the solution according to the invention, extensive and cost-effective spreading of PKI can be carried out to the large masses.

National PKI ambitions exist in some countries (distribution of PKI to the public consisting of fl your millions of people) but there is no budget for, for example, re-updating SIM cards with added SIM files for keys and cryptographic plug-ins etc. Traditional PKI also requires PC settings (for example, credit card-sized smart cards, smart card readers, an additional USB / security port, security client, Internet connection, etc.) and these may not be available to the public and are not cheap. The impact on mobile phones would be much greater (due to subsidized or repaired 10 15 20 25 30 529 774 phones, prepaid plans, etc.). Even when the keys are stored in diskettes, the medium is not very practical to transport, durable or protected. The SIM cards can offer PlN1 protection to the phonebook and a ready-made security terminal in the mobile phone itself without any external devices (for example a second hole, etc.).

Keys (for non-GSM actions - eg not A3 / A5 03.48 etc) can be stored and stored today in other SIMs. However, to achieve this, special SIMs must be defined when a SIM card is introduced (personalization). Users who have a standard SIM card cannot save the application keys on their SIM cards with this method. These people should be given such new SIM cards, which would incur terrible costs to the operator / authority, or those who pay the costs. If the subscriber is set to pay the costs, the amount raised will be minimal and the intended goal would fail.

When the keys are saved on AND, you do not have to issue new SIM cards, which means huge savings in materials and logistics. By saving the keys in a standard GSM file, all the possibilities already developed on the market to support these files can be applied to these keys as well as e.g. Remote OTA creation (eg off-site key generation), updating (eg periodic exchange of keys for encryption keys, updating of public keys) and removal of keys (eg recall) of keys. An endpoint-to-endpoint solution can therefore be offered.

Saving the keys in standard SIMs also limits the scenario for the participating operators - which would have meant that all operators involved had to issue these special SIM cards. They would also have had to have the various card sellers create such SIM cards if they use card sellers.

As can be seen from the past (.tex. Mobile handling of banking matters) such a roll can be complicated and in reality it would result in only one or two operators being selected, which in turn would limit extensive handling of such mobile PKI.

If the keys are saved on the ADN, you become independent of the SIM card seller, operator and to some extent also mobile phone (as long as it can support the security application). 10 15 20 25 30 529 774 Any security application could use the keys as long as they have access to the phonebook. These include J2ME, Symbian appl, Microsoft SmartPhone appl, Palm (mobile) appl, etc. Ideally, they could perform the cryptographic functions on the mobile phone themselves, either completely (eg generate a PKCS # 7 packet), in part (eg only generate the signature and merge it with the user certificate and generate a complete PKCS # 7 packages, á la signature gateway) or if they are linked to a security policy, empty send the keys to a trusted server to perform signing / encryption.

In the following, the invention is further described with the aid of some examples and figures to which the invention is not limited. Although the following description specifically focuses on using the EFADN file in a SIM card in a GSM telephone, the invention can nevertheless be implemented in other EF files, such as e.g. EFFDN file or EFSDN file and te.x. in a USIM card of a UMTS phone.

FIGURES Figure 1 is a presentation of the standardized subscriber identity module (EF) of the Subscriber Identity Module (SIM), which contains Abbreviated Dialing Numbers (ADNs) and / or additional strings for Supplementary Service Control strings (SSC). Figure 2 is an example of an embodiment of the invention applied in the standardized EFADN of Figure 1. Figure 3 presents different access conditions for inserting, using, accessing or removing a key in an ADN file.

Figure 4 presents signals used in connection with various access conditions insertion, use, access or removal of a key in an ADN file. 10 15 20 25 529 774 DETAILED DESCRIPTION Figure 1 is a presentation of a standardized elementary file, Elementary File (EF), in the Subscriber Identity Module (SIM) for a GSM session.

The ETSI TS 100 977 V8.2.0 (2000-05) standard defines the requirements for the physical properties of the SIM, the electrical signals and the transmission protocols, the model for the logical structure of the SIM, the interface function. the commands, the application protocol and the contents of the files required for the GSM applications. The security features, The Elementary Files (EF), for the GSM session define the access conditions, data objects and coding. A data object is part of an EF, which represents a complete logical unit, e.g. alpha tag in an EFADN register. The EF files are mandatory, mandatory (M), or optional, optional (O). The file size of a voluntary EF can be zero. All EFs with a file size greater than zero must contain all mandatory objects.

EFADN is an elementary file that contains Speed Dial Numbers, Abbreviated Dialing Numbers (ADN) and / or additional Strings for Service Control, Supplementary Service Control Strings (SSC). In addition, it contains identifiers of unified network / carrier capabilities and identifiers of expansion registers. It can also contain an associated alpha tagging.

The EFADN file is colloquially called the "phonebook" because the mobile phone user uses it to retrieve the real phone number by name when trying to reach someone by calling or texting.

As for the elementary files, Elementary Files use three different types of structures, namely transparent transparent EF files, linear stationary EF files and cyclic EF files.

An EF with a linear stationary structure consists of a sequence of registers that all have the same (stationary) length. The length of the register, as well as this value multiplied by the number of registers, is indicated in the “header field” of the EF fi. The maximum length of an EFADN file is in accordance with the field presented in Figure 1 with the reference numeral 4, X + 14 bytes, each byte consisting of 8 bits.

Figure 1 also shows access conditions, data objects and encoding of an EFADN file. Figure 1 describes the data objects of the elementary file, Elementary File, EFADN using a field presentation. Thus, field 1 is the identifier of a given SlM-1, i.e. describes which SIM file it is, which in Figure 1 is an EFADN coded as 6F3A and presented with the reference number 1 in Figure 1.

The field presented with the reference numeral 2 indicates that the file is a linear stationary EF file.

According to the field presented by the reference numeral 3, the EFADN file is optional and the length of it can thus be zero. All EFs with a full size greater than zero must contain all mandatory data objects.

The field presented with the reference numeral 5 indicates that the kan can be updated.

Each fl l has its own access condition for each command. There are different levels of access conditions, such as Always (= the action can be performed without restriction), Verification of Card Holder 1 (CHV1) and Verification of Card Holder 2 (CHV2) (Action is possible if the correct CHV1 / CHV2 value has already been presented for SIM during the current session, the CHV1 / CHV2 possible / impossible indicator has been set to "impossible" or a release of CHV1 / CHV2 has been successfully performed during the current session), ADM (= Responsibility for allocation of these levels and requirements to meet these are held by the appropriate administrative authority) and Never (= never) (= the action can not be performed over the SLM / ME interface, but SIM can perform the action internally).

Different functions can act on the fi ls on a SlM. It is mandatory for all SIM cards in accordance with the ETSI TS 100 977 V8.2.0 standard (2000-05) to support the Select, Status, Read Binary, Update Binary, Read Registry, Update Registry, Search, Increase, Invalid and Rehabilitate functions. (Select, Status, Read Binary, Update Binary, Read Record, Update Record, Seek, increase, lnvalidate and Rehabilitate).

As shown in Figure 1, field 6, the functions Read (Register), Update (Register), Invalidate and Rehabilitate can be performed on the EFADN file, the functions having the access conditions CHV1, CHV1, CHV2 and CHV2 respectively. For example, the Read Register function can only be performed if the READ access condition for this EF file is met and so on with regard to the other functions.

Each register consists of a series of data objects represented by fields 7a - 7f, the maximum length of each data object being indicated in column 8, the sum of which is X + 14 bytes. Column 9 indicates whether the field is optional or mandatory, column 10 describes the data information that is included in each row and column 11 defines the order of each data object in a particular row.

Thus, each row contains as its first object an alpha identifier (indicated in field 7a in Figure 1) according to column 10, such as a name associated with a given speed dial number, Abbreviated Dialing Number (ADN), indicated in field 7d. Field 7d may also contain an additional service control string, Supplementary Service Control String (SSC), which consists of e.g. an character string for an abbreviated transfer call code. Column 8 indicates the length of the field 7a to be X bytes, column 9 that this data object is optional. Column 11 tells us that this data object is the first object in a row represented by the first X bytes. The value of X can be from zero to 241 and depends on the settings of the individual mobile terminals.

The second data object described in field 7b informs about the coding method, i.e. the length of the BCD (Binary Coded Decimal) number and possibly the SSC content. Field 7c describes the Number Type, Number Of Number (TON) and Numbering Plan Identification (NPl). Field 7d describes the call number connected to the alpha identifier, alpha identifier, in field 7a or a possible transfer code for transferring the call to another number. Figure 7e presents the capability / configuration identifier and contains the associated capability / configuration parameters required for the call and field 7f is an extension 1 record identifier, which contains a subaddress or additional data for an associated called party.

According to column 9, all data objects 7b - 7f are mandatory, only the alpha identifier 7a is an exception.

Figure 2 shows an example of an embodiment of the SIM card according to the invention, where additional information has been included in the alpha identifier field 7a of the EFADN file. The contents of the fields, represented by the reference numerals 1 - 6 and 7b - 7f, remain intact in the invention compared to the standard EFADN.

Field 7a indicates the coded and / or encrypted name of the key to be saved together with mixed key header information, here e.g.

“Z253abcgtflmgdef” in alphanumeric characters and field 7d itself contains the encrypted and / or encrypted key, i.e. "6598354205 ..." in the form of numeric characters.

If e.g. an EFFDN file or an EFSDN file is used instead of another EFADN file, a similar field, which normally contains the dialing number / SSC string, would be used accordingly.

The terms of Figure 3 can be used to insert, change, update, roll-over, access or use the keys or to remove unused or invalid keys or keys where the expiration date has expired. 32 different combinations of conditions a - e are presented for each action.

The condition “a” means that a user-defined PIN for a Smart Card (eg GSM SIM card) is used to insert the SIM card. It can be turned on or off by the user. A typical security arrangement of the smart card is that it becomes inoperable / locks after several incorrect PlN entries, which prevents unauthorized users from gaining access to the private keys on the Smart Card.

At this point, when you have to insert a private key in the phonebook and if the private keys to be saved on the SIM card are generated remotely (possibly a certificate manager etc.), a server can be used to perform the OTA deposit / - the update of the private keys directly in the user's phonebook (ieOCH file).

In general, said key (s) can be generated, inserted, updated and / or removed remotely or locally by one or more of your designated applications. The installation, updating and / or removal takes place by means of one or more local application programs in the terminal or application programs remotely, by radio, Over The Air (OTA), via cable, via an infrared link, via text message with Short Message Service (SMS ), Near Field Communication (NFC), manually, with Bluetooth or any other input mechanism supported by the mobile device. Near Field 10 15 20 25 30 529 774 12 Communication (NFC) A forum has been set up to promote the use of NFC wireless in short-distance interactions in Consumer Electronics, Mobile Devices and PCs.

Since at this point there is talk of using or having access to the key and you want this action to be linked to appropriate security checks and authorization, a remote application can read the private keys directly from the phonebook by using an OTA server.

And since what we are talking about at this point is to remove the key, a server can be used to remove the private keys OTA directly from the user's phonebook.

The condition "b" means that a PlN defined by the user for a Smart Card (eg GSM SIM card) is needed to access the AND file. It can be turned off by the user.

Here, too, a typical security arrangement of the smart card means that it makes itself inoperable / locks after several incorrect PlN entries, which prevents unauthorized users from gaining access to the private keys on the smart card.

Again, since at this point there is talk of inserting a private key into the phonebook and if the private keys are generated remotely (by a certificate manager etc.) the user can choose between manually entering the private key in speed dial / phone number format by use the phonebook menu in your phone. The user can receive this in text form via any medium that can forward information in text form.

And since at this point there is talk of removing the private key from a certain phonebook entry and the user has an idea of which abbreviation it is (or if there is only a single key in the phonebook list) he / she can remove it from the phone's phonebook menu .

The condition "c" means that a password defined by the user is needed to gain access to the application, which uses or manages the private keys stored on the ADN.

The application can be based on e.g. Java, C ++, Symbian Application etc. Mandatory or voluntary acceleration, as well as password rules may be determined by the application, a content and / or service provider.

Since at this point there is talk of inserting a private key into the phonebook and if the private keys are generated remotely (by a certificate manager etc.), the user can choose between manually entering the private key in speed dial / phone number format by using the user interface of the application. The user can receive this in text form via any medium that can forward information in text form.

When it comes to accessing, using or removing the private key, the Phonebook for Private Keys application seeks to use a predefined identifier embedded within the abbreviation of the telephone entry.

Using the information from the abbreviation of the telephone number, the application displays a context sensitive list of private keys (regardless of the current number of phonebook entries used to store these keys) that are suitable for the required functions or for the user to remove the key. If "e" cannot be used in this context, the application will continue to remove all phonebook entries used to contain this private key.

The condition is asymmetric or a mixture of such. These are generally presented in binary / hexadecimal format. "D" means that the private keys can either be symmetrical. If the keys are rather small, they can be presented in a single phonebook entry. Otherwise, multiple phonebook entries may be required to present them in their entirety.

"Encoded" here means (i) a process that enables binary raw data to be stored as alphanumeric characters in the directory and (ii) a structure, which contains information about parts or whole fragments of the key therein. This information allows the application to use it to extract and reconstruct the keys, as well as display the properties and status of the key and present an overview of / a list of keys to the user. 10 15 20 25 30 529 774 14 When inserting the key, the private keys can also be generated on the device by the application alone or using the telephone, smart card or both. In that case, the private keys will be encrypted, encrypted and finally written in the required number of phonebook entries by the application.

In connection with the removal of the key, if the private key is stored in a single directory entry, only a single directory entry will be removed.

Otherwise, all phonebook entries used to contain fragments of this private key will be removed.

The process in “d” converts binary data to a format that can be saved in the AND, FDN or SDN file. If PlN codes have been used, these have been entered earlier to gain access at this stage. An application password can be used after the key is extracted / read from the ADN, FDN or SDN file.

The keys can e.g. have the following appearance in connection with various actions: 1. To Save the Key (conversion from Binary form to fi lz) Original Binary Key (Original Binary Key) = 00110100 01010001 11111111 11011 1 10 (cannot be displayed in the phonebook) Hex Key (Hex Key ) = 3451FFDE (can be saved in the phonebook as an abbreviation, but not as a phone number) Encoded Key = 6523145672 (can be saved in the phonebook as an abbreviation or as a phone number) Stored Key = 5412034561 (password coded, this sample uses a simple subtraction of '1111111111') 2. To Read the Key (conversion from fi l to Binary form): Stored Key = 5412034561 (password coded, this sample uses a simple subtraction of '1111111111') Encoded Key = 6523145672 (can be saved in the phonebook as an abbreviation or as a phone number) Hex Key (Hex Key) = 3451FFDE (can be saved in the phonebook as an abbreviation, but not as a phone number) 10 15 20 25 30 529 774 15 Binary Key (Original Bi nary Key) = 00110100 01010001 11111111 11011110 (cannot be displayed in the phonebook) An example of an encrypted key formula for a numeric phone number = Log (2 ^ 32) / Log (10). The result has 10 numeric digits.

An example of an encrypted key formula for a numeric telephone number abbreviation = Log (2 ^ 32) / Log (36). The result has 7 alphanumeric characters.

The term “e” means that a password entered by the user is needed to use or manage the private keys stored on the ADN (eg Java, C ++, Symbian, Application, etc.). Mandatory or voluntary incentives, as well as password rules, are determined by the application, the content and / or the service provider. Encrypted here refers to binary data that has been arranged so that it cannot be used without first being saved again in its original form.

If a manual entry is used in connection with the insertion of a key, the user can enter the password for the private key as verification. If the application can decrypt and convert the private keys back to binary format, it can then confirm successful import of the private key.

When the key is used or accessed, the private keys are removed from memory after use.

When it comes to removing the key, once the application can decrypt and convert the private keys back to binary format, it can then speed up a final confirmation with the user to remove this private key.

Thus, e.g. option 5 in figure 3 a scenario where no user PlN is required to start the phone, use the SLM or access the SIM phonebook. However, entering an independent password is required to access the application. The encrypted key is saved in only one directory entry and entry of an independent password is required to decrypt the key. Correspondingly, option 26 means a scenario where user PlN is required to start the phone / use the SlM and to access the SIM phonebook. entering an independent password to access the application is not required. The encrypted key is saved in only a directory entry and entry of an independent password to decrypt the key is also not required.

Figure 4 presents the signals used in connection with the different access conditions for insertion, use, access and removal of a key stored in an ADN file.

Signal "a" describes that the entry of a PlN code is required to turn on the mobile station and use the SIM card and that this PIN code is given by the user and received by the equipment part, i.e. The "phone" of the mobile static.

Signal "b" describes that entry of a PlN code is required to access the SIM card by the mobile station and that this PIN code is given by the user to the cell, whereby the keys are saved e.g. in the ADN file or "phonebook".

Signal "c" describes that the entry of an independent password is required for access to the application that can access and use the keys stored on the SIM file and that this password is given by the user to the application.

Siganl “d” describes that a coded key is saved over several phonebook entries.

Signal “e” describes that the entry of an independent password is required to decrypt the key and that this password is given by the user to the application.

Claims (33)

1. 0 15 20 25 30 529 774 17 2. PATENT REQUIREMENTS 3.. Method for using keys in a terminal, in which method a binary key is created and inserted into a memory space of said terminal, characterized in that an assigned application has access to said key from a standard file in said memory space via security functions by allow access to said key to use it during a session, the security functions preventing unauthorized users from accessing the key in such a way that the functions operating on the memory space have access conditions for each file and for each command to influence and these conditions are used in the insertion, updating and / or removal of said key (s), which are performed remotely or locally by one or more assigned applications in a secure manner. 4.. A method according to claim 1, further characterized in that said key is removed from the memory space of the terminal. 5.. A method according to claim 2, characterized in that said key is removed by means of security functions which prevent unauthorized users from removing the key. 6.. Method according to any one of claims 1 to 3, characterized in that said terminal is a mobile station. 7.. A method according to any one of claims 1 to 4, wherein 6 'I G C k H 8' I thereof. a fi the mobile station is a GSM terminal. A method according to any one of claims 1 to 5, characterized in that said memory space is in a smart card. A method according to claim 5 or 6, characterized in that said smart card is a SIM card. 10 15 20 25 30 529 774 18 8. A method according to claims 5 - 7, characterized in that said memory space is one with the following names: Abbreviated Dialing Number (ADN) file, Fixed Dialing Number (FDN) file or Secondary Directory Number (SDN) file. 9. A method according to claims 5 - 7, characterized in that said key (s) is stored in one or more of your ADN, FDN or SDN files. 10. A method according to claims 5 - 7, characterized in that when said key / keys are saved in your ADN files, a cursor is placed in a numbered or named field of some files to indicate the total number of entries needed to save each key as well as a sequence number to enable a proper reconstruction of the key. 11. A method according to claim 10, characterized in that a checksum is included in the fis to verify the integrity of the recovered key. 12. A method according to claims 5 - 7, characterized in that said key (s) is saved by means of a file name and a numbered field exclusively or in combination. Method according to one of Claims 1 to 8, characterized in that security functions are performed by entering a PIN code and / or a password before access to the key is granted for the assigned application (s). A method according to claim 13, characterized in that said insertion, updating and / or removal takes place by means of one or more local application programs in the terminal, or by remote application programs by radio, Over The Air (OTA), via cable, via an infrared link, via Short Message Service (SMS), Near Field Communication (NFC), manually, Bluetooth or any other available input mechanism supported by the mobile device. 10 15 20 25 30 529 774 19 Method according to one of Claims 1 to 9, characterized in that the binary key (s) is in alphanumeric form and / or hexadecimal form. Method according to one of Claims 1 to 9, characterized in that the binary key (s) is encrypted (e). 17. A method according to any one of claims 1 to 9, characterized in that the binary key (s) are asymmetric or symmetrical. 18. A method according to any one of claims 1 - 13, characterized in that the key (s) is used for encryption, decryption, digital signing of any required data. 19.Terminal with one or fl your binary keys stored in a memory space in the terminal, characterized in that said memory space is a standard file where the key / keys are protected (e) by security functions in such a way that the functions acting on the file in the memory space have access conditions for each command to affect the file and the file can only be accessed by assigned one or more applications, which are bound by the conditions for performing insertion, updating and / or removal of said key / keys remotely or locally in a secure manner. Terminal according to claim 19, characterized in that said memory space is in a smart card. 21. A terminal according to claim 20, characterized in that said application is in the smart card. Terminal according to claims 20 and 21, characterized in that said smart card is a SIM card. 23.Terrnina | according to any one of claims 19 -22, characterized in that it is a mobile station. 10 15 20 25 30 529 774 20 A terminal according to claim 23, characterized in that said mobile station is a GSM terminal. 25.Terrnina | according to claim 24, characterized in that said memory space is a file with the following names: Abbreviated Dialing Number (ADN) file, Fixed Dialing Number (FDN) file or Secondary Directory Number (SDN) file. Terminal according to claim 25, characterized in that said key / keys are stored in one or more of said fis. Terminal according to claim 26, characterized in that when said key / keys are stored in several files, a cursor is placed in a number fi l or a named field to indicate the total number of entries needed for each key as well as a sequence number. to enable a proper reconstruction of the key. Terminal according to claim 26, characterized in that a checksum is included in the numbers. Terminal according to claim 26, characterized by said key (s) is saved (e) by means of a file name and a numbered field exclusively or in combination. Terminal according to one of Claims 19 to 28, characterized in that the security functions with which the key (s) are protected (e) consist of a PIN code and / or a password. Terminal according to one of Claims 19 to 30, characterized in that the binary key (s) is in alphanumeric form and / or hexadecimal form. Terminal according to one of Claims 19 to 31, characterized in that the binary key (s) is encrypted (e). 529 774 21 33.Termina | according to any one of claims 19 to 32, characterized in that the binary keyed binary keys are asymmetric (a) or symmetric (a).