US20200389322A1 - Security for group communication - Google Patents
Security for group communication Download PDFInfo
- Publication number
- US20200389322A1 US20200389322A1 US16/767,685 US201816767685A US2020389322A1 US 20200389322 A1 US20200389322 A1 US 20200389322A1 US 201816767685 A US201816767685 A US 201816767685A US 2020389322 A1 US2020389322 A1 US 2020389322A1
- Authority
- US
- United States
- Prior art keywords
- related information
- signature
- signature verification
- verification related
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 82
- 238000012795 verification Methods 0.000 claims abstract description 140
- 238000000034 method Methods 0.000 claims abstract description 70
- 238000004590 computer program Methods 0.000 claims abstract description 47
- 238000011084 recovery Methods 0.000 claims description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 4
- 230000002085 persistent effect Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000011664 signaling Effects 0.000 description 4
- 239000007787 solid Substances 0.000 description 4
- 239000012634 fragment Substances 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
Definitions
- the invention relates to methods for enabling security for group communication in a communication network, sending nodes, listening nodes, computer programs and a computer program product thereof.
- TIS transport layer security
- RFC5246 request for comments
- HTTPS hypertext transfer protocol secure
- TIS transmission control protocol
- IP internet protocol
- the datagram TI (DTIS) protocol is very similar to TIS, but can also run over unreliable transport such as user datagram protocol (UDP) instead of reliable TCP.
- DTIS is used in Internet-of-Things (IoT) deployments, since networks with high packet data loss or high latency have better performance with UDP.
- the protocol comprises a key exchange protocol, known as the handshake, and a record layer protocol which protects the traffic.
- the handshake authenticates a TIS server and optionally the TIS client based on some pre-existing secret information such as a pre-shared symmetric keys or a private signature key corresponding to a public signature key.
- some pre-existing secret information such as a pre-shared symmetric keys or a private signature key corresponding to a public signature key.
- the handshake protocol if successful, results in symmetric session keys being established between TIS client and TLS server which are used in the record layer protocol to encrypt and integrity protect the traffic.
- multicast communication provides a more efficient mode of communication than point-to-point communication between a single TIS client and a TIS server.
- Reasons for using multicast may include:
- Multicast is also used in many IoT scenarios, e.g. building automation where multiple sensors or actuators need to be contacted at the same time, in particular in lighting systems where deployments often have strict requirements e.g. for delays in turning on lights.
- One preferred mechanism for secure multicast is described in Group Communication for the Constrained Application Protocol (CoAP), IETF RFC7390.
- CoAP is a lightweight HTIP-like protocol suitable for IoT for which security is provided by DTIS, see IETF RFC7252.
- a transport layer security (TIS) protocol may be augmented with signature verification related information enabling the authentication of the sender in a setting where there may be multiple candidate senders.
- TIS transport layer security
- a method for enabling secure group communication in a communication network comprising providing signature verification related information to a plurality of listening nodes, and sending a group message to the plurality of listening nodes, the group message comprising signature verification related information of the sending node.
- At least part of the signature verification related information may be provided by a key exchange procedure.
- At least part of the signature verification related information may be provided by a key distribution procedure.
- At least part of the signature verification related information may be provided by a record layer procedure.
- the signature verification related information may be one or more of the following: a digital signature, a signature with message recovery, compressed or partial signature information, and an indication of where or how to retrieve a signature, a public signature key, an indication of where or how to retrieve a public signature key.
- the signature verification related information may be comprised in a message field intended for other use.
- the signature verification related information may be comprised in a message field dedicated for signature verification related information.
- the group message, one or more fields of the group message, or the whole group message may be encoded with a private signature key related to the signature verification related information.
- the providing step may comprise one or more of the following: providing parts of the signature verification related information by handshake protocols with one or more listening nodes or by record layer protocols with one or more listening nodes.
- the parts of the signature verification related information may be parts of a public signature key.
- the group message may be a record layer transport layer security, TIS, multicast message.
- TIS record layer transport layer security
- the TIS multicast message may be sent in the record layer for version 1.2.
- the group message may be sent without message authentication code, MAC.
- a method for enabling secure group communication in a communication network is performed in a listening node and comprising obtaining signature verification related information from a sending node, and receiving a group message from the sending node comprising signature verification related information of the sending node.
- At least part of the signature verification related information may be obtained by a key exchange procedure.
- At least part of the signature verification related information may be obtained by a key distribution procedure.
- At least part of the signature verification related information may be obtained by a record layer procedure.
- the signature verification related information may be one or more of the following: a digital signature, a signature with message recovery, compressed or partial signature information, and an indication of where or how to retrieve a signature, a public signature key, an indication of where or how to retrieve a public signature key.
- the signature verification related information may be comprised in a message field intended for other use.
- the signature verification related information may be comprised in a message field dedicated for signature verification related information.
- the group message, one or more fields of the group message, or the whole group message may be encoded with a private signature key related to the signature verification related information, and the sending node is verified by a public signature key related to the signature verification related information.
- the obtaining step may comprise one or more of the following: obtaining a public signature key by a handshake protocol with the sending node or by a record layer protocol with the sending node.
- the group message may be a record layer transport layer security, TIS, multicast message.
- TIS record layer transport layer security
- the TIS multicast message may be received in the record layer for version 1.2.
- the group message may be sent without message authentication code, MAC.
- the sending node for enabling secure group communication in a communication network.
- the sending node comprises a processor and a computer program product.
- the computer program product stores instructions that, when executed by the processor, causes the sending node to provide signature verification related information to a plurality of listening nodes, and to send a group message to the plurality of listening nodes, the group message comprising signature verification related information of the sending node.
- a listening node for enabling secure group communication in a communication network.
- the listening node comprises a processor and a computer program product.
- the computer program product stores instructions that, when executed by the processor, causes the listening node to obtain signature verification related information from a sending node, and to receive a group message from the sending node comprising signature verification related information of the sending node.
- the sending node comprises a communication manager for providing signature verification related information to a plurality of listening nodes, and for sending a group message to the plurality of listening nodes (, the group message comprising signature verification related information of the sending node.
- a listening node for enabling secure group communication in a communication network.
- the listening node comprises a communication manager for obtaining signature verification related information from a sending node, and for receiving a group message from the sending node comprising signature verification related information of the sending node.
- a seventh aspect there is presented a computer program for enabling secure group communication in a communication network.
- the computer program comprises computer program code which, when run on a sending node, causes the sending node to provide signature verification related information to a plurality of listening nodes, and to send a group message to the plurality of listening nodes, the group message comprising signature verification related information of the sending node.
- the computer program comprises computer program code which, when run on a listening node, causes the listening node to obtain signature verification related information from a sending node, and to receive a group message from the sending node comprising signature verification related information of the sending node.
- a computer program product comprising a computer program and a computer readable storage means on which the computer program is stored is also presented.
- FIG. 1 schematically illustrates group communication
- FIG. 2 schematically illustrates alternatives for TISCiphertext messages
- FIG. 3 schematically illustrates sender processing
- FIG. 4 schematically illustrates listener processing
- FIG. 5 schematically illustrates multicast, integrated handshake
- FIGS. 6-7 are flow charts illustrating methods according to embodiments presented herein;
- FIGS. 8-9 are schematic diagrams illustrating some components of entities presented herein.
- FIGS. 10-11 are schematic diagrams showing functional modules of embodiments presented herein.
- the parties involved in the communication needs to trust that no node is impersonating another node in the multicast group.
- the verification of a message requires access to the same key as was used to generate the protected message, so in order to verify messages each node in the group needs to have access to each others key used for generating the protected message.
- the existing multicast solutions based on Record Layer require nodes to share the same key material and does not allow the node to authenticate the source of the message.
- This invention relates to securing group communications, in particular multicast, with the Transport Layer Security (TIS) protocol.
- TIS Transport Layer Security
- the quick UDP Internet connection (QUIC) protocol reuses the TIS handshake but defines its communication security protocol replacing the record layer, and analogous changes can be made to that protocol.
- One component of the solution is to augment the Record Layer protocol message with additional information allowing the receiver to acquire a digital signature covering a part or all of the Record Layer message and potentially additional data not sent with the record layer that needs to be authenticated.
- the additional data could e.g. be the sequence number of one of the protected records or other data that needs to be authenticated and that can be assumed to be or become known by the receiving party.
- a digital signature may be included in the message.
- the information in the message may provide location or other information about how to acquire a published signature of the message.
- Another component of the solution is to enable the listener to acquire the public signature key of a sender.
- information about the public signature key may be transferred with the Handshake protocol.
- information about the public signature key may be transferred in the Record Layer.
- Information about the public signature key may be the public signature key itself or information how to verify and/or acquire the public signature key.
- Such signature verification related information may be acquired in parts at different times using multiple instances of handshake or record layer protocols. Parts of this information may be acquired by other means, e.g. using a key distribution protocol.
- the listener With access to the protected TLS message, its digital signature and the sender public signature key, the listener can verify that the signature of the message was made by the sender and thus infer the source of the message.
- the solution provides source authentication in multicast setting using specific TIS components.
- the solution is a minor extension based on the widely deployed TIS and thereby augments TIS to also support secure multicast.
- FIG. 1 A setting where a number of nodes may be involved in group communication is illustrated in FIG. 1 .
- Each message may have different senders and potentially more than one node is a candidate listener.
- the nodes implement TIS record layer and optionally the TIS Handshake.
- the group communication can be any one-to-many communication, such as broadcast, multicast, geocast, or a combination of several unicast/anycast.
- the lower layers do not need to be the same over the whole path.
- the group communication can e.g. be IP multicast as in [DTIS-based Multicast Security in Constrained Environments], but other mechanisms such as a broadcast channel of some radio technology or several unicast channels are also contemplated.
- TLSCiphertext (Section 6.2 of [The Transport Layer Security (TIS) Protocol Version 1.2]) consists of Type, Version, Length and Fragment, which is illustrated in FIG. 2 .
- signature verification related information may be included in an existing message field such as e.g. “Fragment” of the TLSCiphertext, see alternative A in FIG. 2 .
- signature verification related information may be included as an additional message field, here called Sig-Info, see alternative B in FIG. 2 .
- the signature verification related information may be included as a separate record field, e.g. a new record type, here called Sig-Info, see alternative C in FIG. 2 .
- Signature verification related information may alternatively be carried outside the record layer, e.g. in the payload, body, header or extension of a hypermedia such as HTTP or CoAP.
- MAC Message Authentication Code
- Signature verification related information may be included in a TLS multicast message, as presented herein.
- Signature verification related information may e.g. be one or multiple digital signatures, signatures with message recovery, compressed or partial or compressed signature information.
- Signature verification related information may also be information about where to retrieve a signature such as a reference (address, location).
- the signature may cover all the other fields in the message, or only selected parts of the message, e.g. the “Fragment”, or additional information not carried in the message e.g. for overhead reasons, including session identifier, or sequence number.
- the TLS Record Layer protocol may carry the public signature key(s) or partial or compressed information about the public signature key(s), such as the hash of public signature key, and/or a reference to where the key can be retrieved.
- the public signature key is acquired as part of the TLS handshake.
- the TIS handshake may include a certificate containing a public signature key being sent to the listener.
- the listener may take the role of TLS client and run the handshake with the sender as TLS server to obtain its certificate.
- a public signature key or public signature key certificate to be used with message signature verification may be sent as part of the Handshake.
- Other options are described in locating signatures and public signature keys hereafter.
- the certificate may be a raw public signature key as in [Using Raw Public signature keys in Transport Layer Security (TIS) and Datagram Transport Layer Security (DTLS)]. Two alternative sequences for acquiring the public signature key are illustrated in FIG. 5 .
- the public signature key may also be acquired through a key distribution scheme, e.g. based on Authentication and Authorization for Constrained Environments (ACE), IETF Internet Draft draft-ietf-ace-oauth-authz-16.
- ACE Authentication and Authorization for Constrained Environments
- DSA Digital Signature Algorithm
- ECDSA Elliptic Curve DSA
- the application message may contain part of a record layer or several TLS records.
- the application message often contains an integral number of records.
- message may refer to one record, multiple records, a part of a record, or multiple records plus a part of record.
- the signature may cover a number of TLS/DTIS records included in one message.
- the signature verification related information based on the message may be included based on different criteria, for example signature verification related information may included in e.g. every third record (covering a number of records), every 500 bytes etc., every 30 seconds etc. using one of the different alternative message formats for including the signature verification related information described above.
- the information about where to find a signature or a public signature key relevant to verify a TLS multicast message may be carried in either handshake or record layer. In either case, this information may be
- a location e.g. Uniform Resource Identifier (URI)
- URI Uniform Resource Identifier
- the same public signature key is to be used as that which was used to authenticate the sender in the Handshake. This may also be agreed between the listening node and the sending node out of band or defined in a specification.
- the URI may be parametrised such that essentially the same URIs are used modulo some parameter variation, e.g. in part of the URI, such as the query part.
- the URI may e.g. contain the identifier for the session and/or Record Layer sequence number.
- a session identifier and/or sequence number may be carried in other locations in a message, e.g. in the payload/body or header/extension of a hypertext transport protocol (HTP)/Constrained Application Protocol (CoAP) message.
- HTTP hypertext transport protocol
- CoAP Constrained Application Protocol
- IP multicast In the following the use of IP multicast is assumed as an example.
- the sender decides on IP multicast group and generates a message.
- the message is encoded with TIS, for example as described in [DTIS-based Multicast Security in Constrained Environments].
- the sender calculates a signature over a specified part of the message.
- the signature verification related information is included in the message.
- the sender makes the signature available in some other way, for example, publishes the signature to a signature repository, and references the signature in the signature verification related information provided in the message.
- the sender may optionally also need to make its public signature key available to listeners that do not (yet) have access to the public signature key.
- the step may alternatively be performed after the sender sends the TLS multicast message.
- the sender sends the TLS multicast message with signature verification related information.
- the listener receives the TIS multicast message containing signature verification related information, as illustrated in FIG. 4 .
- the listener extracts signature verification related information. Based on the signature verification related information, the listener acquires the digital signature. The listener also acquires the public signature key. Different options are possible.
- the message may contain the digital signature and the public signature key of the sender may be known to the listener, in which case the listener can proceed directly to verification of the signature. Alternatively, the digital signature and/or the public signature key needs to be retrieved first.
- the signature may for example be retrieved from a signature repository, as described previously in this section.
- the public signature key may for example be retrieved by running the TIS Handshake with the sender as described above.
- the listener can verify the signature.
- the listener may respond to a TIS message with signature verification related information with another TIS message with signature verification related information.
- the listener would generate the signature and the original sender would verify the signature of the message sent back with a unicast TIS message augmented with a signature.
- the secure group communication presented herein may for example be used in building automation settings where a number of devices need to be activated, such as a lighting system with multiple luminaries and multiple light switches.
- a number of devices need to be activated, such as a lighting system with multiple luminaries and multiple light switches.
- Another example is alarm-induced actuations, where multiple alarm bells should be triggered, or fire doors closed.
- the secure group communication presented herein may be applied independent of how the messages are distributed between sender and listener.
- One example is the use of multicast IP, where the sender uses a multicast IP address and IP routing functionality makes the message available to any listener within that address range.
- Another example is to use a radio resource available for multiple listeners such as a broadcast channel of a radio access technology in which case the message can be made available to all devices listening to that resource channel.
- a third example is the use a middle box which fans out a message from a sender to multiple listeners using unicast between the middle box and the listener.
- a method, according to an embodiment, for enabling secure group communication in a communication network is presented with reference to FIG. 7 .
- the method is performed in a sending node 2 and comprises providing S 200 signature verification related information to a plurality of listening nodes 1 and sending S 210 a group message to the plurality of listening nodes 1 , the group message comprising signature verification related information of the sending node.
- At least part of the signature verification related information may be provided by a key exchange procedure.
- At least part of the signature verification related information may be provided by a key distribution procedure.
- At least part of the signature verification related information may be provided by a record layer procedure.
- the signature verification related information may be one or more of the following: a digital signature, a signature with message recovery, compressed or partial signature information, and an indication of where or how to retrieve a signature, a public signature key, an indication of where or how to retrieve a public signature key.
- the signature verification related information may be comprised in a message field intended for other use.
- the signature verification related information may be comprised in a message field dedicated for signature verification related information.
- the group message, one or more fields of the group message, or the whole group message may be encoded with a private signature key related to the signature verification related information.
- the providing step may comprise one or more of the following: providing a public signature key by a handshake protocol with one or more listening nodes or by a record layer protocol with one or more listening nodes.
- the group message may be a transport record layer, TLS, multicast message.
- the TLS multicast message may be sent in the record layer for version 1.2.
- the group message may be sent without message authentication code, MAC.
- a method, according to an embodiment, for enabling secure group communication in a communication network is presented with reference to FIG. 6 .
- the method is performed in a listening node 1 and comprises obtaining S 100 signature verification related information from a sending node 2 , and receiving S 110 a group message from the sending node comprising signature verification related information of the sending node.
- At least part of the signature verification related information may be provided by a key exchange procedure.
- At least part of the signature verification related information may be provided by a key distribution procedure.
- a part of the signature verification related information may be provided by other means, e.g. a key distribution procedure.
- the parts of the signature verification related information may be provided at different times, in particular in a different handshake procedure or a different record layer procedure.
- Part of the signature verification related information may be provided by other means, e.g. a key distribution procedure.
- the parts of the signature verification related information may be provided at different times, in particular in different handshake or record layer procedures.
- At least part of the signature verification related information may be obtained by a record layer procedure.
- the signature verification related information may be one or more of the following: a digital signature, a signature with message recovery, compressed or partial signature information, and an indication of where or how to retrieve a signature, a public signature key, an indication of where or how to retrieve a public signature key.
- the signature verification related information may be comprised in a message field intended for other use.
- the signature verification related information may be comprised in a message field dedicated for signature verification related information.
- the group message, one or more fields of the group message, or the whole group message may be encoded with a private signature key related to the signature verification related information, and the sending node is verified by a public signature key related to the signature verification related information.
- the obtaining step may comprise one or more of the following: obtaining a public signature key by a handshake protocol with the sending node or by a record layer protocol with the sending node.
- the group message may be a transport record layer, TLS, multicast message.
- the TLS multicast message may be received in the record layer for version 1.2.
- the group message may be sent without message authentication code, MAC.
- a sending node for enabling secure group communication in a communication network is presented with reference to FIG. 9 .
- the sending node 2 comprises a processor 20 and a computer program product 22 , 23 .
- the computer program product stores instructions that, when executed by the processor, causes the sending node to provide S 200 signature verification related information to a plurality of listening nodes 1 , and to send S 210 a group message to the plurality of listening nodes 1 , the group message comprising signature verification related information of the sending node.
- At least part of the signature verification related information may be provided by a key exchange procedure.
- At least part of the signature verification related information may be provided by a key distribution procedure.
- At least part of the signature verification related information may be provided by a record layer procedure.
- the signature verification related information may be one or more of the following: a digital signature, a signature with message recovery, compressed or partial signature information, and an indication of where or how to retrieve a signature, a public signature key, an indication of where or how to retrieve a public signature key.
- the signature verification related information may be comprised in a message field intended for other use.
- the signature verification related information may be comprised in a message field dedicated for signature verification related information.
- the group message, one or more fields of the group message, or the whole group message may be encoded with a private signature key related to the signature verification related information.
- the providing step may comprise one or more of the following: providing a public signature key by a handshake protocol with one or more listening nodes or by a record layer protocol with one or more listening nodes.
- the group message may be a transport record layer, TLS, multicast message.
- the TLS multicast message may be sent in the record layer for version 1.2.
- the group message may be sent without message authentication code, MAC.
- the listening node 1 comprises a processor 10 and a computer program product 12 , 13 .
- the computer program product stores instructions that, when executed by the processor, causes the listening node to obtain S 100 signature verification related information from a sending node 2 , and to receive S 110 a group message from the sending node comprising signature verification related information of the sending node.
- At least part of the signature verification related information may be obtained by a key exchange procedure.
- At least part of the signature verification related information may be obtained by a key distribution procedure.
- At least part of the signature verification related information may be obtained by a record layer procedure.
- the signature verification related information may be one or more of the following: a digital signature, a signature with message recovery, compressed or partial signature information, and an indication of where or how to retrieve a signature, a public signature key, an indication of where or how to retrieve a public signature key.
- the signature verification related information may be comprised in a message field intended for other use.
- the signature verification related information may be comprised in a message field dedicated for signature verification related information.
- the group message, one or more fields of the group message, or the whole group message may be encoded with a private signature key related to the signature verification related information, and the sending node is verified by a public signature key related to the signature verification related information.
- the obtain step may comprise one or more of the following: obtaining a public signature key by a handshake protocol with the sending node or by a record layer protocol with the sending node.
- the group message may be a transport record layer, TIS, multicast message.
- TIS transport record layer
- the TIS multicast message may be received in the record layer for version 1.2.
- the group message may be sent without message authentication code, MAC.
- a sending node for enabling secure group communication in a communication network is presented with reference to FIG. 11 .
- the sending node 2 comprises a communication manager 91 for providing S 200 signature verification related information to a plurality of listening nodes 1 , and for sending S 210 a group message to the plurality of listening nodes 1 , the group message comprising signature verification related information of the sending node.
- the listening node 1 comprises a communication manager 81 for obtaining S 100 signature verification related information from a sending node 2 , and for receiving S 110 a group message from the sending node comprising signature verification related information of the sending node.
- a computer program 24 , 25 for enabling secure group communication in a communication network is presented.
- the computer program comprises computer program code which, when run on a sending node 2 , causes the sending node to provide S 200 signature verification related information to a plurality of listening nodes 1 , and to send S 210 a group message to the plurality of listening nodes 1 , the group message comprising signature verification related information of the sending node.
- a computer program 14 , 15 for enabling secure group communication in a communication network is presented.
- the computer program comprises computer program code which, when run on a listening node 1 , causes the listening node to obtain S 100 signature verification related information from a sending node 2 , and to receive S 110 a group message from the sending node comprising signature verification related information of the sending node.
- a computer program product 12 , 13 and 22 , 23 comprises a computer program 14 , 15 and 24 , 25 , and a computer readable storage means on which the computer program is stored.
- FIG. 8 is a schematic diagram showing some components of the listening node 1 .
- the processor 10 may be provided using any combination of one or more of a suitable central processing unit, CPU, multiprocessor, microcontroller, digital signal processor, DSP, application specific integrated circuit etc., capable of executing software instructions of a computer program 14 stored in a memory.
- the memory can thus be considered to be or form part of the computer program product 12 .
- the processor 10 may be configured to execute methods described herein with reference to FIG. 6 .
- the memory may be any combination of read and write memory, RAM, and read only memory, ROM.
- the memory may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
- a second computer program product 13 in the form of a data memory may also be provided, e.g. for reading and/or storing data during execution of software instructions in the processor 10 .
- the data memory can be any combination of read and write memory, RAM, and read only memory, ROM, and may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
- the data memory may e.g. hold other software instructions 15 , to improve functionality for the listening node 1 .
- the listening node 1 may further comprise an input/output (I/O) interface 11 including e.g. a user interface.
- the listening node 1 may further comprise a receiver configured to receive signalling from other nodes, and a transmitter configured to transmit signalling to other nodes (not illustrated).
- Other components of the listening node 1 are omitted in order not to obscure the concepts presented herein.
- FIG. 10 is a schematic diagram showing functional blocks of the listening node 1 .
- the modules may be implemented as only software instructions such as a computer program executing in the cache server or only hardware, such as application specific integrated circuits, field programmable gate arrays, discrete logical components, transceivers, etc. or as a combination thereof. In an alternative embodiment, some of the functional blocks may be implemented by software and other by hardware.
- the modules correspond to the steps in the methods illustrated in FIG. 6 , comprising a determination manager unit 80 and a communication manager unit 81 .
- modules are implemented by a computer program, it shall be understood that these modules do not necessarily correspond to process modules, but can be written as instructions according to a programming language in which they would be implemented, since some programming languages do not typically contain process modules.
- the communication manger 81 is for enabling secure group communication in a communication network.
- This module corresponds to the obtaining step S 100 and the receiving step S 11 of FIG. 6 .
- This module can e.g. be implemented by the processor 10 of FIG. 8 , when running the computer program.
- the determination manger 60 is for enabling secure group communication in a communication network.
- This module corresponds to decision related steps taken by the listening node 1 .
- This module can e.g. be implemented by the processor 10 of FIG. 18 , when running the computer program.
- This module can e.g. be implemented by the processor 10 of FIG. 8 , when running the computer program.
- FIG. 9 is a schematic diagram showing some components of the sending node 2 .
- the processor 20 may be provided using any combination of one or more of a suitable central processing unit, CPU, multiprocessor, microcontroller, digital signal processor, DSP, application specific integrated circuit etc., capable of executing software instructions of a computer program 24 stored in a memory.
- the memory can thus be considered to be or form part of the computer program product 22 .
- the processor 20 may be configured to execute methods described herein with reference to FIG. 7 .
- the memory may be any combination of read and write memory, RAM, and read only memory, ROM.
- the memory may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
- a second computer program product 23 in the form of a data memory may also be provided, e.g. for reading and/or storing data during execution of software instructions in the processor 20 .
- the data memory can be any combination of read and write memory, RAM, and read only memory, ROM, and may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.
- the data memory may e.g. hold other software instructions 25 , to improve functionality for the sending node 2 .
- the sending node 2 may further comprise an input/output (I/O) interface 21 including e.g. a user interface.
- the sending node 2 may further comprise a receiver configured to receive signalling from other nodes, and a transmitter configured to transmit signalling to other nodes (not illustrated).
- Other components of the sending node 2 are omitted in order not to obscure the concepts presented herein.
- FIG. 11 is a schematic diagram showing functional blocks of the sending node 2 .
- the modules may be implemented as only software instructions such as a computer program executing in the cache server or only hardware, such as application specific integrated circuits, field programmable gate arrays, discrete logical components, transceivers, etc. or as a combination thereof. In an alternative embodiment, some of the functional blocks may be implemented by software and other by hardware.
- the modules correspond to the steps in the methods illustrated in FIG. 7 , comprising a determination manager unit go and a communication manager unit 91 . In the embodiments where one or more of the modules are implemented by a computer program, it shall be understood that these modules do not necessarily correspond to process modules but can be written as instructions according to a programming language in which they would be implemented, since some programming languages do not typically contain process modules.
- the communication manger 91 is for enabling secure group communication in a communication network.
- This module corresponds to the provide step S 200 and the send step S 210 of FIG. 7 .
- This module can e.g. be implemented by the processor 20 of FIG. 9 , when running the computer program.
- the determination manger 90 is for enabling secure group communication in a communication network. This module corresponds to decision related steps performed in the sending node 2 . This module can e.g. be implemented by the processor 20 of FIG. 9 , when running the computer program.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/767,685 US20200389322A1 (en) | 2017-12-07 | 2018-11-30 | Security for group communication |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762595638P | 2017-12-07 | 2017-12-07 | |
PCT/EP2018/083144 WO2019110445A1 (fr) | 2017-12-07 | 2018-11-30 | Sécurité pour communication de groupe |
US16/767,685 US20200389322A1 (en) | 2017-12-07 | 2018-11-30 | Security for group communication |
Publications (1)
Publication Number | Publication Date |
---|---|
US20200389322A1 true US20200389322A1 (en) | 2020-12-10 |
Family
ID=64564884
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/767,685 Pending US20200389322A1 (en) | 2017-12-07 | 2018-11-30 | Security for group communication |
Country Status (3)
Country | Link |
---|---|
US (1) | US20200389322A1 (fr) |
EP (1) | EP3721598A1 (fr) |
WO (1) | WO2019110445A1 (fr) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210176070A1 (en) * | 2019-12-10 | 2021-06-10 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators using virtual channels with switch |
US11210136B2 (en) | 2019-12-10 | 2021-12-28 | Baidu Usa Llc | Systems and methods for an operating system module for a data processing accelerator |
US11343083B2 (en) | 2019-11-22 | 2022-05-24 | Baidu Usa Llc | Method for key sharing between accelerators in virtual channel |
US11405336B2 (en) | 2019-11-22 | 2022-08-02 | Baidu Usa Llc | Method for key sharing between accelerators in virtual channel with switch |
US11411934B2 (en) | 2019-12-10 | 2022-08-09 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators with switch |
US11457354B2 (en) * | 2019-12-10 | 2022-09-27 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators |
US11516010B2 (en) | 2019-12-10 | 2022-11-29 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators using virtual channels |
US11552790B2 (en) | 2019-11-22 | 2023-01-10 | Baidu Usa Llc | Method for key sharing between accelerators |
US11558357B2 (en) | 2019-11-22 | 2023-01-17 | Baidu Usa Llc | Method for key sharing between accelerators with switch |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0898216A2 (fr) * | 1997-08-22 | 1999-02-24 | Compaq Computer Corporation | Procédé de communication sécurisée de télécommandes dans un réseau d'ordinateurs |
US6697946B1 (en) * | 1997-01-28 | 2004-02-24 | Matsushita Electric Industrial Co., Ltd. | Message recovery signature apparatus |
US20040092310A1 (en) * | 2002-11-07 | 2004-05-13 | Igt | Identifying message senders |
US20060168446A1 (en) * | 2002-09-13 | 2006-07-27 | Pasi Ahonen | Secure broadcast/multicast service |
US20080095360A1 (en) * | 2006-10-19 | 2008-04-24 | Camille Vuillaume | Signature System and Signature Method |
JP2009246657A (ja) * | 2008-03-31 | 2009-10-22 | Nippon Telegr & Teleph Corp <Ntt> | メッセージ復元システムおよび方法 |
US20110185180A1 (en) * | 2008-09-17 | 2011-07-28 | Peter Gullberg | Method and device for creating digital signature |
US20120096274A1 (en) * | 2010-10-15 | 2012-04-19 | Certicom Corp. | Authenticated encryption for digital signatures with message recovery |
US8646041B2 (en) * | 2007-05-25 | 2014-02-04 | Institut Telecom / Telecom Paristech | Method for securing information exchange, and corresponding device and computer software product |
US20170366358A1 (en) * | 2016-06-16 | 2017-12-21 | International Business Machines Corporation | Authentication Via Group Signatures |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013138184A1 (fr) * | 2012-03-15 | 2013-09-19 | Research In Motion Limited | Procédé permettant de sécuriser des messages |
-
2018
- 2018-11-30 US US16/767,685 patent/US20200389322A1/en active Pending
- 2018-11-30 EP EP18811810.3A patent/EP3721598A1/fr not_active Withdrawn
- 2018-11-30 WO PCT/EP2018/083144 patent/WO2019110445A1/fr unknown
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6697946B1 (en) * | 1997-01-28 | 2004-02-24 | Matsushita Electric Industrial Co., Ltd. | Message recovery signature apparatus |
EP0898216A2 (fr) * | 1997-08-22 | 1999-02-24 | Compaq Computer Corporation | Procédé de communication sécurisée de télécommandes dans un réseau d'ordinateurs |
US20060168446A1 (en) * | 2002-09-13 | 2006-07-27 | Pasi Ahonen | Secure broadcast/multicast service |
US20040092310A1 (en) * | 2002-11-07 | 2004-05-13 | Igt | Identifying message senders |
US20080095360A1 (en) * | 2006-10-19 | 2008-04-24 | Camille Vuillaume | Signature System and Signature Method |
US8646041B2 (en) * | 2007-05-25 | 2014-02-04 | Institut Telecom / Telecom Paristech | Method for securing information exchange, and corresponding device and computer software product |
JP2009246657A (ja) * | 2008-03-31 | 2009-10-22 | Nippon Telegr & Teleph Corp <Ntt> | メッセージ復元システムおよび方法 |
US20110185180A1 (en) * | 2008-09-17 | 2011-07-28 | Peter Gullberg | Method and device for creating digital signature |
US20120096274A1 (en) * | 2010-10-15 | 2012-04-19 | Certicom Corp. | Authenticated encryption for digital signatures with message recovery |
US20170366358A1 (en) * | 2016-06-16 | 2017-12-21 | International Business Machines Corporation | Authentication Via Group Signatures |
Non-Patent Citations (3)
Title |
---|
Keoh et al.; "DTLS-based Multicast Security in Constrained Environments, 2014"; DICE Working Group (Year: 2014) * |
Keoh, et al., "DTLS-based Multicast Security in Constrained Environments", 2014, DICE Working Group Internet-Draft, pages 1-14, 2014 (Year: 2014) * |
Keoh, et al.; "DTLS-based Multicast Security in Constrained Environments", 2014 (Year: 2014) * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11343083B2 (en) | 2019-11-22 | 2022-05-24 | Baidu Usa Llc | Method for key sharing between accelerators in virtual channel |
US11405336B2 (en) | 2019-11-22 | 2022-08-02 | Baidu Usa Llc | Method for key sharing between accelerators in virtual channel with switch |
US11552790B2 (en) | 2019-11-22 | 2023-01-10 | Baidu Usa Llc | Method for key sharing between accelerators |
US11558357B2 (en) | 2019-11-22 | 2023-01-17 | Baidu Usa Llc | Method for key sharing between accelerators with switch |
US20210176070A1 (en) * | 2019-12-10 | 2021-06-10 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators using virtual channels with switch |
US11210136B2 (en) | 2019-12-10 | 2021-12-28 | Baidu Usa Llc | Systems and methods for an operating system module for a data processing accelerator |
US11411934B2 (en) | 2019-12-10 | 2022-08-09 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators with switch |
US11457354B2 (en) * | 2019-12-10 | 2022-09-27 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators |
US11516010B2 (en) | 2019-12-10 | 2022-11-29 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators using virtual channels |
US11728996B2 (en) * | 2019-12-10 | 2023-08-15 | Baidu Usa Llc | System and method to securely broadcast a message to accelerators using virtual channels with switch |
Also Published As
Publication number | Publication date |
---|---|
WO2019110445A1 (fr) | 2019-06-13 |
EP3721598A1 (fr) | 2020-10-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200389322A1 (en) | Security for group communication | |
US10505961B2 (en) | Digitally signed network address | |
US9553892B2 (en) | Selective modification of encrypted application layer data in a transparent security gateway | |
EP2905933B1 (fr) | Sécurité de transport basé sur le contenu | |
US7360084B1 (en) | System, device, and method for controlling access in a multicast communication network | |
US9313030B2 (en) | Method and apparatus for secure ad hoc group device-to-device communication in information-centric network | |
EP3171539B1 (fr) | Cryptage transparent dans un réseau axé sur le contenu | |
Tiloca et al. | Axiom: DTLS-based secure IoT group communication | |
US11770707B2 (en) | Lattice mesh | |
CN114503507A (zh) | 安全的发布-订阅通信方法和设备 | |
EP2905924A1 (fr) | Sécurité de transport basée sur le contenu pour des producteurs répartis | |
US10586065B2 (en) | Method for secure data management in a computer network | |
JP2006081082A (ja) | メッセージ受信確認方法、通信端末装置及びメッセージ受信確認システム | |
WO2017185978A1 (fr) | Procédé et dispositif d'analyse d'un paquet | |
US11716367B2 (en) | Apparatus for monitoring multicast group | |
Tonyali et al. | An attribute & network coding-based secure multicast protocol for firmware updates in smart grid AMI networks | |
US9825920B1 (en) | Systems and methods for multi-function and multi-purpose cryptography | |
US20180013729A1 (en) | Secure Application Communication System | |
US10798187B2 (en) | Secure service chaining | |
Buschsieweke et al. | Securing critical infrastructure in smart cities: Providing scalable access control for constrained devices | |
US9525671B1 (en) | Secure address resolution protocol | |
Park et al. | Survey for secure IoT group communication | |
JP4517911B2 (ja) | ポリシー配布方法、システム、プログラム、ポリシー配布サーバ、及び、クライアント端末 | |
Nasiraee et al. | DSBS: A novel dependable secure broadcast stream over lossy channels | |
US20240106659A1 (en) | Authentication process |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), SWEDEN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MATTSSON, JOHN;SELANDER, GOERAN;REEL/FRAME:052773/0698 Effective date: 20181130 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: APPLICATION DISPATCHED FROM PREEXAM, NOT YET DOCKETED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |