Method for generating and validating digital certificate

Abstract

A computer-implemented method for generating a digital certificate, comprising providing at least one satellite (1) orbiting around the Earth (E), providing at least one data processing unit (2) on board the satellite (1), providing at least one ground-based data processing and transmission structure (3), wherein the data processing unit (2) comprises at least one first data processing module (SNS) and at least one second data processing module (SSP) operatively connected to each other and to the satellite (1), and wherein the ground-based data processing structure (3) comprises at least one third data processing module (SGE), the at least one first data processing module (SNS) being configured to act as a certification authority (CA), receiving a request to generate a digital certificate and sending the request to the first data processing module (SNS), acquiring operational data of the satellite (1), verifying said data and, in the event of a positive outcome, generating at least one digital certificate through the first data processing module (SNS).

Description

[0001] “METHOD FOR GENERATING AND VALIDATING DIGITAL CERTIFICATE”

[0002] * * *

[0003] FIELD OF THE TECHNOLOGY

[0004] The present invention relates to a method for generating, assigning and validating digital certificates to be used for the protection of information and communications, through cryptographic techniques and security protocols.

[0005] STATE OF THE ART

[0006] In the field of cryptography and information security, the use of public key certificates issued by a certification authority is known.

[0007] As is known, a public key certificate is a digital document that associates a public key with an entity, for example a person, an organization or a website.

[0008] Public key certificates are instruments used for validating the identity of a subject and for the secure transmission of encrypted data, decipherable exclusively by the holder of the certificate (person, organization or application). Each certificate contains information such as the public key, the identifying data of the entity and a digital signature of the certification authority. The latter verifies the identity of the requesting entities and digitally signs the certificates, thus guaranteeing their authenticity.

[0009] The format of public key certificates (Public Key Certificates, PKC) and of certification authorities (CA, Certification Authorities) is implemented according to a standard, for example the X.509 standard (proposed by ITU-T, International Telecommunication Union).

[0010] One of the most widespread uses of such PKC certificates is for encrypting communications between a browser and a website.

[0011] A system that uses PKC certificates requires validation of the certificate, which includes a public key that must be previously verified. If the service that uses the certificate does not already have a valid copy of the public key of the issuing CA, it is necessary to obtain additional certificates in order to access such key. Validation generally relies on a certificate chain (certification path) that includes the certificate of the public key holder (end-entity certificate), signed by a CA, and one or more intermediate CA certificates signed by other CAs. Such chains are fundamental since software initially contains a limited number of preinstalled CA public keys.

[0012] A certificate chain must comply with specific properties. In particular, the issuer of each certificate must correspond to the subject of the subsequent certificate, with the exception of the root certificate, usually self-signed. Each certificate is signed by the private key associated withthe subsequent certificate, and the signature can be verified by means of the public key of the subsequent certificate. The root certificate, also called “trust anchor”, is considered intrinsically trusted.

[0013] Certificates issued for a CA are defined as “cross -certificates” and are used both in hierarchical models, where a superior CA certifies a subordinate CA, and in distributed models, where different CAs can issue reciprocal certificates.

[0014] The construction and validation of certificate chains occur in two main phases. The first phase involves the construction of the chain, that is the identification of one or more validation chains. Not all of them may be valid, for example due to length restrictions or constraint violations. The second phase concerns chain validation, which involves verification of integrity, temporal validity, absence of revocation, compliance with critical extensions and consistency of the certificates in the chain.

[0015] A certificate may belong to multiple valid chains due to the possibility of generating multiple certificates for a CA, with the same subject and the same public key, but signed by different CAs. This allows cross-certification of public key infrastructures (PKI) and applications.

[0016] A public key infrastructure (PKI) is a system that enables trusted third parties to verify and guarantee the identity of users and to associate public keys with specific users. Typically, public keys are presented as digital certificates issued by CAs.

[0017] The structure of the PKI is hierarchical and is formed by multiple CAs, at the top of which there is a “root” CA that certifies sub-CAs. The root CA self-signs its own certificate, generating its own public and private keys and signing, with the private key, the issued certificates.

[0018] The agreements underlying a PKI structure allow mutual authentication of users and the use of public keys to ensure confidentiality, integrity and authentication of messages, without the need for a prior exchange of confidential information.

[0019] The structure of a PKI is organized according to a set of fundamental components and documents. At the base there is a security policy, which defines the general principles on which the entire system is founded. Alongside it there is the Certificate Practice Statement (CPS), a document that describes in detail the procedures provided for the issuance, registration, suspension and revocation of certificates.

[0020] A central role is played by the Certification Authority (CA) system, responsible for issuing certificates, and by the Registration Authority (RA) system, which handles the registration and authentication of users requesting certificates. Finally, a Certificate Server or a Validation Authority (VA) function is provided, whose task is to verify and attest the correspondencebetween the certificate and the user or entity, acting on behalf of the CA.

[0021] PKI structures, however, are centralized systems that depend on trusted CAs, and trust in the entire system is based on the integrity of the CAs themselves. Any compromise of a CA can compromise the security of the entire PKI.

[0022] The PKI certificate generation system presents several intrinsic disadvantages, mainly related to its centralized nature and to the trust placed in CAs. First of all, the centralized structure of public key infrastructures PKI creates a strong dependency on CAs, which act as guarantors of identity and integrity of certificates. This centralization creates a single point of failure: if a CA is compromised, the entire chain of certificates issued by it loses credibility, compromising the security and reliability of the entire system.

[0023] A further problem lies in the lack of an authority superior to root CAs, capable of supervising their behaviour in a direct and independent manner. Consequently, the system relies on legal rules and national regulations, which often fail to effectively prevent or manage situations of compromise or abuse of CAs. This aspect is amplified by the fact that each CA, among the thousands operating globally, has the ability to issue certificates for any entity. Such power increases the risk of attacks, such as the so-called “Man-in-the-Middle” (MITM), in which an attacker could obtain a fraudulent certificate to impersonate another entity. MITM attacks can be carried out through various techniques, including ARP spoofing, IP spoofing, DNS spoofing, HTTPS spoofing and “Man in the Browser” (MITB). Such attacks may consist in deceiving a CA by convincing it to authenticate a fraudulent identity or in directly compromising the CA in order to issue unauthorized certificates.

[0024] Trust in the entire certification system is ultimately delegated to the end user. When a certificate is not trusted, it is up to the user to decide whether to accept or reject the connection, creating a significant point of vulnerability. Most users, in fact, do not possess the technical skills to correctly assess the validity of a certificate, leaving room for errors and compromises.

[0025] Finally, the current model is exposed to risks of technical and administrative compromise of CAs, which have become preferred targets for cyber attacks. Documented incidents have demonstrated how some CAs have been compromised, leading to the issuance of illegitimate certificates and to serious breaches of trust in the system. This undermines the very perception of reliability of PKIs, which depend critically on the reputation and integrity of the CAs themselves.

[0026] In light of the disadvantages of the public key certificate generation system, various market needs emerge aimed at requiring an increase in the security, reliability and usability of public key infrastructures (PKI).

[0027] First of all, there is a growing demand for decentralized solutions that eliminate the singlepoint of failure represented by centralized certification authorities.

[0028] Another relevant need is represented by the development of automated and robust validation mechanisms that reduce the burden of decision on the end user.

[0029] The market also highlights the need for greater transparency and supervision over existing CAs.

[0030] The increase in cyber attacks has generated a need to improve defenses against compromise of CAs. In parallel, there is a demand for systems that reduce the potential impact of a compromise.

[0031] A further need concerns the simplification of the user experience, with more intuitive solutions for certificate management, so that even less experienced users can navigate securely without the risk of accepting fraudulent certificates.

[0032] OBJECTS OF THE INVENTION

[0033] The object of the present invention is to solve some of the main structural and operational limitations of traditional public key infrastructures (PKT), addressing problems related to trust, to the centralization of certification authorities (CA) and to the intermediate role performed by subordinate CAs. These problems, intrinsic to the centralized model of conventional PKI structures, compromise the security, efficiency and scalability of digital identity management and communication encryption systems.

