Automated changeover of transfer encryption key

The automated changeover of a transfer encryption key from one transfer encryption key to another. This occurs in an environment in which a set of computing systems are to share one or more keys (such as a private and public key pair). The transfer encryption key is used to encrypt communications of the key(s) such that the encrypted key(s) may be transferred over a transfer system without the transfer system having access to the key(s). In order to perform automated changeover of the transfer encryption key, one of the set of computing systems encrypts the next transfer encryption key with the prior transfer encryption key. The transfer system provides this encrypted message to the remainder of the set of computing systems, which may then decrypt the encrypted message using the prior transfer encryption key, to find the next transfer encryption key.

BACKGROUND

Computing systems and associated networks have greatly revolutionized our world. In order to share information between computing systems over a network, that information is often first encrypted prior to transmission over the network. The recipient system may then decrypt that message to extract the original information. This allows two trusted computing systems to securely exchange information over an untrusted network while reducing the risk that the information may be discovered by other entities. The ability to encrypt and decrypt relies on both computing systems having access to a key. For instance, in asymmetric encryption, the encryption is performed using a public or private key, whereas the decryption is performed using a private key. Thus, the encryption/decryption is accomplished using a public/private key pair. In symmetric encryption, encryption and description may be accomplished using the same encryption key.

In some situations, it is advantageous for multiple computing systems to share the same key(s). This may be appropriate when the multiple computing systems are within the same sphere of trust. For instance, the computing systems may share the same public/private key pair. In order to securely communicate the appropriate key(s) over an untrusted network that is outside of the sphere of trust, a separate transfer encryption key is generated and used to encrypt the key(s) with a message. The message is then appropriately decrypted by each recipient that has the transfer encryption key. With the same public/private key pair now being present at each of the multiple computing systems, further messages may be securely transferred between the multiple computing systems.

BRIEF SUMMARY

At least some embodiments described herein are related to the automated changeover of a transfer encryption key from one transfer encryption key to another amongst multiple computing systems. This occurs in an environment in which a set of computing systems are to share one or more keys (such as a private key and potentially also a public key), which may be appropriate when that computing system set is within the same sphere of trust. The transfer encryption key is used to encrypt communications of the key(s) such that the encrypted key(s) may be transferred over a transfer system without the transfer system having access to the key(s). That transfer system may be outside of the sphere of trust. The key(s) that are shared between the computing system set are to be distinguished from the transfer encryption key that is used to securely transmit the key(s) over the transfer system.

As an example only, the transfer system may be a service (such as a cloud service) that is outside of a trust boundary, whereas the set of computing systems are computing systems without the trust boundary. Nevertheless, the transfer system may keep track of the set of computing systems so that when the transfer system receives an encrypted message from one computing system in the computing system set, the transfer system passes the encrypted message to one or more of the remaining computing systems in the computing system set.

In order to perform automated changeover of the transfer encryption key, one computing system of the computing system set encrypts the next transfer encryption key with the prior transfer encryption key. The transfer system provides this encrypted message to one or more of the remaining computing systems of the computing system set. Each recipient computing system may then decrypt the encrypted message using the prior transfer encryption key, to find the next transfer encryption key. The computing system set may use the next transfer encryption key to exchange key(s) thereafter. This automated changeover may happen repeatedly to ensure that the lifetime of the current transfer encryption key is not too long to have a significantly adverse effect on security, such as a potential man-in-the middle attack, in which a computing system outside of the trust boundary is somehow able to access the content of the message in the clear. This allows the transfer system to be used to facilitate transfer of the key(s) while ensuring that the transfer system is not made aware of the key(s) in the clear.

DETAILED DESCRIPTION

At least some embodiments described herein are related to the automated changeover of a transfer encryption key from one transfer encryption key to another amongst multiple computing systems. This occurs in an environment in which a set of computing systems are to share one or more keys (such as a private key and potentially also a public key), which may be appropriate when that computing system set is within the same sphere of trust. The transfer encryption key is used to encrypt communications of the key(s) such that the encrypted key(s) may be transferred over a transfer system without the transfer system having access to the key(s). That transfer system may be outside of the sphere of trust. The key(s) that are shared between the computing system set are to be distinguished from the transfer encryption key that is used to securely transmit the key(s) over the transfer system.

