Control device and value document cassette circuit

EP4804155A1Pending Publication Date: 2026-09-09DIEBOLD NIXDORF SYST GMBH
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
EP2025161494
Authority / Receiving Office
EP · EP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-03-04
Publication Date
2026-09-09

Smart Images

  • Figure IMGAF001_ABST
    Figure IMGAF001_ABST
Patent Text Reader

Abstract

According to various embodiments, a control device (102) may comprise: a memory (102m) that stores initial data implementing a key (MK); an interface (102a) for communicating with a security document cassette according to a communication protocol; one or more processors (102p) configured to: determine (401) a first code (t(2)) based on a first message to the security document cassette generated according to the communication protocol and based on the key (MK); authenticate (403) to the security document cassette by means of a second message to the security document cassette generated according to the communication protocol, wherein the second message contains the first code (t(2)).
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Several embodiments involve a control device and a security document cassette circuit.

[0002] In modern systems that handle valuable documents (for example, receiving or dispensing them), security, especially of internal components, is becoming increasingly important. Attacks on ATMs by well-informed third parties (more commonly referred to as attackers), for example, from the service sector, are on the rise. Such attacks are increasingly organized and are not limited to individual devices or device types.

[0003] A common target for attack is the cash box used to store valuables (also known as a document safe), which, when used for cash, is also called a cash box and is used for transporting cash. The attacker attempts to gain access to the filled cash box in order to tamper with it and remove cash. Depending on the type, the cash box incorporates various security measures against physical tampering. Among other things, the cash box may have an electronic tamper indicator that the attacker would have to reset to conceal the attack, and which can therefore also be a target.

[0004] Generally, the attacker aims to remove the cash from the cassette without leaving a trace. However, simply forcing the cassette open would leave such traces. Therefore, the attacker tries to gain access to the cassette's communication interface to remove cash and eliminate any signs of tampering. If the attacker has sufficient knowledge of the cassette's standard security measures (e.g., tamper detection), they could also use the communication interface to circumvent these measures, for example, by deleting information after the attack.

[0005] Against this background, it is a general aim that the cash cassette should enable normal operation when it is in a secure environment (e.g., in an ATM) while also providing protective measures when it is outside of that secure environment. Such protective measures should make it more difficult for an attacker to electronically access the cassette outside of a secure environment in such a way as to grant access to the cash or to alter security-relevant data, such as tamper indicators.

[0006] Overcoming such protective measures generally becomes more difficult the more complex they are. However, this also means that more effort and resources are needed to implement better protective measures.

[0007] Various implementations have revealed, among other things, that conventional cassettes offer limited possibilities for implementing resource-intensive or complex security measures. Therefore, such security measures are typically either omitted at the expense of protection, or the cassette is equipped with greater computing and storage capacity as well as an improved communication interface to expand these possibilities. The latter, however, increases the cassette's cost and is therefore not always economical in relation to the risk of an attack, especially when security measures are to be uniformly upgraded for a nationwide banking system.

[0008] In this context, it was recognized that such banking systems predominantly use cash cassettes whose electronics (e.g., cash cassette electronics) have extremely low computing and storage capacity and place particular demands on the backward compatibility of the communication interface. The implementation of resource-intensive security measures, for example, based on an asymmetric cryptographic method (such as Rivest-Shamir-Adleman – "RSA"), would therefore be either uneconomical or only possible at very high cost in the aforementioned case, or would overload the cassette's electronics, resulting in performance losses that would impair regular operation. Furthermore, such a cassette would offer no special protection for securing cryptographic keys.Therefore, there is a risk that an attacker could easily read the stored cryptographic keys, thereby compromising the security of other tapes. A similar concern arises from the absence of a (e.g., cryptographic) random number generator in such tapes.

[0009] According to various embodiments, improving the security of a cassette is facilitated, for example, by minimizing or eliminating the need for physical modifications (e.g., upgrades). This is achieved, among other things, by the fact that the embodiments provided herein do not require a secure environment for safeguarding a cryptographic key and / or a cryptographically secure random number generator within the cassette. This is also achieved, among other things, by the resource-efficient nature of the embodiments provided herein, which therefore require minimal computing and storage capacity without impairing the regular operation of the cassette.

[0010] Thus, according to various embodiments, it is possible to equip existing cassettes with a high level of security in a cost-effective manner, and / or to produce cost-effective cassettes with a high level of security.

[0011] It was clearly demonstrated that the ATM has a control device (also called a master controller) that controls the cassettes and is significantly more performant than the cassette's electronics. For example, such a master controller has a security smart card that physically and cryptographically secures a stored key and implements important cryptographic primitives (such as a random number generator).

[0012] According to various implementations, protection against so-called replay attacks or key exposure attacks is also improved. Perfect forward secrecy or confidentiality is not necessarily required for this.

[0013] According to various embodiments, an ATM (or at least its control unit) can reliably authenticate itself to a cash cassette (or at least its electronics). Some of these embodiments further provide two-way authentication between the cassette and the master controller. Depending on the desired security level, additional protective measures, such as further encryption, can be more easily integrated.

[0014] The various embodiments described herein offer an efficient key exchange protocol, so that access to an external key server is not necessarily required for regular operation. Furthermore, the embodiments described herein do not necessarily require an asymmetric cryptographic method and / or a random number generator in the cartridge. This allows for optimal utilization of the cartridge's performance and reduces storage space consumption and communication complexity.

[0015] They show Figures 1 and 11 show a system according to various embodiments in a schematic diagram; Figures 2 and 3 each show the communication and data processing of the system according to a key exchange protocol in a schematic diagram according to various embodiments; Figure 4 shows a method according to various embodiments in a schematic flowchart; Figures 5 and 6 each show various functions of the key exchange protocol according to various embodiments in a schematic diagram; Figure 7 shows a method according to various embodiments in a schematic flowchart; Figures 8, 9 and 10 each show various functions of the key exchange protocol according to various embodiments in a schematic diagram; and Figure 11 shows a money transfer terminal according to various embodiments.

[0016] The following detailed description refers to the accompanying drawings, which form part thereof and illustrate specific embodiments in which the invention can be implemented. In this context, directional terminology such as "top," "bottom," "front," "back," "anterior," "rear," etc., is used with reference to the orientation of the described figure(s). Since components of embodiments can be positioned in a number of different orientations, the directional terminology serves only for illustration and is in no way limiting. It is understood that other embodiments may be used and structural or logical modifications may be made without deviating from the scope of protection of the present invention.It is understood that the features of the various exemplary embodiments described herein can be combined with one another, unless specifically stated otherwise. The following detailed description is therefore not to be interpreted in a limiting sense, and the scope of protection of the present invention is defined by the appended claims.

[0017] Within the scope of this description, the terms "connected," "connected," and "coupled" are used to describe both direct and indirect connections (e.g., resistive and / or electrically conductive, such as an electrically conductive connection), direct or indirect connections, and direct or indirect coupling. In the figures, identical or similar elements are designated with identical reference numerals where appropriate. Several elements can, for example, be coupled along an interaction chain along which an interaction can be exchanged, such as a signal, data, and / or electrical energy. According to various embodiments, "coupled" can be understood in the sense of a mechanical (e.g., physical) coupling, such as by means of direct physical contact.

[0018] For the sake of clarity, this document refers to the operation of the ATM and the cash cassette to describe aspects of different embodiments more comprehensibly, such as the key exchange protocol, its data processing, and / or the communication between them. However, it should be understood that the ATM's cash cassette aspects are implemented by means of a control device, which is not necessarily integrated into the ATM itself. For example, this control device could be provided separately or integrated into another system (e.g., a terminal). Therefore, it should be understood that what is described here regarding the ATM's cash cassette aspects can apply analogously to the control device.

[0019] By analogy, the aspects of the cash box with respect to the ATM are implemented by means of a corresponding circuit, which does not necessarily have to be built into the cash box itself. For example, this circuit can be provided separately or built into another cassette (e.g., a document cassette). Therefore, it can be understood that what is described here for the aspects of the cash box with respect to the ATM can apply by analogy to the circuit (also referred to, for clarity, as the document cassette circuit).