[0034] A further object of the invention is to reduce or even eliminate dependence on the intermediation role of subordinate CAs, making the need for hierarchical and multi-level chains of trust superfluous.

[0035] Another object of the invention is to create, assign and validate digital certificates in a secure and reliable manner capable of overcoming the drawbacks relating to security against cyber attacks that affect traditional-type solutions.

[0036] These and other objects are achieved by the computer-implemented method for generating and validating public key digital certificates according to claim 1. The dependent claims specify further advantages of the method according to the invention.

[0037] The advantages offered by the method for generating and validating public key certificates according to the invention are evident.

[0038] The method according to the invention, in fact, enables decentralized distribution of certification operations, reducing or completely eliminating the single point of failure represented by root CAs or subordinate CAs.

[0039] The computer-implemented method for generating and validating PKC certificates addresses the fundamental problem of trust and of centralization of certification authorities (CA),eliminating the need for intermediaries such as subordinate CAs and radically simplifying the system architecture.

[0040] Unlike traditional PKIs, the method for generating and validating PKC certificates according to the invention uses an innovative combination of satellites and so-called Distributed Ledger Technology (DLT) to ensure a secure, scalable and resilient infrastructure.

[0041] By the expression “Distributed Ledger Technology”, there is meant an information technology infrastructure for managing a shared and synchronized database networked and distributed among multiple subjects, comprising dedicated or virtual servers, possibly located in different points of planet Earth, connected to each other through decentralized p2p-type networks. A common DLT technology is blockchain. In the description that follows, reference will be made, by way of example but not limitation, to a DLT technology such as a blockchain. It is understood that the use of the term “blockchain” with reference to a DLT structure does not exclude the possibility of using alternative forms of DLT. In the present description, therefore, the expressions “DLT” and “blockchain” are used as synonyms, excluding any implicit limitation associable with the term blockchain with respect to the more general term DLT.

[0042] Satellites, by exploiting their physical inaccessibility, are naturally protected from unauthorized access. Moreover, their autonomous and secure operativity makes them immune to political, social or commercial instabilities that may affect terrestrial CAs. Furthermore, the use of secure radiofrequency links independent of the Internet prevents cyber attacks typical of public or private networks, transferring security measures into the aerospace context, a field known to be more controlled and secure.

[0043] In accordance with the method for generating and validating PKC certificates according to the invention, each satellite is configured to operate as an autonomous certification authority, provided with a unique algorithm that generates exclusive security certificates for the satellite itself and not replicable on other satellites or on Earth. Through these exclusive security certificates, third-party user certificates are digitally signed in a secure manner. The same algorithm, moreover, can generate certificates entitled directly to the legitimate holder at the moment of creation, eliminating the need for hierarchical certification chains. Furthermore, the life cycle of certificates and of satellite CAs is strictly limited to the planned mission of the satellite, after which the devices are physically destroyed, eliminating risks of subsequent compromise.

[0044] The certificates generated through the method according to the invention are associated with NFTs (Non-Fungible Tokens) registered on the DLT. This ensures unique identification of the certificate and of its holder. The DLT provides an immutable and public register, whichmakes it possible to trace all transactions related to certificates, from their issuance to transfer of ownership between digital wallets. Transparency and verifiability of operations are achieved without intervention of third parties, thanks to the use of automatic processes called smart contracts, which manage authentication, validation and revocation of certificates.

[0045] Compared to PKI-based solutions, the method according to the invention simplifies and improves fundamental functionalities. Satellite CAs eliminate risks deriving from compromise of terrestrial CAs, while the DLT replaces traditional registration authority (RA) and validation authority (VA) systems, ensuring a decentralized and automated process. Assignment of certificates does not require intermediaries: creation and management of certificates occur through smart contracts that record each operation in a transparent and secure manner. Furthermore, the limited duration of certificates to the life cycle of the satellite eliminates the need for renewal, reducing operating costs and risks related to long-term management.

[0046] The method according to the invention is capable of providing greater security compared to traditional-type solutions, thanks to the physical inaccessibility of satellites, to greater transparency through the DLT and to a simpler and more robust structure, without the need for subordinate CAs or complex chains of trust. This combination makes it possible to meet security and decentralization requirements, making the method for generating and validating PKC certificates suitable for all applications and fields that require high standards of security and resilience.

[0047] DESCRIPTION OF THE FIGURES

[0048] The present invention will now be described, by way of illustration but not limitation, according to its preferred embodiments, with particular reference to the Figures of the attached drawings, in which:

[0049] Figure 1 schematically shows a certification flow operated through the method according to the invention;

[0050] Figure 2 schematically shows a flow for generating a timestamp through the method according to the invention;

[0051] Figure 3 shows a block diagram relating to a data certification flow through the method according to the invention;

[0052] Figure 4 shows a block diagram relating to validation of a certificate through the method according to the invention;

[0053] Figure 5 shows a block diagram relating to creation of a certificate through the method according to the invention.

[0054] DESCRIPTION OF THE INVENTIONThe invention relates to a computer-implemented method, integrated to validate the generation, management and registration of digital certificates and digital signatures, designed to offer greater security and reliability compared to traditional solutions based on public key infrastructures (PKI).

[0055] The method finds application for certification of various data which, in turn, can be obtained through different types of information systems and devices.

[0056] A first example comprises information systems interconnected via the Internet, consisting of computers and integrated electronic devices, capable of generating digital data to be subjected to certification.

[0057] A second example comprises portable digital devices, also connected to the network, capable of producing certifiable digital data.

[0058] A third example provides devices such as sensor systems, which can be connected to each other or to one or more collector devices, called “hubs”, connected to the Internet network to collect data from the sensors themselves and / or create certifiable digital processing.

[0059] A fourth example comprises devices installed on operational satellites, capable of generating digital data to be certified and of communicating with ground control centers (MCC) via antennas and telematic links.

[0060] In particular, with reference to the first three examples previously indicated, the method finds application in solutions such as, by way of example but not limitation, certification of data relating to monitoring by means of sensors of industrial plants, lands, crops, livestock, natural and artificial structures, buildings and infrastructures. Other types of data to be certified include tracking of goods and persons in the transport and logistics sectors, as well as assignment and control of certifications relating to ownership, production, use, transfer and distribution of goods, whether digital or physical.

[0061] With reference to the fourth example, finally, the method according to the invention finds use in certification of data relating to satellite monitoring by means of, for example, optical, spectral, radio, audiometric detection or, in general, by means of any device capable of sending digital data to a processing unit on board a satellite.

[0062] To the cases previously described there is added a further possible use of the method according to the invention implementable by an operator, to autonomously sign digital data and / or communications through a certificate generated through the same method. Such use concerns, for example, encryption of web applications, sites, electronic mail, digital signature of documents, as well as use in private and public communication systems with public encryption keys.According to an aspect of the invention, as will be better described below, the method requires the use of modular devices, a cloud information infrastructure and one or more public DLTs to implement a decentralized, immutable and secure register. The invention solves problems of centralization, vulnerability and inefficiency related to prior art technologies, proposing an innovative architecture that combines the use of at least one processing device installed on board at least one satellite and terrestrial processing and data exchange devices, for automated and secure management of certificates and digital signatures.

[0063] Furthermore, the method may comprise the use of a public DLT to register digital certificates. Such technical possibility ensures immutability, transparency and decentralization of certificates. Once registered, the certificates cannot be modified or deleted, being easily verifiable and independent from a central authority, thus reducing possible risks of manipulation or loss. Moreover, the immutable history of a DLT allows complete traceability of data.

[0064] It is noted that decentralized public registers are resistant in contexts of deactivation or destruction of centralized data storage and connectivity infrastructures.

[0065] The method according to the invention comprises a step of providing at least one satellite 1 on board which at least one data processing unit 2 is installed which, in turn, is operatively connected to the satellite 1 itself in a data exchange regime. Such condition allows the at least one data processing unit 2 to receive and transmit data with respect to a terrestrial data processing and transmission structure 3, hereinafter referred to as terrestrial processing structure 3 for brevity.

