Procedure relating to a transport container for packages

Abstract

Method for transporting an item by: - ​​bringing a transport container for parcels to a sender (V), wherein the transport container (1) for parcels (P) has a data processing device (10) and a memory (16) on which a certificate (Z1) for identifying the transport container (1) and a pair of a public and a private cryptographic key are stored, wherein the transport container has a communication interface (14a, 14b) for sending the certificate (Z1) together with the public cryptographic key to an external unit (2, 3) and for receiving messages from the external unit (2, 3) and an electrically operated locking device (12);- Performing a procedure for opening the transport container (1) for packages, comprising the steps: - Performing a Transport Layer Security (TLS) handshake between the transport container and the sender (2, 3, V) for mutual authentication; - If the authentication is successful, opening the transport container; - Placing the item (P) into the transport container (1); - Transporting the transport container (1) to a recipient (E); - Performing a procedure for opening the transport container (1) for packages, comprising the steps: - Performing a Transport Layer Security (TLS) handshake between the transport container and the recipient (2, 3, E) for mutual authentication; - If the authentication is successful, opening the transport container;- Removing the item (P) from the transport container (1), the transport container being subsequently connected to a backend server to change and / or supplement the certificate.;

Description

The invention relates to a method for transporting an object using a transport container for packages with a data processing device and a storage device. The transport container can also be described as an "intelligent" transport container for packages. Such transport containers are increasingly being used to ensure greater security for the goods being transported. US patent 2018 / 0061162A1 describes a transport container equipped with a computer system. Data, particularly regarding the status of the container's contents, can be transferred to and read from this system via a connector. US 2018 / 0205682A1 describes the use of wireless communication in connection with the delivery of a package. A comparable transport container is described in WO 2020 / 087 648 A1. US 2022 / 0141032A1 discloses that a device to be transported in a transport container must itself have a unique identifier. German patent DE 10 2021 214 641 A1 discloses the use of coding for a transport container. US patent 2021 / 0 059 455 A1 shows a technologically upgraded container and mentions the use of identification codes. From DE 10 2015 111 711 A1 and DE 10 2020 202 594 A1, authentication using cryptographic key pairs is generally known in the field of goods delivery. Anyone entrusting goods to a transport container wants the assurance that they are dealing with a reliable transport company and that the package will reach the recipient without any problems. The object of the invention is to show a way in which increased safety in the transport of goods can be ensured by (intelligent) transport containers for packages. The problem is solved by a method for transporting an object according to claim 1. The transport container for packages used in the invention thus comprises a data processing device and a memory on which a certificate for identifying the transport container as well as a pair of a public and a private cryptographic key is stored, and it comprises a communication interface for sending the certificate together with the public cryptographic key to an external unit (to the transport container) and for receiving messages from the external unit. By using a certificate, such as one based on the X.509 standard (also known as ISO / IEC 9594-8), it can be ensured that the shipping container is uniquely identifiable, allowing the sender to have greater confidence in the container and confidently place the package inside. In particular, a so-called TLS handshake can take place, where "TLS" stands for Transport Layer Security, and "handshake" refers to the exchange of data, specifically for authentication. The TLS handshake protocol is defined in the German Wikipedia article on "Transport Layer Security" (as it appeared online on July 25, 2023), among other things, as follows: TLS handshake with two-way authentication using certificates and RSA key exchange. The TLS Handshake Protocol builds upon the TLS Record Protocol and performs the following functions even before the first bits of the application data stream are exchanged: - Negotiation of the cryptographic algorithms and keys to be used. - TLS also supports unencrypted transmission. - Identification and authentication of the communication partners based on asymmetric encryption methods and public-key cryptography. This step is optionally two-way authentication (in which case it is sometimes referred to as mutual TLS), but usually only the server authenticates itself to the client. The handshake itself can be divided into four phases: i) The client sends a ClientHello to the server, and the server responds to the client with a ServerHello. The message parameters are: the version (the highest TLS protocol version supported by the client), a 32-byte random piece of information (4-byte timestamp + 28-byte random number) that is later used to generate the pre-master secret (thus protecting against replay attacks), a session ID, the cipher suite to be used (algorithms for key exchange, encryption, and authentication), and optionally, the desired FQDN for Server Name Indication support. In TLS version 1.3 (with Diffie-Hellman key exchange), the key shares that define the shared key are also transmitted here. ii) The server identifies itself to the client. For this purpose, an X is issued via a certificate.A 509v3 certificate is sent to the client, followed by a CertificateVerify (in some TLS versions). The CertificateVerify message contains a signature of previously exchanged messages. This proves that the server possesses a secret key that matches the public key contained in the server certificate. The client verifies the certificate and the signature. If the verification fails, the client terminates the connection. The server can also optionally request a certificate for client authentication via a CertificateRequest. This phase may only be omitted if an anonymous cipher suite without authentication is used. iii) The previously obtained server certificate contains the server's public key.If a cipher suite with RSA key exchange is used (see figure), the client-generated pre-master secret is encrypted with this public key and can be decrypted by the server using its private key, which is known only to the server. Alternatively, Diffie-Hellman key exchange can be used to generate a shared pre-master secret. If the Diffie-Hellman secrets are freshly and randomly negotiated by the server and client during the handshake, the requirements for Perfect Forward Secrecy are met. After the pre-master secret is transmitted, the client identifies itself to the server using a certificate, provided the server has sent a CertificateRequest. To do this, the client sends its client certificate, followed by a CertificateVerify message. The CertificateVerify message contains a signature of all previously exchanged messages.This proves to the server that the client possesses a secret key that matches the public key contained in the client certificate. From this point on, the server knows with whom it is communicating. iv) This phase completes the handshake. The master secret, which is a unique session key, can be derived from the existing pre-master secret. Keys are then derived from the master secret, which are used for encrypting and decrypting the data as well as for integrity checks. The messages that the communicating partners now send each other are transmitted only in encrypted form. If the server did not authenticate itself via CertificateVerify in step 2, the client only knows that it is communicating with the legitimate owner of the certificate after receiving the first encrypted message. The above statements from the article are applicable here to the authentication of the transport container as a server and the external unit as a client, the latter for example in the form of a communication device at the sender or recipient of the transport container. The invention has the advantage that communication at the sender and / or recipient can take place offline, i.e., without internet use. Furthermore, it also ensures better tracking of the transport container during and after transport. The inventive method for transporting an object comprises: - delivering a transport container for packages to a sender, wherein the transport container for packages has a data processing device and a memory on which a certificate for identifying the transport container and a pair of a public and a private cryptographic key are stored, wherein the transport container has a communication interface for sending the certificate together with the public cryptographic key to an external unit and for receiving messages from the external unit and an electrically actuated locking device; - performing a method for opening the transport container for packages comprising the steps of: - performing a Transport Layer Security handshake between the transport container and the sender for mutual authentication;- If authentication is successful, open the transport container; - Place the item in the transport container; - Transport the transport container to a recipient; - Perform a procedure to open the transport container for packages, including the following steps: - Conduct a Transport Layer Security (TLS) handshake between the transport container and the recipient for mutual authentication; - If authentication is successful, open the transport container; - Remove the item from the transport container, after which the transport container is connected to a backend server to modify and / or supplement the certificate. According to a preferred embodiment, the transport container used includes an electrically operated locking device. If authentication is successful, the data processing device should open the locking device; otherwise, it should not. Authentication can be useful both when loading a package and when removing a package from the transport container. According to a preferred embodiment of the invention, the communication interface comprises a first unit that enables wireless transmission in the immediate vicinity, where "immediate vicinity" refers in particular to an area around the transport container extending from (for example, 1 m) to at least 10 m, and preferably to at least 50 m, and particularly preferably to 100 m (these figures preferably refer to an area radius). The Bluetooth® standard can be used in this context. Furthermore, the communication interface can also include a second unit that enables wireless communication with a remote backend server, particularly via the internet, allowing the exchange of certificate information with the backend server. This allows the backend server to regularly update the transport container's certificate (e.g., daily) using this second unit of the communication interface. The backend server can also periodically update any software that may be present on the transport container. The sub-method for opening a transport container requires that the transport container has an electrically operated locking device. This sub-method comprises the following steps: - Performing a Transport Layer Security (TLS) handshake between the transport container and an external unit for mutual authentication; - If the authentication is successful, opening the transport container. The process is carried out reliably on both the sender's and recipient's sides. Reliable verification is achieved through the use of certificates. Accordingly, the inventive method for transporting an object comprises the following steps: - Bringing a transport container for packages, in particular one according to the invention, to a sender; - Performing the above-mentioned method for opening with the sender as an external unit; - Placing the object in the transport container; - Transporting the transport container to a recipient; - Performing the above-mentioned method for opening with the recipient as an external unit; - Removing the object from the transport container. The transport container can originally store a certificate originating from a central authentication authority, which is validated by the respective external entity during each Transport Layer Security handshake (series of certificates leading to a so-called root certificate). The transport container will be connected to a backend server periodically to change and / or update the certificate. Alternatively, software stored on the transport container can be updated. The system, which is not specifically claimed here, comprises at least one transport container for packages and a plurality of communication devices for transport participants, wherein the transport container has a communication interface by means of which it can wirelessly exchange certificates or information associated with certificates with a respective communication device for transport participants within a range of at least up to 10 m and preferably up to 100 m, and thus perform TLS handshakes. This system as a whole enables the reliable transport of packages using the transport container. As a further solution, the invention also includes a computer-readable storage medium comprising program code which, when executed by a computer or a computer network, causes it to execute an embodiment of the method according to the invention. The storage medium can be provided at least partially as a non-volatile data storage medium (e.g., as flash memory and / or as an SSD - solid state drive) and / or at least partially as a volatile data storage medium (e.g., as RAM - random access memory). The storage medium can be located within the computer or computer network. However, the storage medium can also be operated, for example, as an app store server and / or cloud server on the internet. The computer or computer network can provide a processor circuit with, for example, at least one microprocessor.The program code can be provided as binary code and / or as assembly code and / or as source code of a programming language (e.g. C) and / or as a program script (e.g. Python). The invention also includes combinations of the features of the described embodiments. The invention therefore also includes realizations that each exhibit a combination of the features of several of the described embodiments, provided that the embodiments have not been described as mutually exclusive. A preferred embodiment of the invention is described in more detail below with reference to the drawing, in which: Fig. 1 shows a schematic representation of the components of a transport container used according to the invention; and Fig. 2a-2h illustrates a sequence of situations corresponding to steps of the method according to the invention by schematic representation. The exemplary embodiments described below are preferred embodiments of the invention. In these exemplary embodiments, the described components each represent individual features of the invention, which can be considered independently of one another and each further develops the invention independently. Therefore, the disclosure is intended to include combinations of features of the embodiments other than those shown. Furthermore, the described embodiments can also be supplemented by further features of the invention already described. In the figures, identical reference symbols denote functionally equivalent elements. The system is based on the principle of a Public Key Infrastructure (PKI): Every participant in the system, including the transport container, possesses a private / public key pair (cryptographic key pair). A trusted Certificate Authority (CA, central authentication authority) issues a certificate corresponding to this key pair. This certificate contains the participant's public key and is signed by the CA, thus making the certificate trustworthy. Each participant should store their certificate locally (it is also stored at the CA and can be verified for validity using other protocols; however, this must be done online). During a TLS handshake, the participants exchange their certificates, validate them, and also check, as described above, whether the other party possesses the matching private key. A (smart) transport container for packages, shown in Fig. 1 and designated therein by 1, comprises a central data processing unit 10. This unit is capable of controlling an electrically operated locking device 12, enabling the transport container to be opened and closed automatically. A first communication interface unit 14a allows the transport container to communicate within its surroundings (approximately: up to a radius of 100 m, always referring to radii), which can be achieved, for example, using a Bluetooth® device. A second communication interface unit 14b enables communication via satellite to provide internet access. Communication with a backend server is possible here. The interfaces are separate from each other. The use of interface 14b, i.e., communication with a backend server, is not mandatory during the process. Data is stored in memory location 16 of transport container 1. This includes, for example, the transport container 1's own certificate Z1, which can be used to identify it. This could be an X.509-v3 certificate. The private cryptographic key prK1 and the public cryptographic key puK1 are also stored there. In the method according to the invention, the transport container 1, as shown in Fig. 2a, is first transported to the sender V, who has a communication device, such as a smartphone 2, tablet computer, laptop, personal computer, or similar device. A TLS handshake is then performed while establishing the communication connection. This includes, among other things, the transport container 1 sending its own certificate Z1 with its public key via the first unit 14a of its communication interface and receiving the certificate Z2 with the public key from the sender V's communication device 2. The transport container verifies whether the sender V / its communication device 2 has authenticated correctly. Only then is the transport container 1 opened, as shown in Fig. 2b. In the subsequent step, as shown in Fig. 2c, a package P is placed inside the transport container 1. The transport container 1 is then transported, as shown in Fig.Figure 2d illustrates this. Optionally, additional authentication can take place between the means of transport and the transport container 1. For example, similar to the situation with shipper V, the driver of a truck can perform a TLS handshake to prevent, for instance, a lock being activated in the transport container, or similar issues. The transport container 1 arrives at recipient E, resulting in the situation shown in Fig. 2e. Recipient E has a communication device 3, such as a smartphone, tablet computer, or similar device. A TLS handshake is performed, and if the authentication is successful, the transport container 1 is opened again in the next step, as shown in Fig. 2f. In step 2g, the package P can then be removed, as shown in Fig. 2g. Fig. 2h illustrates optional further steps: The transport container 1 can be connected to a charging station L to recharge a battery (not shown in the figures) and enable the long-term operation of the transport container 1. Alternatively or additionally, a backend server 4 can communicate with the transport container 1 via the internet I and the second unit 14b of the communication interface. For example, after transport, the transport container 1 can provide information about the transport (identity of the sender V, identity of the recipient E, transport route, optionally tracked by a tracking system not shown in Fig. 1, and much more). Conversely, the backend server 4 can also upload data, such as updating the certificate Z1 after a single use or at regular intervals (e.g., daily).Overall, the examples show how mutual offline authentication of senders and receivers as well as packets can be provided in a smart packet.

