Communications system and methods

Abstract

A method of securely communicating a message in a communication system comprises receiving, by a secure messaging platform, a message at a receiving step. The receiving step may include at least one of: confirming that the message is secure, encrypting the message, confirming that the message includes a digital signature, or generating and associating a digital signature with the message and its sender. The method includes transmitting, by the secure messaging platform, the message at a transmission step. The method includes delivering, by the secure messaging platform, the message at a delivery step. The message is maintained in a cryptographically secure state during each step of the method, and each encryption and signing operation is logged to enable end-to-end auditability of the message through the receiving, transmission, and / or delivery steps.

Description

Communications System and MethodsTechnical Field

[0001] The present disclosure broadly relates to the secure communication of data and, more particularly, to a system for, and a method of, securely communicating a message between a sender and a recipient in a communications system.Background

[0002] Many industries, such as the healthcare industry, have long had strict requirements regarding communications, to ensure sensitive information remains protected. This has resulted in the slow adoption of digital communications technology for the communication of sensitive information, as it has lacked the security required for such sensitive information. For example, ordinary email is generally not considered sufficiently secure for sending sensitive information, as it is vulnerable to interception.

[0003] Secure messaging systems exist. However, both parties in the communication need to use the secure messaging system and when many users have not yet created an account, secure communication is problematic. In particular, if a recipient does not have a secure messaging account, it is not possible to send secure communications. In practice this results in various systems operating in parallel, including new and old communication systems. Furthermore, in many cases, it is not fast or easy to identify which other users use a secure messaging system, resulting in communications being sent unsecured by default.

[0004] Similar communication problems exist in other industries, particularly where sensitive information is being handled, including in the banking and finance sectors, education, and legal industries.

[0005] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application.Summary

[0006] Described herein are multimodal communication systems that support multimodal communication. As used herein, the term “multimodal” refers to communication systems that integrate more than one communication modality. The communication systems are multifaceted, providing a hybrid platform that supports more than one communication type, including one or more of email, fax, SMS and secure digital messaging.

[0007] In one aspect, a multimodal communication system comprises at least one computing device comprising: a data interface; a processor coupled to the data interface; and a memory, coupled to the processor, the memory including instruction code executable by the processor for: receiving, on the data interface, a communication associated with a recipient, the recipient associated with a legacy address; determining, using the processor, whether the legacy address is associated with a secure communications account; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

[0008] The instruction code, when executed by the processor, may further comprise instructions for: storing the communication on a data store; sending a notification to the recipient, using a legacy communications system and the legacy address, indicating that the communication has been received; and enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

[0009] In one aspect of a multimodal communication method, a message that includes a destination address is received, and a destination address type is determined. If the destination address type is associated with a legacy communication network, then the method ascertains whether a secure address is associated with the destination address. If a secure address is associated with the destination address, then the method securely forwards an encrypted digital version of the message to the associated secure address. Alternatively, if no associated secure address exists, then the method converts the message to a message format associated with the legacy communication network and transmits the message to the destination address via the legacy communication network.

[0010] As used herein, the term “legacy” refers to existing, prior art, communication technology that has generally been superseded by newer technologies that are more efficient and / or more secure. Examples of legacy communication technologies include (but are not limited to) text SMS messages, messaging platforms like WhatsApp, email, and / or fax. Legacy communication technologies may include digital technology (such as SMS messages), and may also include analogue technology. Legacy communication networks may include insecure networks such as conventional telecommunication networks that rely on telecommunication carriers. As used herein, the term “legacy communication network address” refers to conventional identifiers used in legacy networks, such as phone numbers, email addresses, fax numbers, etc.

[0011] In another aspect, a multimodal communications method comprises: receiving, on a data interface of a server, a communication associated with a recipient, the recipient associated with a legacy address; determining, using a processor of the server, whether the legacy address is associated with a secure communications account; and upon determining that the legacy address is associated with a secure communications account, sending, on thedata interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

[0012] In one aspect there is provided a method of securely communicating a message in a communication system, the method comprising: receiving, by a secure messaging platform, a message at a receiving step, wherein the receiving step includes at least one of: confirming that the message is secure, encrypting the message, confirming that the message includes a digital signature, or generating and associating a digital signature with the message and its sender; transmitting, by the secure messaging platform, the message at a transmission step, wherein the message is re-encrypted using a transmission-specific encryption key and digitally signed using a transport-layer digital signature; delivering, by the secure messaging platform, the message at a delivery step, wherein the transportlayer signature and encryption are removed and the message is re-encrypted and resigned using system-native cryptographic mechanisms; wherein the message is maintained in a cryptographically secure state during each step, and wherein each encryption and signing operation is logged to enable end-to-end auditability of the message through the receiving, transmission, and delivery steps.

[0013] In another aspect there is provided a method of securely communicating a message between a sender and a recipient in a communications system, the method comprising: preparing, by a sender device, a message payload comprising data to be transmitted to a recipient system, generating, by the sender device, a digital signature for the message payload using a private cryptographic key associated with the sender, wherein the digital signature is generated independently of any transport-layer protocol headers; encapsulating the message payload, the digital signature, and a public key corresponding to the private cryptographic key into a signed message object, wherein the signed message object is self-contained and comprises all information required for verification of the digital signature; transmitting, from the sender device, the signed message object to the recipient system via a transport mechanism that is decoupled from the signing process, such that signing and transmission occur as separate and distinct actions; receiving, by the recipient system, the signed message object via a transport protocol, and extracting the message payload, the digital signature, and the public key from the signed message object; verifying, by the recipient system, the digital signature using the public key and the extracted message payload to confirm the authenticity and integrity of the message payload independently of any transport-layer authentication mechanisms; wherein the decoupling of signing and transmission enables the signed message object to be transported through intermediary systems or alternative platforms that do not possess access to the sender’s private key and are unable to modify the signed message object without invalidating the signature.

[0014] In another aspect there is provided a method for cryptographically secure transmission and deserialization of signed API requests in a distributed system, the method comprising: serializing a request object into a deterministic binary format using Protocol Buffers, wherein the serialized payload includes embedded type information; generating a digital signature of the serialized payload using a private key associated with a client; transmitting the signed payload to a server as part of a self-contained message format, the self-contained message format comprising the binary-encoded signed payload, the sender’s public key, and the digital signature; verifying, at the server, the digital signature using the public key to confirm the authenticity and integrity of the received payload; deserializing the request obj ect using the embedded type information in the signed payload without reference to an external type field; and processing the request based on the deserialized type, thereby maintaining cryptographic validity across platform boundaries and eliminating signature mismatches caused by inconsistent serialization.

[0015] Throughout this specification the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.Brief Description of Drawings

[0016] Embodiments of the disclosure are now described by way of example with reference to the accompanying drawings in which:

[0017] Figure 1 shows an embodiment of a communications system.

[0018] Figure 2 is a block diagram of an example embodiment of a computing device.

[0019] Figure 3 A shows an embodiment of a communications method.

[0020] Figure 3B shows an example implementation of the communications method in Figure 3 A.

[0021] Figure 4A illustrates encryption technologies that form an embodiment of an encryption environment.

[0022] Figure 4B shows another embodiment of a communications method.

[0023] Figure 5 shows a part of an embodiment of a communications system.

[0024] Figure 6 shows an embodiment of a simplified schematic of a message payload of the communications system of Figure 5.

[0025] Figure 7 shows a schematic representation of a sent event item of the communications system of Figure 5.

[0026] Figure 8 shows an embodiment of a delivered event item of the communications system of Figure 5.

[0027] Figure 9 shows a schematic representation of a portion of the blockchain of the communications system of Figure 5.

[0028] Figure 10 shows an embodiment of a communications method.

[0029] Figure 11 shows another embodiment of a communications method.

[0030] Figure 12 is a flow diagram of an embodiment of a method of end-to-end object state verification using event fingerprints and blockchain.

[0031] Figure 13 is a flow diagram of an embodiment of an authenticated API request signing using a public / private key pair.

[0032] Figure 14 is a flow diagram of an embodiment of a method of cryptographic verification.

[0033] Figure 15 shows an embodiment of a payload format.

[0034] Figure 16A shows a new user workflow.

[0035] Figure 16B shows an existing user with a new device workflow.

[0036] Figure 16C shows a recover from error workflow.

[0037] In the drawings, like reference numerals designate similar parts.Detailed Description

[0038] Embodiments of communications systems and methods are described herein that provide confidentiality, auditability and authentication when parties communicate data, such as documents or other communications, with each other remotely. The systems and methods support multimodal communication by interfacing more than one type of communication technology including digital computer-based communication and legacy communication systems including telephone (voice and SMS) messaging and facsimile (fax) communication.System Overview

[0039] Referring to Figure 1 of the drawings, a communications system 100 includes one or more servers 110 that provide a secure communication platform 112, through which secure communications may be routed to both legacy communications systems, when needed, and tosecure communications systems when available. The servers 110 include or are coupled to a data store 112, which stores secure communications in escrow, which is particularly useful when a recipient does not have a secure communications account.

[0040] As used herein, the term “in escrow” refers to secure storage of communications, and / or holding communications in safekeeping. The term should be interpreted within the context of secure communications as described herein, and not interpreted narrowly within a conventional context of , for example, money or property held in custody by a third party. Embodiments of the systems and methods described herein are configured to hold communications in safekeeping unless or until the communications can be transmitted to a recipient securely via a secure communication channel.

[0041] A sender interacts with the secure communication platform 112 on the server 110 using a user computing device 120, such as a personal computer In some embodiments the one or more servers 110 function in part as a web server, and the secure communication platform 112 provides user interfaces with which the sender interacts. In some embodiments a user’s computing device 120 may run an application program 122 configured to connect the user’s computing device 120 to the platform 112 via a network 150 (for example a large area network, LAN, the internet, or other digital communication network, or a combination of interconnected communication networks).

[0042] In other embodiments the communication system 100 may be configured to operate in a different type of configuration, for example a client-server architecture where the server 110 may be a server host, and the platform 112 may comprise the server software that provides the functionality of the communication system 100.

[0043] The computing devices 120 are in communication with the server 110 over the network 150. In an exemplary embodiment, the application program 122 is provided by the server 110 and is accessed by the users of the system from a user computing device 120 via an online web application, thereby accessing the services provided by the platform 112.

[0044] Figure 2 is a block diagram of an example embodiment of a computing device 200 that can be used in the system 100, for example as a user computing device 120 and / or as one or more of the servers 110. Each computing device 200 includes a processor 210, storage 220, memory 230, and a communication interface 240 (also referred to as a “data interface” herein) for communicating with other computing devices. The various components of the computing device 200 are interconnected via a bus 250. This configuration may be implemented using a bespoke computing device, or in some embodiments standard devices such as a mobile phone, tablet, desktop computer or laptop may be used.User IDs and verification

[0045] A user ID is chosen by or assigned to each user, and a user’s user ID is used with interactions with the communications system 100. The user IDs are verified by the system100, providing a verifiable trust mechanism when sending or receiving data through the system 100.

[0046] In particular, the sender interacts with the digital platform 112 on the one or more servers 110 to generate a user ID. This process may include uploading identity documents, such as a driver’s license, performing an identity check, and / or performing third-party verification. The sender also enters communications details, such as a phone number, fax number, email address, or similar, which are also used for verification. The platform 112 verifies access to these communications, e g. by sending codes or other messages to the phone number, fax number or email address, such codes later being entered into the user interface to verify access to the communications.

[0047] Different levels of verification may be used based upon a role of the sender. As an illustrative example, basic user access may be provided upon verification of a mobile phone number. Advanced verification may, on the other hand, be required when sensitive information is being dealt with.

[0048] Other users, being recipients, may similarly create user IDs. As such, recipients may function as senders, and when both a sender and recipient have IDs, secure communication between a sender and recipient may be utilised.

[0049] In some embodiments, the communication system 100 described herein is a bidirectional communication system allowing users to both send and receive communications. In some embodiments, the bidirectional communication may be multimodal, for example upon receiving a communication via SMS, a recipient may be able to reply via SMS (for example to acknowledge receipt). The SMS gateway is then able to receive, convert and forward the received SMS message to the platform, allowing a user to access the content of the message.

[0050] The gateways 130, 140 forward communications from the fax machines 142 and mobile devices 132 to the server 110 when the system receives messages from those legacy devices. When the server 110 sends a communication, the server 110 is in direct communication (via a network or other relevant communication interface) with the devices to deliver the message, generally without the need for an intermediate gateway.Legacy addresses

[0051] The user IDs may be linked to or associated with one or more legacy addresses.

[0052] As used herein the term “legacy address” refers to conventional and prior art communication identifiers, such as a phone number, fax number, email address or the like.

[0053] When legacy addresses are linked to a user ID, access to or ownership of the legacy address may be verified. For example, in the case of a mobile phone number, a code may be sent to that number (e.g. by SMS), wherein the user is required to provide that code forverification. Such configuration enables messages to be sent to a user using a fax number, a mobile number and an email address, without necessarily knowing the user ID.

[0054] The linking of legacy addresses to user IDs enables communication directed to a legacy address to be redirected to secure communications. In particular, when communications associated with a legacy address are received at the server 110, the server 110 may determine whether the legacy address is associated with a user ID. If it is, further communication may be securely provided to the user using the user ID (accessed via a user computing device 120, either via a web interface or via an application program 122). Otherwise, the communication is either (a) routed to the legacy address via an SMS gateway 130 or a fax gateway 140, or (b) stored on the data store 112 at the server 110, until the recipient either creates a user ID, or associates a user ID with the legacy address.

[0055] The linking of legacy addresses to user IDs enables notifications regarding secure communications to be sent using legacy systems, such as SMS or fax. In particular, when communications associated with a legacy address are received at the server 110, the server 110 may determine whether the legacy address is associated with a user ID. If it is, a notification may be sent to the legacy address informing the recipient of the secure communication, upon which the recipient may log into the system to view the communication. Otherwise, a notification is sent to the legacy address, informing the user to create a user ID to access the communication. The communication will generally include a link or instructions regarding how to create the account (and thus user ID).Encryption

[0056] The user IDs are associated with public and private encryption keys, to enable encryption and authentication of messages with the system 100 and between users (i.e. between senders and recipients). The public key is published in association with the user ID, and the private key is kept private by the recipient, as is known in the art of asymmetric encryption.

[0057] When the sender wishes to send a communication to a recipient, the sender creates a message comprising data to be sent at their computing device 120. The data may include documents, images, audio, text, files, or any suitable data.

[0058] The message is then encrypted using either a public key of the server 110 or recipient, or a key (referred to herein as a “shared secret”) that is shared between the sender and the server 110 and / or recipient, to ensure that the initial communication is secure.

[0059] In some embodiments, encrypting the message using the key of the server is not used for sensitive communications, for example if there is a risk of a breach of the server 110 that may expose the sensitive communication.