[0020] The term "entity" can be understood here as either a physical entity or a process. Examples of physical entities include: a device, a circuit, a system, and a component (e.g., an information technology component). A device, such as a control device, can be an electronic computing device (also called a computer) embedded in a technical context, for example, configured to provide one or more functions within that context (also referred to as a technical function). Examples of technical functions include: a monitoring function, a control function, and / or a regulation function (where the output of the monitoring function is used as input for the control function), and a data conversion function (or signal conversion function). The monitoring function can be implemented, for example, using a measurement chain.The control function can be implemented, for example, using a control chain.

[0021] The state of an entity (e.g., a device, system, process) can be understood as the entirety of information that fully describes the variable (e.g., time-dependent) properties of the entity. The actual state can be understood as the state of the entity as it actually exists or can be detected by sensors at a given time. The desired state can be understood as the target state, i.e., a specification. Control can be understood as the intentional influencing of the current state (also referred to as the actual state) of the entity. The current state can be changed according to the specification (also referred to as the target state), for example, by changing one or more operating parameters of the entity.

[0022] This refers to various information technology components (e.g., data processing, data transmission, and / or data storage), such as processors, data storage devices, communication infrastructure (e.g., comprising or consisting of a bus system or other network), and the like. Several information technology components can be interconnected via the communication infrastructure (e.g., through a corresponding interface of the component) and, during operation, exchange data (e.g., a digital representation of information) with each other (more generally referred to as communication).