[0066] In particular, the method according to the invention comprises a step of providing at least one data processing unit 2 which, in turn, comprises a first data processing module, hereinafter also “SNS module” (Society Notary Source) for brevity, and at least one second data processing module, hereinafter also “SSP module” (Society Secondary Payload) for brevity. The method according to the invention comprises a step of providing in the terrestrial processing structure 3 at least one third data processing module, hereinafter also “SGE module” (Society Ground Equipment) for brevity.

[0067] The SNS module, as stated, is installed on board a satellite 1, and represents the satellite CA certification authority. The satellite 1 is operational, meaning that it is functioning and in orbit, along a trajectory or orbit 4, around the Earth (E) (see for example Figure 1).

[0068] The satellite 1 acts as “host” for the SNS module.

[0069] The SNS module has low energy consumption characteristics and compact dimensions, suitable for integration into various types of satellites. For example, the SNS module has dimensions compatible with its installation in pico-satellites, nanosatellites, microsatellites orlarger satellites.

[0070] The SNS module is operatively connected, in a data exchange regime, with the satellite 1 to verify that the satellite 1 is operational along the orbit 4. For this purpose, the SNS module is configured to receive from the satellite 1 information relating to position, velocity, altitude and orientation, as well as synchronized time signals through a Global Navigation Satellite System (GNSS), that is a network of artificial satellites 5 that provide position, navigation and timing data to terrestrial devices (see Figure 2).

[0071] Such data are processed for creation of digital certificates, as better described below. Communication between the SNS module and the terrestrial processing structure 3 occurs through the radiofrequency system of the host satellite 1.

[0072] As stated, the SSP module is also integrated into at least one satellite 1 in which the SNS module is present, and uses peripherals on board the satellite 1 itself to collect data to be subjected to certification.

[0073] The SSP module generates digital signatures relating to the data and transmits them to at least one “Edge” server included in the terrestrial processing structure 3, for further processing.

[0074] Transmission occurs through the radiofrequency system of the satellite 1.

[0075] The SGE module is designed to be integrated into the terrestrial processing structure 3, with particular reference to terrestrial “host devices”, such as for example computers and electronic devices. Preferably, the SGE module is powered by the terrestrial host device in which it is included, thus simplifying its implementation.

[0076] The SGE module uses private or public networks to communicate with the Edge server. It is understood that the terrestrial processing structure 3 may comprise a plurality of Edge servers. For simplicity of exposition, reference will be made to the Edge servers by indicating them with the expression at least one Edge server.

[0077] The SGE module generates digital signatures for data received from the terrestrial host device and sends them to the at least one Edge server for processing and registration on a blockchain.

[0078] The terrestrial processing structure 3 comprises an infrastructure which, in turn, supports hardware modules and consists, for example, of cloud services. If cloud services are provided by third-party providers, they may be managed by a proprietary system included in the terrestrial processing structure 3 according to laaS (Infrastructure as a Service) and PaaS (Platform as a Service) models.

[0079] Preferably, the main services included in the terrestrial processing structure 3 are:

[0080] - at least one “Edge” server, which manages processing of digital certificates and digitalsignatures received from the SNS, SSP and SGE modules. The at least one Edge server processes the data and sends them to Bridge nodes, via the internet, for registration on the DLT (for example a blockchain);

[0081] - “Society Oracle”: provides public interfaces (API) to allow authorized devices to read and verify data registered on the DLT. In other words, verification of data registered on the DLT with respect to data stored on third-party systems occurs by means of so-called “Society Oracle” services.

[0082] The Society Oracle service corresponds to a service dedicated to supporting smart contracts through integration of “trusted” information coming from domains external to the blockchain. The blockchain, being per se a technology indifferent to the data it manages, benefits from the architecture proposed in the present invention, which makes it possible to maintain the complexity of real-world data outside on-chain logic.

[0083] In particular, the Society Oracle system offers advanced functionalities for verification and management of certifications. Certificates or digital signatures associated with such certifications are registered on the DLT (for example blockchain) in the form of transactions managed by the SSP or SGE modules. However, the certified contents remain stored on the information systems of data providers. By way of example, reading on the blockchain a digital signature made by an SGE module for an image makes it possible to obtain the identification code (or hash) corresponding to the image itself. The user can then use such hash to verify the image stored in the service provider’s systems.

[0084] The main services offered by the Society Oracle system include a verification service of certificates registered as NFTs and a digital signature verification service.

[0085] The verification service of certificates registered as NFTs allows verification of certificates deposited on the blockchain in the form of NFTs, which are assigned to a specific user. The user must demonstrate his legitimacy by controlling the qualified name registered in the certificate and the associated digital identity.

[0086] The digital signature verification service verifies a digital signature registered on the blockchain with respect to a provided unique identifier (hash). Subsequently, the service allows retrieval of the code necessary to identify the certified data within the provider’s archives.

[0087] This architecture offers a scalable and reliable solution to ensure data and certification integrity, integrating the capabilities of blockchain with traditional data storage systems.

[0088] Preferably, communication between the services occurs by means of HTTPS protocols and distributed peer-to-peer (p2p) networks, in order to ensure security and scalability.

[0089] The DLT represents the main instrument of the registration system, constituting adecentralized, immutable and cyber-attack-resistant register. The DLT is designed to register digital certificates and digital signatures, ensuring transparency and traceability.

[0090] Each device and each user are associated with a unique digital wallet, used for managing ownership of certificates registered as NFTs (Non-Fungible Tokens). The NFTs, associated with the generated certificates, are transferable between wallets, and each transfer is immutably recorded.

[0091] The operations of management, transfer and validation of certificates and digital signatures are automated through “smart contracts”, programs that automatically execute predefined agreements on the blockchain when certain predefined conditions occur. These contracts allow elimination of intermediaries, ensuring efficiency, security and transparency. Digital certificates, generated by the SNS modules, are associated with unique NFTs and registered on the blockchain. Ownership of the certificates is transferable and traceable without possibility of duplication.

[0092] Finally, digital signatures are created by the at least one SSP module and by the SGE module and are registered on the blockchain, which is used as a decentralized public register.

[0093] Security of the transaction on the blockchain is not directly guaranteed by the method according to the invention, since it is intrinsically ensured by the blockchain infrastructure itself. Flowever, references may be provided to authorize or not the use of a specific blockchain.

[0094] Transmission of data between blockchain nodes occurs by means of encrypted communication channels, designed to ensure authenticity of data and of the users involved. Depending on the implementation, the servers operating as nodes use combinations of asymmetric and symmetric encryption, as well as hash functions, to establish secure communications and uniquely identify senders, recipients and data. Decentralized communication structures are generally based on peer-to-peer (p2p) protocols.

[0095] Writing of data on the blockchain, as well as any modifications of the decentralized register, contribute to determining the “state” of the blockchain itself. To increase security and reliability of the system, each implementation uses a consensus mechanism that guarantees agreement among nodes on the state of the register. Such mechanisms, such as for example “Proof of Work”, “Proof of Stake”, “Proof of Authority” or “Proof of Operation”, vary depending on the characteristics of the blockchain and / or of the involved nodes.

[0096] The blockchain register is intrinsically secure due to its resistance to single -point failures and to blocking, obfuscation or censorship attacks, thanks to its decentralized structure. Moreover, the register is immutable, since data are stored in concatenated “blocks” and cannot be modified after their writing.Registration of digital certificates on the blockchain occurs in compliance with recognized standards, with reference for example to the X.509 v3 standard. This process provides encryption of a specific portion of the certificate by means of the private key of the SNS module, called “SNS Private Key”, and inclusion, within the certificate itself, of the encrypted signature and of the corresponding public key, called “SNS Public Key”. The digital identity of the SNS module can be verified directly on the blockchain through the encrypted signature and the public key included in the certificate.