[0060] When the sender wishes to send a communication to a recipient, the sender initially checks to see whether the recipient is associated with a user ID.(1) If the recipient is associated with a user ID, the sender may send encrypted communication directly between the sender and recipient (via the network 150), and with or without using the server 110 as an intermediate step. In such case, the message is encrypted using a public key of the recipient, or a key (shared secret) shared between the sender and the recipient. The message may comprise data in the form of documents, images, audio, text, files, or any suitable data.(2) If the recipient is not associated with a user ID (or is not associated with a user ID with a sufficient level of security), the sender sends the message to the server 110 together with a legacy address (e g. phone number, fax number, etc) of the desired recipient. In such case, the message is encrypted using either a public key of the server 110 or a key (shared secret) shared between the sender and the server 110, to ensure that the initial communication is secure.

[0061] The private key of the sender may further be used to sign the message, enabling the server 110 to authenticate the origin of the message, and confirm that it has not been tampered with. Alternatively, an encrypted communications channel between the sender and the server 110, e.g. comprising transport layer security or the like, may be used to authenticate the sender.

[0062] In case the communication is encrypted using a key associated with the server 110, the server 110 may decrypt the communication and re-encrypt it using a key associated with the user ID of the recipient.

[0063] In case the communication is encrypted using a key of the recipient, the server 110 is unable to decrypt the message, and the communication may be forwarded to the recipient using communication associated with the user ID. This provides end to end encryption between the sender and recipient.

[0064] As outlined above, in case of sensitive information, it may be undesirable for the server 110 to be able to decrypt the communication, as a breach of the server 110 may expose the sensitive information.

[0065] In such case, initial communication with the server 110 may comprise partial or less sensitive information. Once the recipient generates the user ID, details of the recipient’s and sender’s user IDs and public keys may be made available to each other, enabling end-to-end communication for all future communications. In other words, to avoid potential exposure of sensitive information, initial communication may avoid sensitive information, and instead function solely as a notification and / or end-to-end encryption initiation procedure.

[0066] Furthermore, if the server 110 decrypts and re-encrypts important communication, the sender has no way of verifying that the recipient has actually received the message as originally sent.

[0067] As such, and once the user IDs and public keys are shared between the sender and recipient, the recipient may re-encrypt the communication and send it back to the sender. This enables the sender to confirm that the communication received by the recipient is the same as what was sent, but also enables the communication to be stored in a shared mbox on the server 110.New users & legacy interfacing

[0068] Messages are sent to the platform 112 at the server 110 by a user from their computing device 120, together with a user ID and / or a legacy address (e.g. phone number, fax number, etc) of the desired recipient.

[0069] Upon receipt of the message, the server 110 stores the message on the data store 112. If a user ID is provided, or if a provided legacy address is associated with a user ID associated with a secure communications account, the server associates the message with that user ID. The recipient may access a received message from their computing device 120, using a web interface (e.g., using a secure inbox associated with the server 110, wherein the recipient logs onto the server 110 to view their secure inbox, and / or using an application program 122 that is in communication with the server 110.Notifications

[0070] If the legacy address is not associated with any user ID, the server 110 may:(1) send a notification of receipt of the communication using the legacy communications system, and provide details as to how to create a user ID and retrieve the communication, and / or(2) send the communication to the recipient using a legacy communications system (e.g. SMS or fax).For example, the communication system 100 may be configured (via default and / or user settings) according to any one or more of the following: (a) to send both a notification and a legacy version of the communication, or (b) to send a notification, and if the communication has not been accessed within a predetermined or selected time period, then send a legacy version of the communication, or (c) send a notification, and if an instruction is received (from the sender and / or the recipient), then send a legacy version of the communication, etc.

[0071] When the server 110 sends a notification to the recipient using a legacy communications system (e g. SMS or fax), informing the recipient 140 of the message, in some embodiments if a user ID is not present, the server 110 provides details as to how to create a user ID and retrieve the communication. Repeated notifications may be sent to the recipient using the legacy communications system, in particular where the message stored on the data store 112 requires urgent attention. In this regard, the server 110 may receivenotification that a message to an unspecified recipient has not been accessed within an acceptable time which may prompt the server 110 to send further communications to the recipient requesting the recipient to create a user ID such that they can retrieve the communication. Acceptable times may be defined by the sender during generation of the communication.

[0072] In case a notification is sent, rather than the communication itself, the communication is stored on server 110, and the notification is automatically generated at the server 110, e.g. using a template. The notification may include a link, selectable by a user, for generating a user ID and accessing the communication. The link may compnses a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL).

[0073] The notification is then sent to the recipient using one of the legacy communications systems, e.g. SMS using the SMS gateway 130.

[0074] To receive the communication, the recipient follows a link in the notification (e.g. by clicking on it), which directs the recipient to the server 110, and in particular a user interface / web page thereof. Here the recipient may either create a user ID, or associate a user ID with the legacy address. This process is similar to that described above, and includes verification and authentication of the recipient.Format Conversion

[0075] The methods and systems described herein are enable multimodal communication by integrating more than one communication modality. The multimodal omni channel communication systems integrate multiple messaging technologies.

[0076] The system is configured to convert a communication from one format to another. For example, a scan or image may be converted from an image format suitable for faxmg, to a document format (e g. PDF) suitable for display on a computing device, or vice versa.

[0077] In case the communication is sent using the legacy communication system, the server 110 may convert the communication from one format to another. As an illustrative example, a document or message may be converted to an image format suitable for faxing prior to being forwarded to the fax gateway 140. .

[0078] In particular, the server 110 is in communication with one or more legacy communications systems using respective communications gateways, including for example an SMS gateway 130 and / or a fax gateway 140. The SMS gateway 130 is configured to generate and send SMS messages to a cellular telephone 132 associated with the legacy address (i.e. a phone number), and the fax gateway 140 is configured to generate and send faxes to a fax machine 142 associated with the legacy address (i.e. a fax number).

[0079] The SMS gateway 130 serves as a conduit between the digital communication platform 112 and mobile networks, facilitating the sending and receiving of SMS (ShortMessage Service) messages. It can be either hardware-based or software-based. When an SMS message is sent by the platform 112, or via the platform from a computing device 120 by a user accessing a website, a mobile application program 122, or email client, the SMS gateway 130 receives the message. It then processes the message, converting it into a format compatible with the SMS protocol used by mobile networks. This typically involves encoding the message into the appropriate character set and format. The SMS gateway 130 then forwards the message to the recipient’s mobile network through various protocols like SMPP (Short Message Peer-to-Peer) or HTTP APIs. Once received by the mobile network, the SMS is delivered to the recipient’s phone 132. Conversely, if an SMS is sent to a user or to the platform 112, it is first received by the SMS gateway 130, which then forwards it to the user computing device 120 and / or the communication platform 112. This seamless integration between digital platforms and mobile networks enables the incorporation of SMS messaging into the communication system 100.

[0080] The fax gateway 140 may be implemented in the form of a hardware device or software application and serves as a bridge between the digital communication methods (used by the platform 112 on the server and the application program 122 on the computing devices 120) and traditional fax machines. The fax gateway 140 receives digital messages and converts them into a format compatible with fax machines, such as TIFF. Through encoding, the message is converted into fax protocols like T.30 or T.38 for transmission over analogue telephone lines or IP networks. Once sent, the message is received by the recipient’s fax machine, where it is printed. The fax gateway 140 handles confirmation signals, error handling, and may provide feedback to the communication platform 112 regarding the transmission status. This integration supports faxing in the digital workflow while maintaining compatibility with fax-dependent recipients.

[0081] The server 110 may determine the type of legacy communication, e g. SMS or fax, and send the notification using the determined legacy communications system. This enables the system 100 to work with multiple communications systems, e.g. fax and SMS, in a similar manner.

[0082] The type of communication may be determined in any suitable way. As an illustrative example, the legacy address may identify the type of communication through a prefix. For example, SMS:<number> may be used to identify SMS (text) messages, and fax:<number> may identify fax communications. In other embodiments, however, such determination may be made according to one or more implicit rules. For example, plain text may be implicitly intended for SMS messages, and pdf documents may be implicitly intended for fax.

[0083] As will be readily understood from the above description, the server 110 functions as an automatic router, that routes communications associated with a legacy address to secure communications using a user ID, when available, while automatically falling back to legacycommunications when recipients do not have user ID. This is achieved without requiring the sender to know whether the recipient has a user ID or not.

[0084] In this way, the configurations described herein enable the communication method to automatically fall back to legacy communications when recipients do not have a secure communications account.Application Program

[0085] Users are able to access functionality supported by the secure communication platform 112 via a client program, using a web interface, with an application program 122, or the like. For simplicity, the description herein refers to an application program 122 on a user’s computing device 122.

[0086] The user may be a sender and / or receiver of communication messages. The communication system 100 functions are accessed by the user via a user interface displayed on the user’s computing device 120 by the application program 122. In some embodiments, the program 122 supports secure messaging in the form of text, images, and / or voice messages (comparable to SMS or text messages), including associated audio and / or visual notifications.

[0087] In some embodiments, notifications may include descriptive text and instructions on how to access the message, including a URL and / or hyperlink. The hyperlink may link to an account generation screen of the system 100, and is selectable by the recipient. Once the recipient creates an account, a secure inbox is generated for the user (accessible via a web interface and / or an application program) and the communication is provided in the inbox.

[0088] In case multiple communications are in safekeeping, stored in the data store 112, one or more is made accessible via the secure inbox, and the communications are selectable by the recipient for viewing once the recipient logs in and is authenticated by the system.

[0089] When wishing to send a communication to one or more recipients, the sender may create a message using a message creation interface that includes one or more of: a from address field (e.g., in the form of a free text field, a drop down menu, or the like), a to address field, an add recipient button associated with the to address field, a smart routing radio button, a message text field, and / or a schedule message radio button.

[0090] If the message is sent by legacy systems, e.g., SMS, the SMS gateway 130 generates and sends a text message to the phone 132 based on the message parameters and content that the user defined. In case secure communications are used, the recipient may log into a secure inbox. The secure inbox may be provided by the server 110 and / or a secure application on a user device 132 (e.g. a secure app).

[0091] When a user receives a message in their secure inbox supported by the platform 112, the application program 122 displays a user interface providing access to the secureinbox that may include one or more message elements such as sender details or a message subject. When the user selects a communication to view, the user interface displays the message, including one or more message elements such as text, images, message descriptors (e.g., sender, receiver, date etc.).

[0092] The secure inbox screen may be similar for the sender and recipient. Furthermore, the secure mbox screen may enable the sender and / or recipient to move between communications with different other users. This way the sender and recipient are able to view conversations independently.MethodMethod 1

[0093] Figure 3A is a diagram of an embodiment of a communications method 300 supported by the platform 112. The platform 112 is configured to receive a secure message at 310, cause the secure transmission of the message at 320, and facilitate the secure delivery of the message at 330. All three parts of the method 300 are executed in such a way that the message remains secure, and also in such a way that the secure message’s passage from receipt 310 through to delivery 330 via transmission 320 is auditable end-to-end.

[0094] Figure 3B of the drawings illustrates an example of how this method may be implemented. At 302, a communication associated with a recipient is received on a data interface (also referred to herein as a communication interface). The message and / or recipient may be associated with a legacy address, such as a phone or fax number of the recipient. At 304, the sender is authenticated. This includes receiving a user identifier, and comparing the user identifier to authorised identifiers. If the sender is authenticated then the message is transmitted at 306. If the message is received from a legacy address, step 304 includes determining whether the legacy address is associated with a secure communications account. This may be performed using a look-up table, or any other suitable means.

[0095] In case the legacy address is not associated with a secure communications account, a communication is sent to the recipient using the legacy address and a legacy communications system at 308. The communication may comprise the communication received from the sender, or a derivative thereof, and is delivered via the legacy system at 309.

[0096] In case the legacy address is associated with a secure communications account, the communication, or a derivative thereof, is sent to the recipient, on the data interface and using the secure communications account at 306. Following this secure transmission, the message is then securely delivered at 307. Delivery at 307 is secure and includes authenticating the recipient.

[0097] The systems and methods described herein aim to achieve two specific outcomes. One is providing very secure transmission of messages, so that features such as encryptionand / or user authentication may be useful. The other is supporting auditability, so that auditing features such as digital signatures (also called “cryptographic seals”), may be useful.Authenticity and Integrity

[0098] A message authentication code (MAC) (also referred to as an authentication tag) can be used for authenticating and integrity-checking a message. A MAC can be used to confirm that the message came from the stated sender (its authenticity) and has not been changed (its integrity). The MAC value allows verifiers (who also possess a secret key) to detect any changes to the message content.

[0099] Receiving 310 the message involves inputting the message to be communicated into the secure communication system. In some embodiments this may include providing a user interface for a user to input the message, having an mput / output interface via which a user may provide the message, the communication system itself creating the message, or the like. Irrespective of exactly how the message arrives at the secure communication system, during the receiving step 310 the system will perform at least one of the following: a. check if, or confirm that, the message is secure (e.g., if the message is encrypted), b. encrypt the message to ensure that the message is secure, c. check if, or confirm that, the message includes a digital signature associated with the authenticity of the message, and / or d. create a digital signature and associated with the message and the source or sender of the message.

[0100] HMAC (Hashed Message Authentication Code) is an example of a cryptographic technique used to ensure both data integrity and authenticity. HMAC is a type of message authentication code that involves a cryptographic hash function and a secret key. It performs two hash computations, and supports various hash functions.

[0101] In some embodiments, the secure communication platform 112 described herein may receive the message at 310, and pass the message to the transmission step at 320 as a secure (e g. encrypted) and digitally signed message. Transmission 320 may be performed with the aid of one or more supplementary systems and / or components, such as a third party MAC, e.g. HMAC, before the platform 112 takes responsibility for the message again at the delivery step 330. In these embodiments, a new digital signature is reapplied according to the protocol(s) used for the transmission step 320.

[0102] The delivery step 330 includes at least one of the following: a. Applying or reapplying a digital signature, b. Decrypting the delivered secure message,c. Confirming the authenticity of the delivered message, d. Confirming the integrity of the delivered message, e. Facilitating decrypting the delivered message, and / or f. Facilitating authenticating the delivered message.

[0103] This layered cryptographic approach implements a robust end-to-end security envelope, combining transport-level security with system-native cryptographic integrity, and is particularly effective in systems where control over the transmission channel is limited or where multiple trust boundaries exist.

[0104] In this architecture, when the message is first received by the system, it is secured using the system's native digital signature - which uniquely identifies and binds the message to the authenticated sender - and encrypted using a strong internal encryption key. This ensures the message is cryptographically sealed and confidential within the system's trust domain. The signature serves as a persistent identity seal, while the encryption provides initial data protection.

[0105] Before the message is handed over to the external or intermediate transmission system, the original encryption and signature are unwrapped. The message is then reencrypted using a second, transmission-specific encryption key, and signed again with a different transmission-layer digital signature. This second layer of cryptography secures the message for transport across potentially untrusted or semi-trusted channels, such as internet-based networks or third-party infrastructure. The transport-layer cryptography ensures that the message remains protected during transmission but can be verified and decrypted only by systems authorized within that layer.