[0023] Communication (e.g., within the entity or between the entity and an external component) can be message-based (i.e., based on messages) according to a communication protocol (e.g., a network communication protocol, also referred to simply as a network protocol). Communication can involve transmitting, or at least sending, or at least generating a message containing data according to the communication protocol. The communication protocol can be visualized as an agreement governing communication between two or more components. In its simplest form, the communication protocol can be defined as a set of rules that determine the syntax, semantics, and synchronization of data transmission, including, for example, how the sender and recipient of the message are specified. The communication protocol(s) used (e.g.,One or more network protocols can be selected arbitrarily and can (but do not have to) be configured according to the OSI (Open Systems Interconnect) reference model. Any protocol can also be used within the respective protocol layers. For example, a fieldbus communication protocol can be used for communication over a fieldbus. Similarly, a USB communication protocol can be used for communication over a universal serial bus (USB).

[0024] Of course, a different communication protocol can also be used, which may, for example, be proprietary.

[0025] Each interface (e.g., connected to the communication infrastructure) can be configured to transmit data according to the communication protocol, for example, to transmit, send, or at least generate a message containing the data. The interface can be configured, for example, to communicate via a bus, such as a CAN bus or LIN bus (also known as a Local Interconnect Network bus), ZigBee for wireless communication, or IP over Ethernet. The interface can also be configured to communicate with another interface (e.g., another physical entity).

[0026] For example, a message may contain one or more of the following data: information about who the message is from (also called the sender), information about who the message is addressed to (also called the recipient), the content of the message.

[0027] A security-critical message, as understood herein, may, for example, contain one or more than one command (also referred to as an instruction or directive). Examples of such instructions include: an instruction to issue one or more valuable documents; an instruction to receive one or more valuable documents; an instruction to open the container of a cassette; an instruction to perform a generation change; and the like.

[0028] Regarding communication and the messages transmitted, the terms "authentication" and "verification" are used here. Authentication involves an entity providing proof that it is indeed the entity it claims to be. Verification refers to the checking of the claimed authentication (e.g., the provided proof), for example, by the recipient of the proof. Authentication can, for example, involve verifying the proof, such as by comparing it to a predefined set of criteria and / or by using a verification algorithm. This is distinct from authorization, which refers to the granting of rights, for example, based on the result of authentication. Authorization can, for example, involve the final confirmation of an authentication.An exemplary authentication process is the so-called challenge-response authentication process (also referred to as challenge-response authentication). In the challenge-response authentication process, a communication participant presents the communication participant to be authorized with a task (the so-called challenge), which the communication participant to be authorized answers with proof of knowledge in order to demonstrate that they know a secret piece of information without having to transmit that information themselves.

[0029] According to various definitions, the term "processor" can be understood as any type of entity that allows the processing of data or (e.g., data-representing) signals. The data or signals can, for example, be processed according to at least one (i.e., one or more than one) specific function performed by the processor. Examples of processor components include: an analog circuit, a digital circuit, a mixed-signal circuit, a logic circuit, a microprocessor (e.g., in ARM architecture), a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable logic gate array (FPGA), an integrated circuit, or any combination thereof. A microprocessor in ARM architecture is also referred to herein as an ARM processor or simply ARM.Any other type of implementation of the respective functions described in more detail below can also be understood as a processor (e.g., as a logic circuit). It is understood that one or more of the processes and / or operations described in detail herein can be executed (e.g., realized) by a processor through one or more specific functions executed by the processor. Similarly, a process or operation described herein can be implemented by means of code segments which, when executed by the processor, are configured to cause the processor to execute the process or operation.

[0030] Depending on its specific design, a data storage device (also called a storage medium or simply memory) can be non-transient. Examples of non-volatile data storage include: a hard drive, semiconductor memory such as a read-only memory (e.g., a read-only memory), non-volatile random access memory (also called NVRAM), and / or flash memory (also called flash). The read-only memory (also called ROM) can be, for example, a programmable ROM or an erasable programmable ROM (which can also be called EPROM). The volatile data storage can be, for example, a volatile random access memory.

[0031] In the context of a cryptographic process (e.g., encryption, authentication, or signing), a cryptographic key (also simply called a key) is a piece of information (e.g., a string) that parameterizes the cryptographic process (e.g., its algorithm) and thus influences its output (e.g., independently of the input). The key can be implemented using data (also called key data or key-implementing data). The key data can, for example, contain the key (e.g., its string) as plaintext, such that the key can be read directly from the key data. Alternatively, the key data can contain executable program code that, when executed, causes a processor to store the key implemented by the key data in memory (e.g., a memory location).to write to a predefined memory area, which is defined, for example, by the key data.

[0032] Examples of cryptographic keys described herein include: a session key, a reference key, a communication key, and a cassette key.

[0033] This section refers to various cryptographic algorithms and functions. Examples include: a hash function (e.g., a secure hash function, also known as SHA), a block cipher (e.g., according to the "Advanced Encryption Standard", also known as AES), a message authentication code algorithm, or a key derivation function.

[0034] The secure hash function can be of type SHA-256 (SHA-2) or SHA-3. SHA can be configured according to the Secure Hash Standard (SHS) or the SHA-3 standard. See, for example, Federal Information Processing Standards (Publication (FIPS PUB 180-4)) or Permutation-Based Hash and Extendable-Output Functions (Federal Information Processing Standards Publication, FIPS PUB 202). The block cipher can be of type AES-128 or AES-256. See, for example, The Design of Rijndael: AES - The Advanced Encryption Standard by Rijmen, JD (2002).

[0035] The message authentication code algorithm (also known as the MAC algorithm) can, for example, be configured to generate a key-hash message authentication code (also known as HMAC). HMAC is of the type known as a "Message Authentication Code" (MAC) and is generated based on a hash function, such as the Secure Hash Algorithm (SHA), and a secret key (also known as a MAC key). See also "The Keyed-Hash Message Authentication Code (HMAC)" (Federal Information Processing Standards Publication, FIPS PUB 198-1). Alternatively or additionally, the key derivation function can be, for example, an HMAC-based key derivation function (then also known as HKDF), for example, based on HMAC-SHA. See also "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)," RFC 4279, pp. 1-15, by Pasi Eronen, HT (2005).This configuration offers a simplification, as it does not necessarily require the use of a block cipher.

[0036] The message authentication code algorithm can, for example, be configured to generate a key-block cipher message authentication code (also known as CMAC). CMAC is of the type known as a Message Authentication Code (MAC) and is generated based on a block cipher, such as AES. See, for example, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication" (NIST Special Publications), NIST SP 800-38B, (2016). Alternatively or additionally, the key derivation function can be an HKDF, for example, based on HMAC-SHA. This configuration can be more easily extended to include confidentiality, since in this case an EAX mode (a flexible, nonce-using scheme for AEAD, known as "Authenticated Encryption with Associated Data") based on CMAC and AES can be used to facilitate confidentiality and authentication.

[0037] The key derivation function (also known as KDF) does not necessarily have to be implemented using the security document cassette circuit, which is why a different function can be used for this function than for the other key derivation functions.

[0038] In various embodiments, a key exchange protocol is provided, according to which the retrieval and / or transmission of one or more cryptographic keys takes place. In other words, the key exchange protocol can define what data is retrieved and / or transmitted, how it is transmitted, and / or how it is processed. Accordingly, the key exchange protocol can have various components: Examples of the components of the key exchange protocol include: a communication protocol (which clearly specifies how the data is transmitted), a data processing protocol (which clearly specifies how the data is processed), and an exchange protocol (which clearly specifies what data is transmitted).

[0039] The communication participants are hardware components that differ from one another, for example, in their security features and / or protection mechanisms. A cash box can be individualized (also referred to here as personalized) during production with a box-specific key, while a master controller can receive one or more reference keys (also referred to as master keys), for example, via previously distributed communication keys. This key exchange protocol enables the use of standard communication protocols while simultaneously improving security.

[0040] The key exchange protocol according to various embodiments is based, for example, on the keys distributed in advance, whereby the key exchange protocol takes into account one or more than one of the following circumstances: Communication takes place between two groups of participants: the master controller and the document cassette circuit. Multiple document cassette circuits can differ from one another in their cassette ID and / or their cassette-specific key (also referred to as cassette key or cassette-specific communication key). The master controllers, however, can be identical (e.g., of the same construction), at least in the master key, which allows them to determine the key of each document cassette circuit based on the cassette ID of the document cassette circuit. The document cassette circuit cannot have access to a cryptographically secure key. The document cassette circuit and the master controller can differ from one another in the random number generator they employ (if the document cassette circuit even has a random number generator).Each document safe circuit communicates with various master controllers during its operational lifetime. Therefore, it can be advantageous for a session counter (e.g., only) to be managed by the document safe circuit itself.

[0041] Due to these circumstances, standardized solutions, such as authentication protocols based on symmetric keys or conventional key exchange protocols based on pre-distributed keys, may be difficult to use or even unsuitable. See also "Information technology - Security techniques - Entity authentication - Part 4: Mechanisms using a cryptographic check function. International Organization for Standardization", IEC 9798 (1999).

[0042] The security provided according to the various implementations is scalable. The key exchange protocol provided herein has several parameters that facilitate adaptation to security and efficiency requirements, including, for example: the length of the keys; the length of the tag; the size of the set of challenges; and / or the selection of the key derivation function.

[0043] The key exchange protocol provided herein also achieves one or more than one of the following: Two-way authentication and confidentiality through simple extensions; the ability to corrupt a cassette-specific key without compromising the security of other components; and the ability to revoke one or more master keys and switch to a new key generation in the field. This also minimizes the necessary adjustments in the service environment.

[0044] This document describes methods according to various embodiments, whereby it can be understood that each method can be implemented by means of a physical entity or by means of code segments. The physical entity (e.g., the control device), for example, at least one of its processors, can be configured to execute the method. Alternatively or additionally, the physical entity (e.g., the memory) can have code segments that implement the method or at least contain instructions according to the method. The code segments (e.g., instructions therein) can be configured, when executed by at least one processor, to execute the method.

[0045] Fig.1 A system according to various embodiments is illustrated in a schematic diagram. In one exemplary implementation of the system, it is configured as a terminal, e.g., a self-service terminal (e.g., an ATM). The terminal has, for example, at least one user interface configured to receive information from or output it to the user and / or to receive or output at least one security document from or to the user.

[0046] The system can include a control device 102 and a document cassette circuit 104 (e.g., implemented as a microcontroller), which can be configured to communicate with each other, e.g., when they are coupled together. It can be understood that the control device 102 and the document cassette circuit 104 can also be provided individually, e.g., separately from each other. The document cassette circuit 104 can, for example, be part of the cassette's electronics or provide this electronics.

[0047] The control device 102 (also referred to as controller or, for easier understanding, master controller) has several components that are communicatively coupled to one another, for example by means of a communication infrastructure 102k, including, for example, a data storage device 102m (also referred to as memory), at least one (i.e., one or more than one) interface 102s, and at least one processor 102p. The at least one interface 102s can, for example, have a first interface 102a and / or a second interface 102b.

[0048] The document cassette circuit 104 comprises several components that are communicatively coupled to one another, for example by means of a communication infrastructure 104k, including, for example, a data storage 104m (also referred to as memory), at least one (i.e., one or more than one) interface 104s, and at least one processor 102p. The at least one interface 104s can, for example, have a first interface 104a and / or a second interface 104b.

[0049] The first interface 102a of the control device 102 and the first interface 104a of the document cassette circuit 104 can, for example, be configured to communicate with each other, e.g., if they are coupled together and / or according to a common communication protocol, for example, a fieldbus communication protocol or a USB communication protocol.

[0050] The document cassette circuit 104 can be provided, for example, as a component of a document cassette 106 (also referred to simply as a cassette), but also individually (i.e., separately from it). For example, the system can have one or more cassette slots (not shown) for receiving the document cassette 106. When the document cassette 106 is inserted into the cassette slot, the document cassette circuit 104 and the control device 102 can be coupled together. When the document cassette 106 is removed from the cassette slot, the coupling between the document cassette circuit 104 and the control device 102 can be released.

[0051] The document safe 106 can comprise the document safe circuit 104, a container 106b, and a transfer device 106t. In an exemplary implementation of the document safe 106, it is configured as a cash box.

[0052] Container 106b may have a cavity 106h (also referred to as storage space 106h) for holding one or more valuable documents. The container may, for example, be a security container, such as a safe. Container 106b may, for example, be armored and / or locked by means of an actuator (not shown).

[0053] The transfer device 106t can be configured to transfer the valuable document into or out of the container 106b (e.g., its storage space 106h), for example, through an opening in the container 106b. For instance, the transfer device 106t can be located inside the container 106b.

[0054] The second interface 104b of the document safe circuit 104 can, for example, be configured to communicate with the transfer device 106t and / or the actuator (for example, to control them), e.g., if these are coupled together. The coupling of the second interface 104b of the document safe circuit 104 with the transfer device 106t and / or the actuator can, for example, be located inside the container 106b.

[0055] Key data implementing at least one key (also called a controller key or reference key) can be stored on memory 102m (e.g., a read-only area thereof) of the master controller 102. This at least one reference key can, for example, include a reference key and optionally one or more additional reference keys that differ, for example, in their generation (then also referred to as a reference key set).

[0056] The memory location 104m of the security document cassette circuit 104 can, for example, store one or more of the following: key data implementing at least one additional key (also referred to as a cassette key), a cassette identifier, and / or at least one counter. The at least one cassette key can, for example, be a cassette key and optionally one or more additional cassette keys that differ from each other, for example, in their generation (then also referred to as a cassette key set). The at least one counter can, for example, be a message counter and / or a session counter.

[0057] Fig.2 illustrates the communication and data processing of the system (for example according to embodiments 100) according to a key exchange protocol in a schematic diagram according to various embodiments 200.

[0058] To secure communication between the master controller 102 and the document cassette circuit 104, it is advantageous for the master controller 102 to authenticate itself to the document cassette circuit 104 and / or for the document cassette circuit 104 to authenticate itself to the master controller 102. To enable this, communication and data processing can initially take place according to the key exchange protocol. The key exchange protocol allows the control device 102 and the document cassette circuit 104 to establish a communication link secured according to an authentication protocol.

[0059] According to the authentication protocol, the master controller 102 can be configured, for example, to authenticate messages (e.g., containing instructions) to the security document cartridge circuit 104 (e.g., using a session key). Alternatively or additionally, the security document cartridge circuit 104 can be configured, according to the authentication protocol, to accept instructions (e.g., only if they originate from an authenticating communication participant (e.g., the master controller 102). This ensures that a potential attacker would be unable to control the security document cartridge circuit 104 using unauthenticated instructions. Alternatively or additionally, the replay of authenticated instructions (in the event of a replay attack) can be inhibited, for example, by means of a message counter used according to the authentication protocol.This ensures that the attack scenario described at the beginning can be better defended against.

[0060] The key exchange protocol described here improves security while minimizing resource requirements, thus improving performance and space consumption (program and message size).

[0061] The key exchange protocol will first be explained using an exemplary implementation of the system, which includes a cash box 106 and a master controller 102. In this regard, the following aspects and terms will be noted, as in Fig.2 shown, referenced: MK = Reference key (also called master key): ID = Cassette identifier (also called cassette ID), CK ID = Cassette-specific key (also called cassette key), SC = Session counter, MC = Message counter, R = Set of challenges, rm = Randomly selected challenge (the so-called challenge), k = Key, for example, denoted by the index, for example as k Bezeichnung Richtung , where "mc" indicates the direction from the master controller to the cassette and "cm" indicates the direction from the cassette to the master controller. MAC = message authentication code (e.g., containing a checksum), Vrfy() = verification algorithm, KDF = key derivation functions, for example, denoted by the index, for example, as KDF designation .

[0062] Identical indices, for example, denote the same function or parameter. However, it can be understood that not every single aspect according to embodiment 200 is strictly necessary, as will be explained in more detail later.

[0063] The message authentication code is generated by a message authentication code algorithm MAC(k, bm ) → MAC. The input data (k, bm ) of the message authentication code algorithm (also called the MAC algorithm) intuitively consists of the data bm to be encoded and a key k (for simplicity also referred to as the MAC key).

[0064] The key derivation function can be a cryptographic function that is set up, based on input data that has at least one cryptographic key (also called output key) and optionally one or more additional pieces of information, to generate output data that has one or more keys (also called output keys).

[0065] The verification algorithm can be configured to determine whether the input data (a ∈ V, b ∈ V, c ∈ V) fed into the algorithm are compatible. Expressed as a relation, this can be written as Vrfy(a ∈ V, b ∈ V, c ∈ V) → v, where the input data fed into the verification algorithm are compatible if v = 1 (or if v satisfies another criterion). The output v can, for example, only take the value 1 or 0. For instance, it can be verified whether a claim c meets the expectation based on the input data a and b (without needing to know the expectation for c).

[0066] In the exemplary implementation, the cash box is personalized with a unique cash box ID (ID) and / or a cash box key (CK ID), which are stored, for example, on memory 104m of cash box 106 (also referred to as cash box memory 104m). This cash box key is derived from the master key and is stored, for example, directly during the production of cash box 106. Compromising the cash box key therefore does not necessarily affect the security of other cash boxes or their corresponding cash box keys.

[0067] The 104m cassette memory additionally stores the session counter and / or the message counter, which, for example, cannot be changed externally without destroying the 106 cassette. The cassette ID can optionally be set to be unchangeable and / or read-only, for example, by storing it in a write-protected area (e.g., a read-only area) of the 104m cassette memory (e.g., physically and / or electronically).

[0068] The Master Controller 102 optionally includes a smartcard (e.g., a security smartcard) on which the master key is stored. This master key allows the Master Controller 102 to calculate the cassette key based on the cassette ID and authenticate itself to the cassette. Since this key derivation is performed by the Master Controller 102 and not by the cassette, it can be based on one or more functions of the smartcard. To ensure the confidentiality of the master key, it is stored on the smartcard.

[0069] It can be understood that the smartcard is only one example of a cryptographic measure and that the master key can also be secured by one or more other cryptographic measures (e.g., as an alternative or in addition to the smartcard). For example, what has been described regarding the smartcard can apply analogously to one or more cryptographic measures of other types.

[0070] Optionally, the control device 102, e.g. its smartcard, can have an interface that is set up to exchange the master key (e.g. to change or save it), as will be described in more detail later.

[0071] After the security document cassette circuit 104 is coupled with the control device 102, a (for example, insecure) communication session 209 is established between them 207. During the establishment 207 of the communication session 209, the security document cassette circuit 104 increments the session counter and resets the message counter to an initial value (e.g. 0).

[0072] Once the communication session 209 is established, the master controller 102 initiates the key exchange protocol based on the pre-distributed key data. The (more powerful) master controller 102 can use a cryptographically secure random number generator, while the security document cassette circuit 104 optionally uses the current state of the session counter as a challenge. Alternatively or additionally, the challenge for the security document cassette circuit 104 can be generated using a random number generator, for example, if the security document cassette circuit 104 implements such a (e.g., cryptographic) random number generator.

[0073] The result of the key exchange protocol is a session key. k auth mc , by means of which the subsequent communication between the control device 102 and the document cassette circuit 104 is secured according to the authentication protocol. For example, the control device can be configured according to the authentication protocol to transmit one or more commands (e.g., security-critical ones) to the document cassette circuit 104 using the session key. k auth mc to authenticate. Alternatively or additionally, the document cassette circuit 104 can be configured according to the authentication protocol, one or more commands (e.g., security-critical) transmitted by the control device 102 using the session key. k auth mc to authenticate.

[0074] An exemplary implementation of the key exchange protocol according to embodiments 200 is described below, in which the security document cassette circuit 104 responds to the transmission 201 of a challenge rm from the control device 102 by transmitting a code t (1)< (also referred to as tag or cassette code) as proof of knowledge to the control device 102 203 (also referred to as response transmission 203). The challenge rm (also referred to as challenge rm) may contain random information (also referred to as moment information) generated by the master controller 102. The transmission message 201 containing the challenge rm is referred to herein, for ease of understanding, as the challenge message.Upon transmission 201 (also referred to as the outgoing transmission) of the challenge rm, the security document cassette circuit 104 optionally responds with transmission 203 containing the cassette ID and / or the (e.g., previously incremented) session counter. The transmission of the cassette code t(1)<, the cassette ID, and / or the session counter can, but does not necessarily have to, occur using the same message. For ease of understanding, the response message 203, which contains the cassette code t(1)<, is also referred to here as the authentication message.

[0075] The cassette code t(1)< can be determined by the security document cassette circuit 104 based on the challenge rm, optionally the cassette ID and / or the session counter, for example using the MAC algorithm. The cassette code t(1)< authenticates the cassette ID and the session counter and simultaneously binds the response message to the received challenge rm.

[0076] The document safe circuit 104 and / or the master controller 102 are set up, the MAC key k ke cm to determine, for example using a key derivation function KDF ke , based on one or more than one (e.g., each) of the following: the cassette key, the session counter, and / or the challenge. For example, both communication participants may know the same MAC key. If the cassette code t (1)< is determined using the MAC algorithm, this can further be based on the MAC key. k ke cm take place.

[0077] The master controller 102 is further configured to determine the cassette key based on the master key and the obtained cassette ID. Subsequently, the obtained cassette code t (1)< is verified by the master controller 102, for example, based on the determined MAC key. k ke cm and / or by means of the verification algorithm.

[0078] The master controller 102 is configured to determine an additional code t(2)< (also referred to as an additional tag or controller code), for example, using a MAC algorithm. The additional code t(2)< can be determined based on one or more than one (e.g., each) of the following: the cassette code t(1)< and / or the challenge, and optionally the cassette ID and / or the session counter. If the controller code is determined using the MAC algorithm, it can also be determined based on the MAC key. k ke cm take place.

[0079] By transmitting the controller code t (2)< to the document cassette circuit 104, the master controller 102 authenticates itself to the document cassette circuit 104 using the controller code t (2)< (then also referred to as the authentication proof). The document cassette circuit 104 is configured to verify the authentication proof tag from the master controller 102, for example, using the verification algorithm and / or based on one or more than one (e.g., each) of the following: the cassette code t (1,< the challenge, and / or the determined MAC key. k ke cm , as well as optionally the cassette ID and / or the session counter.

[0080] To conclude the exemplary implementation of the key exchange protocol, each, the master controller 102 and the document cassette circuit 104, determines a session key. k auth mc The session key can be determined based on one or more than one (e.g., each) of the following: the cassette key, the challenge, the session counter, the cassette code, and / or the controller code.

[0081] For example, then k auth mc : = KDF auth CK ID , r m , SC , t 1 , t 2 .

[0082] If the master controller fails to authenticate itself to the security document cassette circuit 104 (using the controller code) in the final step of the key exchange protocol, the security document cassette circuit 104 terminates the communication session. This means, for example, that the associated session counter cannot be reused. Alternatively or additionally, the master controller 102 terminates the session if the security document cassette circuit 104 fails to authenticate itself to the master controller 102 (using the cassette code).

[0083] The communication link following the key exchange protocol can be secured, for example, according to an authentication protocol. The authentication protocol can specify, for example, that the master controller 102 uses the session key to authenticate one or more messages (e.g., security-critical ones). Alternatively or additionally, the secure document cassette circuit 104 uses the session key (e.g., only) for verification.

[0084] Communication between the control device 102 and the document cassette circuit 104 can, for example, take place according to the authentication protocol to provide the secure communication link, as will be described in more detail later. The secure communication link can then be used, for example, to control the document cassette circuit 104, for instance, to transmit instructions.

[0085] If two-way authentication and / or encryption is required, additional keys can optionally be determined and / or transmitted based on the described key exchange protocol. For example, a modified key derivation can be performed such that more than one key is generated.

[0086] In an exemplary implementation of the authentication protocol, not all messages necessarily need to be authenticated with the session key. For example, messages of various types and / or content will be transmitted between the master controller 102 and the security document cassette circuit 104, and the authentication protocol can specify which type and / or content to authenticate. For example, (only) the messages containing a security-critical instruction are authenticated with the session key. Optionally, the message counter can be incremented for each such message, thus preventing a replay attack.

[0087] As shown, the cassette key is bound to the master key and / or can be determined based on the master key and / or based on the cassette ID, for example using a key derivation function.

[0088] To enable the revocation of master keys and thus the updating (e.g., replacement) of keys in the event of a serious compromise, the master controller 102 can store multiple master keys of different generations (also referred to as a reference key set), for example, at least two generations. The master controller 102 can obtain a master key of a new generation via an existing public key infrastructure, thereby updating the reference key set. The security document cassette circuit 104 can already receive multiple cassette keys of different generations (also referred to as a cassette key set) during production, for example, at least two generations.

[0089] The document cassette circuit 104 can be configured to perform a generation change of the cassette keys, for example, a transition to the next generation, when it receives an instruction for a (e.g., authenticated) generation change from the master controller 102 (for example, after successful authentication of the master controller 102 to the document cassette circuit 104). Alternatively or additionally, this can be done in a system specifically designed for this purpose.

[0090] Alternatively, a revocation key can be used to change the generation or to personalize the document cassette circuit 104 with a cassette key of the next generation. If all cassette keys stored in the cassette memory originate from already revoked master key generations, it may be necessary to re-personalize the document cassette circuit 104.

[0091] A key exchange protocol established for generation changes is explained below. In this case, the cassette key of a generation is bound to the master key of the same generation and / or can be determined based on the master key of the same generation and / or based on the cassette ID, for example using a key derivation function.

[0092] Fig.3 illustrates the communication and data processing of the system (for example according to embodiments 100) according to a key exchange protocol in a schematic diagram according to various embodiments 300, which are set up, for example, according to embodiments 200.

[0093] To enable the master controller 102 and the document cassette circuit 104 to agree on a generation of the master key, each master key and each cassette key is assigned a generation number gi. The generation number clearly indicates the generation of the key. If two keys differ in their generation number, they also differ in their generation.

[0094] The cassette keys stored on cassette memory 104m differ from each other in their generation number gc (and thus in their generation). The reference keys stored on controller memory 102m differ from each other in their generation number gm (and thus in their generation).

[0095] The key exchange protocol will first be explained using an exemplary implementation of the system, which includes a cash box 106 and a master controller 102. In this regard, the following aspects and terms will be noted, as in Fig.3 shown, referenced: gm = generation identifier (e.g. generation number) of the current master key (also referred to as current controller generation), gc = generation identifier (e.g. generation number) of the current cassette key (also referred to as current cassette generation); MK gm< = Reference key of the gm-th generation; MK gm+n< = Reference key of the "gm +n"-th generation, where n can be a natural number; C K ID g c = cassette key of the gc -th generation; C K ID g c + n = Cassette key of the "gc +n"-th generation, where n can be a natural number.

[0096] The transmission 201 (also referred to as outgoing transmission) of the actual controller generation gm is answered by the document cassette circuit 104 with the transmission 203 (also referred to as reply transmission) of the actual cassette generation gc .

[0097] The master controller 102 and / or the document cassette circuit 104 are configured to perform a generation comparison and / or a generation change.

[0098] The generation comparison can involve comparing the current cassette generation with the current controller generation and optionally determining a target generation based on the comparison, for example, if the current cassette generation and / or the current controller generation differ from each other.

[0099] If the comparison shows, for example, that the current cassette generation and the current controller generation are the same, the current controller generation can be determined as the target generation and / or the key exchange protocol can continue without a generation change. If the comparison shows, for example, that the current cassette generation and the current controller generation differ, a generation can be determined as the target generation that differs from the current cassette generation and / or the current controller generation (also referred to as a generation change or key change), e.g., is larger than them.

[0100] The master controller 102 can be configured to select a key from the reference key set as the actual reference key, whose generation corresponds to the determined target generation. Alternatively or additionally, the value document cassette circuit 104 can be configured to select a key from the cassette key set as the actual cassette key, whose generation corresponds to the determined target generation.

[0101] The key exchange protocol can then be continued based on the current cassette key and the current reference key, for example after the generation change has taken place.

[0102] If the generational change is to take place (for example, if g m = g c If the cassette key supply does not contain a cassette key of the target generation (plus 1), the communication session is terminated by the security document cassette circuit 104. In this case, it may be necessary to re-personalize the security document cassette circuit 104 before it can be operated normally again.

[0103] In an exemplary implementation, `gm = gc` can lead to a key exchange without a generation change, while a generation change occurs if `gm = gc + 1`. Other values ​​of `gm` and `gc` may be deemed invalid and / or lead to the termination of the communication session.

[0104] As shown, optionally one or more than one (e.g., each) of the following can be performed based on the current cassette generation and / or the current controller generation: determining the MAC key. k ke cm ; determining the cassette code t (1)< ; determining the controller code t (2)< ; determining the session key k auth mc and / or verification (e.g., of the tag and / or the authentication proof tag).

[0105] For example, then k auth mc : = KDF auth CK ID , r m , SC , g m , g c , t 1 , t 2 .

[0106] In an exemplary implementation of transmission 201, the master controller 102 transmits the actual controller generation. g m together with the challenge. If the generational comparison reveals a match, the key exchange protocol continues.

[0107] In an exemplary implementation of the generation change, the generation change of the master controller 102 can show that the old actual reference key "gm -1"-th generation ( MK g m-1< ) ​​is replaced by the reference key "gm"-th generation ( MK gm< ) as the new actual reference key. Alternatively or additionally, the generation change of the security document cassette circuit 104 may show that the old actual cassette key "gc"-th generation ( CK ID g c ) is replaced by the cassette key "gc +1" of the 5th generation ( CK ID g c + 1 ) as the new actual cassette key. For example, the generation change of the security document cassette circuit 104 may involve switching to CK ID g c + 1 and SC := to set 0.

[0108] In this or an additional exemplary implementation of the generation change, the key exchange protocol can be continued (e.g., by the document cassette circuit 104) with the note that the current communication session serves only to perform the generation change (switching the key generation) and that the key exchange protocol will be restarted (e.g., immediately) afterward. For example, document cassette circuit 104 uses the key that it considers to be current. CK ID g c with the note that the current communication session is only used to switch the key generation.

[0109] In an exemplary implementation of the response transmission, the security document cassette circuit 104 transmits its own generation number along with the cassette ID and the session number. g c (also in the case of key replacement without generation change).

[0110] According to the key exchange protocol, the master controller 102 then uses the corresponding master key to authenticate itself. After the security document cassette circuit 104 has verified the authentication 205 of the master controller 102, the next generation of cassette key is activated, the session counter is reinitialized, and a new key exchange protocol based on the new master key is started.

[0111] If a master key becomes corrupted or needs to be replaced as a precaution after a certain period, a newer generation master key can be stored on the master controller using an existing public key infrastructure and / or added to the controller's key pool. The master controller 102 can optionally store one or more master keys of an outdated generation for a predefined period and only delete them afterward. This provides more opportunities for the security document cassette circuit 104 to perform a generation upgrade during regular operation.

[0112] The following describes the procedures and implementations of the master controller 102 and the document cassette circuit 104, which implement various aspects according to embodiments 100 to 300.

[0113] Fig.4 A method according to various embodiments 400 is illustrated in a schematic flowchart, which is implemented, for example, by means of the control device 102 (for example, configured according to embodiments 100), for example, by configuring at least one processor thereof to carry out the method. The method can also be implemented by means of code segments.

[0114] The procedure, as described in section 401, involves determining a code (also referred to as controller code t(2)<) based on a communication protocol (e.g., the

[0115] Key exchange protocol) generated message (also called challenge message) to a security document cassette and based on a key (also called reference key).

[0116] The challenge message can, for example, contain the (e.g., random) challenge `rm` (also referred to as a challenge). The challenge can, for example, contain a so-called (e.g., random) moment piece of information (also referred to as a "nonce" or one-way information), which is determined at the start of the process, for example, using a (e.g., cryptographic) random number generator (also referred to as RAND). The challenge (e.g., the moment piece of information) can, for example, contain a randomly generated string.

[0117] The procedure, as described in section 403, involves authenticating to the security document cassette by means of a second message (also referred to as an authentication message) to the security document cassette, generated according to the communication protocol, wherein the authentication message contains the controller code.

[0118] The reference key can be implemented, for example, by means of key data that is stored, for example on a memory, for example the memory 102m of the control device 102.

[0119] The first message can be transmitted, for example, via an interface configured to communicate with a document safe according to the communication protocol. This interface can, for example, be the first interface 102a of the control device 102.

[0120] Optionally, the method may be set up according to embodiments 200 or 300, e.g. having at least some but not necessarily all aspects of embodiments 200 or 300.

[0121] Fig.5 Figure 500 illustrates various functions of the key exchange protocol according to different embodiments in a schematic diagram, for example, for implementing the method according to embodiment 400. The arrows shown clearly indicate the interdependence of the different pieces of information. A first piece of information is determined from one or more second pieces of information, from which an arrow leads to the first piece of information.

[0122] If the master controller 102 receives the cassette ID from the document cassette circuit 104 (provided it is stored there) and / or determines the cassette key based on this, security is further improved. In essence, the cassette ID enables individualized communication with respect to the document cassette circuit 104, so that the session key and / or authentication using the session key is bound to the document cassette circuit 104 that also stored the cassette ID.

[0123] If the master controller 102 receives the session counter cassette ID from the security document cassette circuit 104 (provided it is stored there) and / or the MAC key is determined based on this, security is further improved. In essence, the session counter enables individualization of the communication session, so that the session key and / or authentication using the session key is bound to the communication session that contains the session counter.

[0124] Fig.6 illustrates various functions of the key exchange protocol according to different embodiments 600 in a schematic diagram, for example for implementing the method according to embodiments 400, similar to embodiments 500.

[0125] Fig.7 A method according to various embodiments 700 is illustrated in a schematic flowchart, which is implemented, for example, by means of the security document cassette circuit 104 (for example, configured according to embodiments 100), for example by having at least one processor of it configured to carry out the method. The method can also be implemented by means of code segments.

[0126] The procedure, as described in Section 701, involves determining a code (also referred to as a cassette code) based on a key (also referred to as a cassette key) and based on the challenge message according to a communication protocol from the control device.

[0127] The procedure, as described in section 703, involves authenticating a second code (also called the controller code) provided by the control device, based on the cassette code.

[0128] The cassette key can be implemented, for example, by means of key data that is stored, for example on a memory, for example the memory 104m of the security document cassette circuit 104.

[0129] The challenge message and / or the controller code can be transmitted, for example, via an interface configured to communicate with the control device according to the communication protocol. The interface can, for example, be the first interface 104a of the document cassette circuit 104. Optionally, the method can be configured according to embodiments 200 or 300, e.g., incorporating at least some, but not necessarily all, aspects of embodiments 200 or 300.

[0130] Fig.8 The schematic diagram illustrates various functions of the key exchange protocol according to different embodiments 800, for example, for implementing the method according to embodiments 400 and / or 700. The arrows shown clearly indicate the interdependence of the different pieces of information, analogous to the explanation above.

[0131] Fig.9 Figure 900 illustrates various functions of the key exchange protocol according to different embodiments in a schematic diagram, for example, for implementing the method according to embodiments 700. The arrows shown clearly indicate the interdependence of the different pieces of information, analogous to the explanation above.

[0132] The diagram shows the group of data exchanged via transmission according to the key exchange protocol, including, for example, the challenge and the cassette code, and optionally the session counter and / or the cassette ID. Also shown are the data determined from this data by the processor 102p of the master controller 102 according to the key exchange protocol, including, for example, the cassette key, the MAC key, the controller code, and / or the session key.

[0133] Fig.10 The schematic diagram illustrates various functions of the key exchange protocol according to different embodiments 1000, for example, for implementing the method according to embodiments 700, similar to embodiments 900. The arrows shown clearly indicate the interdependence of the different pieces of information, analogous to the explanation above.

[0134] Fig.11Figure 1100 illustrates the system, which is configured as a money transfer terminal (e.g., an ATM), according to various embodiments 1100 in a schematic diagram. The system can further incorporate various aspects of one or more embodiments 100 to 1000. The money transfer terminal includes a safe 108 in which, for example, one or more cassette slots and / or the control device 102 are arranged. The security document cassette 106 can optionally be arranged in the safe 108, e.g., in the cassette slot, and / or coupled to the control device 102, e.g., when the security document cassette 106 is located in the safe 108. The cassette slot, if present, can store the security document cassette 106 in such a way that it can be pulled out of and / or inserted into the cassette slot.

[0135] The control device 102 can be configured to determine that it is or will be coupled with a security document cassette 106, and in response optionally trigger the execution of the key exchange protocol.

[0136] The safe 108 may also have a transport device 108v (also referred to as the safe's internal transport device 108v) which is designed to transport a valuable document, for example from the transfer device 106t out of the safe or from outside the safe to the transfer device 106t.

[0137] The money transfer terminal further comprises a housing (not shown) in which the safe 108 is arranged and / or which is coupled to the safe 108. The money transfer terminal may also have a processing system 1104 (e.g., in the housing) which is coupled to the control device (e.g., communicatively), e.g., its second interface 102b, e.g., to exchange data with the control device 102. Exemplary components of the processing system 1104 include: a reading device 1104a (e.g., for reading an RFID chip, a credit card, a smart card, or similar), a printer 1104b, a camera 1104c, a network device 1104d (e.g., a network card), a validation device 1104e, a dispensing device 1104f (e.g., for dispensing valuables), a deposit device 1104g (e.g., for depositing valuables), and an additional transport device 1104h (e.g.,for transporting valuable documents between the safe and the dispensing device and / or the depositing device); a user interface 1104k (e.g. having a PIN pad, a keyboard, a touchscreen or similar), e.g. an encrypted PIN keypad.

[0138] The processing system 1104 is configured to implement one or more technical functions of the money transfer terminal and / or to control the control device 102 according to the technical function. Examples of the technical functions of the money transfer terminal include: accepting and / or dispensing a security document (e.g., cash); reading a chip card; receiving authentication information from a user (e.g., for a PIN entry device); authenticating the user; authorizing the user to make a deposit and / or withdrawal; transporting documents within the ATM; storing and / or retrieving security documents into / from the safe (e.g., a cassette 106 located therein); and the like.

[0139] The control device 102 can be configured to control the security document cassette circuit 104 and / or the vault's internal transport device 108v according to security document transfer information, for example, when instructed to do so by the processing system 1104. The security document transfer information can specify the type and / or quantity of security documents to be transferred and / or the direction in which the transfer should take place (also referred to as the transfer direction). The transfer direction can clearly indicate whether a security document fed to the vault by the processing system 1104 is to be transported into the receiving room 106h (also referred to as the storage room), or whether a security document fed to the processing system 1104 by the vault is to be transported out of the receiving room 106h.

[0140] As described above, the document transfer cassette circuit 104 can be configured to control the transfer device 106t according to an instruction from the control device 102 (e.g., generated according to the document transfer information), (e.g., only) if the control device 102 and / or the instruction have been authenticated, and otherwise, for example, to reject the instructions from the control device 102 (e.g., if the instructions were transmitted by means of a security-critical message) or at least ignore them. This also applies, of course, if the instruction does not originate from the control device.

[0141] The following are various examples that refer to what has been described previously and depicted in the figures.

[0142] Example 1 is a control device (e.g., set up as an embedded system or part thereof) comprising: a memory that stores initial data implementing a key (e.g., MK); an interface for communicating with a security document cassette according to a communication protocol; one or more processors configured to (e.g., perform the following procedure): determine an initial code (e.g., t(2)<) based on an initial message (e.g., having rm) generated according to the communication protocol and sent to the security document cassette (e.g., addressed to it) and based on the key (e.g., MK); authenticate to the security document cassette using the initial code, preferably using a second message generated according to the communication protocol and sent to the security document cassette (e.g., addressed to it), wherein the second message contains the initial code.

[0143] Example 2 is the control device according to Example 1, wherein one or more processors are further configured to generate the first message (e.g. by means of a random number generator, e.g. cryptographic) according to the communication protocol and / or the second message according to the communication protocol; and / or wherein one or more processors are further configured to instruct the interface to send the first message and / or the second message.

[0144] Example 3 is the control device according to Example 1 or 2, wherein the first message comprises a nonce (e.g., rm), preferably according to a cryptographic challenge-response process (e.g., challenge-response authentication process), wherein one or more processors are preferably configured to determine the first code based on the nonce; and / or wherein the control device preferably implements a (e.g., cryptographic) random number generator (e.g., by means of a smart card) which is configured to generate the nonce.

[0145] Example 4 is the control device according to Example 3, wherein the nonce has a randomly generated string and / or is generated by means of a (e.g. cryptographic) random number generator.

[0146] Example 5 is the control device according to one of Examples 1 to 4, wherein the first message initiates a cryptographic challenge-response process (e.g., challenge-response authentication process), e.g., is set up for this purpose.

[0147] Example 6 is the control device according to one of Examples 1 to 5, wherein the memory has at least one memory area which stores the first data, wherein the memory area is preferably write-protected and / or cryptographically secured (e.g. by means of cryptographic measures), wherein the control device further preferably has a smart card which has the memory area.

[0148] Example 7 is the control device according to one of Examples 1 to 6, wherein the determination of the first code (e.g. t (2)< ) is further based on one or more than one of the following: an identification identifier (e.g. ID) of the document cassette (e.g. obtained from it); a session identifier (e.g. SC) originating from the document cassette; a second code (e.g. t (1)< ) originating from the document cassette, preferably based on the first message; a cassette key (e.g. CK ID ), preferably based on the key (e.g. MK) and / or the identification identifier (e.g. ID) of the document cassette, e.g. determined (e.g. by the processor of the control device).

[0149] Example 8 is the control device according to one of Examples 1 to 7, wherein the determination of the first code (e.g. t (2)< ) is based on a cassette key (e.g. CK ID ) which is based on the key (e.g. MK) and / or the identification identifier (e.g. ID), e.g. determined (e.g. by the processor of the control device).

[0150] Example 9 is the control device according to one of Examples 1 to 8, wherein the first code (e.g. t (2)< ) is a message authentication code (e.g. MAC, e.g. HMAC or CMAC) and / or is based on the first message (e.g. rm ) and / or the key (e.g. MK).

[0151] Example 10 is the control device according to one of Examples 1 to 9, wherein the first code (e.g. t (2)< ) is determined by means of a message authentication code algorithm (e.g. MAC, e.g. HMAC or CMAC) which preferably uses the first message (e.g. its content) and / or the key (e.g. MK).

[0152] Example 11 is the control device according to Examples 1 to 10, wherein the processor is further configured to control the security document cassette by means of a third message according to the communication protocol, wherein the third message is authenticated (e.g. by means of the session key) based on the first code (t (2)< ) and / or based on the first message (e.g. having rm), e.g. signed, preferably by means of a session key based thereon.

[0153] Example 12 is the control device according to Example 11, wherein the third message contains an instruction to the security document cassette to dispense or receive a security document; and / or to open a container of the security document cassette.

[0154] Example 13 is the control device according to Example 11 or 12, wherein the third message is authenticated (e.g., by means of the session key), e.g., signed, and is further based on one or more than one of the following: an identification identifier (ID) of the document cassette (e.g., obtained from it); a session identifier originating from the document cassette; a second code originating from the document cassette (e.g., t(1)<), preferably based on the first message; the key (e.g., MK); a communication key (e.g., the cassette key), which is preferably based on the key and / or the identification identifier (e.g., ID) of the document cassette, e.g., determined (e.g., by the control device).

[0155] Example 14 is the control device according to one of Examples 11 to 13, wherein the third message is authenticated, e.g., signed, by means of a session key (e.g., by means of the session key), which is preferably based on one or more than one of the following: an identification identifier (ID) of the security document cassette (e.g., obtained from it); a session identifier originating from the security document cassette; a second code originating from the security document cassette (e.g., t(1)<), which is preferably based on the first message; the key (e.g., MK); a communication key (e.g., the cassette key), which is preferably based on the key and / or the identification identifier (e.g., ID) of the security document cassette, e.g., determined (e.g., by the control device).

[0156] Example 15 is a device (e.g., an ATM) comprising: a safe; the control device according to one of Examples 1 to 14, which is arranged in the safe; a cassette slot arranged in the safe for receiving the security document cassette, wherein the cassette slot has a contact terminal that is coupled to the control device and is configured to transmit an electrical control signal generated by the control device to the security document cassette when it is received in the cassette slot and / or coupled to the contact terminal.

[0157] Example 16 is a document cassette circuit (e.g., set up as an embedded system or part thereof) comprising: a memory containing initial data implementing a key (e.g., CK ID); an interface for communicating with a document cassette-external control device according to a communication protocol; one or more processors configured to (e.g., perform the following procedure): determine an initial code (e.g., t(1)<) based on the key and based on an initial message (e.g., having rm) according to the communication protocol from the control device; authenticate a second code (e.g., t(2)<) originating from the control device, based on the first code, wherein an additional message containing the second code (e.g., t(2)<) originates from the control device.

[0158] Example 17 is the document safe circuit according to Example 16, wherein one or more than one processor is further configured to determine (e.g. extract) the second code (t (2)< ) based on a second message originating from the control device according to the communication protocol, wherein the second message preferably contains the second code (t (2)< ).

[0159] Example 18 is the document cassette circuit according to Example 16 or 17, wherein one or more processors are further configured to generate a third message according to the communication protocol to the control device, wherein the third message includes one or more of the following: the first code; an identification identifier of the document cassette circuit stored in memory; a session identifier stored in memory, wherein the processor is, for example, configured to update the session identifier when communication with the control device is started and / or terminated.

[0160] Example 19 is the document cassette circuit according to one of Examples 16 to 18, wherein the authentication of the second code (t (2)< ) is further based on one or more than one of the following: an identification identifier (e.g. ID) of the document cassette circuit stored in memory, a session identifier (e.g. SC) stored in memory; the first message; and / or a message authentication code (e.g. MAC, e.g. HMAC or CMAC), which is preferably based on the first message, the session identifier and / or the key, wherein the processor is, for example, configured to update the session identifier when communication with the control device is started and / or terminated.

[0161] Example 20 is the document cassette circuit according to one of Examples 16 to 19, wherein the determination of the first code is further based on one or more than one of the following: an identification identifier (e.g. ID) of the document cassette circuit stored in memory; a session identifier (e.g. SC) stored in memory; a message authentication code (e.g. MAC, e.g. HMAC or CMAC), which is preferably based on the first message, the session identifier and / or the key; and / or wherein the processor is, for example, configured to update the session identifier when communication with the control device is started and / or terminated.

[0162] Example 21 is the document security cassette circuit according to one of Examples 16 to 20, wherein the first message contains a nonce according to a (e.g. cryptographic) challenge-response process (e.g. challenge-response authentication process), e.g. a string; and / or wherein the first message initiates the (e.g. cryptographic) challenge-response process, e.g. is set up to do so.

[0163] Example 22 is the document safe circuit according to Example 21, wherein the nonce contains a randomly generated string; and / or wherein the processor is configured, for example, to update the session identifier when communication with the control device is started and / or terminated.

[0164] Example 23 is the document safe circuit according to one of Examples 16 to 22, where the first code is a message authentication code (e.g. MAC, e.g. HMAC or CMAC) and / or is based on the first message and / or the key.

[0165] Example 24 is the document safe circuit according to one of Examples 16 to 23, where the second code is a message authentication code (e.g. MAC, e.g. HMAC or CMAC).

[0166] Example 25 is the document safe circuit according to one of Examples 16 to 24, wherein the first code is formed using a message authentication code algorithm which preferably uses the first message (e.g. its content) and / or the key.

[0167] Example 26 is the document safe circuit according to any one of Examples 16 to 25, wherein the processor is further configured to increment a session identifier stored in memory if authentication of the second code fails; and / or wherein the processor is further configured to terminate communication (e.g. the communication session) with the control device if authentication of the second code fails.

[0168] Example 27 is the document cassette circuit according to any one of Examples 16 to 26, wherein the processor is further configured to validate and / or authorize an instruction, preferably to dispense or receive a document of value, from the control device when: the authentication is successful; and / or a fourth message according to the communication protocol, which contains the instruction, is authenticated (e.g. by means of the session key), e.g. signed, preferably based on one or more than one of the following: the first code, the second code, the key, and / or the first message, preferably by means of a session key based thereon.

[0169] Example 28 is the document cassette circuit according to Example 27, further comprising: an additional interface for controlling a transfer device; wherein the processor is further configured to output a control signal via the additional interface (e.g., to control a transfer device) according to the instruction from the control device when the instruction is validated and / or authorized (e.g., by means of the session key and / or based on one or more than one of the following: the first code, the second code, the key, and / or the first message).

[0170] Example 29 is a document safe comprising: the document safe circuit according to one of Examples 16 to 28, a (e.g., closed and / or physically secured) container (e.g., a security container); the transfer device for transferring a document safe into and / or out of the container; wherein preferably: one or more processors of the document safe circuit are configured to control the transfer device according to an instruction from the control device when: authentication is successful; and / or a fourth message according to the communication protocol containing the instruction is authenticated (e.g., by means of the session key), e.g., signed, preferably based on one or more than one of the following: the first code, the second code, the key, and / or the first message.

[0171] Example 30 is a system comprising: the control device and / or the document cassette circuit according to one of Examples 1 to 28, which are preferably coupled together, wherein the document cassette circuit is provided, for example, by means of the document cassette according to Example 29 of the system.

[0172] Example 31 is a procedure performed by the processor of the control device and / or the security document cassette circuit according to one of Examples 1 to 28.

[0173] Example 32 is a (e.g., non-transitory) storage medium that has code segments set up, when executed by a processor, to cause the processor to perform the procedure according to Example 31.

Claims

1. Control device (102) comprising: • a memory (102m) storing initial data implementing a key (MK); • an interface (102a) for communicating with a security document cassette according to a communication protocol; • one or more processors (102p) configured to: • determine (401) an initial code (t (2) ) based on an initial message to the security document cassette generated according to the communication protocol and based on the key (MK); • Authenticate (403) to the security document cassette using the initial code (t (2) ), preferably by means of a second message generated according to the communication protocol to the security document cassette, wherein the second message contains the first code (t (2) ) exhibits.

2. Control device (102) according to claim 1, wherein one or more than one processor is further configured to generate the first message according to the communication protocol by means of a random number generator; and / or wherein the first message initiates a cryptographic challenge-response process.

3. Control device (102) according to one of claims 1 or 2, wherein the memory (102m) has at least one memory area which stores the first data, wherein the memory area is write-protected and / or cryptographically secured.

4. Control device (102) according to one of claims 1 to 3, wherein determining the first code (t (2) ) furthermore, based on one or more than one of the following: • an identification identifier (ID) of the security document cassette; • a session identifier (SC) originating from the security document cassette; • a second code originating from the security document cassette (t (1)), preferably based on the first message; • a communication key (CK) ID ), which is based on the key (MK) and / or the identification identifier (ID) of the security document cassette; optionally, one or more processors are further configured to use the communication key (CK). ID ) based on the key (MK) and / or the identification identifier (ID).

5. Control device (102) according to one of claims 1 to 4, wherein the first code (t (2) ) is a message authentication code.

6. Control device (102) according to any one of claims 1 to 5, wherein the processor is further configured to control the security document cassette by means of a third message according to the communication protocol, wherein the third message is based on the first code (t (2)), preferably by means of a session key based thereon; wherein optionally the third message contains an instruction to the security document cassette to dispense or receive a security document.

7. Security document cassette circuit (104), comprising: • a memory containing initial data which includes a key (CK) ID ) implement; • an interface (104a) for communicating with a security document cassette external control device (102) according to a communication protocol; • one or more than one processor (104p) configured to: • determine an initial code (t (1) ) based on the key (CK ID ) and based on a first message according to the communication protocol from the control device (102); • Authenticating a second code (t (2) ), which originates from the control device (102), based on the first code (t (1) ).

8. Security document cassette circuit (104) according to claim 7, wherein one or more than one processor is further configured to output the second code (t (2) ) based on a second message originating from the control device (102) according to the communication protocol, wherein the second message preferably contains the second code (t (2) ) exhibits.

9. Security document cassette circuit (104) according to claim 7 or 8, wherein one or more processors are further configured to generate a third message according to the communication protocol to the control device (102), wherein the third message comprises one or more of the following: • the first code (t (1) ); • an identification identifier of the security document cassette circuit (104) stored in memory; • a session identifier stored in memory.

10. Security document cassette circuit (104) according to one of claims 7 to 9, wherein the authentication of the second code (t (2) ) furthermore based on one or more than one of the following: • an identification identifier (ID) of the security document cassette circuit (104) stored in memory, • a session identifier (SC) stored in memory; and / or • the first message; • a message authentication code which is based on the first message, the session identifier (SC) and / or the key (CK) ID ) is based.

11. Security document cassette circuit (104) according to one of claims 7 to 10, wherein determining the first code (t (1)) furthermore based on one or more than one of the following: • an identification identifier (ID) of the security document cassette circuit (104) stored in memory, • a session identifier (SC) stored in memory; • a message authentication code which is on the first message, the session identifier (SC) and / or the key (CK) ID ) is based.