[0097] The private key “SNS Private Key” is generated simultaneously with the public key “SNS Public Key” during activation of at least one SNS module in orbit and is stored exclusively in the module itself, in an OTP (One Time Programmable) memory, not accessible by third-party devices. This configuration makes it impossible to decrypt the digital certificates registered on the blockchain, except by brute-force attacks on the encrypted keys. However, temporal validity of the keys is shorter than the estimated duration necessary to complete such an attack, which exceeds by many orders of magnitude the operational life of the satellite.

[0098] It is noted that the SNS module is designed to process input data received from the satellite 1 and to generate digital certificates upon reaching predefined conditions.

[0099] In particular, the method according to the invention provides creation of at least one digital certificate following verification, by the at least one SNS module, of the operational conditions of the satellite 1 in which the at least one SNS module is installed on board.

[0100] For this purpose, the method provides a first phase of collecting data coming from the satellite 1. Preferably, the data acquired as input from the satellite 1 comprise altitude, velocity, longitude, latitude, orientation, angular momentum.

[0101] The at least one SNS module receives operational parameters from the satellite 1 through internal communications, and verifies them through a processor included in the at least one SNS module itself, in order to establish the necessary and sufficient conditions for activation of a flow for creation of a certificate.

[0102] The verification phase comprises verifying validity of the request to generate a digital certificate and validity of the identity of the satellite 1.

[0103] In particular, the at least one SNS module verifies the data received from the satellite 1 by comparing them with previously received data and with mission references. By the term “mission” there is meant the mission planned for the satellite 1 itself.

[0104] Furthermore, the at least one SNS module validates the altitude value received from the satellite 1 with data coming from at least one sensor integrated in the SNS module itself, in order to detect possible “out-of-range” conditions.By way of example, the at least one sensor is configured as an industrial-type barometric sensor. For example, the barometric sensor is calibrated with minimum values equal to 260 hPa, corresponding to an altitude comprised between 10-15 km above sea level, in the upper troposphere zone. In consideration of the type of sensor, it is possible to expect a constant malfunction of the device under working conditions in low Earth orbit (LEO). Moreover, it is possible to detect breakage of such a barometric sensor.

[0105] According to an alternative embodiment, evaluation of positioning in orbit may occur through GPS detectors, or through an image acquisition system operatively connected to the SNS module.

[0106] The method according to the invention provides that, in case of validation of the data of the satellite 1, the at least one SNS module verifies and synchronizes its on-board clock with the received GPS signal.

[0107] Following these verification operations, the at least one SNS module checks a “timestamp” parameter.

[0108] Calculation of such timestamp parameter forms part of the present method.

[0109] The timestamp parameter is an element for control and management of the process of creating digital certificates, digital signatures and blockchain writing operations.

[0110] Each timestamp consists of information relating to:

[0111] - the current epoch at the moment of issuance (start and end of SNS counts and of the Stardome Clock server counts) and to the difference recorded with respect to the counts performed by the counters of the SNS module and of the Stardome Clock server, called “epoch genesis”;

[0112] - a code generated through a TRNG (True Random Number Generator) device and encrypted with a key calculated on the integrated circuit, called “epoch key”. The “epoch key” constitutes the encryption key of internal communications of the system implementing the method according to the invention;

[0113] - a digital signature created by encrypting, with the key, the data to be certified (called digest) encrypted with the private key of the digital certificate of the SNS module;

[0114] - a public key of the digital certificate of the SNS module.

[0115] To calculate the timestamp, the method according to the invention exploits the phenomenon of time dilation according to relativistic principles described by Lorentz -Einstein transformations, in order to guarantee temporal accuracy.

[0116] The method exploits the phenomenon of time dilation as a reference element in various fields: for control of the digital certificate creation process, for monitoring of digital signature andfor management of blockchain writing operations.

[0117] For this purpose, it is noted that the SNS, SSP and SGE modules are provided with a processor, known as “nanocounter”, configured to measure nanoseconds elapsed between two temporal events. Similar nanocounter processors are integrated in the “Clock” services, which record measured events until definitive writing on the blockchain.

[0118] The method according to the invention is based on use of a GPS time signal, which differs from the UTC system because it does not include corrections related to variations in Earth’s rotation.

[0119] Time dilation is a relativistic phenomenon that modifies measurement of duration of an event as a function of the inertial reference frame from which it is observed.

[0120] The phenomenon of time dilation is used to compensate relativistic effects due to velocity and distance of satellites with respect to the Earth.

[0121] In satellite systems, dilation is influenced by two main factors: satellite velocity and its distance from the Earth’s gravitational center.

[0122] A satellite 1 orbiting around the Earth E is subject to an apparent slowing of time due to its high velocity. As velocity increases, time dilation correspondingly increases.

[0123] The greater distance of the satellite 1 from the Earth E causes an apparent acceleration of time, since proximity to the Earth’s center of gravity influences clock rates.

[0124] By way of example, GPS satellites, located at an altitude of approximately 20,000 km and traveling at a velocity of approximately 4 m / s, show a slowing of the on-board clock of approximately 7 ps (microseconds) per day due to velocity. However, the greater altitude with respect to the Earth leads to a temporal acceleration of approximately 45 ps (microseconds) per day, for a net combined effect of an increase of 38 ps (microseconds) with respect to time measured on the Earth’s surface.

[0125] These effects are mathematically described by Lorentz-Einstein transformations.

[0126] An event EV, measured by an observer O located in reference frame S co-moving with EV (at rest with respect to EV) has duration AtO (proper time), which is the minimum possible.

[0127] An observer O’ located in reference frame S’ with relative velocity v with respect to S will measure, for the same event EV, a greater duration At, given by the relation

[0128] At = y AtO

[0129] where

[0130] “At” is the time interval measured by observer O’ located in reference frame S’, that is the time interval measured by the at least one SNS module on board the satellite. Measurement of time is performed by the at least one SNS module by means of its own nanocounter withreference to the GPS time signal;

[0131] “AtO” is the time interval measured by observer O in S, that is the time interval measured by the Society Clock service on Earth by means of its own nanocounter with reference to the GPS time signal;

[0132] and

[0133] “y = l / sqrt(l - (v / c)2)” is the Lorentz factor where:

[0134] “v” is the relative velocity between the two reference frames S and S’ measured as satellite velocity with respect to GNSS systems;

[0135] “c” is the speed of light in vacuum c = 3*108m / s.

[0136] The same effect, moreover, is determined by the different influence of gravity on the two reference frames S and S’, since the Clock service on Earth is closer to the source of the gravitational field than the satellite, whereby

[0137] At’ = y At

[0138] wherein

[0139] “At” is the time interval previously calculated without including gravitational effects, while At’ is the time interval corrected for gravitational effects

[0140] and

[0141] “Y = l / sqrt(l - (v / c)2)”

[0142] where

[0143] “v” = 2GM,

[0144] with “G” = 6.67 x IO’11nNm2 / kg2, gravitational constant;

[0145] with “M” = 5.972e24m, mass of the Earth;

[0146] “c” = rb for the calculation of the gravitational effect on the interval measured on Earth, with “r” = 6.37* 106m, radius of the Earth;

[0147] with “c” = 3*108m / s, speed of light in vacuum;

[0148] “c” = (r + h)c2for the calculation of the gravitational effect on the interval measured on the satellite,

[0149] with “r” = 6.37* 106m, radius of the Earth;

[0150] with “h” = satellite altitude h;

[0151] with “c” = 3*108m / s, speed of light in vacuum.

[0152] From the difference between the delay accumulated by the Clock service on Earth and the at least one SNS module on board satellite 1, both calculated over the orbital period of satellite 1 and referenced to the GPS time signal and the nanocounter, the slowdown due to the velocity of satellite 1 must be subtracted.With reference to the foregoing, the following values are obtained, expressed in nanoseconds:

[0153] Example 1

[0154] acceleration due to gravity: 286.3ns Height 500km, speed 7612.68m / s, period