[0106] On the recipient’s side, once the message is received from the transmission system, the transport-level signature and encryption are removed The system then re-wraps the message using its native cryptographic protocol, applying the original form of strong encryption and identifier digital signature before final delivery to the recipient. This rewrapping step ensures that the message is again within the system’s full control, both cryptographically and in terms of access policy enforcement. The recipient can then decrypt and verify the message using their credentials and the system’s native verification mechanisms, without needing to trust the transport system or its cryptography.

[0107] This design has two main advantages. First, it ensures that the confidentiality and integrity of the message are maintained across different layers of infrastructure, even when some of those layers fall outside the direct control of the core system. Second, it provides a verifiable chain of custody: each re-signing and re-encryption action can be logged and audited, ensuring that the message's passage through the system can be independently verified and reconstructed. This approach is particularly well-suited to regulated or high-riskenvironments - such as healthcare, legal, and financial communications - where both data security and traceability are required throughout the entire lifecycle of a message.

[0108] In an example embodiment, a method of securely communicating a message in a communication system comprises receiving, by a secure messaging platform, a message at a receiving step. The receiving step may include at least one of: confirming that the message is secure, encrypting the message, confirming that the message includes a digital signature, or generating and associating a digital signature with the message and its sender. The method includes transmitting, by the secure messaging platform, the message at a transmission step. The method includes delivering, by the secure messaging platform, the message at a delivery step.

[0109] In some embodiments, the message may be re-encrypted using a transmissionspecific encryption key and digitally signed using a transport-layer digital signature. In such embodiments, the transport-layer signature and encryption are removed and the message is re-encrypted and re-signed using system-native cryptographic mechanisms as part of the delivery step.

[0110] The message is maintained in a cryptographically secure state during each step of the method, and each encryption and signing operation is logged to enable end-to-end auditability of the message through the receiving, transmission, and / or delivery steps.

[0111] The message may be cryptographically bound to the sender at the receiving step using a native digital signature that uniquely identifies the sender. The transmission step may comprise unwrapping the system-native signature and encryption and applying a transportspecific encryption and digital signature for transmission through a semi-trusted or untrusted network. The delivery step may include applying or reapplying a system-native digital signature and encryption to return the message to the trust domain of the secure messaging platform prior to recipient access. The delivery step may include verifying the authenticity and integrity of the message and / or facilitating its decryption using credentials associated with the intended recipient. Signing and / or encryption operation at the receiving, transmission, and / or delivery steps may be recorded in a cryptographically verifiable audit log to provide a complete chain of custody for the message.

[0112] In such embodiments where there is a handover between systems and / or protocols, it means that security, encryption, digital signatures, authentication and the like, are not uniform end-to-end. This could be problematic for at least two reasons:(1) the same quality of secure and auditable communication cannot be guaranteed end-to-end, and(2) auditability is complicated because the same digital signature is not used end-to-end. In other words, some form of mapping of signatures is required in order to confirm that the digital signature present from start to finish, via each interim step, represents the same thing.

[0113] Where there is a handover between systems and / or protocols, such as in a communication pipeline involving transport-layer and system-native cryptographic operations, security mechanisms like encryption, digital signatures, and authentication are no longer uniform from end to end. This creates potential vulnerabilities and complexities.

[0114] First, it introduces uncertainty in the quality and consistency of security across the entire transmission path. Because each system or protocol may apply its own cryptographic standards, key strengths, or signature schemes, there is no guarantee that the same level of confidentiality, integrity, and authentication is maintained throughout. This inconsistency undermines the ability to assert that the message has been protected to a uniform standard from sender to recipient.

[0115] Second, it complicates auditability, particularly where digital signatures are concerned. In a secure system, digital signatures act as a verifiable proof of origin and integrity. However, when a message is signed and re-signed at each stage - such as at the system level, the transmission layer, and again at the receiving endpoint - the original signature is not preserved end-to-end. As a result, the audit trail cannot rely on a single, continuous cryptographic proof. Instead, some form of signature mapping is required to demonstrate that each signature along the chain corresponds to and derives from the original. This involves maintaining records of each transformation and re-signing event, and ensuring that each new signature cryptographically references or authenticates the previous state of the message. Without this mapping, it becomes difficult - if not impossible - to establish a single chain of trust that spans the full lifecycle of the message.

[0116] To address these issues, a system must implement structured signature provenance and transformation records, ensuring that every cryptographic transition is traceable and verifiable. This allows the recipient, or an auditor, to validate that the content received is indeed the same as that originally sent, even though it has passed through multiple layers of encryption and authentication. This is critical in systems where legal, medical, or financial records must remain intact, verifiable, and trustworthy across multiple technical and administrative boundaries.

[0117] The inventors realised that better quality and a more transparent authentication process can be achieved if the same digital signature is used from start to finish. In other words, when the message is received at 310 and prepared for transmission during the receiving step 310, a native identifier is created and used to digitally sign the message. This native identifier digital signature is associated with the message at the start when the message is prepared for transmission, and is maintained as is, unchanged, during transmission 320 from the sender to the recipient of the message, and the native identifier digital signature is maintained unchanged when the message is received 330. Authentication of the message therefore involves inspection of the same native identifier digital signature in each of the receiving 310, transmission 320, and delivery 330 steps of the secure communication method 300.

[0118] In this way, the event system (described in more detail elsewhere herein) is adapted to provide an end-to-end data trail with enhanced transparency because the digital signature does not need to be mapped or interpreted in any way at different stages of the message transmission.

[0119] The native identifier digital signature furthermore facilitates integration of the platform 112 in existing communication systems in order to make them secure and auditable. This is because the native identifier digital signature enables both portability and adaptability to different system architectures. The secure message can traverse a communication channel with almost any architecture, for example passing via one or more servers and / or nodes, before being delivered, and maintaining the same native identifier digital signature throughout.

[0120] The native identifier digital signature also protects against interception, incorporating replay protection.

[0121] To implement a secure communication system where a single, persistent digital signature (native identifier) is used from start to finish - across message preparation, transmission, and delivery the system separates the core message integrity layer from the transport layer, and ensures that the digital signature is never stripped or replaced during transit. This requires a combination of cryptographic primitives, secure message container formats, and integrity-preserving transmission protocols.

[0122] At the message creation point (step 310), the system generates a native identifier, which uniquely identifies the message and sender. This can be a UUID, user public key fingerprint, or a system-issued identity token. The system then uses a cryptographic digital signature algorithm (such as ECDSA or RSA) to sign the message contents using the sender’s private key.

[0123] Figure 4A illustrates encryption technologies that form an embodiment of an encryption environment, including: CIPHER (Xsalsa20), HMAC (Polyl305), KEYS (Curve25519), SIGNATURE (Ed25519), and HASHING (SHA512).

[0124] The digital signature includes a hash of the message content, the native identifier, and optionally a timestamp to prevent replay attacks. The signed message is packaged into a structured format that allows the signature to travel with the message. In some embodiments the format may include a JSON Web Signature (JWS) or CMS / PKCS 7 (Cryptographic Message Syntax) envelope.

[0125] In some embodiments, libraries such as OpenSSL, libsodium, or Bouncy Castle may be used for the cryptographic signing, and message standards like JWS (from the JOSE suite) or CMS / PKCS 7 may be used for packaging the message with its signature. Thenative identifiers may be assigned using UUID libraries, or public key fingerprints may be generated via SHA-256 of the sender’s public key.

[0126] To ensure that the transmission layer (Step 320) operates without tampering to the signature, during transmission the message container, with the original signature, is transported as-is without alteration. The transmission system may add outer encryption for privacy (e.g., using TLS, VPN, or onion routing), but it does not decrypt, inspect, or re-sign the message content. If additional metadata or routing information is required, it is appended outside the signed message container (e.g., in a transport envelope or as headers).

[0127] Technology used to implement this may include using standard TLS 1.3 for secure channel transport without touching message contents. Message brokers such as RabbitMQ or Kafka may be used, configured in opaque binary payload mode, ensuring the signed message is passed unchanged For web transport, HTTP POST with JWS payloads, or MQTT over TLS for loT-style systems may be used.

[0128] At the recipient’s end, in step 330 the system extracts the message and its associated digital signature from the received container. Using the sender’s public key, the system verifies the digital signature. This confirms that the message content has not been altered and that the message originated from the sender identified by the native identifier. If the signature is valid, the system decrypts the message (if it was encrypted) and presents it to the recipient.

[0129] Signature verification can be done using the same libraries (e g., OpenSSL, Bouncy Castle, libsodium) and the sender’s public key, which can be retrieved from a trusted public key directory, blockchain-based identity system, or X.509 certificate.

[0130] Access control is used to ensure only authorized recipients can decrypt the message (e.g., using PGP, CMS EnvelopedData, or hybrid encryption models like AES for content + RS A for key exchange).

[0131] To maintain the Signature End-to-End, the system is configured to enforce the following key design rules: a. Never allow intermediate systems to modify the signed message or replace the signature. b. Use immutable message formats, where the signature covers all the message fields that should not be changed. c. Where intermediate systems add metadata, use nested message formats (e.g., outer envelope for routing, inner envelope for content and signature). d. Maintain logs of the native signature’s hash or metadata at each step for audit purposes. Optionally, store these in a blockchain ledger for tamper-proof auditing.

[0132] Optional Audit Enhancements may include one or more of the following: a. Store the hash of the signed message or the digital signature itself in a blockchain ledger to create an immutable audit trail. b. Use timestamping services (RFC 3161) to bind the signature to a point in time. c. Maintain an event-sourcing database to track when each message was created, sent, received, and verified.

[0133] To implement this system, the method performs the following steps: a. Sign the message once at creation with a native identifier digital signature. b. Package the message and signature using a standard like JWS or CMS. c. Transmit the package unchanged over a secure channel. d. At the recipient side, verify the signature using the sender’s public key.

[0134] By keeping the signature unchanged across all stages and layering transport security without modifying the message, the system ensures consistent authentication, verifiable integrity, and transparent auditability. This architecture is practical with widely available cryptographic libraries and standard secure transport protocols.

[0135] Table 1A and Table IB show an example of code that demonstrates how to prepare, sign, transmit, and verify a secure message using persistent digital signatures and a JWS-style message envelope: # Reference implementation of secure message flow with persistent digital signature # Technologies used: Python, cryptography library, JSON Web Signature (JWS) format import json import base64 from cryptography.hazmat. primitives import hashes, serialization from cryptography.hazmat. primitives. asymmetric import padding, rsa from cryptography.hazmat. primitives. asymmetric import utils as asym_utils from cryptography.hazmat. backends import default_backend # Step 1: Generate sender's keys (would normally be stored securely and reused) sender_private_key = rsa.generate_private_key( public_exponent=65537, key_size=2048, backend=default_backend() ) sender_public_key = sender_private_key.public_key() # Step 2: Prepare message and native identifier message_content = { "nativejd": "user-1234", "timestamp": "2025-05-02T12:00:00Z", "body": "This is a confidential message." } message_bytes = json.dumps(message_content).encode('utf-8') # Step 3: Sign the message using sender's private key message_hash = hashes. Hash(hashes.SHA256(), backend=default_backend()) message_hash.update(message_bytes) digest = message_hash.finalize() signature = sender_private_key.sign( digest, padding. PSS( mgf=padding.MGFl(hashes.SHA256()), saltJength=padding.PSS.MAX_LENGTH ), asym_utils.Prehashed(hashes.SHA256()) )Table 1A: Code example for secure message flow (part 1)# Step 4: Package message in a secure envelope (JWS-style) secure_envelope = { "payload": base64.urlsafe_b64encode(message_bytes).decode('utf-8'), "signature": base64.urlsafe_b64encode(signature).decode('utf-8') } # Step 5: Transmit secure envelope (mocked) transmitted_message = json.dumps(secure_envelope) # Step 6: Receiver side - decode and verify received_envelope = json.loads(transmitted_message) received_payload = base64.urlsafe_b64decode(received_envelope["payload"]) received_signature = base64.urlsafe_b64decode(received_envelope["signature"]) # Recompute hash verify_hash = hashes. Hash(hashes.SHA256(), backend=default_backend()) verify_hash.update(received_payload) verify_digest = verify_hash.finalize() # Verify signature try: sender_public_key.verify( received_signature, verify_digest, padding. PSS( mgf=padding.lVIGFl(hashes.SHA256()), salt_length=padding.PSS.MAX_LENGTH ), asym_utils.Prehashed(hashes.SHA256()) ) printf'Signature verification succeeded. Message is authentic and intact.") except Exception as e: printf'Signature verification failed:", str(e))Table IB: Code example for secure message flow (part 2)

[0136] In this way, users have a verified identity, the messages are transmitted as verified transactions, and therefore interactions between senders and recipients are verified interactions.

[0137] Referring to Figure 12 of the drawings illustrates a method 1200 of end-to-end object state verification using event fingerprints and blockchain. The method 1200 begins at step 1202, where an input is received that initiates a change to the state of an object. This input does not directly modify the object itself; instead, it produces a change in the corresponding event data at step 1204. This event data represents a discrete, immutable record of the state change and becomes the basis for further processing.

[0138] From this change to the event data, two outcomes are generated in parallel. First, a cryptographic fingerprint (hash) of the event is computed at step 1206. This hash uniquely represents the contents of the event data and cannot be used to infer the underlying information. This fingerprint is used to update the cumulative event fingerprint at step 1208, which may reflect a running or aggregated hash of all previous events associated with the object. This updated event fingerprint is then written to a public blockchain database at step 1210, providing an immutable and publicly verifiable record of the event. Simultaneously, the system stores the resulting state fingerprint at step 1212. This state fingerprint represents the object’s expected state after the event has been applied, as computed at the time of the event.

[0139] In parallel, the same event data change from step 1202 is also recorded in a private database at step 1220. From this private event log, the object’s current state is reconstructed at step 1222 by replaying the full series of events. The reconstructed state is then subjected to the same fingerprinting process at step 1224, resulting in a hash of the current object state. This produces a set of current state fingerprints at step 1226, which represent the actual state of the object as held by the private system.

[0140] Finally, at step 1230, the stored state fingerprints (from step 1212) are compared with the current state fingerprints (from step 1226). If the fingerprints match, the system concludes that the reconstructed object state is identical to the state that was originally generated and recorded, confirming both the authenticity and integrity of the object. This comparison yields a verified state at step 1232, offering strong assurance that the object has not been tampered with and that its state remains faithful to its historical record.

[0141] The system employs a private event store to retain immutable records of specific objects, such as transactions. Modifications to an object are not made by altering its state directly, but rather by applying a senes of discrete events. At any point, the object can be accurately reconstructed by replaying the full sequence of events that have occurred to it.

[0142] To ensure the integrity and authenticity of these events, each is assigned a unique identifier and subjected to a cryptographic hashing process - referred to as "fingerprinting." The resulting hash values, along with the corresponding event identifiers, are recorded on a public blockchain. This enables independent verification of the object’s authenticity.

[0143] To verify the integrity of a recorded object, one retrieves the complete list of events used to build it, applies the same cryptographic hashing function to each event, and compares the resulting fingerprints with those stored on the blockchain. As long as the computed hashes match the publicly recorded ones, it can be guaranteed that the object has not been altered and remains identical to the original version.

