DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 12/29/2025. Claims 1, 11, and 21 are amended. Claims 1-22 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 17/538,451.
Response to Argument
Applicant’s arguments see pages 15-19 of remarks, filed 12/29/2025, with respect to claims 1-22 rejection under U.S.C. 112, First Paragraph, and under U.S.C. 112, Second Paragraph, have been fully considered and are persuasive. The rejections have been withdrawn.
Applicant’s arguments with respect to claims 1, 11, and 21 for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-22 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US20100217986) issued to Schneider (filed in IDS 07/14/2022) and in view of US Patent No. (US2021/0111875) issued to Le Saint, and further in view of KIM (US2015/0312759), and further in view of Wang (US2021/0350021), and further in view of Proulx ( US2016/0140335).
Examiner Note: Examiner is unclear with:
If one the receiving device is offline or compromised, then how the receiving device will be able to send any response or error signals even when it has sent its consent to the trustor device to join the trustor-trustee relationship? If all the receiving devices are trustee devices with TEE including a storage, then where else the receiving device can store the secret share before sending an error message? Is it stored in the main memory of the receiving device in a non-secure environment of the trustee device?
Regarding claims 1, and 11 Schneider discloses A method executed by a first electronic device, the method comprising [ see FIG. 1, distributor 103]; and
splitting a selected secret for backup into N secret shares in a trusted execution environment (TEE) of the first electronic device [0022] FIG. 1 illustrates an exemplary cryptosystem 100 in which embodiments of the present invention may operate. The cryptosystem 100 includes a plurality of recipients 101 and a distributor 103(equated to the first computing device) coupled by a network 102, which may be a public network (e.g., Internet) or a private network (e.g., Ethernet or a Local Area Network (LAN)). In one embodiment, each of the distributor 103 and recipients 101 is a computing system that manages secret information (equated to TEE environment). Alternatively, the distributor 103 may be a computing system and each recipient 101 may be a storage device (equated to data storage within the TEE environment) for receiving and storing one or more shares of a secret. The distributor 103 is locally coupled to data storage 105 in which a secret 106 is stored (equated to TEE environment). Data storage 105 may include one or more storage devices (e.g., the computer-readable medium described above) that are local to the distributor 103 and/or remote from the distributor 103. In alternative embodiments, the secret 106 may be stored in the main memory of the distributor 103. In one embodiment, the secret 106 may be a cryptographic key, a password, or any secret data to be jointly held in escrow by the recipients 101], and [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 ( equated to the first computing device) determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶31, At block 240, the distributor 103 constructs a secret splitting polynomial of degree (K-1) with K coefficients, where K is the threshold number of shares for reconstructing the secret...], and
transferring, via a transceiver of the first electronic device, the N secret shares to N trustee devices, in order to transfer each secret share from among the N secret shares to a different trustee device from among the N trustee devices, wherein each secret share is configured to, when received by a trustee device, request the trustee device to store the secret share in a data storage within a TEE of the trustee device [0022] FIG. 1 illustrates an exemplary cryptosystem 100 in which embodiments of the present invention may operate. The cryptosystem 100 includes a plurality of recipients 101(equated to trustee device) and a distributor 103(equated to the first computing device) coupled by a network 102, which may be a public network (e.g., Internet) or a private network (e.g., Ethernet or a Local Area Network (LAN)). In one embodiment, each of the distributor 103 and recipients 101 is a computing system that manages secret information (equated to TEE environment). Alternatively, the distributor 103 may be a computing system and each recipient 101 may be a storage device for receiving and storing one or more shares of a secret. The distributor 103 is locally coupled to data storage 105 in which a secret 106 is stored (equated to TEE environment). Data storage 105 may include one or more storage devices (e.g., the computer-readable medium described above) that are local to the distributor 103 and/or remote from the distributor 103. In alternative embodiments, the secret 106 may be stored in the main memory of the distributor 103. In one embodiment, the secret 106 may be a cryptographic key, a password, or any secret data to be jointly held in escrow by the recipients 101], and [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 ( equated to the first computing device) determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶32] Continuing to block 250, the distributor 103 evaluates the splitting polynomial at N non-zero random points (also referred to as "evaluation points") in the chosen field or ring. The evaluation is performed by arithmetic logic circuits of the share constructor 132 (e.g., adders, subtractors, multipliers and/or dividers, etc.). The evaluations generate N result values, with one result value corresponding to one evaluation point. At block 260, the distributor 103 generates N shares of the secret, with each share including one of the evaluation points and the corresponding result value. At block 270, the distributor 103 then distributes the N shares to the recipients 101 and the method 200 terminates], and [see Figs 1, 2 and corresponding text for more details].
Schneider does not explicitly disclose, however, LeSaint discloses:
Over N respective over a short-range device-to device (D2D) transmission 9[¶5, devices registered into the peer-to-peer network (equated to device-to device (D2D) transmission) may be capable of establishing a shared data encryption key (DEK). Each device may be configured to obtain a share of a data encryption key (DEKi) that can be stored locally]., and [¶34, an example system includes N devices. The devices may be connected via network interfaces that allow for the exchange of data. For example, the devices may each comprise network interfaces for connecting over a wired and/or wireless communications network, such as through Ethernet, cellular telecommunications, Bluetooth, WIFI, and/or any other form of electromagnetic signaling, such as radio signaling, optical signaling, microwave relay, etc.].
in a trusted execution environment (TEE) of the first electronic device; a TEE of the trustee device; determining whether the transferred N secret shares are stored in the data storages within the TEEs of the N trustee devices based on (i) reception of an acknowledgements transmitted from each of one or more the trustee devices confirming the transferred secret share is stored in the data storages within TEE of the trustee device and (ii) reception of an error transmitted from each of one or more others of the trustee devices warning the transferred secret share is not stored in the data storages within TEE of the trustee device[¶5, devices registered into the peer-to-peer network may be capable of establishing a shared data encryption key (DEK). Each device may be configured to obtain a share of a data encryption key (DEKi) that can be stored locally. The shares may be shares in an M of N (e.g., Shamir’s) Secret Sharing Scheme], and [¶25, The term “secret sharing scheme” can refer to a method for distributing a secret amongst N participants, each of which can be referred to as a “share.” In this manner, the secret can be protected even if one participant is compromised (will produce error message). The secret sharing scheme can be a “threshold scheme,” in which a threshold number M of participants within the group of participants are required to reconstruct the secret, M less than or equal to...], and [0030] Embodiments described herein are directed to systems, methods, and devices for secure peer-to-peer communication. For example, embodiments describe shared key establishment for a network of N devices in which a data encryption key can be generated from shares of M of N devices in the network. In embodiments, a secure peer-to-peer network can be created between the devices, so long as the devices have established trust. Trust can be established between the N devices by generating certificates for each device and adding each certificate to a registry. The certificates may provide proof of inclusion (i.e., registration) into the trusted peer-to-peer network, such that devices in the network may utilize the secure key establishment methods described herein. Each device may locally store its own certificate as well as its own copy of the registry comprising the certificates of the other device in the network]., and [0035] FIG. 1 shows an exemplary network 100 according to embodiments of the invention. FIG. 1 shows a plurality of devices of a peer-to-peer network, such as first trusted device 11, second trusted device 12, requesting trusted device 10, Mth trusted device 13, Nth trusted device 14, etc. According to embodiments, any number of devices (e.g., ranging from a quantity of 2 to N devices) may be connected in the network via one or more network interfaces of each device. The devices of the network may further establish a trust relationship with one another via a registration into the network], and [, and [0051] At step 303, at least M−1 encrypted shares of the data encryption key is received by the requesting device from the M−1 devices. In one embodiment, each of the M−1 devices may retrieve a locally stored DEK share and may encrypt the DEK share using the public key of the requesting device. In one embodiment, each of the M−1 devices may reference a local registry to determine if the requesting device is included in the trusted network. In one embodiment, the local registry may comprise the certificates of every computing device registered into the trusted network, i.e., N certificates for N devices. In another embodiment, the registry of certificates may not be stored on the devices but be located in an online repository shared by the devices. Individual certificates may be obtained upon request. e.g., using a lightweight directory access protocol (LDAP) query. Thus, each of the N devices can be communicably coupled to a registry of certificates that correspond to devices that belong to the trusted network, thereby enabling any one of the N devices to authenticate another device as being in the trusted network], and [0085] At step 9, the requesting server Si 610 may generate the DEK using the M DEK shares. In one embodiment, the DEK may be generated from the M DEK shares according to Shamir's secret-sharing scheme. For example, the DEK may be a string of characters or a very large number, which can be expressed as an unknown term of a polynomial, and each of the DEK share values may represent random numbers that may serve as coefficients for other terms of the polynomial. The requesting server Si 610 may then be configured to reconstruct the polynomial from M shares to determine the DEK, such as through interpolation or other suitable method. In one embodiment, further authentication steps may be performed/may be required before generation of the DEK. For example, server Si 610 may configure to check the location, status, authentication state, and/or system parameters of one or more computing devices in the trusted network to verify that the one or more computing devices in the network have not been compromised], and [Abstract, ¶32].
Examiner Note: as it is indicated in LeSaint application, the server Si 610 (requesting server) may configure to check the location, status, authentication state, and/or system parameters of one or more computing devices (trusted devices) in the trusted network to verify that the one or more computing devices in the network have not been compromised which interpreted that either the device is trusted and acknowledgment will send out that the device is a trusted device to store the share of a data encryption key or receive an error message will be produced since the device is compromised an is not a trusted device to store a share of a data encryption key.
and determining whether backup of the selected secret to the N trustee devices is incomplete based on a determination result of whether the transferred N secret shares are stored in the data storages within the TEEs of the N trustee devices
While Schneider discloses [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶31, At block 240, the distributor 103 constructs a secret splitting polynomial of degree (K-1) with K coefficients, where K is the threshold number of shares for reconstructing the secret...], and [¶32, Continuing to block 250, the distributor 103 evaluates the splitting polynomial at N non-zero random points (also referred to as "evaluation points") in the chosen field or ring. The evaluation is performed by arithmetic logic circuits of the share constructor 132 (e.g., adders, subtractors, multipliers and/or dividers, etc.). The evaluations generate N result values, with one result value corresponding to one evaluation point. At block 260, the distributor 103 generates N shares of the secret, with each share including one of the evaluation points and the corresponding result value. At block 270, the distributor 103 then distributes the N shares to the recipients 101 and the method 200 terminates], and [see Figs 1, 2 and corresponding text for more details], and [Abstract].
Furthermore, LeSaint discloses: [¶48, FIG. 3 shows a flowchart for a method according to embodiments of the invention. The method may be directed to establishing a data encryption key that can be split into parts and shared between devices in a trust network. In one embodiment, the method can be implemented by devices in network 100 of FIG. 1. For example, the method may describe requesting trusted device 10 of FIG. 1 requesting key parts or shares from other devices in network 100. The shares may be requested via share requests, and each share request may be received by each device. M−1 devices in a trusted network may receive a share request so that M−1 DEK shares can be obtained by the requesting device. For example, DEKj. DEKk, and DEKm may be retrieved and obtained from first trusted device 11, second trusted device 12, and mth trusted device 13 of FIG. 1 respectively. The M−1 obtained shares can be decrypted and, along with a local share of requesting trusted device 10 (i.e., DEKi of FIG. 1), may result in M of N shares for generating a data encryption key (DEK).]], and [¶5, devices registered into the peer-to-peer network may be capable of establishing a shared data encryption key (DEK). Each device may be configured to obtain a share of a data encryption key (DEKi) that can be stored locally. The shares may be shares in an M of N (e.g., Shamir’s) Secret Sharing Scheme], and []25, The term “secret sharing scheme’ can refer to a method for distributing a secret amongst N participants, each of which can be referred to as a “share.” In this manner, the secret can be protected even if one participant is compromised (equated to storing in secure environment such as TEE, will produce error message). The secret sharing scheme can be a “threshold scheme,” in which a threshold number M of participants within the group of participants are required to reconstruct the secret, M less than or equal to...], and [[35, FIG. 1 shows an exemplary network 100 according to embodiments of the invention. FIG. 1 shows a plurality of devices of a peer-to-peer network, such as first trusted device 11, second trusted device 12, requesting trusted device 10, Mth trusted device 13, Nth trusted device 14, etc. According to embodiments, any number of devices (e.g., ranging from a quantity of 2 to N devices) may be connected in the network via one or more network interfaces of each device. The devices of the network may further establish a trust relationship with one another via a registration into the network], and [Abstract, J38[, In embodiments, a requesting trusted device 10 may request data encryption key shares from the other trusted computing devices of the network, for generating the DEK. M shares may be required for generating the DEK, such that the DEK can be obtained and used to perform the desired cryptographic operation (encryption or decryption). Requesting trusted device 10 may request DEK shares from M-1 trusted devices, which may be stored locally on each device], and []85, At step 9, the requesting server Si 610 may generate the DEK using the M DEK shares. In one embodiment, the DEK may be generated from the M DEK shares according to Shamir's secret-sharing scheme. For example, the DEK may be a string of characters or a very large number, which can be expressed as an unknown term of a polynomial, and each of the DEK share values may represent random numbers that may serve as coefficients for other terms of the polynomial. The requesting server Si 610 may then be configured to reconstruct the polynomial from M shares to determine the DEK, such as through interpolation or other suitable method. In one embodiment, further authentication steps may be performed/may be required before generation of the DEK. For example, server Sk 610 may configure to check the location, status, authentication state, and/or system parameters of one or more computing devices in the trusted network to verify that the one or more computing devices in the network have not been compromised].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Schneider, by incorporating “wired and/or wireless communications network, such as through Ethernet, cellular telecommunications, Bluetooth, WiFi, and/or any other form of electromagnetic signaling”’, as taught by LeSaint. One could have been motivated to do so in order for providing secure peer-to-peer communication for devices in a trusted network that allows for the exchange data [ Le Siant, Abstract, ¶¶33-34].
trusted execution environment (TEE
While Schneider discloses this limitation as: each of the distributor 103 and recipients 101 is a computing system that manages secret information (equated to TEE environment), and the distributor 103 may be a computing system and each recipient 101 may be a storage device (equated to data storage within the TEE environment) for receiving and storing one or more shares of a secret.
And furthermore, LeSaint discloses this limitation as: trusted devise, and each of the M−1 devices may retrieve a locally stored DEK share and may encrypt the DEK share using the public key of the requesting device. In one embodiment, each of the M−1 devices may reference a local registry to determine if the requesting device is included in the trusted network
however, Schneider, and LeSaint do not explicitly disclose this limitation and Kim discloses: [Abstract, A mobile device and methods for sharing content are provided. The mobile device includes a communicator configured to communicate with at least one external device; and a controller configured to control decryption of encrypted content that is shared with the at least one external device, in response to determining that the mobile device is located within a proximate spacing of the at least one external device], and [ 0016] The mobile device may further include a storage configured to store at least one of a partial key allocated to the mobile device, from among the plurality of partial keys, and the encryption key], and [0020] The communicator may comprise a short-range wireless communication module that includes at least one of a near field communication (NFC) module, a Bluetooth module, a WiFi module, and a ZigBee module, wherein the communicator is configured to determine whether the mobile device is located within the proximate spacing of the at least one external device.], and [0112] In operation S620, the first device 100 splits the private key t into three parts, and thus, generates first through third partial keys. For example, the first device 100 may generate at least first through third partial keys t1 through t3 by splitting the private key t into three parts. In this case, the first device 100 may split the private key t by using a secret sharing scheme, such as a Shamir scheme], and [0169] In operation S1120, the first device 100 splits the private key into at least 2 parts, and thus, generates at least first and second partial keys. For example, the first device 100 may generate at least the first and second partial keys t1 and t2 by splitting the private key t into at least 2 parts. In this case, the first device 100 may split the private key t by using a secret sharing scheme such as a Shamir scheme], and [0286] One of the first through third devices 500 through 700 may generate and store content, and the server 800 may encrypt content. The encrypted content may be copied and shared between the first through third devices 500 through 700. At least one selected of the first through third devices 500 through 700 may store the encrypted content in a security zone, for example, TrustZone or other hardware-based security architecture, and thus, protect the encrypted content by using hardware. According to another exemplary embodiment, the server 800 store encrypted content, and the stored content may be shared between the first through third devices 500 through 700.
Examiner Note: Internet search indicates that: AL overview: TrustZone is a hardware-based security architecture that protects code and data by separating secure and non-secure worlds. Furthermore, KIM (US2021/0279334) discloses the ARM Trustzone Architecture; however, this reference is not used in mapping the limitation and mentioned here just for informational purposes. [0027] The secure world may mean a secure data processing architecture, and the normal world may mean a general data processing architecture that is not secure. As an exemplary embodiment, the main processor 110 may operate based on the “ARM Trustzone Architecture”. This architecture may include two runtime environments, and one of them, a non-secure runtime environment (e.g., a Rich Execution Environment (REE)), may be referred to as a normal zone or a normal world, and may be controlled by a normal operating system. Another runtime environment, a secure runtime environment (e.g., a Trusted Execution Environment (TEE)), may be referred to as a Trustzone or TrustedWorld or Secure World, and the secure runtime environment may be controlled by a secure operating system].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Schneider, and Le Saint. by incorporating “Trustzone Architecture”’, as taught by Kim. One could have been motivated to do so in order protect the encrypted content and protect content private key in a security zone by implementing a Trustzone architecture hardware. [ Kim, Abstract, ¶¶83, 131].
Schneider, and Le Saint, and Kim do not explicitly disclose, however, Wang discloses:
individually transmitting signed requests for user consent to establish N trustee devices in trustor-trustee relationships in which the first electronic device is designated as a trustor; based on receiving the user consent signed by each of the N trustee devices [¶11, The subject matter described in this specification can be implemented in particular embodiments so as to realize one or more of the following advantages. Using attestation tokens described in this document to communicate user consent settings to other entities ensures that the user consent settings were received from the user and enables the entities to technically verify the user's consent. The attestation tokens use digital signature schemes to prevent entities from falsifying users' consent, thereby preserving data security. The attestation tokens securely link user identifiers with user data and with user consent settings such that the entities that receive the user data can verify the user's consent to use the user data in accordance with the user consent. In this way, a user is provided with a mechanism in which they can manage their data in a secure way when dealing with multiple entities], and [¶25, The user consent settings can be sent from a client device of the user in the form of an attestation token. The attestation token can include the consent settings and a digital signature of the consent settings and other data such that any modification to the user consent settings after creation can be detected. The signed data can include a unique identifier for the user so that recipients of the attestation token can verify that the attestation token was sent from a device of the user. The attestation token can also include an integrity token, e.g., a device integrity token and/or a browser integrity token, so that recipients can verify that the attestation token was received from a trusted device or trusted web browser or other application].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of b Schneider, Le Saint, and Kim. By incorporating “user consent setting in the form of attestation setting which includes digital signature”’, as taught by Wang. One could have been motivated to do so in order to verify that the attestation token was sent from a device of the user. The attestation token can also include an integrity token, e.g., a device integrity token and/or a browser integrity token, so that recipients can verify that the attestation token was received from a trusted device or trusted web browser or other application. [ Wang, ¶25].
Schneider, Le Saint, and Kim, do not explicitly disclose, and while Wang discloses individually transmitting signed requests for user consent to establish N trustee devices in trustor-trustee relationships in which the first electronic device is designated as a trustor [ ¶¶11, 25], however, furthermore Proulx discloses : individually transmitting signed requests for user consent to establish N trustee devices in trustor-trustee relationships in which the first electronic device is designated as a trustor ;Setting an identifier of each respective one of the N trustee devices as a trustee device [¶¶31-32, In one or more particular embodiments, an ARB is encrypted with an ARK referred to as an ARB_ARK. The ARK secret is held or stored only by the account holder (e.g., the forgetful user). In one or more embodiments, the ARK secret is split into a predetermined number m pieces, and each piece is securely shared with an ARP Trusted Friend (ARPTF) to be kept in escrow until needed while the contents of the ARK secret and pieces are hidden from the point of view of the ARPTF… In particular embodiments, a trusted friend is invited by the account holder to be an ARPTF and has the option to accept or reject the invitation. In particular embodiments, the account holder can modify the list of ARTFs at will. In one or more embodiments, the ARK secret is split and shared to the ARPTFs via Shamir's Secret Sharing (SSS). SSS is a cryptographic algorithm in which a secret is divided into a predetermined number of parts, giving each participant its own unique part, where some or all of the parts are needed to reconstruct the secret… In the embodiment illustrated in FIG. 2, user B associated with second client device 202b, user C associated with third client device 202c, user D associated with fourth client device 202d, user E associated with fifth client device 202e, and user F associated with sixth client device 202f are each designated as trusted friends, or ARPTFs, of the account holder user A associated with first client device 202a.], and [¶¶38-39, User A is associated with first client device 202a having a client application, password application 212a, that user A uses to interact with authentication server 206. Users B, C, D, E, F—are members of user A's trusted friends (i.e. ARPTFs) with whom User A shares pieces of his account recovery key (ARK). As discussed, the ARK is a randomly generated secret key used to encrypt the ARB that is held only by the account holder (user A) and is split into m pieces, each securely shared with a Trusted Friend (e.g., users B, C, D, E, F)], and [¶¶44-46, In 320, password manager application 212a displays the contact list to user A. In 322, user A selects the friends from the contact list that user A trusts to participate in the account recovery protocol (ARP) as ARPTFs. In 324, password application 212a displays the updated contact list to user A and prompts user A to confirm the selections. In 326, user A confirms the ARPTF invites to password manager application 212a. …In 334, password application 212a splits the ARK into a predetermined number m pieces (the number of ARPTFs selected). In a particular embodiment, password application 212a splits the ARK into the predetermined number of pieces using Shamir's Secret Sharing (SSS). As a result, a complete list of shared pieces is generated in which each shared piece (ARK-Px) is kept in escrow as hidden in an ARPTF's account and may later be used to recover the ARK. In one or more embodiments, SSS parameters are set up so that there is a consensus of user A's ARPTFs (e.g., >=50%)—i.e. 3 of 5 required in order to recover the ARK. In particular embodiments, these security parameters may be adjusted as a tradeoff between convenience and consensus].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of b Schneider, Le Saint, and Kim, and Wang, by incorporating “Shamir's Secret Sharing (SSS).”’, as taught by Proulx. One could have been motivated to do so in order to generate an ARK ( account recover key) by account holder and split it into m pieces, select the friend from the contact list that the user trust to participate in the account recovery protocol (ARP) as ARPTFs , and securely sharing each with a Trusted Friend [ Proulx, ¶¶ 31, 44-46].
Regarding claims 2, and 12, Schneider discloses the method of Claim 1, further comprising: computing integrity information for each of the N secret shares; appending, to each of the N secret shares, the computed integrity information of the N secret shares; and detecting a hacked trustee device based on comparing a consensus of integrity information of the N secret shares to integrity information appended to a secret share retrieved from the hacked trustee device [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S). At block 220, a random number is generated. The random number is to be used as a key in the generation of a message authentication code (MAC), e.g., a keyed-Hash Message Authentication Code (abbreviated as HMAC or KHMAC). The MAC can be used to verify data integrity and the authenticity of a reconstructed secret. The length and the quality of the key can be selected to satisfy a desired cryptographic strength of the MAC.
Regarding claims 3, and 13, Schneider discloses, further comprising: receiving a subset of configuration selections that include a number K of secret shares required to reconstruct the secret from the N secret shares, wherein K is less than N [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶31, At block 240, the distributor 103 constructs a secret splitting polynomial of degree (K-1) with K coefficients, where K is the threshold number of shares for reconstructing the secret...], and [ see FIGs.1 and 2 and corresponding text for more details].
Regarding claims 4, and 14, Schneider discloses, further comprising, after determining that the backup of the selected secret to the N trustee devices is completed: retrieving, via the at least one transceiver o, a subset of K secret shares from a subset of K trustee devices; and reconstructing the selected the secret from the subset of K retrieved secret shares [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶31, At block 240, the distributor 103 constructs a secret splitting polynomial of degree (K-1) with K coefficients, where K is the threshold number of shares for reconstructing the secret...], and see FIGs.1 and 2 and corresponding text for more details].
Regarding claims 5, and 15, Schneider discloses, wherein reconstructing the selected secret from the subset of K retrieved secret shares comprises: in response to completing retrieval of the subset of K secret shares from the subset of K trustee devices, determining whether some of the retrieved secret shares have incorrect hashes; removing each of the retrieved secret shares that has an incorrect hash; and replacing each removed secret share by retrieving a secret share from another trustee device [¶32, Continuing to block 250, the distributor 103 evaluates the splitting polynomial at N non-zero random points (also referred to as "evaluation points") in the chosen field or ring. The evaluation is performed by arithmetic logic circuits of the share constructor 132 (e.g., adders, subtractors, multipliers and/or dividers, etc.). The evaluations generate N result values, with one result value corresponding to one evaluation point. At block 260, the distributor 103 generates N shares of the secret, with each share including one of the evaluation points and the corresponding result value. At block 270, the distributor 103 then distributes the N shares to the recipients 101 and the method 200 terminates], and [see Figs 1, 2 and corresponding text for more details].
Regarding claims 6, and 16, Schneider discloses, wherein reconstructing the selected secret from the subset of K retrieved secret shares comprises: identifying a selected algorithm for generating the N secret shares and reconstructing the selected secret, the selected algorithm having been applied to the selected secret during the splitting; and generating a reconstructed secret by applying the identified selected algorithm to the subset of K secret shares [¶36, The shares will be the N equations, or a representation of the N equations, in step (4). For more required shares (e.g., K>4), additional random components can be generated in step (3). For example, to require five shares for secret reconstruction (e.g., K=5), random components R and Q can be generated in step (3), and the equations will have a solution at (R, Q, key, M, S). In an example where K=3, the R component can be eliminated. To reconstruct the secret, K shares are collected to obtain K of the equations. The K equations can be solved to obtain the key, the secret, M and the other (K-3) random components. The reconstructed secret can be verified by computing the MAC of the reconstructed secret and compare the MAC with the M value in the solution.
Regarding claims 7, and 17, Schneider discloses, further comprising: receiving a subset of configuration selections that includes a selected algorithm for generating the N secret shares and reconstructing the selected secret, wherein the selected algorithm supports: backup of the selected secret to up to the N trustee devices; an ability of any subset of K trustee devices being able to reconstruct the secret from K secret shares; an inability of fewer than K trustee devices cannot reconstruct of the secret; and encryption of the N secret shares such that none of the trustee devices is able to access the secret selected by decrypting the secret share transferred to the trustee device [¶30, At block 230, the distributor 103 computes the MAC (represented as M) over the secret using the random key and a hash function (e.g., MD5, SHA-1, or any iterative cryptographic hash functions) based on MAC algorithms known in the art. For example, an MAC over S can be computed as M=h((key xor opad).parallel.h((key xor ipad).parallel.S)), where h is a hash function, "key" is the random key, "opad" and "ipad" are values constructed to be the same length as the key and are used to guarantee that the data being hashed do not share a common prefix, "xor" is an exclusive--or operator and "II" represents concatenation. Other MAC algorithms can also be used to calculate the MAC.
Regarding claims 8, and 18, further comprising: receiving a subset of configuration selections that include a number K2 of secret shares required to reconstruct a second secret, from a plurality of secret shares that were generated by a second electronic device; retrieving, via the at least one transceiver froms with a second plurality of trustee devices, K2 secret shares that were generated by the second electronic device; and reconstructing the second secret from the K2 retrieved secret shares.
Wang does not explicitly disclose, however, the combination of Schneider and LeSaint, Kim, and Proulx discloses these limitations as:
Schneider discloses: [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶31, At block 240, the distributor 103 constructs a secret splitting polynomial of degree (K-1) with K coefficients, where K is the threshold number of shares for reconstructing the secret...], and see FIGs.1 and 2 and corresponding text for more details].
LeSaint discloses: [¶5, devices registered into the peer-to-peer network may be capable of establishing a shared data encryption key (DEK). Each device may be configured to obtain a share of a data encryption key (DEKi) that can be stored locally. The shares may be shares in an M of N (e.g., Shamir’s) Secret Sharing Scheme], and [¶25, The term “secret sharing scheme” can refer to a method for distributing a secret amongst N participants, each of which can be referred to as a “share.” In this manner, the secret can be protected even if one participant is compromised. The secret sharing scheme can be a “threshold scheme,” in which a threshold number M of participants within the group of participants are required to reconstruct the secret, M less than or equal to] and [¶34, an example system includes N devices. The devices may be connected via network interfaces that allow for the exchange of data. For example, the devices may each comprise network interfaces for connecting over a wired and/or wireless communications network, such as through Ethernet, cellular telecommunications, Bluetooth, WIFI, and/or any other form of electromagnetic signaling, such as radio signaling, optical signaling, microwave relay, etc.], and [Abstract].
Kim discloses [ 0112] In operation S620, the first device 100 splits the private key t into three parts, and thus, generates first through third partial keys. For example, the first device 100 may generate at least first through third partial keys t1 through t3 by splitting the private key t into three parts. In this case, the first device 100 may split the private key t by using a secret sharing scheme, such as a Shamir scheme], and [0144] According to the method of generating a plurality of partial keys by splitting the private key which is described with reference to FIGS. 6 through 8, one of the first through third devices 100 through 300 which are included in the security group 10 may independently encrypt content. However, when devices amounting to a value equal to or greater than a threshold value, from among the first through third devices 100 through 300 included in the security group 10, are located within a proximate spacing between each other, a private key may be recovered from each stored partial keys, and thus, the encrypted content may be decrypted], and [¶¶164].
Proulx discloses [ ¶¶31-32, 38-39, 44-46].
Regarding claims 9, and 19, Schneider discloses, further comprising: receiving a subset of configuration selections that includes at least one assignment of an identifier of one of the N trustee devices to a specific one of the secret shares to be transferred to the assigned trustee device [¶39, Referring to FIG. 3B, the re-constructor 104 includes the receiving interface 141 to collect shares and to provide collected shares to the interpolating unit 142. In one embodiment, the interpolating unit 142 includes one or more multipliers 344, dividers 345, adders 346 and subtractors 347 for generating interpolating polynomials and reconstructing the splitting polynomial. Additional computation units can also be included. The secret (S), the authentication code (M) and the key extracted from the splitting polynomial are sent to the authentication unit 143 for authentication. In one embodiment, the authentication unit 143 includes a hash unit 341 for computing a hash value, an xor operator 342 and a concatenator 343 to perform the same computations as the MAC calculator 132. Different hardware components may be included to implement different MAC algorithms], and [ see Figs. 1-2, 3A-#b and corresponding text for more details].
Regarding claims 10, and 20, Schneider discloses, further comprising: identifying a security policy including one or more rules applicable to the at least one assignment; determining whether the at least one assignment complies with the one or more rules; and one of: in response to determining a particular assignment does not comply with the security policy, disallowing the specific one of the secret shares from being transferred to the assigned trustee device; or in response to determining the particular assignment complies with the security policy, allowing transfer of the specific one of the secret shares to the assigned trustee device [¶41... If, at block 450, the authentication unit 143 verifies that MAC(S, Key)=M, the reconstructed secret S is authenticated to be the secret (block 470). If MAC(S, Key) is not equal to M, at block 460, the value of Q (the number of collected shares) is incremented and the method 400 returns to block 410 to collect more shares. ...], and [see Figs. 1-2, 4 and corresponding text for more details].
Regarding claim 21, the subject matter of independent claim 21 contains the corresponding features as the method of claim 1 expressed respectively in analogous terms and additionally the features disclosed in 21: KIM (US2015/0312759) discloses wherein the trustee electronic device further comprises a non-secure execution environment outside of the TEE of the trustee electronic device [Abstract, A mobile device and methods for sharing content are provided. The mobile device includes a communicator configured to communicate with at least one external device; and a controller configured to control decryption of encrypted content that is shared with the at least one external device, in response to determining that the mobile device is located within a proximate spacing of the at least one external device], and [ 0016] The mobile device may further include a storage configured to store at least one of a partial key allocated to the mobile device, from among the plurality of partial keys, and the encryption key], and [0020] The communicator may comprise a short-range wireless communication module that includes at least one of a near field communication (NFC) module, a Bluetooth module, a WiFi module, and a ZigBee module, wherein the communicator is configured to determine whether the mobile device is located within the proximate spacing of the at least one external device.], and [0112] In operation S620, the first device 100 splits the private key t into three parts, and thus, generates first through third partial keys. For example, the first device 100 may generate at least first through third partial keys t1 through t3 by splitting the private key t into three parts. In this case, the first device 100 may split the private key t by using a secret sharing scheme, such as a Shamir scheme], and [0169] In operation S1120, the first device 100 splits the private key into at least 2 parts, and thus, generates at least first and second partial keys. For example, the first device 100 may generate at least the first and second partial keys t1 and t2 by splitting the private key t into at least 2 parts. In this case, the first device 100 may split the private key t by using a secret sharing scheme such as a Shamir scheme], and [0286] One of the first through third devices 500 through 700 may generate and store content, and the server 800 may encrypt content. The encrypted content may be copied and shared between the first through third devices 500 through 700. At least one selected of the first through third devices 500 through 700 may store the encrypted content in a security zone, for example, TrustZone or other hardware-based security architecture, and thus, protect the encrypted content by using hardware. According to another exemplary embodiment, the server 800 store encrypted content, and the stored content may be shared between the first through third devices 500 through 700.
Examiner Note: Internet search indicates that: AL overview: TrustZone is a hardware-based security architecture that protects code and data by separating secure and non-secure worlds. Furthermore, KIM (US2021/0279334) discloses the ARM Trustzone Architecture; however, this reference is not used in mapping the limitation and mentioned here just for informational purposes. [0027] The secure world may mean a secure data processing architecture, and the normal world may mean a general data processing architecture that is not secure. As an exemplary embodiment, the main processor 110 may operate based on the “ARM Trustzone Architecture”. This architecture may include two runtime environments, and one of them, a non-secure runtime environment (e.g., a Rich Execution Environment (REE)), may be referred to as a normal zone or a normal world, and may be controlled by a normal operating system. Another runtime environment, a secure runtime environment (e.g., a Trusted Execution Environment (TEE)), may be referred to as a Trustzone or TrustedWorld or Secure World, and the secure runtime environment may be controlled by a secure operating system].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Schneider, and Le Saint. by incorporating “Trustzone Architecture”’, as taught by Kim. One could have been motivated to do so in order protect the encrypted content and protect content private key in a security zone by implementing a Trustzone architecture hardware. [ Kim, Abstract, ¶¶83, 131].
Regarding claim 22, receive, from a recovery electronic device, a request to transfer the secret share to the recovery electronic device, wherein the request contains an identifier of the source electronic device; establish a short-range D2D communications connection to the recovery electronic device; and transfer, to the recovery electronic device, the secret share corresponding to the identifier of the source electronic device.
Wang does not explicitly disclose, however, the combination of Schneider and LeSaint, Kim, and Proulx discloses these limitations as:
Schneider discloses: [¶29, Referring to FIG. 2, at block 210, the method 200 begins with the distributor 103 determining the total number (N) of shares to be generated and the threshold number (K) of shares for reconstruction. Alternatively, the determination may be made by a user or an administrator of the distributor 103, based on the available computing or storage resources and the available number of recipients 101 that can jointly hold the shares of the secret (S)], and [¶31, At block 240, the distributor 103 constructs a secret splitting polynomial of degree (K-1) with K coefficients, where K is the threshold number of shares for reconstructing the secret...], and see FIGs.1 and 2 and corresponding text for more details].
LeSaint discloses: [¶5, devices registered into the peer-to-peer network may be capable of establishing a shared data encryption key (DEK). Each device may be configured to obtain a share of a data encryption key (DEKi) that can be stored locally. The shares may be shares in an M of N (e.g., Shamir’s) Secret Sharing Scheme], and [¶25, The term “secret sharing scheme” can refer to a method for distributing a secret amongst N participants, each of which can be referred to as a “share.” In this manner, the secret can be protected even if one participant is compromised. The secret sharing scheme can be a “threshold scheme,” in which a threshold number M of participants within the group of participants are required to reconstruct the secret, M less than or equal to] and [¶34, an example system includes N devices. The devices may be connected via network interfaces that allow for the exchange of data. For example, the devices may each comprise network interfaces for connecting over a wired and/or wireless communications network, such as through Ethernet, cellular telecommunications, Bluetooth, WIFI, and/or any other form of electromagnetic signaling, such as radio signaling, optical signaling, microwave relay, etc.], and [Abstract].
Kim discloses: [0030] The method may further include the decrypting of the encrypted content includes: recovering a decryption key corresponding to the encryption key from the plurality of partial keys distributed to the plurality of devices in response to determining that the number of devices located within the proximate spacing of each other is equal to or greater than the threshold value; and decrypting the encrypted content by using the recovered decryption key], and [0090] In detail, the security group 10 that includes the first through third devices 100 through 300 may encrypt or decrypt content based on a threshold method. The threshold method is a modified method of a secret sharing method. In the threshold method, if t or more participants from among N participants are near each other, original secret information may be recovered. If less than t participants are near each other, the original secret information may not be recovered. For example, if N is 3 and t is 2, encrypted content may be decrypted and shared when two or more devices from among the first through third devices 100 through 300 are near each other (within a proximate spacing)], and 0094] However, if the first through third devices 100a through 300a are near each other, the original secret information may be recovered based on the split secret shares S1 through S3.], and [ ¶¶141, 144, 227].
Proulx discloses [ ¶¶22, 31-32, 38-39, 44-46].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
Kothavate ( US2019/0306128) [ [0038] The operations 200 include, at block 202, receiving, from a user device, a first request to link a user account at the identity management service to a data provider that is external to the identity management service and that possesses data associated with a user of the user account, the request including a digitally signed consent ticket representing the user's consent for the data provider to perform one or more actions involving one or more specified data items associated with the user. Referring to FIG. 1, for example, an identity management service 102 can receive a request from a client computing device 100 requesting to link a user account to one or more data providers 110].
Rubira (US11469887) (32) For example, consent manager 114 may store or otherwise maintain portions of a secret in separate logically sealed containers. Wherein the portions of the secret comprise shares of a secret assigned to entities that may provide consent for debugging operations, such as a customer, a technician/engineer, and/or a service of the service provider network 102, such as the remote hardware execution service 104. While customer consent is required, in some embodiments more or fewer additional parties may participate in providing consent, such that more or fewer portions of the secret may be stored in more or fewer logically sealed containers for the additional parties].
Sudia (US2002/0013898) [ [0208] If one or more of the authorizing agents lose their keys (e.g., loose their trusted device smart cards), then new smart cards would be registered on the same signing device. The decryption key shares could be recovered from other signing devices and could be reinstated to the newly registered smart cards by submitting an electronic message, signed by the SWA signature key, for the signature devices to transfer shares of the decryption key to the newly registered devices. As an alternate method, subject to the consent of the SWA, a given device could receive all description shares, decrypt its signing share, generate a new encryption key pair, re-encrypt the signing share under the public key, divide the new private decryption key into new shares and redistribute these shares to the trusted devices of the relevant authorities, taking care to encrypt them under the public encryption keys of those receiving authorities' trusted devices].
Mangalore (US2014/0095890) [0034] In FIG. 2B, a mobile platform 250 may be used for execution of software in secure space and secure memory in electronic devices 108. Mobile platform 250 includes application software 260, platform software 270, hardware 280, non-secure memory 290, and secure memory 295. In FIG. 2B, security software is split into two components. Non-critical software 265 is executed in the application software space 260 and critical security software 287 runs in secure part or secure execution 285 of hardware, also known as a secure or trusted execution environment (TEE). In some embodiments, the critical security software 287 is configured to communicate with and store secure contents in secure memory 295. In some embodiments, non-critical software 265 is configured to communicate with and store non-secure contents in non-secure memory 290. In some embodiments, the secure and non-secure contents are manipulated or processed and stored separately from each other].
Wasily (US2019/0036688) [ [0029] The personal device 102 has a trusted execution environment (“trusted environment”) 112 and an untrusted environment 128. The trusted environment 112 includes a medical application 118, a trusted memory 114, an encryption engine 116 and a user interface 136 within the trusted environment 112. The untrusted environment 128 may include other applications 120, an untrusted memory 122, a network access device 124 and/or a sensor 126. The components within the trusted environment 112 are logically and/or physically isolated from the components within the untrusted environment 128 and may establish a trust zone with a unique identifier. The trusted environment 112 may run a separate and/or a distinct operating system and have distinct resources from the untrusted environment 128. The trusted environment 112 and the untrusted environment 128 may have different processors 130a-b, respectively, within each environment, as shown in FIG. 1C for example, or may share the same processor 130, as shown in FIGS. 1A and 1B, for example.
FU (US2021/0271751) [ [0053] The second devices 404 may provide a trusted execution environment (TEE) allowing a creation of shielded areas within an normal untrusted operating system. The trusted execution environment may be configured to perform functions related to attestation. For example, the trusted execution environment may be provided by ARM TrustZone with a trusted environment or other type of TEE-enabling processor].
Ibrahim (US2021/0110064) [0041] Moving on to FIG. 2B, shown is an example of a client device 106 according to various embodiments. The client device 106 can include an untrusted execution environment 250, a trusted execution environment 253, and an interface 254 between the untrusted execution environment 250 and the trusted execution environment 253. The client application 203 can be executed in the untrusted execution environment 250 along with many applications under control of the user. The trusted execution environment 253 is a secure environment with its own secure operating system executed on a secure virtual processor or a secure physical processor. The untrusted execution environment 250 may be executed on a different virtual or physical processor from the secure virtual or physical processor of the trusted execution environment 253.
DAI HONGJUN (CN111212094A) [ TrustZone conceptually divides the hardware and software resources that run the trusted execution environment into two worlds: secure and non-secure. All operations that require confidentiality are performed in the secure world (such as fingerprint recognition, password processing, data encryption and decryption, security authentication, etc.) , The rest of the operations are executed in the non-secure world (such as user operating systems, various applications, etc.), and the secure world and non-secure world are converted through a mode called Monitor Mode. At present, trustzone is mainly applied to mobile devices such as mobile phones and tablets].
Bursell (US20210374234 [ SEE fig.2, [0053] Computing device 110A may use the same processor and storage device to establish multiple instances of trusted execution environment 120. Each instance of a trusted execution environment (e.g., TEE instance, TEEi) may be established for a particular set of one or more computing processes and may be associated with a particular memory encrypted area. The instances of a trusted execution environment may be provided by the same hardware (e.g., processor and memory) but each instance may be associated with a different memory encrypted area and a different set of one or more processes (e.g., set including an individual process or set of all processes of a VM). Each instance may guard all data of a computing process or a portion of the data of a computing process. For example, computing process 225A (e.g., application or VM) may be associated with both a trusted execution environment and an untrusted execution environment. In this situation, a first portion of the data of computing process 225A may be stored and/or executed within trusted execution environment 120 and a second portion of the data of computing process 225A may be stored and/or executed within an untrusted execution environment. The second portion may be stored in the same storage device as the first portion but the second portion may be stored in a decrypted form and may be executed by processor 214 in a manner that enables another process (e.g., multiple higher privileged processes) to access or modify the data. In either example, trusted execution environment may be used to execute one or more of the computing processes 225A-C].
[ Paz de Araujo) [ US2019/0044697) a single interconnected computer system of a single owner/client may have untrusted environments that include data that is at rest (i.e., stored) in the owner/client's own end-point devices outside of the owner/client's digital secure perimeter such that it is beneficial to store the data in the untrusted environment of a single computing system in encrypted format even though other environments on the same computer system/device may properly handle secured information in unencrypted format.
Guthery (US8322610) [Abstract, Mechanisms are provided for executing security-sensitive applications with a general-purpose computing device. In particular, the general-purpose computing device includes an unsecure computing environment and a secure computing environment. The secure computing environment is established with a secure access module that includes data and functions for executing the security-sensitive application on behalf of the unsecure computing environment.
KR 20220144810 A In an example, the at least one processor 204 of the computing device 102 may: (1) share at least one secret; and/or (2) verifying the reconstructed secret itself. In an example, this is implemented in the verification module 222 . In an example, the at least one processor 204 is configured to compare hashes taken at two different times. In an example, the at least one processor 204 may: (1) obtain a hash generated from the secret share before the secret share is distributed to the shareholders; can be compared with the hash generated by If the two hashes match, the secret share (from which the hash was generated) is verified to be identical (e.g., a secret share retrieved from a shareholder is verified to be identical to the secret share provided to the original shareholder).Alternatively or additionally, the at least one processor 204 may: (1) compare a hash generated from the secret before the secret is split with (2) a hash generated from the secret after reconstruction. If the two hashes match, the secret from which the hash was generated is verified to be identical (eg, the reconstructed secret is verified to be identical to the original secret). It should be noted that the various validations discussed herein are optional.In an example, the at least one processor 204 of the computing device 102 is further configured to collect and store metadata for secrets and/or secret shares created at the computing device 102 . In an example, this is implemented in the metadata module 224 . Among other things, metadata can be used to verify secret sharing before and after secret reconstruction. The metadata can also be used to identify which of the secret shares retrieved from the shareholders was the cause of the failure if an error occurred during secret reconstruction (or if the wrong secret was reconstructed using the retrieved secret share).
Secret (434-2) from shared secret (436-2) (either an error occurred during secret (434-2) reconstruction or because the reconstructed secret (434-2) does not match the original secret (434-1)) , the verification module 222 may identify the at least one secret share 436 - 2 as incorrect based on the metadata 440 . In an example, this includes comparing a hash of at least one of the retrieved secret shares 436 - 2 to a list of shared hashes 437 in the metadata 440 . If the hash of the retrieved secret share 436-2 matches the hash of the list of shared hashes 437 (in the metadata 440), then (this is the secret share 436-1 originally distributed to the shareholder 442-1) ) is the "correct" retrieved secret share (436-2). If the hash of the retrieved secret share 436-2 does not match the hash of the list of shared hashes 437 (in the metadata 440), it (since not one) this is the "incorrect" retrieved secret share 436-2. This post-reconfiguration verification/identification can narrow the problem down to a specific shareholder's secret shared storage or medium 438
CN 111049644 A [the secret sharing is the rational user of introduced into the conventional secret sharing, in the real environment to achieve the fairness of the secret reconstruction, so that all the users can obtain the shared secret. However, since omitted fairness defined the behaviour of the user, the secret share contained in that the user is not sending secret can also obtain the shared secret unfair situation; caused when using a secret sharing scheme is designed by directing to the definition of, and cannot ensure that all users are capable of obtaining the shared secret, even further will be sent an error sub-secret deceive other users, resulting in the false sharing the reconstructed secret considered extreme situation of the real secret. In summary, the problem of the existing technology as follows: the existing secret sharing method when using a secret sharing scheme is designed by directing to the definition of, and cannot ensure that all users are capable of obtaining the shared secret, even further will be sent an error sub-secret deceive other users, resulting in the false shared secret from the reconstructed considered extreme situation of the real secret.
Armileder (US2021/0234678) The present invention relates a method, the method comprising: based on a data element (50), generating M data element shares (52), wherein M is an integer greater than 1; providing each of M encryption keys (42) to a first data processing unit (10); the first data processing unit (10) encrypting each of the M data element shares (52) with an encryption key (42), respectively, and thus generating M encrypted data element shares (55), wherein each of the encryption keys (42) corresponds to a decryption key (45), respectively. The present invention also relates to a determining method to determine the data element. The present invention also relates to corresponding computer programs, data processing units and systems], and [¶¶387-392].
CSinger (US 2018/0004930) [0259] Advantages of this approach tend to include the following: (1) Secure: SSSS is information-theoretically secure; (2) Minimal: No share exceeds the size of the original secret; (3) Extensible: When m is fixed, the total number of conspiring devices, n can be dynamically increased/decreased without affecting the other shares—this means that new devices can be added incrementally to a Conspiracy without affecting existing members; (4) Flexible: Shares can be distributed unequally between members of the Conspiracy, so that, for instance, devices with higher security (such as those equipped with a Secure Element) can hold multiple shares as described in the specific conditions of the policy engine; (5) Dynamic: Security can be easily enhanced without changing the secret, but by changing the polynomial occasionally (keeping the same free term) and distributing new shares to the participants.[0262] In this embodiment, after the shares of the random symmetric key K have been shared among the user devices 200, block 706 directs the processor 210 to delete the random symmetric key K from the user device 202. Block 706 further directs the processor 210 to generate and store a user policy record for the transaction in a user policies store 290 in the computer-readable medium 260, identifying the n user devices that received shares of the encryption key K, and specifying that key shares must be successfully obtained from at least m of those devices], and [0062] In this embodiment, the plurality of user devices 200 further includes a tablet 204 which in this embodiment is an iPad, a laptop computer 206 and a desktop computer 208. As with the user device 202, in this embodiment each of the tablet 204, laptop 206 and desktop 208 includes a communications interface comprising at least a Wi-Fi transceiver for communication with the network 102, and each further includes a local communications interface which in this embodiment includes a Bluetooth Low Energy (Bluetooth 4.0+) compatible transceiver.
Meyer (US2019/0280863) [ Abstract, Secret data is maintained as a plurality of secret shares distributed among a plurality of system nodes. When seeking to recover the secret data, a user node sends a request comprising a seed value to the system nodes. The user node receives, from each system node of at least a first subset of the plurality of nodes, a cryptographic hash value based on the seed value and information unique to the system node. The user node then generates an ordered listing of the first subset of the plurality of system nodes according to the corresponding plurality of cryptographic hash values. The user nodes select a second subset of system nodes from the first subset based on the ordered listing. The user node then reconstructs the secret data based on the secret shares possessed by at least some of the second subset of the plurality of system nodes].
Saad (US11082220) [ 45) In 406, the system may perform (or execute, initiate, etc.) an operation (or function, method, etc.) to generate N key shares (or pieces) of the secret key (S). The operation may use any suitable secret sharing algorithm such as a Shamir's Secret Sharing algorithm. In some embodiments, the operation may use a secret sharing algorithm based on a (K, N) threshold scheme (e.g. using Shamir's Secret Sharing algorithm) requiring at least K number of the N key shares to reconstruct the secret key (S). As described, each of the N key shares may correspond to a different one of the storage systems. For example, as shown in diagrams 200/300, four key shares (S.sub.1-S.sub.4) may be created for the four storage systems 180A-D. Thus, as shown in such an example, key share S.sub.1 corresponds to storage system 180A, S.sub.2 corresponds to storage system 180B, S.sub.3 corresponds to storage system 180C, and S.sub.4 corresponds to storage system 180D].
Triandopoulos (US11115196) [ Abstract, Methods and apparatus are provided for secret sharing with a verifiable reconstruction type. An exemplary method comprises receiving a plurality of shares of a secret generated using a secret splitting scheme; reconstructing the secret if the plurality of shares satisfies a predefined reconstruction threshold; and generating a proof identifying at least one of the plurality of shares used in the reconstruction. The proof is optionally verified by a verifier and the verification is optionally based on auxiliary information derived by the secret splitting scheme used to share the secret. The verifier optionally implements layered access control, for example, based on a rank of the shares used for reconstruction. The reconstructed secret is optionally provided to the verifier. A user can be granted a level of access to a protected resource based on the proof, the reconstructed secret and one or more predefined policies].
National ICT Australia limited (US20170228547) (filed in IDS) [0275] In one example, the privacy peers, such as 912/920 perform a further step of multiplication, such as determining A*B*C after determining A*B as described with reference to FIG. 9. In that case, peer 912/920 stores result 924 on data memory and the distributor 910 receives the shares related to the third secret data C at the second input port or associated with input_index=2], and [0277] In the first iteration, controller 1104 receives first shares of first secret data at first input port 1106 and second shares of second secret data on second input port 1108. The controller 1104 then distributes the shares as described above to the peers of cloud 1102. The peers 1102 process the shares to determine a product of shares and each peer feeds its product of shares back to the second port 1108 (indicated by arrow 1110). As a result, this feedback is performed 16 times for 16 peers. Controller 1104 distributes these shares as described above and each of the peers 1102 receives 16 shares stores them on data memory. Then, each of the peers 1102 sums the received shares to determine a share of the product (rather than a product of shares)].
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496