As an example only, the transfer system may be a service (such as a cloud service) that is outside of a trust boundary, whereas the set of computing systems are computing systems without the trust boundary. Nevertheless, the transfer system may keep track of the set of computing systems so that when the transfer system receives an encrypted message from one computing system in the computing system set, the transfer system passes the encrypted message to one or more of the remaining computing systems in the computing system set.

In order to perform automated changeover of the transfer encryption key, one computing system of the computing system set encrypts the next transfer encryption key with the prior transfer encryption key. The transfer system provides this encrypted message to one or more of the remaining computing systems of the computing system set. Each recipient computing system may then decrypt the encrypted message using the prior transfer encryption key, to find the next transfer encryption key. The computing system set may use the next transfer encryption key to exchange key(s) thereafter. This automated changeover may happen repeatedly to ensure that the lifetime of the current transfer encryption key is not too long to have a significantly adverse effect on security, such as a potential man-in-the middle attack, in which a computing system outside of the trust boundary is somehow able to access the content of the message in the clear. This allows the transfer system to be used to facilitate transfer of the key(s) while ensuring that the transfer system is not made aware of the key(s) in the clear.

Because the principles described herein operate in the context of a computing system, a computing system will be described with respect toFIG. 1. Then, the utility of a transfer encryption key will be described with respect toFIG. 2 through 4. Then, the principles of automated rollover of such a transfer encryption key will be described with respect toFIGS. 5 through 9.

Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, datacenters, or even devices that have not conventionally been considered a computing system, such as wearables (e.g., glasses, watches, bands, and so forth). In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

As illustrated inFIG. 1, in its most basic configuration, a computing system100typically includes at least one hardware processing unit102and memory104. The memory104may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system100has thereon multiple structures often referred to as an “executable component”. For instance, the memory104of the computing system100is illustrated as including executable component106. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media.

The term “executable component” is also well understood by one of ordinary skill as including structures that are implemented exclusively or near-exclusively in hardware, such as within a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. Accordingly, the term “executable component” is a term for a structure that is well understood by those of ordinary skill in the art of computing, whether implemented in software, hardware, or a combination. In this description, the term “component” or “vertex” may also be used. As used in this description and in the case, this term (regardless of whether the term is modified with one or more modifiers) is also intended to be synonymous with the term “executable component” or be specific types of such an “executable component”, and thus also have a structure that is well understood by those of ordinary skill in the art of computing.

In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions that constitute an executable component. For example, such computer-executable instructions may be embodied on one or more computer-readable media that form a computer program product. An example of such an operation involves the manipulation of data.

The computer-executable instructions (and the manipulated data) may be stored in the memory104of the computing system100. Computing system100may also contain communication channels108that allow the computing system100to communicate with other computing systems over, for example, network110.

While not all computing systems require a user interface, in some embodiments, the computing system100includes a user interface112for use in interfacing with a user. The user interface112may include output mechanisms112A as well as input mechanisms112B. The principles described herein are not limited to the precise output mechanisms112A or input mechanisms112B as such will depend on the nature of the device. However, output mechanisms112A might include, for instance, speakers, displays, tactile output, holograms, virtual reality, and so forth. Examples of input mechanisms112B might include, for instance, microphones, touchscreens, holograms, virtual reality, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

Those skilled in the art will also appreciate that the invention may be practiced in a cloud computing environment, which is supported by one or more datacenters or portions thereof. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations.

In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

For instance, cloud computing is currently employed in the marketplace so as to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. Furthermore, the shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.