[0155] slowdown due to velocity: -1830.3ns lh34m:37s (5677s)

[0156] delta temporale totale: -1543.3ns Example 2

[0157] acceleration due to gravity: 594.4ns Height 1000km, speed 7350.20m / s, period slowdown due to velocity: -1895.6ns lh45m07s (6307s) total time delta

[0158] : -1301.2ns

[0159] Example 3

[0160] Height 5000km, speed 5918.83m / s, period acceleration due to gravity: 3690.9ns 3h21ml9s (12079s) slowdown due to velocity: -2354.1ns

[0161] total time delta: 1336.8ns

[0162] Example 4

[0163] acceleration due to gravity: 15176.9ns Height 15000km, speed 4318.02m / s,

[0164] slowdown due to velocity: -3226.6ns period 8h38m27s (31107s)

[0165] total time delta: 11950.3ns

[0166] Example 5

[0167] acceleration due to gravity: 51285ns Height 36000km, speed 3066.89m / s,

[0168] slowdown due to velocity: -4543ns

[0169] period 24h07m01s (86821s)

[0170] total time delta: 46741.9ns

[0171]

[0172] The method according to the invention comprises a phase of generating time stamps, applicable in the context of satellite systems and based on temporal synchronization between onboard satellite modules and ground services, with particular reference to the use of GPS signals and nanocounters.

[0173] The expected difference between the nanocounter counts onboard the at least one SNS module and those of the Clock services located on Earth is verified over a variable interval, referred to as an “epoch,” established according to the orbital characteristics and mission profile of satellite 1.

[0174] The control flow comprises two main phases, defined as “epoch seed” (beginning of the period) and “epoch start” (end of the period), which ensure correct synchronization andtemporal validation.

[0175] In the initial phase of the period (epoch seed), the at least one SNS module stores an initial value of its nanocounter and the GPS time. These data are acquired at the time of establishing communication between the at least one SNS module and a ground antenna 6, during a first pass of satellite 1 overhead. The at least one SNS module transmits the start-of-count data to the Clock service located on Earth E, using communication systems included in the ground processing infrastructure 3, which may be public or private in nature. Upon receipt of the message, the Clock service records the value of its local nanocounter and associates the corresponding GPS time.

[0176] In the final phase of the period (epoch start), the at least one SNS module acquires a new value of its nanocounter and an updated GPS time during a second pass of satellite 1 over the same ground antenna 6. The data relating to the end-of-count time and the nanocounter are sent to the ground Clock service.

[0177] The Clock service then compares the value of its local nanocounter with that of the at least one SNS module, determining a difference in count between the two nanocounters with reference to the GPS time corresponding to the nanocounter measurement of the at least one satellite 1. Subsequently, the ground Clock service sends the at least one SNS module a validation message containing the verified data.

[0178] Once the validation data have been received and their correctness verified, the at least one SNS module proceeds to generate digital time stamps referring to the current period, defined as the “epoch.” This ensures the unique and verifiable association of a time interval with the recorded events.

[0179] The process is repeated for each satellite 1 equipped with at least one SNS module. The Clock service records all “epochs” relating to SNS modules operating in orbit, ensuring control and integrity of temporal data within the system.

[0180] If the detected difference is not compatible with the references based on the time dilation phenomenon, the ground Clock service considers the status of the SNS module invalid and communicates this to at least one Edge server. Such condition is recorded on the blockchain and results in the invalidation of digital certificates issued by the at least one SNS module, until correct operating conditions are restored. The at least one SNS module remains operational, and the system continues to monitor and record its values. In particular, the detected counting difference, excluding malfunction of electronic components, may be attributable to an attempt to use the module on the Earth’s surface, thus indicating fraudulent activity.

[0181] In accordance with the foregoing, it is evident that the method according to the inventionenables precise and reliable management of temporal data between satellites 1 and the ground processing infrastructure 3, ensuring the generation of time stamps with high precision and security.

[0182] One objective of the method is to detect a constant and predicted time dilation, used as an indicator of correct operation of satellite 1 in orbit, rather than to synchronize clocks.

[0183] To ensure system reliability and mitigate potential fraudulent attempts, the time dilation measurement interval is varied unpredictably. The clocks of satellites 1 operate deliberately in a non-synchronous manner, and their counters are reset at each measurement interval. This operation is carried out exclusively in orbit, under conditions in which the system is already subject to relativistic effects. Any synchronization between clocks could represent an anomaly, suggesting that the at least one SNS module was activated on Earth E rather than in space. Such an approach ensures that the at least one SNS module operates correctly under the expected orbital conditions, confirming system integrity and security.

[0184] An exemplary, non-limiting calculation of time dilation effects is provided below.

[0185] Consider a satellite 1 in low Earth orbit (LEO) at an altitude of 500 km, with a velocity of 7612.68 m / s, over a period of 1 h 34 m 37 s as recorded by the SNS module.

[0186] In the initial phase of the period (epoch seed), at the time of establishing the first communication with the at least one SNS module, the Earth Clock service log records the following data:

[0187] message reception time from SNS: 17:10:00;

[0188] - SNS module start-of-count time: 17:00:00.

[0189] At the end of the period (epoch start), upon communication with the at least one SNS module, the Earth Clock service log records:

[0190] - message reception time from the at least one SNS module: 18:44:37;

[0191] - end-of-count time of the at least one SNS module: 18:34:37;

[0192] - nanocounter value of the at least one SNS module: 5,676,999,998.457 ns due to time dilation effect equal to -1.54 ns;

[0193] - Clock nanocounter value referred to the end-of-count time of the at least one SNS module: 5,677,000,000.000 ns.

[0194] Therefore, the recorded difference is 1544 ns, consistent with the expected time dilation. In the example case, satellite 1 has a period, understood as the time required to complete one full orbit 4 around Earth (E), equal to 1 h 34 m 37 s. Accordingly, satellite 1 performs 15.2 revolutions per day.

[0195] For each period, the at least one SNS module is capable of issuing digital certificates, thusensuring the possibility of issuing a high overall number of digital certificates per day.

[0196] It is noted that the digital certificates issued by the at least one SNS module are signed by the same module, thereby exhibiting the typical characteristics of previously described root certificates, and are compliant with applicable standards (for example, X.509 v3).

[0197] Each digital certificate issued by the at least one SNS module includes, in addition to the information required by the applicable standard, information relating to satellite 1, to the at least one SNS module itself, and to the epoch during which the digital certificates were issued.

[0198] By way of example, the information included in the digital certificate comprises the altitude of satellite 1, velocity, longitude, latitude, orientation, angular momentum of satellite 1, and epoch data.

[0199] It is noted that the encryption method of the digital certificates according to the invention, implemented by the at least one SNS module, meets high security levels, such as, for example, the FIPS 140-3 standard of the NIST (National Institute of Standards and Technology), and employs PKGS (Public-Key Cryptography Standards), including RSA, DSA, ECDSA, Ed25519, Ed448, X25519, and X448.

[0200] The at least one SNS module is designed to operate in space, and thus under extreme environmental conditions, thereby ensuring high physical security, effective resistance to tampering attempts, and high robustness.

[0201] The at least one SNS module is capable of protecting itself against sophisticated attacks, both invasive, entailing direct access to its internal components, and non-invasive, operating without direct contact. The isolation of the operational conditions of satellite 1 is intrinsic and ensures that physical access to the module cannot occur while satellite 1 is in orbit. Furthermore, the at least one SNS module and the SSP module are designed to be isolated from the remainder of the satellite system, significantly limiting the possibility of compromise through side-channel attacks.

[0202] Such an attack would require that satellite 1 itself act as the attacking agent, for example by performing measurements through onboard instruments.

[0203] This configuration ensures that the integrity and security of the modules depend primarily on their intrinsic properties and on their isolated design with respect to the host satellite system.