12. Security document cassette circuit (104) according to any one of claims 7 to 11, wherein the first message initiates a cryptographic challenge-response process; and / or wherein the first code (t (1) ) is a message authentication code and / or where the second code (t (2) ) is a message authentication code.

13. Security document cassette circuit (104) according to one of claims 7 to 12, wherein the processor is further configured when the authentication of the second code (t (2)) fails: • to increment a session identifier stored in memory, and / or • to abort communication with the control device.

14. Security document cassette circuit (104) according to any one of claims 7 to 13, wherein the processor is further configured to authorize an instruction, preferably for issuing or receiving a security document, from the control device (102) when: • authentication is successful; and / or • a fourth message according to the communication protocol, which contains the instruction, is authenticated based on the second code, preferably by means of a session key based thereon; wherein optionally the security document cassette circuit (104) further comprises: • an additional interface (104b) for controlling a transfer device (106t); • wherein the processor is further configured to output a control signal via the additional interface according to the instruction from the control device (102) when the instruction is authorized.

15. Security document cassette (106), comprising: • the security document cassette circuit (104) according to claim 14, • a container (106b); • the transfer device (106t) for transferring a security document into and / or out of the container (106b).

Citation Information

Patent Citations

  • Method and device for authenticating components within an ATM

    DE102009032355A1

  • Procedure for operating a cash box with customer-specific keys

    DE102011001430A1