Then, the utility of a transfer encryption key will be described with respect toFIG. 2 through 4. Thereafter, the principles of automated rollover of such a transfer encryption key will be described with respect toFIGS. 5 through 9.FIG. 2illustrates an environment200that includes a transfer system220and a set of computing systems210(also called herein a “computing system set210” or simply “computing system set”). Each of the computing systems in the computing system set210may be structured and operate as described above for the computing system100ofFIG. 1. Likewise, the transfer system220may also be structured and operate as described above for the computing system100ofFIG. 1. In one embodiment, the transfer system220operates in a cloud computing environment. For instance, the transfer system220may be a service that operates in the cloud computing environment.

The transfer system220is used to share a private key (amongst potentially other keys) between each computing system of the computing system set210. For instance, the transfer system220may be used in cases in which there is no direct communication link between the computing systems of the computing system set210. Furthermore, for security reasons, the transfer system220is not to have access to the unencrypted private key. In some embodiments, as described further below, the transfer system220also manages the computing system set210so that each computing system set210has access to a common set of keys.

The computing system set210is illustrated as including computing system211,212and213. Each of the computing systems211,212, and213includes a corresponding private key201A, which is actually the same private key, and thus can be used to decrypt the same encrypted messages. The unencrypted private key201A is symbolized as a circle inFIG. 2. Data that is not encrypted is often referred to in the art as data that is “in the clear”.

Each of the computing systems211,212and213also includes a transfer encryption key202, which may be used to securely share the private key201A over the transfer system220amongst the set of computing systems210. This first transfer encryption key202is symbolized as a rectangle inFIG. 2.

To share a private key from one computing system (e.g., computing system211) to another computing system (e.g., computing system212) in the computing system set210, the sharing computing system would encrypt the private key201A using the transfer encryption key202, and then initiate transfer of the encrypted private key201A′ to the transfer system220(as represented by arrow231). A private key (represented as a circle) that is encrypted using a transfer encryption key (represented as a rectangle) is represented inFIG. 2by a rectangle that represents the transfer encryption key encasing the circle that represents the private key. Throughout this description, different shapes will be used to represent different keys, and encryption of one key with another will be symbolized by similar encasement. For instance, encrypted private key201A′ is represented by the private key201A appearing inside of the transfer encryption key202that was used to encrypted the private key201A. The transfer system220can then at appropriate times (e.g., when a new computing system is joined into the set of computing systems210), provide that encrypted private key201A′ to each of the other computing systems (e.g., as represented by arrows232and233).

Again, the computing system set210is illustrated as including three computing system211,212and213. However, as represented by the ellipses214, the principles described herein are not limited to the number of computing systems within the computing system set210that share a private key. As an example, there might be as few as one computing system in the computing system set, though the principles described herein are most helpful if there are multiple computing systems that share a common private key. This is because the principles described herein are directed to an automated mechanism for rolling over (or changing) the transfer encryption key. Conventionally, the transfer encryption key is entered into each of the computing systems210that are to share the private key. This is true not just for the first transfer encryption key, but for any change in transfer encryption keys as well. Thus, the automation provides the most advantage when there are a larger number of computing systems that share the private key, since such automation prevents a larger number of manual entries of the new private encryption key. Furthermore, the automation improves security since there is now no manual barrier to changeover. Thus, changeover of the transfer encryption key is likely to be more frequent, improving security by diminishing the opportunity for a man-in-the-middle security attack.

There may be any number of reasons why multiple computing systems might share a private key, and not have direct communication between those multiple computing systems. As an example, the multiple computing systems might be redundant storage systems, in which case when data is written to one of the computing systems, and at least in some cases the data is also written to another of the computing systems. To allow the data to be saved to be securely sent to each of the computing systems in the computing system set210, the data is encrypted with a public key. When the encrypted data arrives at each of the computing systems in the computing system set210, the respective computing system may use the private key201A that each possesses to decrypt the data for storage.

As another example, each computing system in the computing system set210may render content, such as multimedia content. That multimedia content may likewise be encrypted for transmission to each computing system in the computing system set210. Again, as the encrypted multimedia content is received, it is decrypted at each computing system of the computing system set210using the private key201A present on each computing system of the computing system set210.