[0204] Side-channel attacks represent a threat to the security of cryptosystems, as they exploit the ability to monitor collateral channels to gather information about the internal state of the system. Such attacks exploit specific weaknesses in the implementation of a cryptographic system, enabling attackers to obtain sensitive data, such as the cryptographic keys used, or to compromise the system itself.Data monitored during such attacks may include, by way of example, electrical power consumption during operation, execution time of algorithmic operations, variations in magnetic fields, and electromagnetic noise emissions generated during operation.

[0205] The at least one SNS module, integrated onboard satellite 1, is designed to be intrinsically immune to such attacks. The physical isolation to which the at least one SNS module is subject and its placement in space onboard satellite 1 render it inaccessible to the instruments necessary to conduct a side-channel attack. The orbital position and absence of direct physical interfaces ensure natural protection against monitoring of collateral signals, providing high operational security of the at least one SNS module and of the implementation of the method according to the invention.

[0206] The SNS and SSP modules communicate with the host satellite 1 through serial communication ports, adopting secure communication procedures that ensure integrity and confidentiality of exchanged data. Communication with host satellite 1 is encoded in a command set defined by the host itself, in compliance with applicable security standards. Such communication enables negotiation of data exchange and management of system operations, without permitting access to the OTP (One Time Programmable) memory of the at least one SNS module and of the SSP module.

[0207] Data transmitted between a system compliant with the method according to the present invention and Earth are encrypted using symmetric encryption based on epoch keys, which are indecipherable both to host satellite 1 and to ground systems within the validity period of the keys. This protection ensures information security during operational use.

[0208] The creation and registration of digital certificates on the blockchain occur in compliance with applicable standards (for example, X.509 v3). The process includes calculating the hash of a specific portion of the certificate and subsequently encrypting it using the private key of the at least one SNS module. The certificate itself contains the corresponding public key, registered on the blockchain, which may be used by any user to repeat the hash calculation on the same portion of the certificate and compare it with the encrypted hash, thereby confirming that encryption was performed with the private key exclusively held by the at least one SNS module.

[0209] The private key of the at least one SNS module, referred to as “SNS Private Key,” is generated simultaneously with the corresponding public key, referred to as “SNS Public Key,” during activation of the at least one SNS module in orbit. The private key is stored in an OTP memory not accessible by third-party devices, thereby ensuring security of cryptographic operations. Decryption of digital certificates registered on the blockchain would theoretically be possible only through brute-force attacks, but the temporal validity of the keys is significantlyshorter than the estimated time required to complete such an attack, considering the operational lifetime of satellite 1.

[0210] Validation of digital certificates occurs through qualified request lists collected by Edge servers and transmitted to the at least one SNS module. Requests include the data necessary for validation, compliant with standards such as X.509 v3, and specific to execution of a method according to the present invention. These data include:

[0211] - a qualified name consisting of a domain, acronym, alphanumeric code, or other identifiers allowing unique attribution of the certificate to a requesting user or device, in relation to its digital identity registered on the blockchain;

[0212] - the public key of the certificate assigned to the user or device, corresponding to an NFT registered on the blockchain;

[0213] - the digital signature of the assigned user or device, required to prove digital identity by means of the public key presented in the certificate.

[0214] The at least one SNS module verifies the signatures contained in the certificate by comparing them with the corresponding public keys. Subsequently, the at least one SNS module signs the hash of a specific portion of the certificate using its private key “SNS Private Key.” The certificate is then updated by addition, including the digital signature generated by the SNS module and the public key “SNS Public Key.”

[0215] This process ensures integrity, security, and authenticity of the digital certificate, providing robust cryptographic protections compliant with industry standards.

[0216] With reference to Figures 3-5, block diagrams schematically illustrate a process for managing digital signatures, validating a certificate, and creating a certificate according to the present method.

[0217] The digital signature management process integrates technology for certification and validation of data through a secure and decentralized chain of custody.

[0218] The process uses an architecture based on specialized electronic modules, SSP and SGE, and a high-precision time synchronization service.

[0219] As stated, the SSP module is integrated into satellites 1, from which it receives electrical power, and is operatively connected to the satellite’s communication system to establish data exchange with the ground service.

[0220] Similarly, the SGE (Society Ground Equipment) module is installed in electronic devices or computers, powered by the host device in which it is installed and connected to private or public networks through that device.

[0221] Both SSP and SGE modules periodically synchronize their nanocounter with epoch dataprovided by the at least one SNS module through the Clock service. Such synchronization is essential to generate unique time signals and to validate digital signatures.

[0222] The time signal, based on an epoch reference system, is a key element of the certification process forming the subject of the method according to the invention. This signal exhibits specific characteristics that render it suitable for the application environment.

[0223] In particular, the time signal is an incremental signal enabling synchronization of connected devices, eliminating the need for a central authority.

[0224] The term “synchronization” denotes a comparison between counts performed on Earth and those performed onboard satellite 1 with respect to a common reference time determined by the GPS signal.

[0225] According to the method, time stamps are calculated by intentionally exploiting the lack of synchronization resulting from uncorrected relativistic effects. This approach forms the basis of the system’s security device, which operates through control of orbit 4 and use of encrypted communications via symmetric keys derived from time stamps. Devices are therefore synchronized with respect to the time stamp in the sense that, at each update thereof, the internal counter is reset. Thereafter, counters of SNS and SSP modules begin incrementing, but their values are affected by relativistic time dilation effects, while the counter of SGE devices remains synchronized with ground systems.

[0226] Each SNS module generates distinct time signals, disseminated through the ground processing infrastructure 3 via the Clock service, yet consistent for registered devices.

[0227] The signal is based on GNSS time and is renewed at each revolution period of satellite 1, limiting risks of error or attacks on a single epoch.

[0228] The signal further enables incremental validation of digital signatures by comparing the nanocounter count relative to the reference epoch. Any intrusion altering the state of the nanocounter results in invalidation of the signature.

[0229] The process for using epoch keys to encrypt internal communications within a system implementing the method may be described as follows:

[0230] - first, the SNS module generates a time stamp based on the epoch just concluded and a new time stamp relating to the new epoch;

[0231] - subsequently, the SNS module transmits the new time stamp to the System Clock server, using as symmetric encryption key the “epoch key” relating to the previous epoch;

[0232] - the System Clock server verifies validity of the associated digital signature and checks compliance of the time stamp with epoch genesis data;

[0233] - once verification is completed, the System Clock server initiates propagation of the new“epoch key,” communicating it to Edge servers. Communication of the new key occurs securely, as it is encrypted using the previous “epoch key”;

[0234] - System Edge servers, upon receiving the new epoch key, integrate it into subsequent communications with SGE and SSP modules, as well as with System Clock and Edge servers themselves;

[0235] - in parallel, SGE and SSP modules synchronize their nanocounters on the basis of the new epoch;

[0236] - during propagation of the new key, System Clock and System Edge servers, as well as SGE and SSP modules, progressively transition to the new encryption key for communications among them, using the new “epoch key” as symmetric encryption key.

[0237] The maximum number of time stamps simultaneously present in a system compliant with the method is two per each SNS module. Duration of each time stamp corresponds to that of one epoch, plus the time required for certificate propagation within the system. Epoch certificates are not recorded on the DLT and are used exclusively to encrypt internal communications between SSP and SGE modules and Clock and Edge servers, as well as to validate digital signatures generated by SGE and SSP modules for purposes of registration on the DLT.

[0238] SSP and SGE modules generate digital signatures compliant with standard X.509 v3.7. To increase the specific security level of communications with SGE devices, the method uses an OTP authentication protocol in two possible modes: HOTP (Hash-based One-Time Password) and TOTP (Time -based One-Time Password).

[0239] In particular, the OTP protocol enables verification of the SGE module prior to establishing encrypted communication by checking the negotiation message initiating communication. The OTP authentication protocol requires that devices share a secret key (“shared secret”) and be remotely synchronized through a synchronized count (“counter”); devices exchange a message and a code generated by applying the same hash operation to the message, and only devices with the same secret key can generate a code identical to that received with the message. In particular, the method provides that the synchronized value is: the nanocounter value for HOTP implementations, whereas for TOTP implementations it is the timestamp of the device’s local time synchronized with the GPS signal.