[0144] This approach enables the system to keep sensitive information private while still maintaining public accountability. The term "fingerprint" refers to the use of a cryptographichashing function - in this case, SHA-512. Hashing the same content will consistently produce the same hash value, thereby justifying the analogy to a fingerprint. Furthermore, just as a fingerprint cannot be used to reveal other personal details about its owner, a hash value cannot be reversed to disclose information about the original object from which it was derived.Example Embodiment: Authentication Model

[0145] In one example embodiment, an authentication model is based on digital signatures, and is used as the default method for verifying all requests made to the secure messaging system. The approach relies on asymmetric cryptography to provide strong guarantees of authenticity, non-repudiation, and protection against common attack vectors, without requiring traditional user logins or token-based session tracking.

[0146] When a client prepares to make an authenticated request, it begins by constructing a request object and computing a cryptographic hash of its contents. The client then creates a digital signature by encrypting this hash using its private key. The resulting HTTP request to the server includes the request object in the body, along with the digital signature and the client’s public key in the headers.

[0147] Upon receiving the request, the server verifies the digital signature using the provided public key. If the signature is valid, the server is assured that the request was created by the holder of the corresponding private key and that the message contents have not been altered in transit. The server then derives the user’s identity directly from the public key and processes the request on behalf of the authenticated user.

[0148] This method ensures that message contents cannot be modified after signing, since any change would invalidate the signature. It also prevents impersonation. If an attacker attempts to switch the public key in a request, the signature verification will fail unless the attacker also possesses the private key, in which case the system would treat the request as coming from a different user entirely, subject to normal authorization checks.

[0149] The approach also defends against man-in-the-middle attacks, as any changes to the request payload by an intermediary would result in a mismatch between the received payload and the cryptographic hash embedded in the signature. Without access to the original private key, an attacker cannot forge a valid signature for an altered payload.

[0150] Replay attacks, where an attacker captures and reuses an authenticated request, pose a unique challenge because the request alone contains everything needed to execute a valid action. To mitigate this, two strategies are proposed. The first is to timestamp each request, allowing the server to reject those that fall outside an acceptable time window. This is simple to implement but requires balancing transmission delay tolerance with minimizing the window for replay. The second strategy involves including a unique nonce - a number used only once - in each request. The server tracks all used nonces and rej ects any duplicates. Thismethod provides strong protection against reuse but requires the server to store and manage a growing list of used nonces.

[0151] A hybrid approach combines both timestamping and nonce tracking. In this model, the server only checks nonce reuse within a specified time window. Any nonce outside this window is discarded, reducing storage and lookup requirements while maintaining effective protection. This approach allows for a flexible, efficient authentication mechanism that upholds message integrity and user accountability, even in distributed or asynchronous environments.

[0152] In one example embodiment, a method of authenticating requests in a secure messaging system comprises constructing, by a client device, a request object comprising data to be transmitted to a server, and then generating, by the client device, a cryptographic hash of the request object The method includes generating a digital signature by encrypting the cryptographic hash using a private cryptographic key associated with the client, and transmitting, from the client device to the server, a request (for example, an HTTP request) comprising the request object in the body, and including the digital signature and a public key corresponding to the private key in the headers. The method includes receiving, by the server, the request (e.g., an HTTP request) and verifying the digital signature using the public key. Upon successful verification, the method includes deriving the client’s identity from the public key and processing the request on behalf of the authenticated client. The method does not rely on login sessions or token-based tracking, and provides cryptographic guarantees of authenticity, integrity, and non-repudiation.

[0153] Any modification to the request object after the digital signature is generated may cause the digital signature verification to fail, thereby ensuring message integrity. The server may reject any request in which the digital signature does not correspond to the request object and public key, thereby preventing impersonation.

[0154] The method may also include defending against man-in-the-middle attacks by ensuring that any modification to the request by an intermediary results in a failed signature verification.

[0155] The method may also comprise including a timestamp in the request object, and rejecting, by the server, any request in which the timestamp falls outside a specified allowable time window, thereby mitigating replay attacks.

[0156] The method may also comprise including a unique nonce in each request object and maintaining, by the server, a record of used nonces within the allowable time window, wherein the server rejects any request containing a duplicate nonce.

[0157] Figure 13 shows an embodiment of an authenticated API request signing method1300 using a public / private key pair. The Client Signing Process 1300 is a structured methodused to securely authenticate an API request by generating a verifiable digital signature. The process begins at step 1302, where a cryptographic key pair, consisting of a private key and a public key, is provided. These keys serve as the foundation for the signing and verification operations.

[0158] The first stage of the process, referred to as "Signing API Request" 1310, involves the application of the private key to produce a digital signature. At step 1312, the private key is securely received and provided to a signer module 1314. Concurrently, the request data intended for transmission is processed by a hashing module 1318, which generates a hash of the API request 1316. This hash serves as a fixed-length, tamper-evident representation of the original request. The signer 1314 then uses the private key to encrypt this hash, resulting in a digital signature that is mathematically bound to both the contents of the request and the identity of the key holder.

[0159] The next phase, "Building Payload" 1320, involves constructing the complete HTTP request to be sent to the server. The public key is introduced at step 1322 and is included as a header in the HTTP request. The original API request object is added as the request body at step 1326, and may also optionally be provided to the hasher 1318 in the earlier step if needed for hashing. The API request signature, which was produced by the signer 1314, is included as a separate header at step 1328. All these elements - public key, signature, and API request body - are combined at step 1324 to form the final HTTP request.

[0160] This process ensures that the server receiving the request can verify the identity of the sender by using the public key to confirm the validity of the digital signature. It also guarantees that the contents of the request have not been altered in transit, as any modification would cause the verification to fail. By cryptographically binding the request to the client’s private key, the Client Signing Process 1300 supports both authentication and integrity in a secure and auditable manner.

[0161] In an example embodiment, a method for securely signing and transmitting an authenticated API request from a client to a server comprises receiving or generating, by a client device, a cryptographic key pair comprising a private key and a corresponding public key. The method comprises generating a cryptographic hash of an API request object using a hashing module, the hash representing a fixed-length, tamper-evident representation of the request obj ect. The method includes generating a digital signature by encrypting the cryptographic hash using the private key via a signer module, and then constructing a request (such as an HTTP request) comprising the API request object as a request body, and including the digital signature and the public key in headers. The method includes transmitting the request to a server. The server verifies the digital signature using the public key to confirm that the API request object has not been altered and that it originates from the holder of the corresponding private key.

[0162] The API request object is optionally provided to the hashing module both for generating the cryptographic hash and for inclusion in the HTTP request body, thereby ensuring consistency between the signed data and the transmitted request.

[0163] The digital signature and public key may be added as separate HTTP headers in the request, enabling the server to perform authentication and integrity verification independently of any session or token-based mechanism.

[0164] Figure 14 shows an embodiment of a method of cryptographic verification. The Server Verification Method (1400) describes a process by which an incoming HTTP request is authenticated and validated before being processed. At the outset, the server receives an HTTP request (1402), which includes three key components: the API Request Object as the body (1410), the API Request Signature as a header (1420), and the Public Key as a header (1430).

[0165] The API Request Object (1410), containing the substantive content of the request, is passed to a hashing module (1414), which generates a cryptographic hash of the payload (1416). This hash serves as a tamper-evident representation of the request content and is later used for signature verification.

[0166] Simultaneously, the API Request Signature (1420) and the Public Key (1430) are passed to a Validator module (1422). The Validator attempts to decrypt the signature using the provided public key. If the signature is malformed or the public key is invalid, the system generates appropriate error messages and terminates the request processing.

[0167] If decryption succeeds, the Validator outputs a hash value (1432) derived from the signature. This is then compared at step 1440 with the hash of the request payload (1416). If the two hashes do not match, the signature is considered invalid and an error is generated, indicating that the request cannot be authenticated. If the hashes do match, the signature is confirmed as valid, meaning that the request content has not been altered and was signed by the holder of the corresponding private key.

[0168] Upon successful validation, the Public Key (1430) is passed to a conversion step (1434), where it is deterministically mapped to a corresponding user ID (1436). This user ID is used to establish the identity of the sender. Finally, both the verified API Request Object (1412) and the user ID (1436) are passed to the API Request Handler (1450), which processes the request on behalf of the authenticated user.

[0169] In an example embodiment, a method for cryptographically verifying an incoming API request at a server comprises receiving, by the server, a request (such as an HTTP request) comprising an API request object in the body, a digital signature in a header, and a public key in a separate header. The method includes generating, by a hashing module, a cryptographic hash of the API request object to produce a tamper-evident representation ofthe request content, and verifying, by a validator module, the digital signature by decrypting it using the provided public key, and generating a second hash value derived from the signature. The method includes comparing the generated hash of the request object with the second hash value, and rejecting the request if the hashes do not match. Upon determining that the hashes match, the method confirms the validity of the signature and authenticating the request. The method includes mapping the verified public key to a user identifier and processing the request on behalf of the corresponding user.

[0170] If the digital signature is malformed or the public key is invalid, the server may generate an error response and terminates further processing of the request. The mapping of the public key to a user identifier may be performed using a deterministic conversion function, thereby enabling traceability of the authenticated request to a specific user.

[0171] This method ensures the authenticity, integrity, and traceability of each incoming request using cryptographic verification, and provides a clear link between the request content and the verified identity of the sender.Example Embodiment: out-of-band request signing

[0172] The embodiment described above with reference to Figures 13 and 14 can be limiting when integrating this part of the method with other complementary services. Accordingly, the inventors updated the existing process to decouple signing from the http protocol allowing signing and sending to occur as two distinct actions, opening up the ability to ‘proxy’ requests through other servers and / or protocols.

[0173] The problem arises from the way cryptographic verification and user authentication have been integrated into the HTTP protocol using headers. This integration was originally efficient and convenient, as it allowed for HTTP interceptors to automatically manage user session keys — signing outgoing requests and validating incoming ones. However, because the signing operation relies on the user’s private key, it must be performed by the user’s own device. This imposes a strict requirement that users interact directly with the secure messaging system’s APIs.

[0174] This requirement becomes problematic when there is a need to send secure messaging system messages from other platforms, such as an alternative messaging platform. These external platforms cannot sign on the user’s behalf, since providing them with access to the user's private key would compromise the key’s confidentiality. At the same time, bypassing the external platform and sending secure messages directly to the secure messaging system would exclude any valuable intermediate workflows — such as mail merge, SMS campaigns, or cost estimation — that the external platform may offer. Re-implementing such features within the secure messaging system or tightly coupling the two platforms' APIs would introduce significant technical complexity and reduce future integration flexibility.

[0175] To resolve this, the inventors have found a new method, referred to here as “out-of- band request signing”. This approach separates the signing process from the act of making an HTTP request. Rather than signing requests dynamically as they are transmitted, the user prepares and signs the secure messaging payload independently. This can occur in advance, even while offline. Once signed, the self-contained payload can be transmitted using a standard HTTP request or any alternative transmission method. Because the payload contains its own cryptographic signature and verification data, it can be proxied through third-party systems without compromising authenticity. These systems may wrap the payload in their own formats or append metadata, but cannot alter the signed contents without invalidating the signature.

[0176] To support this approach, several changes were made. The HTTP interceptor that previously handled request signing was removed. Instead, a standalone client-side signing service was developed. Referring to the payload format 1500 shown in Figure 15 of the drawings, the authenticated request types were updated to accept a SignedRequest<TRequest> 1580 structure, which now includes fields — such as the sender’s public key and signature — that were previously sent as headers. Correspondingly, the authentication middleware was updated to process these self-contained SignedRequest<TRequest> payloads.

[0177] The new request structure encapsulates the SendersPublicKey 1560 and SendersSignature 1570 within the payload itself. For replay protection, the Nonce 1520 and TimeStamp 1530 fields are also included, but are grouped in a ReplayProtection 1540 structure and wrapped within a SignedRequestPayload<TRequest> 1550. The inner Request payload 1510 can be of any type, matching the expected input of the destination secure messaging endpoint. It may contain data that is or is not end-to-end encrypted. Although the payload cannot be modified without invalidating the signature, proxy platforms that are aware of the pay load format can still extract relevant metadata — such as message size or sender and recipient identifiers — for legitimate uses like routing or billing.

[0178] In one embodiment, a method of securely communicating a message between a sender and a recipient in a communications system comprises preparing, by a sender device, a message payload comprising data to be transmitted to a recipient system, and then generating, by the sender device, a digital signature for the message payload using a private cryptographic key associated with the sender. The digital signature may be generated independently of any transport-layer protocol headers. The method includes encapsulating the message payload, the digital signature, and / or a public key corresponding to the private cryptographic key into a signed message object. The signed message object may be self- contained and comprise all information required for verification of the digital signature. The method includes transmitting, from the sender device, the signed message object to the recipient system via a transport mechanism that is decoupled from the signing process, such that signing and transmission occur as separate and distinct actions. The method includesreceiving, by the recipient system, the signed message object via a transport protocol, and extracting the message payload, the digital signature, and / or the public key from the signed message object. The method may also include verifying, by the recipient system, the digital signature using the public key and the extracted message payload to confirm the authenticity and integrity of the message payload independently of any transport-layer authentication mechanisms. The decoupling of signing and transmission enables the signed message object to be transported through intermediary systems or alternative platforms that do not possess access to the sender’s private key and are unable to modify the signed message object without invalidating the signature. The recipient system and the sender device may be associated with one another, for example the recipient system and the sender device may be components of the same secure communication system.

[0179] The signed message object may be generated and signed by the sender in advance of transmission, and optionally while the sender device is offline. The signed message object may be transmitted via a standard HTTP request, or via an alternative transport protocol or communication mechanism. The signed message object may comprise a structure that includes the sender’s public key, the digital signature, and a replay protection structure including a nonce and timestamp. The signed message object may comprise a wrapped payload structure containing a generic request object (e.g., of type TRequest), enabling the request to be transmitted without reference to transport-layer headers for authentication. The signed message obj ect may be proxied through one or more intermediary systems that append metadata or encapsulate the signed message object in an alternative format, without altering the signed message object itself. A receiving system may authenticate the sender by verifying the digital signature and derives an identity or address of the sender from the sender’s public key included in the signed message object.

[0180] This architecture enables secure messaging requests to be passed through third-party platforms while preserving authentication, integrity, and accountability. However, limitations remain when features like mail merge are combined with end-to-end encryption. Since encryption requires the message content to be finalized and signed at the time of transmission, mail merge — by its nature requiring content substitution at delivery — cannot function alongside signing and encryption without modification.

[0181] Two possible approaches are proposed. One is to disallow mail merge features in modes that involve the secure messaging system. The other is to modify the mail merge functionality to operate on templates rather than finalized content. In this model, the template could be signed and encrypted, and placeholders rendered later, resulting in a message that is partially encrypted and verifiable. Given that the unverified sections would typically contain user-specific content, this may be an acceptable trade-off in many use cases.

[0182] Additionally or alternatively, the security of the message can be ensured (or in some embodiments even guaranteed), if the same encryption process is maintained throughout the process. In other words, the message is encrypted at the start of the process during thereceiving step 310, and the same encryption is maintained unchanged during each step of the communication path as the message is handed over from one stage to the next (and / or from one medium to the next), without decrypting and / or re-encrypting the message. The message is delivered 330 with the same encryption with which it starts the transmission, i.e., as applied in the receiving step 310.