In any case, the principles described herein are helpful in any circumstance in which there is a computing system set that are to share a private key. In the above two examples, each of the computing systems in the computing system set may be a listener computing system that receive encrypted data from a multicasting source computing system, and that each use the private key to decrypt the data. Other examples might be a file-sharing environment, in which at least some files that are present on one computing system in the computing system set are to be shared over a service to another computing system in the computing system set.

In some embodiments, a public key corresponding to the private key may also be communicated and shared amongst the set of computing systems210. This may be accomplished in the same manner, and perhaps even in the same encrypted message, as the private key was shared.FIG. 3illustrates an environment300that is similar to the environment200ofFIG. 2, except that each computing system211,212and213is illustrated as including the public key201B corresponding to the private key201A. Furthermore, there is an encrypted message301that is illustrated as including the private key201A and the public key201B encrypted by the transfer encryption key202. Exchange231may be used by the computing system211to transfer this encrypted message301to the transfer system220. Exchanges232and233may be used for the transfer system220to provide the encrypted message301to the computing systems212and213, respectively. The exchanges232and233might occur at the same time or at different times, and may be at any time after the exchange231.

FIG. 4illustrates a flowchart of a method400for participating in secure communication of key(s) between multiple computing systems using a transfer system that does not have access to the key(s). As the method400ofFIG. 4may be performed in the environment200ofFIG. 2, and in the environment300ofFIG. 3, the method400ofFIG. 4will now be described with frequent reference toFIGS. 2 and 3.

The method400includes participating in communication of an encrypted message between the computing systems of the computing system set that is to share a private key (act401). The encrypted message includes the encrypted private key as well as potentially the encrypted public key. For instance, in the context ofFIG. 2, the encrypted message may be the encrypted private key201A′. In the context ofFIG. 3, the encrypted message may be the encrypted message301.

The “participating in communication” of a message may include transmitting a message, or receiving a message. For instance, inFIG. 2, the computing system211is illustrated as participating in communication of the encrypted private key201A′ by initiating transfer of the encrypted private key201A′ (as represented by the arrow231inFIG. 2, and act410inFIG. 4). InFIG. 3, the computing system211is illustrated as participating in communication of the encrypted message301by initiating transfer of the encrypted message301(as represented by the arrow231inFIG. 3, and act410inFIG. 4). This initiation of transfer (act410) may include accessing the appropriate key(s) (act411), encrypting the appropriate key(s) using the transfer encryption key (act412), and transmitting the encrypted key(s) to the transfer system (act413).

As represented by arrows232and233inFIG. 2, the computing system212and213, respectively, are illustrated as participating in communication of the encrypted private key201A′ by receiving the encrypted private key201A′ (act420). As represented by arrows232and233inFIG. 3, the computing system212and213, respectively, are illustrated as participating in communication of the encrypted message301by receiving the encrypted message301(also act420). This receipt of the encrypted message (act420) includes detecting receipt of the encrypted key(s) (act421), decrypting the encrypted key(s) using the transfer encryption key (act422), and accessing the decrypted key(s) (act423).

Specifically, one of the computing system in the computing system set210(hereinafter called the “initiating computing system”) is tasked with initiating the rolling over of the transfer encryption key when that initiating computing system accesses a new transfer encryption key (act501). This may happen when a user enters the new transfer encryption key (or a new transfer key is automatically generated) at one of the computing systems in the computing system set210(e.g., say computing system212in an example herein). After entering that new transfer encryption key into one of the computing systems, however, there is no need for further manual entry. In some embodiments, automated intelligence may generate and enter the new manual transfer key in the initiating computing system to thereby automatically initiate the process, and enabling fully automated changeover of the transfer encryption key.

FIG. 5illustrates a flowchart of a method500for initiating a secure rollover of the transfer encryption key in accordance with the principles described herein. For security purposes, it is advantageous for a transfer encryption key not to have too long of a lifetime. For instance, regular rollover or changeover of the transfer encryption key mitigates the risk that the transfer encryption key will be discovered during its lifetime, which discovery would enable a man-in-the-middle attack, with the private key itself being discovered outside of the trust boundary. Thus, the transfer encryption key is rolled over every so often. Traditionally, this is accomplished by manually entering the new transfer encryption key at each computing system in the set of computing systems210. However, in accordance with the principles described herein, this rolling over is accomplished automatically.

Specifically, one of the computing system in the computing system set210(hereinafter called the “initiating computing system”) is tasked within initiating the rolling over of the transfer encryption key when that initiating computing system accesses a new transfer encryption key (act501). This may happen when a user enters the new transfer encryption key (or a new transfer key is automatically generated) at one of the computing systems in the computing system set210(e.g., say computing system212in an example herein). After entering that new transfer encryption key into one of the computing systems, however, there is no need for further manual entry. In some embodiments, automated intelligence may generate and enter the new manual transfer key in the initiating computing system to thereby automatically initiate the process, and enabling fully automated changeover of the transfer encryption key.

FIG. 6Aillustrates an environment in a first state600A, which is similar to the environment200ofFIG. 2and the environment300ofFIG. 3, except that there is a new transfer encryption key203is shown as present at the computing system212.FIG. 6Afurther differs fromFIG. 2in that the private key201A and encrypted private key201A′ are no longer illustrated though it will be understood that each computing system211,212and213continues to possess the private key201A, and the encrypted private key201A′ could continue to remain on the transfer system220.FIG. 6Afurther differs fromFIG. 3in that neither the private key201A nor the public key201B are illustrated though it will be understood that each computing system211,212and213continues to possess the private key201A and the public key201B. Also, the encrypted message301is not shown though it will be understood that the encrypted message301could continue to remain on the transfer system220. Furthermore, the arrows231,232and233are no longer visible as they were associated with the prior sharing of the private key201A and, in the case ofFIG. 3, the public key201B, andFIGS. 6A through 6Fare to illustrate what happens after that. Lastly, to keepFIG. 6Asimpler, the boundary210is not illustrated and the ellipses214are removed.

The initiating computing system then encrypts the new transfer encryption key using the old transfer encryption key (act502).FIG. 6Billustrates the environment ofFIG. 6Ain a subsequent state600B in which the initiating computing system212has encrypted transfer encryption key203with the old transfer encryption key202. The encrypted transfer encryption key203′ is represented by triangle that represents the new transfer encryption key203being encased by the rectangle that represents the old transfer encryption key202. In one embodiment, the encrypted message203′ is also encrypted to include a new private key, and potentially also a new corresponding public key. This further improves the security of the system as a whole.

The initiating computing system then initiates transfer of the encrypted transfer encryption key203′ over the transfer system (act503).FIG. 6Cillustrates the environment ofFIG. 6Bin a subsequent state600C in which the initiating computing system212has transferred (as represented by arrow631) the encrypted transfer encryption key203′ to the transfer system220.

Upon receiving the encrypted transfer encryption key203′, the transfer system220transmits the encrypted transfer encryption key203′ to the remainder of the computing systems in the computing system set210. The transfer system220keeps track of membership of the computing system set210so that it knows where to propagate the encrypted transfer encryption key203′ to. The transfer system220may ensure reliable delivery of the encrypted transfer key203′ by confirming that each computing system in the computing system set210received (and potentially also decrypted and applied) the new transfer encryption key203. The transfer system220also potentially keeps the encrypted transfer encrypted key203′.

The remaining states600D,600E and600F ofFIGS. 6D, 6E and 6Fwill be described after describingFIG. 7, which illustrates a flowchart of a method700for the transfer system to intermediate and manage the sharing of a set of keys amongst the computing system set. First, the transfer system identifies the computing systems in the computing system set (act701). For instance, in the context ofFIGS. 2 and 3, the transfer system220keeps track of membership in the computing system set210. As represented by arrow702, this identification is continuously performed such that the membership is kept track up. As a new computing system joins the computing system set210, the transfer system220registers that new computing system as being a member of the computing system set210. As a computing system is removed from the computing system set210, the transfer system220removes that computing system from the computing system set210.