Claims

Method for transporting an item by: - ​​bringing a transport container for parcels to a sender (V), wherein the transport container (1) for parcels (P) has a data processing device (10) and a memory (16) on which a certificate (Z1) for identifying the transport container (1) and a pair of a public and a private cryptographic key are stored, wherein the transport container has a communication interface (14a, 14b) for sending the certificate (Z1) together with the public cryptographic key to an external unit (2, 3) and for receiving messages from the external unit (2, 3) and an electrically operated locking device (12);- Performing a procedure for opening the transport container (1) for packages, comprising the steps: - Performing a Transport Layer Security (TLS) handshake between the transport container and the sender (2, 3, V) for mutual authentication; - If the authentication is successful, opening the transport container; - Placing the item (P) into the transport container (1); - Transporting the transport container (1) to a recipient (E); - Performing a procedure for opening the transport container (1) for packages, comprising the steps: - Performing a Transport Layer Security (TLS) handshake between the transport container and the recipient (2, 3, E) for mutual authentication; - If the authentication is successful, opening the transport container;- Removing the item (P) from the transport container (1), the transport container being subsequently connected to a backend server to change and / or supplement the certificate.; Method according to claim 1, wherein the transport container initially stores a certificate originating from a central authentication authority, which is validated by the respective external unit at each Transport Layer Security handshake. Method according to claim 1 or 2, wherein the transport container is finally connected to the backend server, also to update software stored on the transport container. Method according to one of claims 1 to 3, wherein a transport container is used in which the data processing device (10) is designed to check a result of a data exchange according to a predetermined criterion and to open the closing device (12) depending on the result of the check. Method according to one of claims 1 to 4, wherein a transport container is used, wherein the communication interface comprises a first unit (14a) which enables wireless transmission in the immediate vicinity. Method according to one of claims 1 to 5, wherein a transport container is used, wherein the communication interface has a second unit (14b) which enables wireless communication to the remote backend server (4), preferably via the Internet (I).

Images