[0183] In this way, for example, if the secure communication system uses very secure Elliptic-Curve Cryptography (ECC), while the transmission system incorporates (e.g., by default) a less secure encryption such as Data Encryption Standard (DES), downgrading the level of security (from ECC to DES) during the transmission step 320 is avoided.Notification

[0184] In some embodiments, the communication may comprise a notification, requesting the recipient to create a secure communications account to access the message. When a communication is sent to one or more recipients, a notification may be sent to the one or more recipients using a legacy communications system (e.g. SMS). .

[0185] The notification may be automatically generated at the server 110, e.g. using a template. The notification may include a link, selectable by a user, for generating a user ID and accessing the communication. The link may comprise a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL).

[0186] The server 110 may convert the notification from one format to another for communication on the legacy communications network. As an illustrative example, a document or message may be converted to an image format suitable for faxing prior to being forward by the fax gateway 140.

[0187] To receive the communication, the recipient follows a link in the notification (e.g. by clicking on it), which directs the recipient to the server 110, and in particular a user interface e.g., provided by a web page. Here the recipient may either create a user ID, or associate a user ID with the legacy address. This process may include verification and authentication of the recipient.

[0188] The server 110 facilitates safekeeping of messages in the data store 112 until the recipient creates an appropriate account. In some embodiments, this is achieved without requiring the sender to know whether the recipient has a user ID or not, or when the recipient creates a user ID.

[0189] In embodiments where the server 110 decrypts and re-encrypts the communication, the sender may not be required to verify that the recipient has received the message as originally sent. In some embodiments, once user IDs and public keys are shared between the sender and recipient, the recipient may re-encrypt the communication and send it back to the sender. This enables the sender to confirm that the communication received by the recipientis the same as what was sent, but also enables the communication to be stored in a shared inbox on the server 110 and / or data store 112.Method 2

[0190] Figure 4B illustrates an embodiment of a communications method 400.

[0191] At 402, a communication associated with a recipient is received on a data interface. The message and / or recipient may be associated with a legacy address, such as a phone or fax number of the recipient. At 404, the communication is stored on a data store. The data store may be accessible from the internet. At 406, a notification is sent to the recipient indicating that communication has been received. The notification is sent to the recipient using a legacy communications system (e g. SMS) and the legacy address.

[0192] The method 400 further comprises enabling the recipient to subsequently access communication that is stored on the data store using a secure communications account at 408. In case the recipient already has an account, the recipient may simply log in to their account to access their secure inbox and thereby the communication. Alternatively, the recipient may create an account and / or associate their account with the legacy address.Method 3

[0193] Refernng to Figure 11 of the drawings, a multimodal communication method 1100 comprises, at a processor, at 1110 receiving a message that includes a destination address. At 1120 a destination address type is determined. If it is determined at 1130 that the destination address type is a secure address, then at 1150 the method securely forwards an encrypted digital version of the message to the secure destination address.

[0194] Alternatively, if at 1130 it is determined that the destination address type is associated with a legacy communication network, then the method ascertains, at 1140, whether a secure address is associated with the destination address. If a secure address is associated with the destination address, then at 1150 the method securely forwards an encrypted digital version of the message to the associated secure address. Alternatively, if no associated secure address exists, then (via a suitable gateway) at 1160 the method converts the message to a message format associated with the legacy communication network and at 1170 transmits the message to the destination address via the legacy communication network.Secure Communication

[0195] In some embodiments, the type of encryption and cryptography use in the communication system includes the use of blockchain and cryptographic hashes, so that each block contains a cryptographic hash of the previous block (as well as a timestamp and transaction data).

[0196] Some embodiments use a permissions-based blockchain. Joining the blockchain network includes a verification process before being able to securely send and receive data. This promotes security and compliance when transmitting any sensitive information.

[0197] In some embodiments, the communication being sent (e g. in the form of an electronic document) is stored off-chain, while the blockchain hash referencing the communication is stored on-chain.

[0198] An event item, e.g.in the form of a hash of the communication, may be generated and stored on a blockchain, for example. This may enable verification of the communication, by comparing a hash of the communication with the hash on the blockchain, without needing to put the communication itself on the blockchain.

[0199] In one or all embodiments, once the message has been created, it is hashed, at the computing device 120 of the sender, using a known hash algorithm that takes messages and converts them to a binary string of fixed size, such that the hash is representative of the message. As an illustrative example, Secure Hash Algorithm 3 (SHA-3) may be used to generate a binary string of 224, 256, 384, or 512 bits.

[0200] Hashes of communications are then stored on a blockchain, allowing the generation of a hash using the same known hash algorithm, and comparison with the hash to verify that the communication has not been altered or replaced.

[0201] Figure 5 illustrates part of an embodiment of a communications system 500. The communications system 500 includes a server 502, which may be similar or identical to the server 110, associated with a data store 504 and blockchain 506, including a plurality of event hashes 508.

[0202] The system 500 includes an event system, to enable an audit trail of actions associated with communications to be maintained, such as the communication (e.g. message) being sent, delivered, and read. The event system includes an event source database (also referred to as an event store), which is a database architecture where data is stored as a sequence of immutable events rather than directly updating the database’s current state. Each event captures a change, action, or decision within the system, providing a historical log of all changes. This approach allows for auditability, replayability, and flexibility in querying and data modelling.

[0203] When a communication, e.g. in the form of a message, is received at the server 502, the message is stored on the data store 504 and a payload of the communication is generated, for use by an event system, as outlined elsewhere herein.

[0204] Figure 6 is a schematic representation of a message payload 600. The message payload 600 may be similar or identical to the message payloads used by the systems 100, 500.

[0205] The message payload 600 includes a message location pointer 602, which comprises a pointer (e.g. a URL) to a location on the data store 504, together with a hash of the message, and a hash of the encrypted message.

[0206] The pointer 602 points to the actual contents of the encrypted message, such as encrypted text, images, sound, files, etc.

[0207] The message payload 600 may further include a digital sender’s signature (not shown), to enable any entity to authenticate the message. In particular, the digital signature comprises a signature of the message using the sender’s private key, which can be verified using the sender’s public key, which is publicly available.

[0208] When a notification is sent to the recipient, indicating that the message is able to be accessed, a ‘sent’ event is then generated corresponding to the ‘sending’ of the message to the recipient, including the payload 600, which event item is hashed and stored on the blockchain 506 as an event hash 508.

[0209] Figure 7 illustrates an embodiment of a simplified schematic of a sent event item 700. The sent event item 700 may be similar or identical to a ‘sent’ event used by the systems 100, 500.

[0210] The sent event item 700 comprises a unique event identifier 702, an event name 704 specifying the type of event (in this case a ‘sent’ event), and a timestamp 706 relating to when the message was sent. These parameters are common across all events, as illustrated in further detail below.

[0211] The sent event item 700 further includes a transaction ID 708, a from element 710, a to element 712, a payload element 714 and a payload type 716.

[0212] The transaction ID 708 is a unique identifier used to identify a particular message. The from and to elements 710, 712 are used to identify who the message is from and who the message is to (i.e. sender and recipient). These elements may include email addresses or similar identifiers associated with public and private keys (for encryption purposes), and may be similar or identical to the user ID. The payload element 714 includes the message payload, which may be similar or identical to the message payload 600. Finally, the payload type 716 identifies how to interpret the payload, and may include version numbering, or any suitable indicator of how to interpret the payload.

[0213] Such configuration is particularly useful as it allows for easy expansion of event types (through different event names), but also expansion of payload formats through the addition of new payload types.

[0214] The sent event item 700 is then hashed, again using the known hash algorithm to generate an event hash 508, which is stored on the blockcham 506.

[0215] The recipient then accesses the server 502, and requests a copy of the message. The recipient is then provided the encrypted message, and can proceed to decrypt the message on their computing device 120 with their private key, and without needing to share their private key with the server 502.

[0216] The private key of the recipient may similarly be used for authentication with the server 502, enabling the server 502 to verify that the recipient (and not another user) has accessed the message. Alternatively, an encrypted communications channel between the sender and the server, e g. comprising transport layer security or the like, may be used to authenticate the recipient.

[0217] The recipient’s interactions with the message, including receipt thereof, are also recorded on the blockchain 506 as events. In particular, a cryptographic hash of an event associated with each interaction is generated by the server, hashed and stored on the blockchain as an event hash 508.

[0218] Figure 8 illustrates an embodiment of a delivered event item 800. The delivered event item 800 includes an event identifier 702, an event name 704 specifying the type of event (in this case a ‘delivered’ event), and a timestamp 706 relating to when the message was delivered.

[0219] The structure of the delivered event item 800 may be applied to a variety of other events, such as ‘read’ events, by simply changing the event name. Furthermore, extended structures may be provided where any suitable data is concatenated to the event, which can be recognised through the event name 704.

[0220] The blockchain 506 generally comprises a plurality of blocks, wherein event hashes 508 are stored as blocks on the blockchain 506. The blockchain 506 may, for example, comprise an Ethereum blockchain. Furthermore, while the term “blockchain” is used in singular, the skilled addressee will readily appreciate that any number of blockchains may be used together as a distributed ledger.

[0221] Figure 9 is a schematic representation of a portion of the blockchain 506.

[0222] The blockcham includes blocks 910, which are linked to each other in a chain using a blockchain hash 912, comprising a hash of the previous block. The use of a chain of hashes, comprising hashes of the previous blocks, prevents blocks 910 in the blockchain from being replaced, as this would break the chain of hashes.

[0223] The blocks 910 further include an event hash 914, comprising a hash of the message or transaction. The event hash 914 may be similar or identical to the event hash 508 of Figure 5.

[0224] When an event is initially created, the event hash 914 comprises a hash of the event, as outlined above. This enables confirmation that the event has not been modified or replaced. Furthermore, the event may include hashes of a message residing off the blockchain, thereby enabling determination that the message has not changed.

[0225] While not illustrated, the skilled addressee will readily appreciate that any suitable type of data may be stored in the blocks 910, but is not shown in the simplified schematic for the sake of clarity. For example, timestamps, headers and the like may be stored in the block and outside of the event hash 914.

[0226] The communications system 500 enables senders and recipients, respectively, to communicate with each other in a secure manner, while maintaining an auditable record on a blockchain 506. By storing hashes of messages and associated events that follow it, including those by the recipient, an audit of transactions can be made, while maintaining confidentiality of the data.

[0227] This is achievable as the users are able to identify themselves before both sending and receiving data, and that communications are encrypted end-to end, meaning that even if the server 502 is compromised, data is not leaked.

[0228] In some cases, however, messages may be sent without encryption. As an illustrative example, messages comprising non-sensitive data may be sent in un-encrypted form. In such case, the use of the blockchain 506 is still beneficial as it provides transparency and enables verification that messages have not been tampered with.

[0229] Furthermore, in addition to providing the data store 504 for storing communications, the data store 504 may be used for secure file storage. In such case, end-to-end encryption need not be used between a sender and recipient, but instead encryption to and from the data store 504 may be used. For example, AES-256 encryption may be used when communicating directly with the data store to access a file.

[0230] While the above embodiments illustrate senders and recipients connecting directly to the server 110, 502 and data store 504, in other embodiments, third party systems (not illustrated) provide access to the server 110, 502 and / or data store 504.

[0231] In one or all embodiments, the third party systems comprise Secure Message Delivery (SMD) systems in the healthcare industry. In such case, the system 100, 500 may support messages according to the Clinical Document Architecture (CD A) standard, and be used for eReferrals, specialist letters, prescriptions, lab results, diagnoses outcomes, discharge summaries and similar. The skilled addressee will, however, readily appreciate that any suitable third-party systems may be used, and in any industry, including outside of the healthcare industry.

[0232] Furthermore, in the case where third party systems are used, the various interactions described above as occurring on the computing devices 120, such as encryption, may be performed by the third-party system.

[0233] Figure 10 illustrates an embodiment of a communications method 1000. The communications method 1000 may be similar or identical to methods performed by the systems 100, 500.

[0234] At 1010, a message is generated, the message associated with one or more recipients. The message may be associated with one or more recipients using user IDs of the recipients, or other identifiers or addresses of the recipients.

[0235] The message may include various types of data, such as text, images, audio, files, etc. In one or all embodiments, the message comprises an eReferral, a specialist letter, a prescription, lab results, a diagnosis outcome, or a discharge summary. In other embodiments, the message comprises an invoice, a quote, a letter, or any other suitable document or data. The message may be encrypted. The message may be encrypted using end- to-end encryption. A sender may be authenticated prior to or upon receipt of the message therefrom. This may be performed using a digital signature of the sender, or any suitable method.

[0236] At 1020, a cryptographic hash of the message is generated. In one or all embodiments, multiple cryptographic hashes of the message are generated, including a hash of the message prior to encryption, and a hash of the message once encrypted.

[0237] The hash is generated according to a known hash algorithm, such as the Secure Hash Algorithm 3 (SHA-3) to generate a binary string of 224, 256, 384, or 512 bits. By using a known (and pre-defined) algorithm, others are able to rehash the message, and compare the hash with that generated above.

[0238] At 1030, a recipient of the one or more recipients is authenticated. This may, for example, be in response to a request from the recipient to access the message. In one or all embodiments, the recipient is notified of the presence of a message, enabling the recipient to request access to same. The recipient may be authenticated using any suitable means, including using a digital signature.

[0239] Upon authentication of the recipient, the message is delivered to the recipient at 1040. The (encrypted) message may be stored on a data store, and a link to the message may be provided to the recipient.

[0240] At 1050, an event associated with provision of the message is generated. The event includes one or more hashes of the message, an event identifier, a timestamp, and details of the sender and / or recipient(s).

[0241] At step 1060, a cryptographic hash of the event is generated, similarly using a known hash algorithm.

[0242] At step 1070, the hash is stored on the blockchain. This enables parties to independently verify that the message has been provided to the recipient.

[0243] By storing the hash on the blockchain, information from the message, as well as the senders and recipients, may remain confidential, while providing the ability to audit already known information.

[0244] The method 1000 may include validating the message using the blockchain. The message may be validated by generating a hash of the message, generating the event including the hash of the message, hashing the event, and comparing the hash of the event with a hash recorded on the blockchain.

[0245] Similarly, the method 1000 may include generating further events relating to interactions with the message, and storing hashes of same on the blockchain. These further events may be validated by regenerating the hash and comparing the hash to the corresponding value found on the blockchain.

[0246] In one or all embodiments, some of the user IDs may be published on an online directory of the system 100, 500 and publicly available to anyone. In such case, details of the recipient, such as name and other details, may be published on the directory, to enable persons to easily search for user IDs. In such case, secure communication may be initiated directly using the user ID.

[0247] However, some or all of the user IDs may be private, requiring the recipient to provide their user ID to other parties for communications. Such configuration is useful when recipients wish to minimise or avoid cold contact.