[0240] SSP and SGE modules are subject to an enrolment process consisting of registration and initial configuration of each module within a system or network, aimed at enabling its specific functionalities. During this phase, each module is authenticated, configured, and associated with a unique digital identity.During configuration, specific operational parameters are set, such as encryption keys, communication protocols, and security rules, to adapt each SSP and SGE module to its intended role. This may include activities such as data signing, synchronization with other devices, or authentication in a decentralized environment. Furthermore, enrolment may include formal association with a parent platform, such as a central module or management server. For example, enrolment includes transfer of an NFT (Non-Fungible Token) from a central SNS module to the board to be registered and configured, to certify its integration. The SSP or SGE module receives a digital certificate defining its unique identity within the system. This certificate, often compliant with standards such as X.509, is used to authenticate the SSP or SGE module in future communications. Subsequently, the authenticated SSP or SGE module is registered in the network through creation of credentials and access parameters, which may include cryptographic keys, tokens, or other identifiers.

[0241] Enrolment takes place after deployment of SSP or SGE modules and before initiation of the third-party data certification process. Through this procedure, the SSP or SGE module is assigned:

[0242] - the shared secret required for OTP authentication;

[0243] - the digital identity of the module corresponding to an address associated on the blockchain with the specific board, referred to as a wallet;

[0244] - the digital certificate created and validated by the at least one SNS module for the SSP or SGE module, and assigned as an NFT to the wallet of the SSP or SGE module on the DLT (for example, a blockchain) .

[0245] The process concludes with a final verification to ensure all parameters have been correctly configured. Following such verification, the SSP or SGE module is active and ready to perform the required operations. This process is essential to ensure that each module is secure, traceable, and properly integrated into the system, preventing unauthorized access and ensuring that all future operations are verifiable and reliable.

[0246] Digital signatures are generated using the certificate assigned to the SSP or SGE module to attribute signing identity and comprise four main components:

[0247] - SFIA-256 hash of the data to be certified;

[0248] - the digital signature created by encrypting the digest of the data to be certified with the private key of the digital certificate of the SSP / SGE module;

[0249] - the public key of the digital certificate of the SSP / SGE module;

[0250] - the time stamp of the epoch to which the SSP / SGE module is synchronized at the time of signing and the value of its nanocounter.Digital signatures are transmitted via epoch-key-encrypted connections and, once receipt is confirmed by the Edge server, are managed to ensure high security without being stored on the board.

[0251] SSP and SGE modules operate independently from the host devices in which they are integrated, namely satellite 1 and ground devices respectively, ensuring clear separation between the system according to the invention and third-party systems.

[0252] According to one aspect of the method, both SSP and SGE modules do not verify identity of the host device and do not check consistency of received data. In the event of critical occurrences such as interruptions or tampering attempts, they are configured to reset their nanocounter.

[0253] Registration of the digital signature attributed to the host device occurs on the blockchain through smart contracts, automating the attribution process.

[0254] Digital signatures generated by SSP and SGE modules remain valid until events such as tampering, malfunction, or physical destruction of the board.

[0255] Physical security of the installation and integrity of signed data are the responsibility of the host system operator, who must ensure that certified data remain consistent for future verification.

[0256] Additional SSP and SGE modules may be integrated into the transmission chain between an originating SSP / SGE module and the Edge server.

[0257] In this configuration, the digital signature generated by the originating module is transmitted to a destination SGE device, which adds an additional digital signature. This process uses the digital certificate of the destination device and employs the pre-existing digital signature data previously indicated, namely the SHA-256 hash of the data to be certified, the digital signature created by encrypting the digest with the private key of the digital certificate of the SSP / SGE module, the public key of the digital certificate of the SSP / SGE module, and the epoch time stamp to which the SSP / SGE module was synchronized at the time of signing and the value of its nanocounter.

[0258] The enriched digital signature then proceeds along the chain until reaching the Edge server, completing a process known as “Chain of Custody.”

[0259] Unlike traditional public registration systems, digital signatures according to the system adopt a DLT to ensure public, decentralized, and highly secure storage while maintaining data confidentiality.

[0260] The process provides that the SSP / SGE module generates a digital signature and transmits it to the Society Edge server, which validates it and forwards it to the Society Bridgeservice. The latter records the signature on the blockchain, uniquely attributing it to the digital identity of host system operators.

[0261] The following describes some examples of application of the method.

[0262] Example 1: Certification of documents at source

[0263] A digital document production system uses the method to certify creation and transfer of produced documents, applicable to production, reception, and transmission devices such as sensors, digital hubs, gateways, electronic control units, and acquisition devices. Suitable systems include industrial telemetry, loT systems, document archiving systems, logistics infrastructures, systems for management and transport of persons and goods, access control systems, surveillance systems, monitoring systems, and similar solutions. In this context, SGE modules integrated into the host system receive digital documents and generate a unique digital signature unequivocally attributable to the SGE module, the digital document, and the host system. This process uses a certificate issued for the SGE module by at least one SNS module. The procedure may be executed for each digital document, each host device, or each SGE module, depending on operational requirements and availability of SNS certificates.

[0264] Example 2: Certification of satellite data at source

[0265] A satellite 1 equipped with onboard devices, such as Earth Observation payloads, uses the method to certify generation of digital files. SSP modules integrated into the host system receive files from the onboard device and produce a unique digital signature attributable exclusively to the SSP module, the digital file, and the host system. Certification occurs using a certificate issued by at least one SNS module for the SSP module. As in the previous case, the operation is repeatable for each generated file, each host device, or each SSP module, depending on specific requirements and availability of issued certificates.

[0266] Example 3: Certification of digital transactions

[0267] A third party may use the method to certify an act of transfer of tangible or intangible assets representable digitally. Two digital identities, identified by a qualified name and a certificate validated in accordance with the method, are referred to as “buyer” and “seller.”

[0268] An SGE module integrated into the host system receives digital documents associated with the transaction and generates a unique digital signature attributable to the SGE module, the digital document, and the host system.

[0269] This process is based on use of certificates issued by at least one SNS module for both involved identities. Notarization may be applied for each digital document, each host device, each SGE module, and for each digital identity of “buyer” or “seller,” depending on operational needs and availability of certificates generated by the at least one SNS module.With reference to Figures 4 and 5, an example application of the method is provided. In the listed cases, the general flow may be represented as follows:

[0270] 1. collection of validation and certificate creation requests

[0271] A System Edge server collects a list of requests consisting of:

[0272] 1.1 requests for validation of digital certificates, qualified by data according to applicable certification standards, for example X.509 v3, corresponding to digital identity certificates assigned to SSP / SGE modules, their users, or other involved parties. The Edge server verifies on the DLT the corresponding digital identities and NFTs previously registered on the DLT, referred to as “System NFT,” and, if absent, activates the identity and certificate production flow. If the request originates from an SSP / SGE module, the Edge server also verifies the provided epoch data;

[0273] 1.2 requests for creation of digital certificates, qualified by data necessary to create a digital certificate according to applicable certification standards, for example X.509 v3, to be assigned to SSP / SGE modules, their users, or other involved parties. The Edge server creates digital identities on the DLT and a corresponding NFT for the requested certificate not yet registered on the DLT, referred to as “Request NFT,” and sends the certificate creation request to the SNS module. If the request originates from an SSP / SGE module, the Edge server also verifies the provided epoch data.

[0274] 2. receipt of requests on satellites equipped with SNS module

[0275] A satellite equipped with an SNS (System Notary Source) module receives the list of requests.

[0276] 3. processing of requests on the SNS module

[0277] 3.1 validation of digital certificates: the SNS module verifies signatures contained in the certificate against corresponding public keys and:

[0278] 3.1.1 signs a specified portion of the certificate with its private key “SNS Private Key” and adds the digital signature “SNS Digital Signature”;

[0279] 3.1.2 adds its public key “SNS Public Key” to the certificate;