Furthermore, as potentially a separate process from maintaining this membership, when the transfer system receives any encrypted message from a computing system in the computing system set (act710), the transfer system potentially stores that encrypted message (act711) as well as delivering the encrypted message to one or more of the remaining computing systems in the computing system set (act712). Storage may especially occur when the encrypted message includes another encryption key, as when rollover of the transfer encryption key is occurring. This process may be repeated regardless of which computing system acts as the initiating computing system in the transfer encryption key rollover process. For instance, in one rollover of the transfer encryption key, the computing system211may act as the initiating computing system. In a next rollover of the transfer encryption key, the computing system212may act as the initiating computing system.

FIG. 6Dillustrates the environment ofFIG. 6Cin a subsequent state600D in which the transfer system transferred (as represented by arrow632and633) the encrypted new transfer encryption key203′ to each of the other computing systems211and213in the computing system set210. Each of the computing systems211and213is shown as having received the encrypted transfer encryption key203′.

FIG. 8illustrates a flowchart of a method800for responding to the receipt of the encrypted transfer encryption key203′. The first act is detecting receipt of the encrypted message203′ (act801). InFIG. 6D, the computing systems211and213have detected receipt of the encrypted transfer encryption key203′. At this point, the computing systems211and213might not actually know the content of the message, but simply understand that they now must decrypt the message using the transfer encryption key202that they already have.

Then, the recipient computing system decrypts the encrypted transfer encryption key using the old transfer encryption key (act802). This allows the recipient computing system to acquire the new transfer encryption key (act803).FIG. 6Eillustrates the environment ofFIG. 6Din a subsequent state600E in which the recipient computing systems211and213have each decrypted the encrypted transfer encryption key203′ using the old transfer encryption key202(act802), to thereby acquire the new transfer encryption key203. The new transfer encryption key203may then be applied (act804), which allows the old transfer encryption key to be discarded or ignored from that time forth. Accordingly,FIG. 6Fillustrates the environment ofFIG. 6Eis a subsequent state600F in which the computing systems211,212, and213are illustrated as having and applying the new transfer encryption key203, and with there being no old transfer encryption key202having not been removed or rendered irrelevant.

Accordingly, the principles described herein allow for automated rollover of transfer encryption keys. Furthermore, it permits a computing system that was offline or newly joined into the computing system set to become caught up to the current transfer encryption key.

For instance, suppose that there have been three rollovers of transfer encryption key.FIG. 9illustrates the encrypted messages901,902and903that could be stored by the transfer system. The encrypted message901is an encryption of the second transfer encryption key203(represented as a triangle) using the very first transfer encryption key203(represented as a rectangle), and is stored by the transfer system at the first rollover of the transfer encryption key. The encrypted message902is an encryption of the third transfer encryption key204(represented as a rhombus) using the second transfer encryption key203(again represented as a triangle), and is stored by the transfer system at the second rollover of the transfer encryption key. The encrypted message903is an encryption of the current transfer encryption key205(represented as an octagon) using the third transfer encryption key204(again represented as a rhombus), and is stored by the transfer system at the third and final rollover of the transfer encryption key.

Through cooperation with the transfer system, a computing system that has only the first transfer encryption key can get caught up to acquire the current transfer encryption key. The computing system could acquire the encrypted message901from the transfer system, decrypt that encrypted message using the very first transfer encryption key201to thereby acquire the second transfer encryption key202. The computing system could then acquire the encrypted message902from the transfer system, decrypt that encrypted message using the second transfer encryption key202to thereby acquire the third transfer encryption key203. Finally, the computing system could acquire the encrypted message903from the transfer system, decrypt that encrypted message using the third transfer encryption key203to thereby acquire the current transfer encryption key203.