[0248] While the terms “sender”, “recipient” and “user” are used here, the skilled addressee will readily appreciate that an organisation (with multiple associated individuals) may be associated with a user ID, rather than an individual. This is particularly relevant where hospitals, pathologists, medical centres, law firms, accountancy firms, or the like communicate, which have multiple individuals (e.g. doctors, lawyers or other staff), each having access to the system f OO, 500.

[0249] While much of the above description describes a recipient either having an account or not, the skilled address will appreciate that there may be accounts with different levels of verification. As an illustrative example, a recipient may generate a basic account with only minimal verification, or a more secure account with further verification.

[0250] In such case, the sender may determine what level of account security is required to access the communication. For example, marketing may be received with a basic account, whereas sensitive health information may require a more secure account.

[0251] In such case, having an account that is not sufficiently secure may be treated much like a non-existent account (i.e. the message is held in escrow), the difference being that the more secure account need not be created from scratch.

[0252] Similarly, while the above description describes a single secure communication system, the system may integrate with a number of third-party secure communication systems. In such case, it may be determined if the legacy address is associated with a secure communications account of a secure communications system of a plurality of secure communications systems. The communications may then be sent using the secure communications system with which the legacy address is associated.

[0253] Such configuration enables the method to work with a vanety of secure communications systems, and without requiring a sender to check each of a plurality of communications systems.Example Embodiments: Workflows

[0254] Figure 16A shows a new user workflow 1610. Figure 16B shows an existing user with a new device workflow 1620. Figure 16C shows a recover from error workflow 1630.

[0255] The workflow for creating private keys and onboarding new users to the secure messaging system is designed to support strong cryptographic identity, flexible authentication models, and secure device-based key storage. This process involves coordinated interaction between the secure messaging system, a user service, and a key management service.

[0256] The system supports several authentication models. In an open model, requests to certain endpoints do not require authentication and are publicly accessible, although they may be subject to throttling to deter misuse. A verification-based model employs multi-factor authentication (MFA), in which a verification code is sent to the user via a side channel such as SMS; this code is short-lived and must be included in the request. The primary model, however, is based on cryptographic signatures. In this model, new users generate a private key (SK) on their device. From this key, a public key (PK) is derived using a one-way cryptographic function. A further one-way derivation of the public key yields a unique address (Addr) that serves as the user’s public identifier. The secure messaging APIs require that most requests be digitally signed using the user's private key. The backend verifies the signature using the corresponding public key and authorises the request by validating that it is associated with the derived address.

[0257] The sign-up and sign-in workflow begins when a user initiates registration. The secure messaging system and the user service verify that the phone number is not already registered. If not, a verification code is sent to the phone via SMS. The user’s device generates a private / public key pair, and the user service collects necessary identifying information, including a PIN provided by the user. The user’s address, phone number, and the encrypted private key — digitally signed for integrity — are then transmitted to the key service for secure registration. If the user service already has a record for the phone number, but the key service does not, the system treats the operation as a new user onboarding process. In such cases, verified ownership of the phone number via SMS permits updates to the user service record as required.

[0258] Exactly one SMS-based two-factor authentication call is required during these workflows. Under normal conditions, the user’s private key remains securely stored on their device. The device checks in with both the user service and the key service to verify that all required records exist, and can automatically initiate recovery procedures if any discrepancies are found.

[0259] On the device, private keys are stored in secure storage provided by the device’s operating system. This storage holds the private key in encrypted form, with encryption performed using the user’s PIN and a device-generated salt. Although the salt is not considered sensitive, it is also stored securely. The user’s PIN is stored in secure storage only while the app is running. Upon termination of the app, lifecycle management functions remove the PIN from storage to enhance security. Each time the private key is needed, it is decrypted from secure storage using the PIN and salt. This decryption process also serves to validate the PIN, ensuring that the user has provided correct credentials at the time of app launch. The private key is never retained in memory longer than necessary.

[0260] In some configurations, biometnc authentication is also supported. Devices with biometric sensors, such as fingerprint readers or facial recognition, provide binary authentication APIs. These can be used to gate access to the PIN. In this setup, the private key is still encrypted using the PIN and salt, but the app retrieves the PIN from secure storage only after a successful biometric check. To ensure the user retains familiarity with their PIN — especially in key recovery or new device scenarios — the system may periodically remove the PIN from secure storage, requiring the user to re-enter it. This reinforces the memorability of the PIN while maintaining a high standard of security.

[0261] Through this combination of public-key cryptography, strong device-level encryption, and layered authentication mechanisms, the secure messaging system ensures robust user identity, secure private key management, and support for interoperability across devices and sessions.Serialized Data Format

[0262] It is challenging to preserve the integrity of digitally signed API requests as they pass through backend infrastructure, particularly when those requests are signed on the client side. This issue arises from the fact that even small changes to the serialized format of the data — such as changes introduced during parsing, reserialization, or encoding — will result in a signature mismatch, rendering the request invalid when it is verified on the server side.

[0263] In the secure messaging system, where the client generates a digital signature over a serialized request payload using their private key (SK), and the server later verifies that signature using the corresponding public key (PK), it is essential that the exact byte representation of the signed data remains unchanged between signing and verification. This requirement extends to all intermediate systems, including any backend servers that transport or inspect the data. If any part of the backend modifies the serialized request — whether by reformatting ISON, altering whitespace, changing key order, or making encoding adjustments — the cryptographic signature will no longer match the payload, and the request will fail verification.

[0264] In some embodiments as described elsewhere herein, the system may employ an HMAC-style authentication process, where commands and queries are serialized to JSON on the client, signed using the sender’s private key, and then transmitted to the API endpoint with the signature and public key. Upon receipt, the server verifies the signature using the provided public key and then proceeds with access control based on the sender’s identity (“subjective” processing).

[0265] However, inconsistencies between different JSON serializer and deserializer libraries may be problematic. These libraries often differ in how they handle data formatting, key ordering, numeric precision, or whitespace. As a result, a JSON object serialized on the client may not exactly match its server-side equivalent after deserialization and reserialization, causing the signature to fail even if the semantic content remains unchanged.

[0266] To address this, the inventors explored more robust serialization techniques that could produce consistent and deterministic binary representations of data across platforms. One such approach involves binary serialization, in which objects are serialized into a compact byte array using a format that preserves strict ordering and representation. By eliminating the variability introduced by text-based serialization formats like JSON, binary serialization can ensure that the byte sequence signed on the client matches the byte sequence verified on the server, even when the message passes through backend systems.

[0267] This serialization issue fits directly into the overall architecture of the secure messaging system described herein, where digital signatures are used to ensuring message integrity, authentication, and non-repudiation. It also highlights the role of maintaining a stable data format between the point of signing and verification. Without such consistency, even well-designed cryptographic systems can fail due to mismatches in representation ratherthan true compromise or tampering. Binary serialization, when implemented carefully, offers a potential solution by producing a canonical, deterministic representation of the data that remains intact across all transmission and processing layers.

[0268] In some embodiments, the serialization problem may be addressed using MessagePack, a cross-platform binary serialization format. The goal of using MessagePack is to achieve consistent serialization and deserialization (ser / des) of API requests between the client and server, particularly to preserve the integrity of client-side digital signatures. MessagePack may be implemented for this purpose, as it provides a deterministic binary representation that avoids the inconsistencies associated with text-based formats like JSON.

[0269] However, MessagePack lacks a formal schema, meaning it does not natively enforce or validate data types or structure. This introduces a type-safety concern. In this implementation, requests are wrapped in a structure called SignedStirdieRequest, which includes metadata fields: the type of the request (RequestType), the serialized request payload (SignedPayload), the sender’s public key (SendersPublicKey), and the corresponding signature (SendersSignature).

[0270] The SignedPayload field contains the actual binary representation of the API command. To interpret it correctly, the system uses the RequestType field to determine what type of object the payload represents and how it should be deserialized. The deserialization logic (Unpack) relies on this RequestType value being accurate and trustworthy.

[0271] The key security issue is that the system implicitly trusts the RequestType field, which is not cryptographically protected against manipulation in this model. If an attacker could craft a payload with the same structure and valid signature — such that the cryptographic check passes — but falsely label it with a different RequestType, the server could deserialize the payload incorrectly. This could result in the request being misinterpreted, processed under the wrong logic, or triggering unintended behaviour.

[0272] Because the system assumes that the RequestType correctly describes the payload and uses it as a basis for deserialization, it cannot guarantee safety against malicious attempts to confuse or exploit the deserializer. This lack of guaranteed binding between the payload and its declared type introduces a potential attack surface, particularly if multiple command types share similar structure or data signatures. The conclusion is that, while MessagePack provides consistency and performance benefits, its lack of schema enforcement means additional safeguards are needed to ensure that payloads are interpreted correctly and securely.

[0273] This approach proposes a solution to the type-safety and deserialization issues that arise from using schema-less binary serialization formats — such as MessagePack — by switching to Protocol Buffers (protobuf) with a structured implementation that eliminates the need for an explicit RequestType field.

[0274] Although protobuf is commonly associated with explicit schemas defined in .proto files, the C# library protobuf-net provides flexibility by allowing schema definitions to be expressed directly in code through attribute-based annotations. This makes it possible to serialize and deserialize objects in a consistent and type-safe manner, while still benefiting from protobuf s compact and deterministic binary format.

[0275] In the proposed mechanism, the serialized payload includes not only the request data but also type information, removing the need to separately pass a RequestType property. The new structure, SignedStirdieProtobufRequest, contains three fields: the SignedPayload (a bmary-en coded object), the sender’s public key, and the sender’s signature. The key difference is that the type of the request is now embedded within the payload itself, ensuring that deserialization can occur safely without relying on an external string identifier that could be manipulated or spoofed.

[0276] The SignedPayload holds an instance of SignedProtobufRequestPayload, which includes both the actual request object and a Repl ay Protection object used to mitigate replay attacks. The request object must implement the IStirdi eRequest interface — a marker interface with no methods — used to constrain and identify valid request types during serialization and desenahzation. While C# typically uses attributes for such purposes, in this case, an interface is required to provide better control over the types permitted in the protobuf payload and to support runtime serialization logic.

[0277] Protobuf serialization is performed using the protobuf-net library. There are multiple ways to achieve this: developers can annotate each request class with [ProtoContract] and its properties with [ProtoMember(n)] attributes, allowing the built-in Serializer. SerializeQ method to convert objects to binary form. Alternatively, they can define a custom type model using RuntimeTypeModel.Create() to manage serialization behavior, or take the traditional “model first” route by defining a .proto schema and generating C# classes using the protoc compiler.

[0278] By embedding type information directly into the serialized payload and relying on a well-defined set of protobuf-annotated request classes, this approach avoids the vulnerabilities introduced by external type references and inconsistent JSON handling. It ensures that payloads are deserialized accurately and securely, while preserving the clientside digital signature verification process.

[0279] There are a number of technical considerations involved in serializing and deserializing API requests within a microservice architecture, specifically in the context of the secure communication system. The objective is to serialize a request in such a way that the specific type of command or query it represents is preserved within the serialized payload itself.

[0280] While it is technically feasible to implement such functionality, doing so would require a degree of coupling that exceeds the intended scope of responsibility for a given component. More specifically, the "common request" interface — intended to be generic and reusable — would need to be aware of every possible command and query implemented across all Stirdie microservices. This would undermine modularity, introduce tight coupling between services, and complicate maintainability.

[0281] To avoid this, the design evolves along a different path. Rather than relying on a marker interface (an interface without methods, used only for type identification), the IStirdieRequest interface is extended to include responsibility for its own encoding and decoding. It now explicitly defines two instance methods: EncodeQ, which returns a byte array representing the serialized form of the request, and Decode(byte[] encoded), which populates the instance’s properties from the provided byte array. This change enables each request type to manage its own serialization logic, preserving autonomy and avoiding centralized knowledge of all request types.

[0282] The language features of C# impose further constraints. Although C# supports abstract static methods in interfaces, allowing the declaration of a method such as public static abstract IStirdieRequest Decode(byte[] encoded), this feature is available only in preview at the time of investigation and not supported in stable releases. Static interface methods without default implementations are also not supported in earlier versions, such as C# 8 under .NET Standard 2.1, which was the relevant environment.

[0283] As a result, the approach taken for deserializing a request involves two steps. First, an instance of the target request type is created. Then, the instance’s DecodeQ method is invoked, using the serialized byte array as input, to populate the request object with its original values. This preserves type safety, decentralizes responsibility for serialization, and avoids leaking implementation details across service boundanes.

[0284] In some embodiments, cross-platform binary serialization may be achieved using Protocol Buffers (Protobuf). In some example embodiments, the data models are first defined using proto files — Protobuf s schema definition language — before being used to generate serialization code for both C# and TypeScript implementations. The primary objective of this approach is to achieve consistent and platform-agnostic binary serialization, which is particularly important for use cases such as binary request signing, where even slight inconsistencies in serialization can invalidate cryptographic signatures.

[0285] In this model, the structure of data is defined — such as messages, commands, or queries — in .proto files. These schema files are then used to generate language-specific classes: for C#, using tools like protoc and relevant NuGet packages (Google. Protobuf, Grpc.Tools), and for TypeScript, using npm packages such as protobufjs and protobuf] s-cli. The configuration steps for each language are also outlined: for TypeScript, .proto files are placed in a src / proto directory and converted into JavaScript and TypeScript definition filesvia npx pbjs and npx pbts commands. The TypeScript usage pattern involves creating message instances (e.g., PtReplay Protection), serializing them into Uint8 Array using serializeBinary(), and deserializing them with deserializeBinary().

[0286] In C#, the same proto file is used to generate classes via the protoc compiler, and the generated files are compiled as part of the project. Developers must configure project settings in .csproj, specifying that the .proto files should be compiled with the protobuf compiler, and defining options like class accessibility and whether to generate gRPC stubs. In C#, message instances are serialized into byte arrays using WriteToQ with a MemoryStream and deserialized using ParseFromQ through the class's static Parser property.

[0287] An additional technique may be used for dynamic deserialization where the specific Protobuf type is not known at compile time. A helper class (ProtobufHelper) is introduced that uses reflection to dynamically locate and invoke the ParseFromQ method. This enables runtime deserialization based on the type name, which is helpful in systems where the payload type is determined dynamically (e.g., when it is embedded in a signed wrapper).

[0288] The approach also supports modular and maintainable project structure, with .proto files stored near where their corresponding commands or queries are first defined, typically within microservice API projects. In C#, the files can be included in projects using the csproj feature "Add as Link", allowing the physical file location to be separate from its logical appearance in the proj ect explorer.

[0289] The .proto schema used as an example is involves a message called PtReplayProtection containing a string nonce and an int64 timestamp, which are typically used to guard against replay attacks.

[0290] In this way, a fully defined, language-neutral serialization workflow that maintains cryptographic integrity, supports versioning and modularity, and accommodates dynamic typing when required is achieved.

[0291] In some embodiments, the system may implement s signed API endpoints within the Transactions Microservice using a structured Protobuf-based approach. Each of these endpoints accepts a uniform input format, defined as a ProtobufSignedRequest object. This object is serialized using Protocol Buffers, then encoded as a Base64 UTF-8 string for transport. The design ensures consistent request formatting across multiple endpoints while supporting cryptographic signing and verification.