[0280] 3.2 creation of digital certificates:

[0281] 3.2.1 the SNS module creates an asymmetric key pair “User Private Key” and “User Public Key” corresponding to the digital identity of the requester;

[0282] 3.2.2 signs a specified portion of the certificate with the requester’s private key “User Private Key” and adds the “User Digital Signature”;

[0283] 3.2.3 signs a specified portion of the certificate with its private key “SNS Private Key” and adds the “SNS Digital Signature”;3.2.4 adds to the new certificate the public key “User Public Key,” its public key “SNS Public Key,” and necessary and ancillary data according to the used standard, e.g., X.509 v3.

[0284] 4. registration and delivery of digital certificates

[0285] The SNS module sends validated and / or created certificates to the Edge server:

[0286] 4.1 for validated certificates: if the validated certificate differs from the one submitted in the request, the Edge server registers it on the DLT as an NFT corresponding to the validated certificate (“System NFT”), sending it to a System Bridge node and verifying successful writing via transaction ID. Once registered, it transmits via encrypted connection both the new “System NFT” certificate and the transaction ID to designated holders;

[0287] 4.2 for created certificates: the Edge server registers the received certificate on the DLT as an NFT corresponding to the created certificate (“System NFT”), sending it to a System Bridge node and verifying successful writing via transaction ID. Once registered, it transmits via encrypted connection both the “System NFT” certificate and the “User Private Key” assigned.

[0288] 5. use of System certificates for digital signing

[0289] 5.1 when the “System NFT” certificate is used to certify data at origin via SSP / SGE module:

[0290] 5.1.1 the SSP / SGE device uses its “System NFT” certificate to attribute signing identity and creates digital signatures based on data received from a connected third-party device;

[0291] 5.1.2 such signatures are registered on the DLT by sending them from the SSP / SGE device to a System Bridge node through a System Edge server;

[0292] 5.2 when the certificate is used directly by the end user without SSP / SGE modules:

[0293] 5.2.1 the end user installs the “System NFT” digital certificate in its digital systems and uses it according to applicable standards and procedures.

[0294] From the foregoing, it is evident that the method achieves its intended objectives.

[0295] The computer-implementable method overcomes limitations of traditional PKI structures, offering a secure, decentralized, and scalable system for certificate and digital signature management. The combination of satellite and ground modules with a blockchain infrastructure ensures enhanced reliability, traceability, and transparency, making the system suitable for a wide range of applications, including high-security sectors such as aerospace, military, and telecommunications .

[0296] The use of at least one SNS module installed onboard satellite 1 renders the system non-vulnerable to attacks or tampering affecting exclusively terrestrial systems.

[0297] Furthermore, the certificate validation process allows verification that satellite 1 is effectively operational and has not been tampered with.The method exhibits high compatibility with standard solutions, as signatures and certificates adhere to current X.509 v3 standards, ensuring interoperability and regulatory compliance and facilitating implementation within existing infrastructures.

[0298] Certain embodiments and variants have been described; however, those skilled in the art may introduce modifications and changes without departing from the scope of protection defined by the appended claims..

Claims

CLAIMS1. Computer-implemented method for generating a digital certificate, comprising:- providing at least one satellite (1) orbiting around the Earth (E),- providing at least one data processing unit (2) on board said satellite (1),-providing at least one ground-based data processing and transmission structure (3); wherein said data processing unit (2) comprises at least one first data processing module (SNS) and at least one second data processing module (SSP) operatively connected to each other and to said satellite (1), and wherein said ground-based data processing structure (3) comprises at least one third data processing module (SGE);said at least one first data processing module (SNS) being configured to act as a certification authority (CA), and said satellite (1) acting as a host for said at least one first data processing module (SNS);- receiving a request to generate a digital certificate and sending said request to said first data processing module (SNS);- acquiring operational data of said satellite (1) through said first data processing module (SNS); - verifying said acquired data;- generating at least one digital certificate through said first data processing module (SNS) following a verification, through said acquired data, that said satellite (1) is moving along an orbit (4) with respect to the Earth (E).

2. Computer-implemented method according to claim 1, wherein said step of acquiring operational data comprises receiving input data from said satellite (1), including altitude, velocity, longitude, latitude, attitude, and angular momentum of said satellite (1).

3. Computer-implemented method according to claim 1 or 2, wherein said step of verifying comprises verifying the validity of the request to generate a digital certificate, verifying the data received from said satellite (1) by comparing them with previously received data and with mission reference data available in said first data processing module (SNS).

4. Computer-implemented method according to the preceding claim, wherein said verification comprises a step of comparing an altitude value received from said satellite (1) with data from at least one sensor comprised in said first data processing module (SNS) in order to detect any “out-of-range” conditions.

5. Computer-implemented method according to any one of the preceding claims, comprisinga step of calculating and verifying a timestamp parameter through said at least one first data processing module (SNS) and a processing system comprised in said ground-based data processing structure (3), wherein said step of calculating said timestamp exploits Lorentz -Einstein transformations to account for a time dilation phenomenon to which said at least one first data processing module (SNS) on board said satellite (1) in orbit is subject with respect to said ground-based data processing structure (3).

6. Computer-implemented method according to claim 5, wherein said at least one first data processing module (SNS), said second data processing module (SSP), and said ground-based data processing structure (3) each comprise a nanocounter processor configured to measure a time quantity equal to one nanosecond, wherein said method comprises synchronizing said at least one first data processing module (SNS) and said ground-based data processing structure (3) by means of a time signal (GPS).

7. Computer-implemented method according to claim 6, comprising a step of verifying a difference in time counts performed by said nanocounter on board said first data processing module (SNS) and by said nanocounter comprised in said ground-based data processing structure (3), comparing said difference in time counts with an expected value, and performing said comparison over a period defined as an epoch.

8. Computer-implemented method according to claim 7, wherein said comparing comprises executing a control flow comprising two phases: an “epoch seed” start-period phase and an “epoch start” end-period phase, in order to synchronize and temporally validate said timestamp parameter.

9. Computer-implemented method according to claim 8, wherein during said start-period phase said at least one first data processing module (SNS) stores an initial value of its own nanocounter and a GPS time, said storing comprising acquiring said initial values upon establishment of a communication between said at least one first data processing module (SNS) and a ground antenna (6) comprised in said ground-based data processing structure (3) during a first pass of said satellite (1) over said antenna (6); and wherein during said end-period phase said at least one first data processing module (SNS) acquires a new value of its own nanocounter and an updated GPS time during a second pass of said satellite (1) over said ground antenna (6), said method comprising sending data relating to the end-of-count time of said nanocounter to said ground-based data processing structure (3), said ground-based data processing structure (3)recording a value of its own local nanocounter at the moment of receipt of said data from said first data processing module (SNS) and associating a corresponding GPS time, wherein said ground-based data processing structure (3) compares the value of said local nanocounter with that of said at least one first data processing module (SNS), determines a count difference between the two nanocounters, and sends to said at least one first data processing module (SNS) a validation message containing the verified data.

10. Computer-implemented method according to claim 9, comprising the step of receiving, in said at least one first data processing module (SNS), said validation message, verifying the correctness of said data comprised in said message, generating and signing said digital certificates through said at least one first data processing module (SNS) by referring them to the current epoch.

11. Computer-implemented method according to claim 1, wherein:- said step of acquiring operational data of said satellite (1) comprises acquiring at least orbital parameters selected from altitude, velocity, longitude, latitude, attitude, and angular momentum; - said step of verifying comprises verifying the operating conditions of said satellite (1) by comparing said orbital parameters with previously received data and with mission reference data stored in said first data processing module (SNS);and wherein the generation of said at least one digital certificate takes place following verification of said operating conditions of the satellite (1) along its orbit (4) around the Earth (E).

12. Computer-implemented method according to any one of the preceding claims, wherein said step of verifying the operational data of the satellite (1) comprises comparing orbital parameters received from satellite navigation systems with parameters measured by at least one independent sensor on board the satellite (1).

Images