[0292] The ProtobufSignedRequest includes three principal components. The RequestType field specifies the class name of the underlying request object. The Request field contains the serialized request payload, also encoded in Base64. The ReplayProtection field holds a nonce and a timestamp, which are used to prevent replay attacks and ensure the uniqueness of each incoming request. The system authenticates each request by verifying the digital signatureagainst the binary payload and the sender’s public key, thereby ensuring both integrity and authenticity.

[0293] The Protobuf SignedReques t is a structured, self-contained message format used in a secure communication system to encapsulate a cryptographically signed API request. It ensures authenticity, integrity, and protection against replay attacks, even when the request is transmitted across potentially untrusted or intermediary systems. The request is serialized using Protocol Buffers, which provides a compact, deterministic, and cross-platform representation of the data. This serialization approach avoids the inconsistencies and vulnerabilities associated with text-based formats such as JSON.

[0294] A Protobuf SignedReques t typically contains a signed payload, a public key, and a digital signature. The signed payload is a binary-encoded representation of the actual command or query being sent, and may include additional fields such as a nonce and timestamp to prevent replay attacks. The public key is the key corresponding to the private key used to generate the signature and is provided so the server can verify the message’s authenticity. The digital signature is generated by hashing the signed payload and encrypting the hash with the sender’s private key. This signature binds the payload to the sender and ensures that any modification to the message after signing will cause verification to fail.

[0295] Unlike systems that rely on external metadata — such as request type fields passed in headers — the Protobuf SignedReques t embeds all required information directly in the payload. This prevents type-spoofing and deserialization errors that could otherwise result in incorrect or unauthorized processing. By using schema-based binary serialization and embedding type information within the signed data, the format supports secure, type-safe deserialization without requiring the server to rely on unverified external fields. The Protobuf SignedRequest enables consistent and secure request processing across environments, making it particularly suitable for distributed systems that require strong cryptographic guarantees and structured message handling.

[0296] To support this structure, the system embeds the request type within the payload, enabling dynamic deserialization. As a result, the system can theoretically route all signed requests through a single, generic endpoint. Upon receipt, the embedded RequestType and payload allow the server to deserialize the request into its specific type and dispatch it using a mediator-based mechanism (e.g., MediatR) to the appropriate handler. This approach allows the use of a shared controller method, such as PerformRequest, to standardize request processing.

[0297] However, the system intentionally avoids using a single universal endpoint for all request types. One reason is that each request typically returns a different type of response. For example, a “Send” request may return a transaction identifier, while a “GetConversationsPaged” request returns a list of conversations. Clients — particularly those generated from service definitions — depend on knowing the exact return type of eachendpoint. Using distinct, explicitly typed endpoints ensures correct client-side deserialization and avoids ambiguity in interpreting responses.

[0298] The system also identifies a critical security concern associated with routing multiple request types through a single endpoint. If access controls are based solely on the endpoint path, it is possible for a client with permission to access one request type (e.g., “Send”) to submit a different, unauthorized request (e.g., “GetConversationsPaged”) to the same endpoint. Since the request type is declared within the payload, the server may inadvertently process an unauthorized command unless additional checks are performed. While this risk can be mitigated by validating that the desenahzed request type matches the expected type for the endpoint, such validation must be implemented explicitly. The system design recognises that this introduces the potential for human error or omissions in enforcement, which could lead to injection attacks.

[0299] Accordingly, the system adopts a design that uses consistent Protobuf-based request signing while preserving separate, clearly defined endpoints for each operation. This approach balances the benefits of standardized request handling with the need for precise response typing and robust access control.

[0300] In an example embodiment, a method for cryptographically secure transmission and deserialization of signed API requests in a distributed system comprises serializing a request object into a deterministic binary format using Protocol Buffers. The serialized payload may include embedded type information. The method include generating a digital signature of the serialized payload using a private key associated with a client. The method includes transmitting the signed payload to a server as part of a self-contained message format (for example a ProtobufSignedRequest as described herein), the self-contained message format comprising the binary-encoded signed payload, the sender’s public key, and / or the digital signature. The method comprises verifying, at the server, the digital signature using the public key to confirm the authenticity and integrity of the received payload, and deserializing the request object using the embedded type information in the signed pay load. Deserialising may occur without reference to an external RequestType field. The method includes processing the request based on the deserialized type, thereby maintaining cryptographic validity across platform boundaries and eliminating signature mismatches caused by inconsistent serialization.

[0301] The signed payload may further include a Replay Protection object comprising a nonce and a timestamp. The server may reject replayed requests based on the uniqueness of the nonce and / or the validity of the timestamp within a defined time window.

[0302] The request object may conform to an interface that includes explicit Encode ( ) and Decode ( byte [ ] encoded ) methods for binary serialization and deserialization, respectively.

[0303] The embedded type information in the payload may enable dynamic deserialization using reflection, allowing for runtime type identification and / or parsing based on the binary content.

[0304] The Protocol Buffers schema for at least one of the request types may be defined in . proto files and / or compiled into language-specific classes in multiple client and server environments as described herein, thereby supporting cross-platform compatibility and / or consistent serialization.

[0305] The self-contained message format (e.g. a ProtobufSignedRequest) may be encoded as a Base64 UTF-8 string to support transport over HTTP and / or other protocols that are not binary-safe.

[0306] The system may verify that the deserialized type of the request matches the expected type for a given endpoint, thereby preventing inj ection attacks wherein a client could submit unauthorized requests by exploiting type mismatches.

[0307] Separate and / or explicitly typed endpoints may be used for the request types, thereby enabling client systems to correctly interpret return types, and / or thereby maintaining the enforceability of endpoint-specific access controls.

[0308] Every signing and deserialization operation may be auditable and logged to provide a verifiable history of message transmission and integrity verification.Advantages

[0309] The secure communication system described herein provides several significant advantages over typical existing communication systems, particularly in environments requiring high levels of data integrity, authenticity, auditability, and interoperability.

[0310] End-to-End Cryptographic Integrity: The system maintains a persistent digital signature from message preparation through transmission to final delivery. This ensures that any tampering or unauthorized modification — whether in transit or at rest — can be detected, as even minor changes will invalidate the signature. This contrasts with traditional systems that may rely on transport-layer security (e.g. TLS), which does not persist beyond the channel session.

[0311] Transport- Layer Independence and Interoperability: By decoupling the signing process from transport mechanisms, the system supports transmission through untrusted or semi-trusted intermediaries, including third-party platforms or public networks. The signed payloads remain verifiable regardless of how or where they are transmitted, offering significant flexibility and robustness compared to systems that rely on point-to-pomt secured sessions.

[0312] Cross-Platform, Deterministic Serialization: The use of Protobuf or similar schema-based binary serialization ensures a consistent byte-level representation of data across different client and server environments. This eliminates signature failures caused by inconsistencies in JSON serialization (e.g., key ordering or whitespace), which are common in conventional systems and present a challenge in cryptographically signed workflows.

[0313] Embedded, Type-Safe Message Structures: By embedding type information within the signed payload and enforcing strict serialization schemas, the system avoids reliance on external metadata such as request type fields, which are vulnerable to manipulation. This enhances security and correctness during desen ahzation, reducing the nsk of injection attacks and misrouted requests.

[0314] Replay Attack Protection and Temporal Validation: The system incorporates both timestamps and nonces in its Repl ay Protect! on structure, enabling reliable prevention of replay attacks without relying solely on session tokens. This provides a stateless yet secure model well suited to distributed, asynchronous, or offline-capable environments.

[0315] Verifiable Audit Trail and Traceability: Each cryptographic operation — signing, verifying, encrypting, decrypting — is structured in a way that can be logged and audited. This provides a clear chain of custody for every message, request, or transaction, meeting stringent regulatory and compliance requirements often lacking in standard communication systems.

[0316] Collectively, these advantages deliver a highly secure, adaptable, and verifiable communication framework ideal for sectors such as healthcare, law, finance, and government, where trust, auditability, and data integrity are critical.

[0317] Advantageously, the multi-channel messaging platform described herein facilitates digital transformation by supporting a transition away from legacy messaging. The hybrid approach to messaging provides a pathway for organisations to make the shift from legacy communications, like fax and SMS, to secure messaging applications audited by blockchain, without being in sync with every other organisation in the industry.

[0318] The system automatically routes messages based on the recipients preferred form of message delivery, and also provides integration with a secure framework for data transactions and verified identity management audited by blockchain.

[0319] The systems and methods described can be used even where there are users who continue to use legacy messaging channels with verified messages and secure files sent digitally, while fax and SMS are also supported. In some embodiments, an SMS and / or verified digital message may be sent. In some embodiments, a fax and / or a secure digital file may be sent. Messages sent digitally provide an end-to-end encrypted messaging solution via tamperproof messaging, with all actions (including when a message is sent, delivered, opened and more) audited by blockchain.

[0320] The methods and systems described are configured to convert fax communication into digital files, thereby ensuring privacy and accountability of data through secure end-to- end encrypted digital file transfer, audited by blockchain.

[0321] Fax numbers are associated with user IDs so that secure digital files can be sent instead of a fax. In this way, insecure fax document transmissions are avoided, and instead secure digital file transfers are made. Secure digital transmission cuts out the fax provider and carrier, reducing costs and unreliability due to reliance on third parties. All secure digital files are encrypted end-to-end, ensuring the sender and intended recipient are the only ones able to view the document. Both sender and recipient have access to an audit trail of information, from when the document was sent, received, delivered and more.

[0322] In summary, a user is assigned a user ID and associates their fax number with the user ID. The user uploads a file and sends the file using the recipient’s fax number. The system inputs the fax number and determines the associated user ID, and then sends the file as a secure digital file via a secure file transfer data sharing method that uses secure protocols and encryption to safeguard data in transit (e.g., an industry-standard protocol that provides encrypted file transfer, such as SFTP, FTPS, HTTPS, and AS2, etc.) If no user ID is associated with the recipient fax number, the file is sent via fax.

[0323] Users of the system can associate their phone numbers with their user ID, enabling secure, private messaging between users via a verified messaging network audited by blockchain. This connection allows users to securely communicate through an end-to-end encrypted mobile messaging app.

[0324] Users can send verified messages to other users that have connected their mobile number to a user ID. In this way insecurities and fraud associated with SMS can be removed, providing users with a trustworthy and tamperproof messaging app.

[0325] When sending a verified message the SMS provider and carrier are avoided, improving security and reliability of messages. All verified messages are encrypted end-to- end, ensuring the sender and intended recipient are the only ones able to view the document. Both sender and recipient have access to an audit trail of information, from when the message was sent, received, delivered and more.

[0326] In summary, a user is assigned a user ID, and associates their phone number with their user ID. When an SMS message is sent using the messaging application described, the system determines whether the recipient mobile number is associated with a user ID. If so, the message is sent as a verified message to the user’s account (accessible via e.g., mobile app, desktop, web application, etc ). If not, the message is sent via conventional SMS. Secure digital messages sent can be audited

[0327] Blockchain technology ensures privacy and auditability. Every action from when a secure file or verified message is sent, delivered, read and more are ciyptographically hashed and stored on the blockchain. This cryptography generates a complete audit trail of actions, ensuring safety of confidential information and meeting compliance standards across various industries such as healthcare and finance.

[0328] Advantageously, the methods and systems described herein enable automatic (smart) routing of communications associated with legacy address (e.g. SMS or fax) to secure communications systems, where available, while communications may be sent using legacy communications systems otherwise. The configurations described herein allow a recipient of a communication who does not yet have a secure communications account to be notified using legacy communications. The recipient may then create a secure communications account to access the communication.

[0329] This may in turn simplify the process for transitioning from legacy communications systems in a seamless manner, communications may be generated in the same manner regardless of how they are ultimately received.

[0330] Furthermore, the methods and systems enable users to select what sort of communications they send on legacy (insecure) systems. For example, in case of sensitive communications, the user may require that secure communications are used to retrieve the message, and in such case a notification is provided on the legacy system (the notification not including the sensitive information).

[0331] Advantageously, the methods and systems described above enable communications to be held in escrow until the recipient creates a secure communications account, at which time they may access the communications in a secure manner. This further alleviates the need for a sender to keep track of whether a user has created a secure communications account or not.

[0332] This is particularly useful when a secure communications system is being deployed, as it alleviates the need to know account details for other users, and in particular users that have not yet created a secure communications account.

[0333] Furthermore, the methods and systems described above enable confidentiality, auditability and authentication to be provided when parties communicate data, such as documents or other communications, with each other remotely.

[0334] By storing the cryptographic hash of the message interactions on the block chain, an immutable record of the message activity is able to be provided, without storing or disclosing the message on the blockchain. This may in turn enable auditing to be performed in a transparent manner, without compromising the data of the message.

[0335] By enabling every action to be validated on the blockchain through a peer-to-peer network, sensitive data may be sent and received without the risk of data tampering, which in turn breaks down the barriers of distrust.

[0336] Furthermore, the methods and systems may be used with end-to-end encryption, meaning that even if there is a leak and / or other compromise of a server of the system, sensitive data will not be leaked.

[0337] Reference throughout this specification to ‘one embodiment’ or ‘an embodiment’ means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearance of the phrases ‘in one embodiment’ or ‘in an embodiment’ in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[0338] It will be understood to persons skilled in the art of the invention that many modifications may be made without departing from the spirit and scope of the invention.EXAMPLE EMBODIMENTS:1. A multimodal communications method comprising: receiving (1110), on a data interface of a server, a communication associated with a recipient, the recipient associated with a legacy address (1130); determining, using a processor of the server, whether the legacy address is associated with a secure communications account (1140); and upon determining that the legacy address is associated with a secure communications account, sending (1150), on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.2. The method of clause 1 further comprising: upon determining (1140) that a further legacy address is not associated with a secure communications account, sending the communication, or a denvative thereof, to a further recipient using a legacy communications system (1170) and the further legacy address.3. The method of clause 1 or clause 2, further comprising enabling the recipient to generate the secure communications account.4. The method of any one of the preceding clauses, further comprising: determining that the legacy address is not associated with a secure communications account, wherein the notification includes instructions regarding how to generate a secure communications account.5. The method of any one of the preceding clauses further comprising: upon determining that a further legacy address is not associated with a secure communications account, sending a notification communication to a further recipient indicating that the communication has been received, using the legacy communications system and the further legacy address.6. The method of any one of the preceding clauses, wherein the communication comprises one or more of: a message, text, images, a combination of text and images, documents, audio, and electronic files.7. The method of any one of the preceding clauses, comprising converting (1160) the communication from one format to another.8. The method of clause 7, wherein the converting comprises converting an image format suitable for faxing to a document format suitable for display on a computing device.9. The method of any one of the preceding clauses, comprising generating the notification communication, wherein the notification communication may comprise one or more of: a text message, a fax message, an email communication, and a physical communication.10. The method of any one of the preceding clauses, wherein the notification communication comprises a link to a secure communications system, wherein the link is selectable by the user and comprises a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL).11. The method of clause 10, wherein the notification communication is, at least partly, automatically generated.12. The method of any one of the preceding clauses, wherein the recipient is authenticated when requesting the communication using a key associated with the recipient, wherein the key comprises a key of a public / private key pair.13. The method of any one of the preceding clauses, wherein the legacy address comprises one or more of: a telephone number, a fax number, an email address, and a street address.14. The method of any one of the preceding clauses, comprising determining (1120) a type of legacy communication, wherein communications are sent using a selected legacy communications system of a plurality of legacy communications systems according to the determined type of communication.15. The method of any one of the preceding clauses, comprising: verifying an identity of the recipient; and generating the secure communications account upon verifying the identity of the recipient.16. The method of any one of the preceding clauses, wherein the communication is encrypted, and wherein the method comprises decrypting the received communication, and subsequently encrypting the communication using a key associated with the secure communications account.17. The method of clause 16, wherein the decrypting of the communication at the server is performed on initial communication, and wherein subsequent communication is encrypted end-to-end.18. The method of clause 16 or clause 17, wherein communications re encrypted using one or more of: a key of the recipient, a key of a sender, and a shared secret generated using keys of the sender and the recipient.19. The method of any one of the preceding clauses, comprising encrypting the communication prior to being received by a server.20. The method of any one of the preceding clauses, comprising encrypting, at a computing device of a sender, a message.21. The method of any one of the preceding clauses, comprising end-to-end encryption between a sender and the recipient.22. The method of any one of the preceding clauses, comprising associating a sender with a secure communications account, wherein an identity of the sender is verified by the system, and the identity of the sender is authenticated using a key associated with the sender.23. The method of any one of the preceding clauses, comprising determining (1140) that the legacy address is associated with a secure communications account of a secure communications system of a plurality of secure communications systems, wherein the communication on the data store is associated with and / or sent (1150) using the secure communications system.24. The method of clause 23, further comprising authenticating the recipient, wherein the communication is provided to the recipient upon authenticating the recipient, wherein the recipient is authenticated using a digital signature generated using public key private key cryptography, and wherein the digital signature comprises an electronic, encrypted stamp of authentication.25. The method of any one of the preceding clauses, comprising authenticating the sender using a digital signature generated using public key private key cryptography, wherein the digital signature comprises an electronic, encrypted stamp of authentication.26. The method of any one of the preceding clauses, wherein: the sender and receiver are associated with user identifiers (IDs); wherein public and private keys are associated with the user IDs; and the sender and receiver are verified prior to allocation of a user ID using one or more of a phone number, a fax number, and an email address.27. The method of any one of the preceding clauses, comprising receiving identity documents of the sender and / or recipient, and performing an identity check based thereon.28. The method of any one of the preceding clauses, comprising storing at least part of the communication on a data store in an encrypted manner using AES-256 encryption.29. The method of any one of the preceding clauses,, wherein the server (110) comprises one or more server devices collaborating to function as a server, wherein the one or more server devices comprise multiple computing devices operating in a cloud environment.30. The method of any one of the preceding clauses, comprising generating, using the at least one processor, a cryptographic hash of at least part of the communication, wherein the cryptographic hash, or a derivative thereof, is stored, on a blockchain.31. The method of any one of the preceding clauses, comprising generating an event item relating to the communication, wherein a cryptographic hash of the event item is stored on the blockchain,.32. The method of clause 31 , wherein the communication is encrypted, and the event item comprises a cryptographic hash of the encrypted communication.33. The method of clause 31 or 32, wherein the event item comprises one or more of: a timestamp, and a unique event identifier.34. The method of any one of clauses 31 to 33, comprising generating event items relating to interactions with the communication.35. The method of clause 34, wherein the interactions comprise: delivering a communication to a recipient; the recipient viewing a communication; the recipient sharing a communication; and validating one or more interactions with a message using the blockchain.36. The method of any one of clauses 31 to 35, wherein the event item comprises or is associated with metadata comprising one or more of: timestamp data, a sender identifier, and a recipient identifier.37. The method of clause 35, comprising validating the message by regenerating the cryptographic hash.38. A communications system (100) comprising: at least one computing device (200) comprising: a data interface (240); a processor (210) coupled to the data interface; and a memory (230), coupled to the processor (210), the memory including instruction code executable by the processor for: receiving (1110), on the data interface (240), a communication associated with a recipient, the recipient associated with a legacy address; determining (1140), using the processor, whether the legacy address is associated with a secure communications account; and upon determining that the legacy address is associated with a secure communications account, sending (1150), on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.39. The communication system of clause 39, wherein the instruction code, when executed by the processor, includes instructions for: storing the communication on a data store (112); sending a notification to the recipient, using a legacy communications system and the legacy address, indicating that the communication has been received; and enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.40. A non-transitory computer-readable medium including instruction code stored thereon, the instruction code when executed by one or more processors, cause the one or more processors to: receive, on a data interface, a communication associated with a recipient, the recipient associated with a legacy address; determine, using a processor, whether the legacy address is associated with a secure communications account; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a denvative thereof, to the recipient.41. A non-transitory computer-readable medium including instruction code stored thereon, the instruction code when executed by one or more processors, cause the one or more processors to: receive, on a data interface, a communication associated with a recipient, the recipient associated with a legacy address; store the communication on a data store; send a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enable the recipient to subsequently access the communication that is stored on the data store using a secure communications account.42. A multimodal communication method comprising: at a processor (210): receiving (1110) a message comprising a destination address; determining (1120, 1130) that a destination address type is associated with a legacy communication network; based on the determination, ascertaining (1140) whether a secure address is associated with the destination address; and if a secure address is associated with the destination address, then securely forwarding (1150) an encrypted digital version of the message to the associated secure address; or if no associated secure address exists, then converting (1160) the message to a message format associated with the legacy communication network and transmitting (1170) the message to the destination address via the legacy communication network.

Claims

CLAIMS1. A method of securely communicating a message in a communication system, the method comprising: receiving, by a secure messaging platform, a message at a receiving step, wherein the receiving step includes at least one of: confirming that the message is secure, encrypting the message, confirming that the message includes a digital signature, or generating and associating a digital signature with the message and its sender; transmitting, by the secure messaging platform, the message at a transmission step, wherein the message is re-encrypted using a transmission-specific encryption key and digitally signed using a transport-layer digital signature; delivering, by the secure messaging platform, the message at a delivery step, wherein the transport-layer signature and encryption are removed and the message is re-encrypted and re-signed using system-native cryptographic mechanisms; wherein the message is maintained in a cryptographically secure state during each step, and wherein each encryption and signing operation is logged to enable end-to-end auditability of the message through the receiving, transmission, and delivery steps.

2. The method of claim 1, wherein the message is cryptographically bound to the sender at the receiving step using a native digital signature that uniquely identifies the sender.

3. The method of claim 1 or claim 2, wherein the transmission step comprises unwrapping the system-native signature and encryption and applying a transportspecific encryption and digital signature for transmission through a semi-trusted or untrusted network.

4. The method of any one of the preceding claims, wherein the delivery step includes applying or reapplying a system-native digital signature and encryption to return the message to the trust domain of the secure messaging platform prior to recipient access.

5. The method of any one of the preceding claims, wherein the delivery step includes verifying the authenticity and integrity of the message and facilitating its decryption using credentials associated with the intended recipient.

6. The method of any one of the preceding claims, wherein each signing and encryption operation at the receiving, transmission, and delivery steps is recorded in a cryptographically verifiable audit log to provide a complete chain of custody for the message.

7. A method of securely communicating a message between a sender and a recipient in a communications system, the method comprising: preparing, by a sender device, a message payload comprising data to be transmitted to a recipient system; generating, by the sender device, a digital signature for the message payload using a private cryptographic key associated with the sender, wherein the digital signature is generated independently of any transport-layer protocol headers; encapsulating the message payload, the digital signature, and a public key corresponding to the private cryptographic key into a signed message object, wherein the signed message object is self-contained and comprises all information required for verification of the digital signature; transmitting, from the sender device, the signed message object to the recipient system via a transport mechanism that is decoupled from the signing process, such that signing and transmission occur as separate and distinct actions; receiving, by the recipient system, the signed message object via a transport protocol, and extracting the message payload, the digital signature, and the public key from the signed message object; verifying, by the recipient system, the digital signature using the public key and the extracted message payload to confirm the authenticity and integrity of themessage payload independently of any transport-layer authentication mechanisms; wherein the decoupling of signing and transmission enables the signed message object to be transported through intermediary systems or alternative platforms that do not possess access to the sender’s private key and are unable to modify the signed message object without invalidating the signature.

8. The method of claim 7, wherein the signed message object is generated and signed by the sender in advance of transmission, and optionally while the sender device is offline.

9. The method of claim 7 or claim 8, wherein the signed message object is transmitted via a standard HTTP request, or via an alternative transport protocol or communication mechanism.

10. The method of any one of claims 7 to 9, wherein the signed message object comprises a structure that includes the sender’s public key, the digital signature, and a replay protection structure including a nonce and timestamp.

11. The method of any one of claims 7 to 10, wherein the signed message object comprises a wrapped payload structure containing a generic request object of type TRequest, enabling the request to be transmitted without reference to transport-layer headers for authentication.

12. The method of any one of claims 7 to 11, wherein the signed message object is proxied through one or more intermediary systems that append metadata or encapsulate the signed message object in an alternative format, without altering the signed message object itself.

13. The method of any one of claims 7 to 12, wherein a receiving system authenticates the sender by verifying the digital signature and derives an identity or address of the sender from the sender’s public key included in the signed message object.

14. A data processing system comprising means for carrying out the method of any one of the preceding claims.

15. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any one of claims 1-13.

16. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1-13.

17. A method of authenticating requests in a secure messaging system, the method comprising: constructing, by a client device, a request object comprising data to be transmitted to a server; generating, by the client device, a cryptographic hash of the request object; generating a digital signature by encrypting the cryptographic hash using a private cryptographic key associated with the client, transmitting, from the client device to the server, an HTTP request comprising the request object in the body, and including the digital signature and a public key corresponding to the private key in the headers; receiving, by the server, the HTTP request and verifying the digital signature using the public key; upon successful verification, deriving the client’s identity from the public key and processing the request on behalf of the authenticated client; wherein the method does not rely on login sessions or token-based tracking, and provides cryptographic guarantees of authenticity, integrity, and non-repudiation.18 The method of claim 17, wherein any modification to the request object after the digital signature is generated causes the digital signature verification to fail, thereby ensuring message integrity.

19. The method of claim 17 or claim 18, wherein the server rejects any request in which the digital signature does not correspond to the request object and public key, thereby preventing impersonation.

20. The method of any one of claims 17 to 19, further comprising defending against man-in-the-middle attacks by ensuring that any modification to the request by an intermediary results in a failed signature verification.

21. The method of any one of claims 17 to 20, further comprising including a timestamp in the request object, and rejecting, by the server, any request in which the timestamp falls outside a specified allowable time window, thereby mitigating replay attacks.

22. The method of claim 21, further comprising including a unique nonce in each request object and maintaining, by the server, a record of used nonces within the allowable time window, wherein the server rejects any request containing a duplicate nonce.

23. A method for securely signing and transmitting an authenticated API request from a client to a server, the method comprising: receiving or generating, by a client device, a cryptographic key pair comprising a private key and a corresponding public key; generating a cryptographic hash of an API request object using a hashing module, the hash representing a fixed-length, tamper-evident representation of the request object; generating a digital signature by encrypting the cryptographic hash using the private key via a signer module; constructing an HTTP request comprising the API request object as a request body, and including the digital signature and the public key in headers; transmitting the HTTP request to a server; wherein the server verifies the digital signature using the public key to confirm that the API request object has not been altered and that it originates from the holder of the corresponding private key.

24. The method of claim 23, wherein the API request object is optionally provided to the hashing module both for generating the cryptographic hash and for inclusion in theHTTP request body, thereby ensuring consistency between the signed data and the transmitted request.

25. The method of claim 23 or claim 24, wherein the digital signature and public key are added as separate HTTP headers in the request, enabling the server to perform authentication and integrity verification independently of any session or token-based mechanism.

26. A method for cryptographically verifying an incoming API request at a server, the method comprising: receiving, by the server, an HTTP request comprising an API request object in the body, a digital signature in a header, and a public key in a separate header; generating, by a hashing module, a cryptographic hash of the API request object to produce a tamper-evident representation of the request content; verifying, by a validator module, the digital signature by decrypting it using the provided public key, and generating a second hash value derived from the signature; comparing the generated hash of the request object with the second hash value, and rejecting the request if the hashes do not match; upon determining that the hashes match, confirming the validity of the signature and authenticating the request; mapping the verified public key to a user identifier and processing the request on behalf of the corresponding user.

27. The method of claim 26, wherein if the digital signature is malformed or the public key is invalid, the server generates an error response and terminates further processing of the request.

28. The method of claim 26 or claim 27, wherein the mapping of the public key to a user identifier is performed using a deterministic conversion function, thereby enabling traceability of the authenticated request to a specific user.

29. A method for cryptographically secure transmission and deserialization of signed API requests in a distributed system, the method comprising serializing a request object into a deterministic bmaiy format using Protocol Buffers, wherein the serialized payload includes embedded type information; generating a digital signature of the serialized payload using a private key associated with a client; transmitting the signed payload to a server as part of a self-contained message format, the self-contained message format comprising the binary-encoded signed payload, the sender’s public key, and the digital signature; verifying, at the server, the digital signature using the public key to confirm the authenticity and integrity of the received payload; deserializing the request object using the embedded type information in the signed payload without reference to an external type field; and processing the request based on the deserialized type, thereby maintaining cryptographic validity across platform boundaries and eliminating signature mismatches caused by inconsistent serialization.

30. The method of claim 29, wherein the signed payload further includes a Replay Protection object comprising a nonce and a timestamp, and wherein the server rejects replayed requests based on the uniqueness of the nonce and the validity of the timestamp within a defined time window.31 . The method of claim 29 or claim 30, wherein the request object conforms to an interface that includes explicit Encode() and Decode(byte[] encoded) methods for binary serialization and deserialization, respectively.

32. The method of any one of claims 29 to 31, wherein the embedded type information in the payload enables dynamic deserialization using reflection, allowing for runtime type identification and parsing based on the binary content.

33. The method of any one of claims 29 to 32, wherein the Protocol Buffers schema for each request type is defined in .proto files and compiled into language-specific classesin multiple client and server environments, thereby supporting cross-platform compatibility and consistent serialization.

34. The method of any one of claims 29 to 33, wherein the self-contained message format is encoded as a Base64 UTF-8 string to support transport over HTTP and other protocols that are not binary-safe.

35. The method of any one of claims 29 to 34, wherein the system verifies that the deserialized type of the request matches the expected type for a given endpoint, thereby preventing injection attacks wherein a client could submit unauthorized requests by exploiting type mismatches.

36. The method of any one of claims 29 to 35, wherein separate and explicitly typed endpoints are used for each request type, enabling client systems to correctly interpret return types and maintaining the enforceability of endpoint-specific access controls.

37. The method of any one of claims 29 to 36, wherein every signing and deserialization operation is auditable and logged to provide a verifiable history of message transmission and integrity verification.

Images