WO2021133153A1

WO2021133153A1 - Transaction signing with ergonomic addressing and compact encapsulation

Info

Publication number: WO2021133153A1
Application number: PCT/MY2020/050076
Authority: WO
Inventors: Goh ALWYN
Original assignee: Mimos Berhad
Priority date: 2019-12-24
Filing date: 2020-08-26
Publication date: 2021-07-01

Abstract

The present invention relates to a system (100) and method (200) for transaction signing with ergonomic addressing and compact encapsulation between client application, as representative of particular user, and server as representative of service provider. In particular, the present invention provides for client-server AKE-ID interaction and client-originated PSS computation comprising AUTH server (102) for AUTH interaction between client and server, comprising AKE-ID interaction as protection for client-originated PSS signature computation on TX of interest; system interface, SI (104) to BDL network (106) for AUTZ interaction, comprising AUTZ verification on present BDL state as prior requirement for PSS computation, and then insertion of TX encapsulation into TX multiplicity for validation into subsequent BDL state; IDM server (108) for IDM interaction with AUTH server comprising AKE-ID add to certificate PK realisation, as enables subsequent PSS verification; and registration server (110) as dependent on prior registration interaction with client, comprising client origination of AKE-ID(add), server origination of cert(PK), and subsequently enablement of add to cert(PK) realisation computation.

Description

TRANSACTION SIGNING WITH ERGONOMIC ADDRESSING AND COMPACT

ENCAPSULATION

FIELD OF INVENTION

The present invention relates to a system and method to enable transaction signing with ergonomic addressing and compact encapsulation. In particular, the present invention relates to a system and method to establish a secure connectivity between a user and server provider by utilizing address of ergonomic form.

BACKGROUND OF INVENTION

Current challenges in providing a transaction signing on communication channel revolve in the system architecture. The conventional systems deploy a system architecture which consist a bulky encapsulation of transaction and means of verification between connection of user and server. The conventional systems also comprises a bulky authentication key addressing, usually in the length of 256 bits or more which may cause lacks attestation in establishing secure connection between user and server. Thus, current solution involve an ergonomic addressing form and compact encapsulation of transaction in producing a significant computation, communication and storage advantages, in comparison to conventional systems.

United States Patent No. US 8,966,273 B2 (hereinafter referred to as the US 273 B2 Patent) entitled “Lightweight Group Signature System and Method with Short Signature” having a filing date of 6 September 2012 (Patentee: Hwang et al.) discloses a lightweight group signature system and method with short signature which able to provide excellent operation efficiency during the process of signature generation, signature verification, and revocation on smart terminals. US 966 B2 Patent comprises of similar security characteristics as group signature mechanisms providing the existing known controllable linkability but outputting very short signatures lengths.

United States Patent No. US 8,683,209 B2 (hereinafter referred to as the US 209 B2 Patent) entitled “Method and Apparatus for Pseudonym Generation and Authentication” having a filing date of 13 October 2009 (Patentee: Hui et al.) discloses a method and apparatus for pseudonym generation and authentication through transmitting a user identity to Personal Identity Manager (PIM). US 209 B2 Patent further exposes the functionality of PIM in determining a set of public parameter and a set of private parameter, receiving a user identity from a user device, generating a prime pseudonym and transmitting the prime pseudonym and set of public parameters to the user device for authentication.

United States Patent No. US 9,582,799 B2 (hereinafter referred to as the US 799 B2 Patent) entitled “Token Based Transaction Authentication” having a filing date of 10 April 2013 (Patentee: Lindelsee et al.) discloses a token based transaction authentication system where unique tokens or keys are generated between entities comprises of issuer, merchants and payment processing network to authenticate the sending entity, messages between the entities, and identify an authentication thread. US 799 B2 Patent further provides a support for money transfer between portable consumer device such as credit card, debit card or any portable device such as software application in supporting fund transferring platform.

United States Patent Publication No. US 2015/0195280 Al (hereinafter referred to as the US 280 Al Application) entitled “Authentication System and Authentication Method” having a filing date of 7 January 2011 (Patentee: Toyonaga et al.) provides an authentication system and authentication method, which detect the falsification of request information and safely authenticate request information from a client terminal for an access with a server. US 280 Al Application further discloses the use of public-key authentication as such the input of request information at client terminal is encrypted using a key method and subsequently submitted to server for verification. The encrypted request information was then decoded by server using the same common key method.

Due to the drawbacks and limitation of the conventional system and method, there is a need to provide a system and method which enable transaction signing with ergonomic addressing and compact encapsulation to exhibit a more significant computation, communication and storage advantages in establishing a secure connection and communication between a user and a server.

SUMMARY OF INVENTION

The present invention relates to a system and method to enable transaction signing with ergonomic addressing and compact encapsulation. In particular, the present invention relates to communication between client application, as representative of particular user, and server as representative of service provider.

One aspect of the invention provides a method (200) for secure connectivity establishment between client application, as representative of particular user, and server node, as representative of service provider. The method comprising steps of user identity specification via address of ergonomic form, as would be practical for particular user to remember, and to be able to input into client via manual transcription or alternative low-capacity user interface, UI method (202); signature computation, on transaction of interest, within protected interior component of client (204); with such computation contingent on establishment of secure connection to server, and proof of possession (POP) demonstration by client, relating to uniqueness and secrecy of client device and application instances, and if applicable proof of knowledge (POK) demonstration by user, relating to secret input into client via manual transcription or alternative UI method; and subsequent to that composition of encapsulation comprising transaction, signature, source user address as means with which to undertake server-side signature verification, and if applicable destination user address; transmission of encapsulation on secure connection to server such that encapsulation, and in particular enclosed signature, is not accessible client-side exterior to protected component (206); establishment of secure client-server connectivity (208); and identity management, IDM of user credentials (210).

Another aspect of the invention provides that establishment of secure client-server connectivity (208) is conducted via public-key, PK authenticated key establishment, AKE and further comprising steps of (300) request by third-party transaction application to client, in response to action of user or associated transaction server, for signature computation on particular transaction (302); first action by client, contingent on positive assessment of request and requesting application (304) comprising computation of client-to-server challenge within protected interior component, and then transmission of user address and such challenge to server, via client-server connectivity established by third-party system; second action by server, contingent on positive third-party authorisation of request and requesting application (306) comprising computation of response to received challenge, computation of reciprocal server-to-client challenge, and if applicable computation of key establishment key (KEK) resulting from AKE interaction, encryption of transaction-related payload with KEK, such that only initiating client as properly designated with user address can undertake corresponding decryption, and then transmission of service provider address, response, reciprocal challenge and encrypted payload, via third-party client-server connectivity; third action by client, within interior component (308) comprising assessment of received response, and only on positive outcome thereof, retrieval of POP key- factorisation, and if applicable request and receipt of POK factorisation, client-side private- key, sk computation, with which to undertake response and computations, computation of response to reciprocal challenge, computation of signature on transaction, computation of KEK resulting from AKE interaction, decryption of received payload, encryption of transaction encapsulation with KEK, such that only responding server as designated with provider address can undertake corresponding decryption, and then transmission of reciprocal response and encrypted encapsulation, via third-party connectivity; and following that; and fourth action by server (310) comprising assessment of reciprocal response, and only on positive outcome thereof, decryption of received encapsulation, verification of enclosed signature, and only on positive outcome thereof, and onward transmission of encapsulation to requesting transaction server.

A further aspect of the invention provides that client-side private-key, sk computation (308) further comprising steps of sk as hashed message authentication code, HMAC computation output, internal element into key input, and external element into message input; as both persistent for client-specific computation; or ephemeral for interaction-specific computation, whichever applicable.

Still another aspect of the invention provides that client-side private key, sk computation (308) is further configured for particular user associated with client instance and further comprising multiplicity of factors, as characterised by uniqueness and furthermore immutability, as particular to client device and subject to proof-of-possession, POP via single or multiple system-read operations executed within protected interior environment of client, such system elements inclusive of Media Access Control, MAC address, International Mobile Equipment Identifier, IMEI and International Mobile Subscriber Identifier, IMSI; and secrecy, as particular to client instance, subject to limitation of access to within such protected environment; and if applicable user, subject to proof ok knowledge, POK via user input into client; with such factorisation instances subject to computation during each AKE- signing interaction and prior to that establishment during prior registration interaction as further characterised in that incorrect client-side demonstration of any single POP or POK factor results in negative server-side assessment of particular AKE interaction; and providing provider issued sk-add associated with user address.

Yet another aspect of the invention provides that client-side private key, sk computation, subject to computation for particular AKE-signing or registration interaction; comprising multiplicity of factors, as characterised by internal state dependency as furthermore secret, particular to interaction instance and subject to limitation of access to within protected interior environment; and external sensitivity as furthermore of high granularity, subject to single or multiple sensor-read operations likewise executed within protected environment at instance of interaction, such sensor elements inclusive of clock and Global Positioning Satellite, GPS; as further characterised in that such computation enables computation of corresponding elliptic curve, EC PK via specified group operation.

Another aspect of the invention provides that the client-side private key, sk computation (308) is further configured for computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address; and the configuration further comprising steps of (400) initial registration interaction (402) with receipt of sk-add in KEK encryption, following second action by server of registration interaction (404); computation of sk, subject to positive AKE assessment and correct POP and POK input into HMAC computation, in third action of interaction by client within interior component (406); recovery of sk-add via KEK decryption (408); computation of factorisation via same POP and POK input into alternative HMAC computation (410); differentiation of sk-add and such factor (412); and insertion of differential thereof into client storage (414); and then for subsequent AKE- signing interaction (416); with equivalent computation of sk and sk-add factor, subject to similar conditions, in third action of interaction (418); computation of sk-add, as integration of such valuation and differential as recovered from storage as enabling method for equivalence of (sk, sk-add) association with particular user (420); enabling user-associated (sk, sk-add) and (PK, add) as the respective composite sk and PK (422); and protective measure for provider issued sk share associated with singular share of multi signature of n a group with designated address (424). A further aspect of the invention provides that enabling user-associated (sk, sk-add) and (PK, add) as the respective composite sk and PK (422) further comprising steps of (500) extension of EC framework to pairing P operations, for computation of EC -P -based short signatures, PSS (502); with characteristics inclusive of hash and signature outcomes on same EC framework, absence of EC-P operations for client-side signature computation, minimum of EC-P operations for server-side signature verification, and preservation of such minimum for aggregate verification of multiple signatures, contingent on similarity of transaction or PK inputs (504); and further extension of framework to EC-P-identity ID operations, for computation of AKE-ID interaction parameters, computation of PK-ID as full domain hash FDH of user address; with characteristics inclusive of initial sk-add issue, by trusted party as acknowledged by service provider, during user registration; as then applicable to subsequent AKE-ID interaction for client-server secure connectivity; subject to correct sk-add computation in third action of interaction; as equivalent to correct sk computation from POP/K demonstration in same action; as protective measure for client-side PSS computation, subject to positive assessment of AKE outcome; and then server-side PSS verification, also subject to positive assessment of AKE outcome; with further characteristics inclusive of minimum of EC-P operations for client and server engaged in interaction, and PSS of shorter length in comparison to alternative ECC formulations; and enabling AKE-ID interaction as protective measure for PSS share computation and ring signature computation (506).

Yet another aspect of the invention provides that AKE-ID interaction as protective measure for PSS computation (506) further comprising steps of (600) first action by client comprising AKE-ID computations (602); second action by server comprising AKE-ID computations (604); third action by client comprising AKE-ID computations (606); and only on positive outcome thereof PSS computation, encapsulation thereof as protected by AKE-ID computation, and KEK encryption thereof, for transmission to server; and fourth action by server comprising AKE-ID computations (608), and only on positive outcome thereof KEK decryption of incoming transmission from client, and PSS verification of encapsulation; enabling post interaction server action on PSS computation on common transaction by user multiplicity as individually subject to AKE-ID protected submission (610); and enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing (612). Still another aspect of the invention provides that identity management, IDM of user credentials (210) further comprising steps of (700) server-side storage of user-associated add, certificate(PK) on corresponding PK, and personally identifiable information (PII) into separate tables (702); establishment of realisation-virtualisation traversal mechanisms between all pairs of tables (704); with traversal from table(PII) to table(add) and separately table(cert) via respective virtualisation operations, with corresponding attachments of respective virtualisation outcomes V(PII) on each of table(add) and table(cert); traversal from table(add) to table(cert) as virtualisation operation, for access to PK for particular PSS verification; and access to table(cert) information relating to initial establishment of cert(PK), and issue of sk-add prior to verification operation; with characteristics inclusive of certificate valuation as index for table(cert) as derivation of address valuation; and if applicable attachment of virtualisation outcome V(add) to table(cert); reciprocal traversal from table(cert) to table(add) as realisation operation, with corresponding attachment of realisation outcome R(PK) to table(add); and reciprocal traversal to table(PII) from each of table(add) and table(cert) via respective realisation operations, with corresponding attachments of realisation outcomes R(add) and R(PK) on table(PII); and enabling identity management, IDM via hash computation (706).

Another aspect of the invention provides that IDM via hash computation (706) further comprising table(add)-table(cert) traversal via set of virtualisation-realisation (VK, RK) keys, with certificate index of table(cert) as hash or HMAC output from add input, with additional input of VK if applicable, and R(PK) on table(add) as HMAC output from PK input, with additional input of applicable RK; table(add)-table(PII) traversal via another (VK, RK) set, with V(PII) on table(add) as HMAC output from PII input, with additional input of applicable VK, and R(add) on table(PII) as HMAC output from add input, with additional input of corresponding RK; and table(cert)-table(PII) traversal via yet another (VK, RK) set, with V(PII) on table(cert) as HMAC output from PII input, with additional input of applicable VK, and R(PK) on table(PII) as HMAC output from PK input, with additional input of corresponding RK; as enabling methods for table(cert) access from address input, limitation of reciprocal table(add) access from certificate input, limitation of access to table(add) and table(cert) access from PII input; restrictive limitation of table(PII) access from address or certificate input; and IDM of user credentials arising from initial registration interaction. Yet another aspect of the invention provides that IDM of user credentials arising from initial registration interaction further comprising steps of (800) first action by client comprising AKE computations via EC operations (802); second action by server comprising AKE-EC computations (804); third action by client comprising AKE-EC computations (806); and only on positive outcome thereof composition of encrypted encapsulation; comprising certificate signing request (CSR) for subsequent user association, inclusive of PSS PK for subsequent signing operations, and PII if applicable, then PSS computation on CSR, and address of user choice for subsequent AKE-ID interactions for subsequent transmission to server; and fourth action by server comprising AKE-EC computations (808); and only on positive outcome thereof decryption of incoming encapsulation from client, and PSS verification on CSR, as establishment for correctness of PK association; and enablement of IDM action (810).

Still another aspect of the invention provides that enablement of IDM action (810) further comprising steps of (900) first action by client comprising AKE computations via EC operations (902); second action by server comprising AKE-EC computations (904); and only on positive outcome thereof composition of encrypted payload; comprising cert(PK) corresponding to previous CSR(PK) submission, as issued by trusted party acknowledged by service provider, and sk-add corresponding to address of user choice, or if applicable (add, sk-add), as similarly issued by trusted party; for subsequent transmission to client; third action by client comprising AKE-EC computations (906); and only on positive outcome thereof, decryption of incoming payload from server; factorisation of sk-add, and commitment of differential thereof to client storage, composition of encrypted encapsulation; comprising acknowledgement of payload received, as hash thereof, PSS computation on acknowledgement; address as chosen or issued; for subsequent transmission to server; and fourth action by server comprising AKE-EC computations (908); and only on positive outcome thereof decryption of incoming encapsulation from client, and PSS verification on acknowledgement, as enabling method for subsequent client engagement in AKE-ID interactions and PSS signing.

Another aspect of the invention provides that encapsulation thereof as protected by AKE-ID computation (606) further comprising steps of (1000) encapsulation (1002); transaction (1004); itself comprising source (SRC) add, as denotes particular user in present interaction, destination (DST) add, as denotes user or other entity as designated recipient of present interaction, and transaction information, as denotes exchange between SRC and DST entities; and PSS on transaction (1006). Yet another aspect of the invention provides that transaction (1004) further including specifying DST within transaction encapsulation and further comprising steps of (1100) summation of user address multiplicity, for specification that all n users in list must contribute signatures (1102); and concatenation of address multiplicity, for specification that 1-of-n users in list must contribute ring signature (1104).

Still another aspect of the invention provides that computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address is further configured for client-side sk computation as protective measure for provider-issued sk share associated with singular share of multi -signature k-of-n group with designated address and further comprising steps of (1200) receipt of sk-share as encrypted payload, following second action of registration interaction (1202); factorisation of sk-share and commitment of differential thereof into client storage (1204); subsequent AKE-signing interaction (1206); computation for sk-share from integration of factorisation, as presently computed, and differential, as retrieved from storage; as enabling method for equivalence of sk, sk-share association with particular user (1208).

A further aspect of the invention provides that enabling AKE-ID interaction as protective measure for PSS share computation (506) further comprises steps of (1300) third action by client comprising AKE-ID computations, and only on positive outcome of prior actions in interaction (1302); PSS share computation, via sk-share computation; encrypted encapsulation thereof for transmission to server; and fourth action by server comprising AKE-ID computations, and only on positive outcome thereof (1304), decryption of incoming transmission from client, and PSS verification of encapsulation, via PK corresponding to sk- share associated with particular user.

Another aspect of the invention provides that enabling AKE-ID interaction as protective measure for ring signature, RS computation (506) further comprising steps of (1400) third action by client comprising AKE-ID computations, and only on positive outcome of prior actions in interaction (1402); RS computation, via sk as also applicable for PSS computation; then encrypted encapsulation thereof; for transmission to server; and fourth action by server comprising AKE-ID computations, and only on positive outcome thereof (1404), decryption of incoming transmission from client, and RS verification of encapsulation, via PK corresponding to concatenation of PK as individually associated with user addresses on designated list.

Yet another aspect of the invention provides that enabling post interaction server action on PSS computation on common transaction by user multiplicity as individually subject to AKE- ID protected submission (610) further comprising steps of summation, according to designated list of user addresses, via EC addition operation of individual PSS computations on common transaction; or alternatively summation, according to weightage of individual users in multi-signature group, of at least k-of-n PSS-share computations on common transaction; such that summation outcome as multi-signature is subject to verification via PK as aggregate via addition of PK as individually associated with signing users; or alternatively singular PK as associated with particular signing group; as enabling method for multi signature computation from PSS multiplicity.

Still another aspect of the invention provides that enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing (612) further comprises steps of (1500) aggregation into leaf element of all TX encapsulations with positive signature verification outcomes (1502); and computation of PSS on leaf (TX) aggregation, subject to verification via server PK; as enabling method for aggregation and validation of leaf encapsulation of TX multiplicity (1504).

Another aspect of the invention provides that post-aggregation server action, as subject to previous validation by aggregation server and further comprising steps of (1600) computation of PSS on leaf TX by subsequent server, as likewise subject to verification via corresponding PK; as enabling method for joint validation of leaf TX aggregation (1602); and enabling joint post validation server action (1604).

Still another aspect of the invention provides that enabling joint post-validation server action (1604) further comprising steps of (1700) aggregation and validation of particular leaf TX as elements in consensus protocol for further aggregation into block encapsulation of leaf multiplicity (1702); and addition thereof to blockchain or distributed ledger, BDL (1704).

Another aspect of the invention provides a system (100) for client-server AKE-ID interaction and client-originated PSS computation. The system comprising AUTH server (102) for AUTH interaction between client and server, comprising AKE-ID interaction as protection for client-originated PSS signature computation on TX of interest; system interface, SI (104) to BDL network (106) for AUTZ interaction, comprising AUTZ verification on present BDL state as prior requirement for PSS computation, and then insertion of TX encapsulation into TX multiplicity for validation into subsequent BDL state; IDM server (108) for IDM interaction with AUTH server comprising AKE-ID add to certificate PK realisation, as enables subsequent PSS verification; and registration server (110) as dependent on prior registration interaction with client, comprising client origination of AKE-ID(add), server origination of cert(PK), and subsequently enablement of add to cert(PK) realisation computation.

The present invention consists of features and a combination of parts hereinafter fully described and illustrated in the accompanying drawings, it being understood that various changes in the details may be made without departing from the scope of the invention or sacrificing an of the advantages of the present invention.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

To further clarify various aspects of some embodiments of the present invention, a more particular description of the invention will be rendered by references to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the accompanying drawings.

FIG. 1.0 illustrates a general architecture of a conceptual arrangement of AUTH/Z system with ergonomic addressing and compact encapsulation comprising client and server sub- systems; as requires prior registration and IDM address-to-certificate translation, and as subsequently applicable to BDL interactions. FIG. 1.0a illustrates transaction (X) encapsulation with signature and certificate, corresponding to signing entity A. FIG. 1.0b illustrates encapsulation with signature and PK, with size reduction due to omission of certificate.

FIG. 1.0c illustrates X encapsulation with compact signature and address, with external link to certificate.

FIG. l.Od illustrates BDL encapsulation with source (A) and destination (B) entity addresses.

FIG. l.Oe illustrates BDL encapsulation, with compact address and signature; with add(A) linked to PK(A) for X verification and optionally cert(A) for PII(A).

FIG. l.Of illustrates BDL environment with transacting clients, as capable of (browser) read and (wallet) write operations, (optional) controllers undertaking client-server interactions for write and (optionally) read operations, and nodes undertaking P2P interactions for attainment of consensus on BDL state.

FIG. l.Og illustrates the relationships between EC, EC-P and EC-P-ID formulations, and between IF and IF-ID.

FIG. l.Oh illustrates the initial KG interaction between entity client and registrar server, with client-side sk-p and server-side sk-id establishment, and protection arising from AKE-P interaction

FIG. l.Oi illustrates subsequent AUTH interaction between entity client and controller server, with client-computed SIG-P, and protection arising from AKE-ID interaction. FIG. l.Oj illustrates SIG-P client-side computation, comprising sk-p and sk-id computations and applicability thereof in SIG and add computations. FIG. 1.0k illustrates AKE-ID client-server interaction, enabling secure entity-controller communication, with subsequent controller-node communication for (optional) entity- authenticated read and verified write operations. FIG. 1.01 illustrates IDM via separation and controlled traversal of add, PK and PII tablespaces.

FIG. 1.0m illustrates VF workloads for conventional EC and BLS signatures, illustrating W(VF) advantage of latter for aggregation use-cases.

FIG. l.On illustrates SIG-group for conventional EC signatures, via 3-pass interaction; and for BLS, via single-pass non-interactive computation.

FIG. l.Oo illustrates SIG-ring arrangement, with signing by 1-of-n singular entity with sk corresponding to PK in set of ring(PK).

FIG. l.Op illustrates the length of S-ring and S-GS 1-of-n signatures, illustrating L(SIG) advantage of former for small ring(PK). FIG. l.Oq illustrates S-threshold arrangement, with signing by k-of-n entity set surpassing initially established threshold.

FIG. l.Or illustrates the conventional BDL aggregation as linked list from previous state terminating on B(t-l) to present with addition of B(t), with internal structure as T-graph of L elements, with further internalisation as X multiplicity subject to computation-efficient VF.

FIG. 1.0s illustrates BDL aggregation as T-binary of preceding B(0) and B(l), as advantageous in terms of B formation liveness. FIG. l.Ot illustrates BDL aggregation into tangle-graph, comprising T-binary elements.

FIG. 2.0 is a flowchart illustrating a general methodology of the present invention. FIG. 3.0 is a flowchart illustrating steps for establishment of secure client-server connectivity is conducted via public-key, PK authenticated key establishment, AKE.

FIG. 4.0 is a flowchart illustrating steps for client-side private key, sk computation is further configured for computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address and the configuration.

FIG. 5.0 is a flowchart illustrating steps for enabling user-associated (sk, sk-add) and (PK, add) as the respective composite sk and PK.

FIG. 6.0 is a flowchart illustrating further steps for AKE-ID interaction as protective measure forPSS computation.

FIG. 7.0 is a flowchart illustrating steps for identity management, IDM of user credentials.

FIG. 8.0 is a flowchart illustrating steps for IDM of user credentials arising from initial registration interaction.

FIG. 9.0 is a flowchart illustrating steps for enablement of IDM action.

FIG. 10.0 is a flowchart illustrating steps for encapsulation thereof as protected by AKE-ID computation.

FIG. 11.0 is a flowchart illustrating steps for transaction further including specifying DST within transaction encapsulation.

FIG. 12.0 is a flowchart illustrating further steps for computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address is further configured for client-side sk computation as protective measure for provider-issued sk share associated with singular share of multi -signature k-of-n group with designated address.

FIG. 13.0 is a flowchart illustrating steps for enabling AKE-ID interaction as protective measure for PSS share computation.

FIG. 14.0 is a flowchart illustrating steps for enabling AKE-ID interaction as protective measure for ring signature computation. FIG. 15.0 is a flowchart illustrating steps of enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing.

FIG. 16.0 is a flowchart illustrating steps of post-aggregation server action, as subject to previous validation by aggregation server.

FIG. 17.0 is a flowchart illustrating steps of enabling post-validation server action.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention relates to a system and method for transaction signing with ergonomic addressing and compact encapsulation between a client application, as representative of particular user, and a server as representative of service provider. In particular, the present invention provides transaction signing with ergonomic addressing in natural such as name, email or phone number and short-size in which less than 256-bits are transmitted from client to server in encapsulation form consisting transaction, signature and user address in order to undertake server-side signature verification. Thereinafter, it is to be understood that limiting the description to the preferred embodiments of the invention is merely to facilitate discussion of the present invention and it is envisioned without departing from the scope of the appended claims.

Reference is first made to FIG. 1.0 which illustrates a general architecture of a conceptual arrangement of AUTH/Z system with ergonomic addressing and compact encapsulation comprising client and server sub-systems; as requires prior registration and IDM address-to- certificate translation, and as subsequently applicable to BDL interactions. As illustrated in FIG. 1.0, the system (100) for client-server AKE-ID interaction and client-originated PSS computation comprising AUTH server (102) for AUTH interaction between client and server, comprising AKE-ID interaction as protection for client-originated PSS signature computation on TX of interest; system interface, SI (104) to BDL network (106) for AUTZ interaction, comprising AUTZ verification on present BDL state as prior requirement for PSS computation, and then insertion of TX encapsulation into TX multiplicity for validation into subsequent BDL state; IDM server (108) for IDM interaction with AUTH server comprising AKE-ID add to certificate PK realisation, as enables subsequent PSS verification; and registration server (110) as dependent on prior registration interaction with client, comprising client origination of AKE-ID(add), server origination of cert(PK), and subsequently enablement of add to cert(PK) realisation computation.

Reference is now made to FIG. la which illustrates the conventional encapsulation of transaction (X); with attachment of SIG S(A; X) on X as computed by user (A) using sk, as previously established and associated; and cert thereof; containing the corresponding PK and ID details pertinent to A, as to be considered authentic arising from signature of a trusted third-party (TTP) considered trustworthy by both A and recipients of X. FIG. lb illustrates an alternative arrangement with attachment of PK, rather than cert(PK), which is more compact due to the relative sizes of both, but which does not permit TTP establishment that the signer credential PK is trustworthy. FIG. lc illustrates another arrangement with a more compact signature form and also add(PK) as a more compact credential; with verification (VF) of X only possible on external reference of cert(PK), as also allows establishment that credential add(PK) is associated with PK and cert(PK) thereof, and therefore trustworthy.

Reference is made to FIG. l.Od which illustrates the conventional BDL encapsulation; with attachment of S(A; X, B) by source (SRC) entity add(A), additionally designating destination (DST) entity add(B); with additional attachment of PK for VF enablement. FIG. l.Oe illustrates the encapsulation proposed herein; with compact add and SIG, and also requirement for external reference of PK for VF. The arrangement for external PK access, on the IDM system as subsequently described, would not be burdensome to BDL use cases, given that attachment to X to some future state of the BDL is subject to VF and validation (VL), that X is consistent with the present state thereof, as undertaken by one or more nodes on the BDL P2P network; and may be any case be VF via access to such PK on the proposed IDM system. BDL use cases conventionally require association of multiple add to a single PK, as is also possible with the proposed arrangement. The compactness of the proposed X encapsulation should result in significant computation, communications and storage advantages; in comparison to conventional encapsulations.

Reference is now made to FIG. l.Of which illustrates a contemporary BDL environment with transacting clients, controller servers and node servers. Clients engage in browser read and wallet write operations, as respectively subject to prior and subsequent authentication (AUTH) VF and authorisation (AUTZ) VL. Controllers undertake AUTH on client read requests, as respectively demonstrable by a particular client undertaking a proof of possession (POP) on add(user), such POP inclusive of without limitation authenticated key establishment (AKE) which additional benefit of secure channel establishment subsequent to interaction. Controllers also undertake VF on X submissions by clients, such transaction outgoing with respect to prior transaction in present BDL state with particular add(A) as designated DST. The present X submission would therefore have add(A) as the SRC, and add(B) as the presently designated DST. Nodes undertake aggregation of multiple X into a block aggregation B(N; X) thereof, one or more of such node-associated B being candidates for insertion into future state of BDL chain, such insertion subject to some previously designated POX consensus protocol. A particular server might undertake both controller and node functions, with presentation of front-end client-facing and back-end BDL-facing services.

Reference is made to FIG. l.Og which illustrates the relation between the EC, EC-P (PBC) and EC-P-ID (IBC) formulations, such that any IBC execution, inclusive of without limitation, the proposed AKE-ID execution for client-controller AUTH-mutual and secure session establishment; would require prior PBC establishment as a foundation element, which in turn permits, inclusive of without limitation, the proposed SIG computation by means of the proposed BLS or other PSS protocol. IBC is also possible within the IF formulation, with EC protocols generally having a significant size and security in relation to size advantages in relation to comparable IF protocols. The major value proposition of IBC is that PK(id) can be specified in terms of compact and/or human-readable strings with names, email addresses or phone or account numbers being exemplary, with lends itself to BDL applicability in which add(PK) are compact and straightforwardly input into client-side UI elements via manual transcription, which is impractical with non-IBC PK representations, of at least 256- bit length for acceptable security. IBC would however require centralised TTP generation of user sk(id), as subsequently described, which is substantively different from other PK formulations, and which would not be suitable for all use cases.

Reference is mace to FIG. l.Oh which illustrates the initial TTP-side ak = sk(id) generation (SKG) within the context of a composite system, in which a particular uses possesses both (sk, PK) PBC and (ak, id) IBC key-pairs. The former EC-P formulation necessary for the latter EC-P-ID, as previously stated. The motivation of this arrangement is to enable computation of compact signatures, while also enabling compact/ergonomic PK(id) = id and add(id) representations; with the technical challenge being to undertake client-side (sk, ak) protection, and server-side (PK, id) IDM measures; so as to enable use of both capabilities. The initial client registration interaction would therefore use the client-originated (sk, PK) pair to enter into an AKE interaction with the SKG/registrar, with the subsequently established secure channel used for server-to-client transport of ak. The registrar would subsequently undertake (PK, id) association, as subsequently described. The client would correspondingly undertake localised ak protection; inclusive of without limitation, by post registration internal storage of sk-differential dk, such that subsequent recovery of ak(sk) is contingent on correct recovery of sk, which is itself subject to protection via factorisation sk(a) and partial ephemerality thereof, as subsequently described.

Reference is made to FIG. l.Oi which illustrates the subsequent AKE-id interactions of the proposed composite system, with the subsequently established secure channel for protection of subsequent client-controller traffic, inclusive of without limitation transactions and PSS/BLS signatures thereon; respectively subject to controller-side VF via id and PK, as previously established during registration interaction. Some combination of user secret input and device-unique specification, as also previously established, is required for the (sk, ak) computations for AKE and SIG correctness.

Reference is made to FIG. l.Oj which illustrates the client-side factorisation of sk(a) and then ak(sk) computations; inclusive of without limitation user-secret, device-unique and random instance-unique factors; with the last necessary for accommodation of client reset actions, in which particular user undertakes personalisation on a new client-instance, as possible on either on present or new mobile device. Such new personalisation undertaken on the existing mobile device would therefore result in new a new PBC key-pair, with optional retention or reset of the IBC key-pair. The PBC sk then serves as input for SIG(sk) computations, inclusive of without limitation SIG-group/ring/threshold as subsequently described. The IBC ak correspondingly serves as input for AKE(ak) computations, with correct completion of the interaction resulting in protection of SIG payloads, the importance of which is subsequently described. The PBC PK also correspondingly serves as input into add(PK) computations, as is conventional in BDL use cases. The alternative formulation, proposed herein, would be to undertake add(id) formulation, which would have the advantage of compact representation comparable in size to the id specification. The add = id formulation is also possible, which results in 1-to-l add-to-PK correspondence; which is not conventional in BDL applicability, but would be acceptable in various use cases.

Reference is now made to FIG. 1.0k which illustrates the client-controller AKE interaction; as comprising mutual challenge-response interactions, with respective challenge-side random inputs, and corresponding response as POP(id) subject to challenge-side VF; and subsequent secure channel establishment, and transaction-specific payload thereof, inclusive of without limitation client-originated SIG outcomes. Some use cases would require read-AUTH/Z, and can therefore only be undertaken consequent on correct server-side AUTH(id) in the preceding step with write operations inclusive of without limitation SIG/POP outcomes in the succeeding step. Read operations without necessity for AUTH/Z can be undertaken earlier, with write operations then undertaken in the succeeding step.

Reference is made to FIG. 1.01 which illustrates IDM with separation of add, PK and PII tables, with table traversal control by means of HMAC computations with sk therein subject to AUTZ stringency commensurate with sensitivity of such traversal. add-to-PK traversal would be necessary for SIG VF, and therefore exemplify a low-sensitivity operation; to extent of traversal execution being by means of hash, without need for sk at all, rather than HMAC computation. add-to-PII and PK-to-PII traversals would exemplify high-sensitivity operations, with corresponding necessity for AUTZ control.

Reference is now made to FIG. 1.0m which illustrates the computation advantages of undertaking VF for aggregation of BLS-signed transactions (X); for particular use cases when X is identical, or the signer PK is identical for multiple transactions. Such an X aggregation would only require a single VF-aggregate computation. Conventional SIG(EC) protocols would not offer such a VF-side advantage, to extent that the total work W(VF) is directly proportional to the number of individual VF computations. The W(VF-aggregate) undertaken for such an aggregation would be less, and therefore advantageous, if such aggregations can be undertaken to some numerical degree, which would be attainable in conventional BDL use cases. B(X) aggregation would be an exemplary use case, especially in the context of such aggregation in the form of binary T(X) of multiple tiers, as is conventional. Such VF capability enables node-level POW collaboration, as proposed herein; which is advantageous in comparison to the conventional formulation of POW competition, with emergence of single winning node.

Reference is made to FIG. l.On which illustrates the multi-signer interaction required for SIG-group and SIG-threshold computations, with conventional SIG(EC) protocols in need of a 3 -pass interaction. Such interactivity requires each contributing signer to interact in a synchronous manner with other signers. The use of the BLS/PSS/SIG(EC-P) protocol enables non-interactive combination of each SIG-share, as contributed asynchronously by the corresponding signers; and is therefore advantageous in its simplicity, and reduced requirements with regards to computation and communications. Group or threshold-group specification can be undertaken in add(DST) of particular incoming BDL transaction, which requires k..n-of-n multi-signer collaboration for SIG-group/threshold computation to execute subsequent outgoing transaction.

Reference is made to FIG. l.Oo which illustrates a SIG-ring arrangement, in which a single signer (of n in ring) undertakes SIG computation thereof, as subject to VF via PK of entire ring, with outcome that signer preserves individual privacy within ring. Ring specification is likewise undertaken in add(DST) of an incoming transaction, with any 1-of-n signer in ring capable of executing the subsequent outgoing transaction.

Reference is made to FIG. l.Op which illustrates the comparative lengths of the SIG-ring of conventional formulation, in comparison to the SIG-GS protocol of prior art (PA) 1. L(S- ring) scales with size of the ring, but would be smaller in comparison to L(S-GS) for rings of size less than 8; as would be practical for most BDL use cases. SIG-ring computation would also be simpler in comparison.

Reference is made to FIG. l.Oq which illustrates a SIG-threshold arrangement; in which a threshold of k signers (of n in group) undertakes SIG-share computation, with subsequent non-interactive combination; with outcome that single SIG-threshold is representative of entire group. Communications relating to SIG-share computation can be undertaken privately, so as to facilitate signer (and non-signer) privacy within group. Threshold-group specification is similarly undertaken in add(DST) of an incoming transaction, with any k-of-n signers in collaboration capable of executing the subsequent outgoing transaction. SIG- threshold capability requires prior setup of the signing group, resulting in a single PK for such group. S-group specification, with all n-of-n signers required, does not require prior setup, and can be undertaken on an ad hoc basis via specification of all PK in group in add(DST).

Reference is made to FIG. l.Or which illustrates a conventional BDL formulation with external structure as linked-list of all B(t) with t denoting time of consensus, with internal structure of B comprising T-graph containing L(X) of all X aggregated and subject to consensus protocol from time t-1 to t. T composition comprising smaller T-sub lends itself to the proposed POW collaboration, in which one or more nodes can add their signatures to T- sub structures as its VL contribution. B-aggregation to T of some prescribed size can then proceed subject to each T-sub having to satisfy some prescribed VL threshold for inclusion.

Reference is made to FIG. 1.0s which illustrates alternative BDL formulation as T-binary, as opposed tall T-graph, of any two preceding B of earlier aggregation; resulting in FIG. l.Ot of tangle-graph. Such formulations would also benefit from POW collaboration, from the choice of preceding B(0) and B(l), with VL in the form of node adding B(t) adding its signature to each of B(0) and B(l), thereby contributing towards some prescribed VL threshold.

Reference is now made to FIG. 2.0 which is a flowchart illustrating a general methodology of the present invention. As illustrated in FIG. 2.0, the method (200) for secure connectivity establishment between client application, as representative of particular user, and server node, as representative of service provider; comprising steps of user identity specification via address of ergonomic form, as would be practical for particular user to remember, and to be able to input into client via manual transcription or alternative low-capacity user interface, UI method (202); signature computation, on transaction of interest, within protected interior component of client (204); with such computation contingent on establishment of secure connection to server, and proof of possession (POP) demonstration by client, relating to uniqueness and secrecy of client device and application instances, and if applicable proof ok knowledge (POK) demonstration by user, relating to secret input into client via manual transcription or alternative UI method. Subsequent to that, composition of encapsulation comprising transaction, signature, source user address as means with which to undertake server-side signature verification, and if applicable destination user address; and transmission of encapsulation on secure connection to server such that encapsulation, and in particular enclosed signature, is not accessible client-side exterior to protected component (206) followed by establishment of secure client-server connectivity (208); and identity management, IDM of user credentials (210).

Reference is made to FIG. 3.0 which is a flowchart illustrating steps for establishment of secure client-server connectivity is conducted via public-key, PK authenticated key establishment, AKE. As illustrated in FIG. 3.0, establishment of secure client-server connectivity (208) is conducted via public-key, PK authenticated key establishment, AKE and further comprising steps of (300) request by third-party transaction application to client, in response to action of user or associated transaction server, for signature computation on particular transaction (302) followed by a first action by client, contingent on positive assessment of request and requesting application (304); comprising computation of client-to- server challenge within protected interior component, and then transmission of user address and such challenge to server, via client-server connectivity established by third-party system. Subsequently, a second action by server, contingent on positive third-party authorisation of request and requesting application (306); comprising computation of response to received challenge, computation of reciprocal server-to-client challenge, and if applicable computation of key establishment key (KEK) resulting from AKE interaction, encryption of transaction- related payload with KEK, such that only initiating client as properly designated with user address can undertake corresponding decryption, and then transmission of service provider address, response, reciprocal challenge and encrypted payload, via third-party client-server connectivity. Thereafter, a third action by client, within interior component (308); comprising assessment of received response, and only on positive outcome thereof, retrieval of POP key- factorisation, and if applicable request and receipt of POK factorisation, client-side private- key, sk computation, with which to undertake response and computations, computation of response to reciprocal challenge, computation of signature on transaction, computation of KEK resulting from AKE interaction, decryption of received payload, encryption of transaction encapsulation with KEK, such that only responding server as designated with provider address can undertake corresponding decryption, and then transmission of reciprocal response and encrypted encapsulation, via third-party connectivity; and following that; and fourth action by server (310); comprising assessment of reciprocal response, and only on positive outcome thereof with decryption of received encapsulation, verification of enclosed signature, and only on positive outcome thereof, and onward transmission of encapsulation to requesting transaction server.

The client-side private-key, sk computation (308) further comprising steps of first sk hashed message authentication code, HMAC computation output, with internal element into key input, and external element into message input ; as both persistent for client-specific computation; or ephemeral for interaction-specific computation, whichever applicable. Client-side private key, sk computation (308) is further configured for particular user associated with client instance and further comprising multiplicity of factors, as characterised by uniqueness and furthermore immutability, as particular to client device and subject to proof-of-possession, POP via single or multiple system-read operations executed within protected interior environment of client, such system elements inclusive of Media Access Control, MAC address, International Mobile Equipment Identifier, IMEI and International Mobile Subscriber Identifier, IMSI; and secrecy, as particular to client instance, subject to limitation of access to within such protected environment; and if applicable user, subject to proof ok knowledge, POK via user input into client; with such factorisation instances subject to computation during each AKE-signing interaction and prior to that establishment during prior registration interaction as further characterised in that incorrect client-side demonstration of any single POP or POK factor further results in negative server-side assessment of particular AKE interaction; and providing provider issued sk-add associated with user address.

Client-side private key, sk computation, subject to computation for particular AKE-signing or registration interaction; comprising multiplicity of factors, as characterised by internal state dependency as furthermore secret, particular to interaction instance and subject to limitation of access to within protected interior environment; and external sensitivity as furthermore of high granularity, subject to single or multiple sensor-read operations likewise executed within protected environment at instance of interaction, such sensor elements inclusive of clock and Global Positioning Satellite, GPS. Such is further characterised in that such computation enables computation of corresponding elliptic curve, EC PK via specified group operation. Reference is now made to FIG. 4.0 which is a flowchart illustrating steps for client-side private key, sk computation is further configured for computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address and the configuration. As illustrated in FIG. 4.0, client-side private key, sk computation (308) is further configured for computation of client-originated sk, as protective measure for provider- issued sk-add associated with user address; and the configuration further comprising steps of (400) initial registration interaction (402); with receipt of sk-add in KEK encryption, following second action by server of registration interaction (404) followed by computation of sk, subject to positive AKE assessment and correct POP and POK inputs into HMAC computation, in third action of interaction by client within interior component (406); recovery of sk-add via KEK decryption (408); computation of factorisation via same POP and POK inputs into alternative HMAC computation (410); differentiation of sk-add and such factor (412); and insertion of differential thereof into client storage (414). Thereafter, for subsequent AKE-signing interaction (416) with equivalent computation of sk and sk-add factor, subject to similar conditions, in third action of interaction (418); followed by computation of sk-add, as integration of such valuation and differential as recovered from storage as enabling method for equivalence of (sk, sk-add) association with particular user (420); enabling user- associated (sk, sk-add) and (PK, add) as the respective composite sk and PK (422); andprotective measure for provider issued sk share associated with singular share of multi signature of n a group with designated address (424).

Reference is made to FIG. 5.0 which is a flowchart illustrating steps for enabling user- associated (sk, sk-add) and (PK, add) as the respective composite sk and PK. As illustrated in FIG. 5.0, in enabling user-associated (sk, sk-add) and (PK, add) as the respective composite sk and PK (422) further comprising steps of (500) of extension of EC framework to pairing P operations, for computation of EC-P -based short signatures, PSS (502); with characteristics inclusive of hash and signature outcomes on same EC framework, absence of EC-P operations for client-side signature computation, minimum of EC-P-identity ID operations for server-side signature verification, and preservation of such minimum for aggregate verification of multiple signatures, contingent on similarity of transaction or PK inputs (504); and further extension of framework to EC-P-(ID)entity operations, for computation of AKE- ID interaction parameters, computation of PK-ID as full domain hash FDH of user address; with characteristics inclusive of initial sk-add issue, by trusted party as acknowledged by service provider, during user registration; as then applicable to subsequent AKE-ID interaction for client-server secure connectivity; subject to correct sk-add computation in third action of interaction. Such is as equivalent to correct sk computation from POP/K demonstration in same action; as protective measure for client-side PSS computation, subject to positive assessment of AKE outcome; and then server-side PSS verification, also subject to positive assessment of AKE outcome; with further characteristics inclusive of minimum of EC-P operations for client and server engaged in interaction, and PSS of shorter length in comparison to alternative ECC formulations; and enabling AKE-ID interaction as protective measure for PSS share computation and ring signature computation (506).

Reference is now made to FIG. 6.0 which is a flowchart illustrating further steps for AKE-ID interaction as protective measure for PSS computation. As illustrated in FIG. 6.0, AKE-ID interaction as protective measure for PSS computation (506) further comprising steps of (600) first action by client comprising AKE-ID computations (602) followed by a second action by server comprising AKE-ID computations (604) and a third action by client. The third action by client comprising AKE-ID computations (606); and only on positive outcome thereof PSS computation, encapsulation thereof as protected by AKE-ID computation, and KEK encryption thereof, for transmission to server. The third action is followed by a fourth action by server comprising AKE-ID computations (608), and only on positive outcome thereof KEK decryption of incoming transmission from client, and PSS verification of encapsulation; enabling post interaction server action on PSS computation on common transaction by user multiplicity as individually subject to AKE-ID protected submission (610); and enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing (612). In enabling post interaction server action on PSS computation on common transaction by user multiplicity as individually subject to AKE-ID protected submission (610) further comprising steps of summation, according to designated list of user addresses, via EC addition operation of individual PSS computations on common transaction. Alternatively, summation, according to weightage of individual users in multi-signature group, of at least k-of-n PSS-share computations on common transaction; such that summation outcome as multi-signature is subject to verification via PK as aggregate via addition of PK as individually associated with signing users. Alternatively, singular PK as associated with particular signing group; as enabling method for multi-signature computation from PSS multiplicity. Reference is made to FIG. 7.0 which is a flowchart illustrating steps for identity management, IDM of user credentials. As illustrated in FIG. 7.0, identity management, IDM of user credentials (210) further comprising steps of (700) server-side storage of user-associated add, certificate(PK) on corresponding PK, and personally identifiable information (PII) into separate tables (702); establishment of realisation-virtualisation traversal mechanisms between all pairs of tables (704); with traversal from table(PII) to table(add) and separately table(cert) via respective virtualisation operations, with corresponding attachments of respective virtualisation outcomes V(PII) on each of table(add) and table(cert); traversal from table(add) to table(cert) as virtualisation operation, for access to PK for particular PSS verification; and access to table(cert) information relating to initial establishment of cert(PK), and issue of sk-add prior to verification operation; with characteristics inclusive of certificate valuation as index for table(cert) as derivation of address valuation; and if applicable attachment of virtualisation outcome V(add) to table(cert); reciprocal traversal from table(cert) to table(add) as realisation operation, with corresponding attachment of realisation outcome R(PK) to table(add); and reciprocal traversal to table(PII) from each of table(add) and table(cert) via respective realisation operations, with corresponding attachments of realisation outcomes R(add) and R(PK) on table(PII); and enabling identity management, IDM via hash computation (706).

IDM via hash computation (706) further comprising table(add)-table(cert) traversal via set of virtualisation-realisation (VK, RK) keys, with certificate index of table(cert) as hash or HMAC output from add input, with additional input of VK if applicable, and R(PK) on table(add) as HMAC output from PK input, with additional input of applicable RK; table(add)-table(PII) traversal via another (VK, RK) set, with V(PII) on table(add) as HMAC output from PII input, with additional input of applicable VK, and R(add) on table(PII) as HMAC output from add input, with additional input of corresponding RK; and table(cert)- table(PII) traversal via yet another (VK, RK) set, with V(PII) on table(cert) as HMAC output from PII input, with additional input of applicable VK, and R(PK) on table(PII) as HMAC output from PK input, with additional input of corresponding RK; as enabling methods for table(cert) access from address input, limitation of reciprocal table(add) access from certificate input, limitation of access to table(add) and table(cert) access from PII input; restrictive limitation of table(PII) access from address or certificate inputs; and IDM of user credentials arising from initial registration interaction. Reference is made to FIG. 8.0 which is a flowchart illustrating steps for IDM of user credentials arising from initial registration interaction. As illustrated in FIG. 8.0, IDM of user credentials arising from initial registration interaction further comprising steps of (800) first action by client comprising AKE computations via EC operations (802) followed by a second action by server comprising AKE-EC computations (804). The second action is followed by a third action by client comprising AKE-EC computations (806); and only on positive outcome thereof composition of encrypted encapsulation; comprising certificate signing request (CSR) for subsequent user association, inclusive of PSS PK for subsequent signing operations, and PII if applicable, then PSS computation on CSR, and add of user choice for subsequent AKE- ID interactions for subsequent transmission to server; and fourth action by server comprising AKE-EC computations (808); and only on positive outcome thereof decryption of incoming encapsulation from client, and PSS verification on CSR, as establishment for correctness of PK association; and enablement of IDM action (810).

Reference is made to FIG. 9.0 which is a flowchart illustrating steps for enablement of IDM action. As illustrated in FIG. 9.0, enablement of IDM action (810) further comprising steps of (900) a first action by client comprising AKE computations via EC operations (902) followed by a second action by server comprising AKE-EC computations (904); and only on positive outcome thereof of composition of encrypted payload which further comprising cert(PK) corresponding to previous CSR(PK) submission, as issued by trusted party acknowledged by service provider, and sk-add corresponding to address of user choice, or if applicable (add, sk-add), as similarly issued by trusted party; for subsequent transmission to client. Such is followed by a third action by client comprising AKE-EC computations (906); and only on positive outcome thereof with decryption of incoming payload from server; factorisation of sk-add, and commitment of differential thereof to client storage, and composition of encrypted encapsulation which further comprising acknowledgement of payload received, as hash thereof, PSS computation on acknowledgement; address as chosen or issued; and for subsequent transmission to server. The third action is followed by a fourth action by server comprising AKE-EC computations (908); and only on positive outcome thereof with decryption of incoming encapsulation from client, and PSS verification on acknowledgement, as enabling method for subsequent client engagement in AKE-ID interactions and PSS signing. Reference is made to FIG. 10.0 which is a flowchart illustrating steps for encapsulation thereof as protected by AKE-ID computation. As illustrated in FIG. 10.0, encapsulation thereof as protected by AKE-ID computation (606) further comprising steps of (1000) encapsulation (1002) followed by transaction (1004) which itself comprising source (SRC) add, as denotes particular user in present interaction, destination (DST) add, as denotes user or other entity as designated recipient of present interaction, and transaction information, as denotes exchange between SRC and DST entities. The step of transaction (1004) is followed by PS S on transaction (1006).

Reference is made to FIG. 11.0 is a flowchart illustrating steps for transaction further including specifying DST within transaction encapsulation. As illustrated in FIG. 11.0, transaction (1004) further including specifying DST within transaction encapsulation and further comprising steps of (1100) summation of user address multiplicity, for specification that all n users in list must contribute signatures (1102); and concatenation of address multiplicity, for specification that 1-of-n users in list must contribute ring signature (1104).

Reference is now made to FIG. 12.0 which is a flowchart illustrating further steps for computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address is further configured for client-side sk computation as protective measure for provider-issued sk share associated with singular share of multi -signature k-of-n group with designated address. As illustrated in FIG. 12.0, computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address is further configured for client-side sk computation as protective measure for provider-issued sk share associated with singular share of multi -signature k-of-n group with designated address and further comprising steps of (1200) receipt of sk-share as encrypted payload, following second action of registration interaction (1202); factorisation of sk-share and commitment of differential thereof into client storage (1204); subsequent AKE-signing interaction (1206); computation for sk-share from integration of factorisation, as presently computed, and differential, as retrieved from storage; as enabling method for equivalence of sk, sk-share association with particular user (1208).

Reference is made to FIG. 13.0 which is a flowchart illustrating steps for enabling AKE-ID interaction as protective measure for PSS share computation. As illustrated in FIG. 13.0, enabling AKE-ID interaction as protective measure for PSS share computation (506) further comprises steps of (1300) third action by client comprising AKE-ID computations, and only on positive outcome of prior actions in interaction (1302) with PSS share computation, via sk-share computation; encrypted encapsulation thereof; for transmission to server. Such is followed by a fourth action by server comprising AKE-ID computations, and only on positive outcome thereof (1304) with decryption of incoming transmission from client, and PSS verification of encapsulation, via PK corresponding to sk-share associated with particular user.

Reference is made to FIG. 14.0 which is a flowchart illustrating steps for enabling AKE-ID interaction as protective measure for ring signature, RS computation. As illustrated in FIG. 14.0, enabling AKE-ID interaction as protective measure for ring signature computation (506) further comprising steps of (1400) a third action by client comprising AKE-ID computations, and only on positive outcome of prior actions in interaction (1402); RS computation, via sk as also applicable for PSS computation; then encrypted encapsulation thereof for transmission to server. It is followed by a fourth action by server comprising AKE-ID computations, and only on positive outcome thereof (1404) with decryption of incoming transmission from client, and RS verification of encapsulation, via PK corresponding to concatenation of PK as individually associated with user addresses on designated list.

Reference is made to FIG. 15.0 which is a flowchart illustrating steps of enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing. As illustrated in FIG. 15.0, enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing (612) further comprises steps of (1500) aggregation into leaf element of all TX encapsulations with positive signature verification outcomes (1502); and computation of PSS on leaf TX aggregation, subject to verification via server PK; as enabling method for aggregation and validation of leaf encapsulation of TX multiplicity (1504).

Reference is now made to FIG. 16.0 which is a flowchart illustrating steps of post aggregation server action, as subject to previous validation by aggregation server. The steps for enabling AKE-ID interaction as protective measure for ring signature computation (506) further comprises post-aggregation server action, as subject to previous validation by aggregation server and further comprising steps of (1600) computation of PSS on leaf TX by subsequent server, as likewise subject to verification via corresponding PK; as enabling joint post validation of leaf TX aggregation (1602); and thereafter enabling post validation server action (1604).

Reference is made to FIG. 17.0 which is a flowchart illustrating steps of enabling joint post validation server action. As illustrated in FIG. 17.0, enabling post-validation server action (1604) further comprising steps of (1700) aggregation and validation of particular leaf TX as elements in consensus protocol for further aggregation into block encapsulation of leaf multiplicity (1702); and addition thereof to blockchain or distributed ledger, BDL (1704).

Unless the context requires otherwise or specifically stated to the contrary, integers, steps or elements of the invention recited herein as singular integers, steps or elements clearly encompass both singular and plural forms of the recited integers, steps or elements. Throughout this specification, unless the context requires otherwise, the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated step or element or integer or group of steps or elements or integers, but not the exclusion of any other step or element or integer or group of steps, elements or integers. Thus, in the context of this specification, the term “comprising” is used in an inclusive sense and thus should be understood as meaning “including principally, but not necessarily solely”.

Claims

1. A method (200) for secure connectivity establishment between client application, as representative of particular user, and server node, as representative of service provider; comprising steps of: user identity specification via address of ergonomic form, as would be practical for particular user to remember, and to be able to input into client via manual transcription or alternative low-capacity user interface, UI method (202); signature computation, on transaction of interest, within protected interior component of client (204); with such computation contingent on establishment of secure connection to server, and proof of possession (POP) demonstration by client, relating to uniqueness and secrecy of client device and application instances, and if applicable proof of knowledge (POK) demonstration by user, relating to secret input into client via manual transcription or alternative UI method; and subsequent to that composition of encapsulation comprising transaction, signature, source user address as means with which to undertake server-side signature verification, and if applicable destination user address; transmission of encapsulation on secure connection to server such that encapsulation, and in particular enclosed signature, is not accessible client- side exterior to protected component (206); establishment of secure client-server connectivity (208); and identity management, IDM of user credentials (210).

2. The method (200) according to claim 1, wherein establishment of secure client- server connectivity (208) is conducted via public-key, PK authenticated key establishment, AKE and further comprising steps of (300): request by third-party transaction application to client, in response to action of user or associated transaction server, for signature computation on particular transaction (302); first action by client, contingent on positive assessment of request and requesting application (304); comprising computation of client-to-server challenge within protected interior component, and then transmission of user address and such challenge to server, via client- server connectivity established by third-party system; second action by server, contingent on positive third-party authorisation of request and requesting application (306); comprising computation of response to received challenge, computation of reciprocal server-to-client challenge, and if applicable computation of key establishment key (KEK) resulting from AKE interaction, encryption of transaction-related payload with KEK, such that only initiating client as properly designated with user address can undertake corresponding decryption, and then transmission of service provider address, response, reciprocal challenge and encrypted payload, via third-party client-server connectivity; third action by client, within interior component (308); comprising assessment of received response, and only on positive outcome thereof, retrieval of POP key-factorisation, and if applicable request and receipt of POK factorisation, client-side private-key, sk computation, with which to undertake response and computations, computation of response to reciprocal challenge, computation of signature on transaction, computation of KEK resulting from AKE interaction, decryption of received payload, encryption of transaction encapsulation with KEK, such that only responding server as designated with provider address can undertake corresponding decryption, and then transmission of reciprocal response and encrypted encapsulation, via third-party connectivity; and following that; and fourth action by server (310); comprising assessment of reciprocal response, and only on positive outcome thereof, decryption of received encapsulation, verification of enclosed signature, and only on positive outcome thereof, and onward transmission of encapsulation to requesting transaction server.

3. The method (200) according to claim 2, wherein client-side private-key, sk computation (308) further comprising steps of: sk as hashed message authentication code, HMAC computation output, internal element into key input, and external element into message input ; as both persistent for client-specific computation; or ephemeral for interaction-specific computation, whichever applicable.

4. The method (200) according to claim 3, wherein client-side private key, sk computation (308) is further configured for particular user associated with client instance and further comprising multiplicity of factors, as characterised by: uniqueness and furthermore immutability, as particular to client device and subject to proof-of-possession, POP via single or multiple system-read operations executed within protected interior environment of client, such system elements inclusive of Media Access Control, MAC address, International Mobile Equipment Identifier, IMEI and International Mobile Subscriber Identifier, IMSI; and secrecy, as particular to client instance, subject to limitation of access to within such protected environment; and if applicable user, subject to proof ok knowledge, POK via user input into client; with such factorisation instances subject to computation during each AKE-signing interaction and prior to that establishment during prior registration interaction as further characterised in that incorrect client-side demonstration of any single POP or POK factor results in negative server-side assessment of particular AKE interaction; and providing provider issued sk-add associated with user address.

5. The method (200) according to claim 4, wherein client-side private key, sk computation, subject to computation for particular AKE-signing or registration interaction; comprising multiplicity of factors, as characterised by internal state dependency as furthermore secret, particular to interaction instance and subject to limitation of access to within protected interior environment; and external sensitivity as furthermore of high granularity, subject to single or multiple sensor-read operations likewise executed within protected environment at instance of interaction, such sensor elements inclusive of clock and Global Positioning Satellite, GPS; as further characterised in that such computation enables computation of corresponding elliptic curve, EC PK via specified group operation.

6. The method (200) according to claim 2 and claim 4, wherein client-side private key, sk computation (308) is further configured for computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address; and the configuration further comprising steps of (400): initial registration interaction (402); with receipt of sk-add in KEK encryption, following second action by server of registration interaction (404); computation of sk, subject to positive AKE assessment and correct POP and POK inputs into HMAC computation, in third action of interaction by client within interior component (406); recovery of sk-add via KEK decryption (408); computation of factorisation via same POP and POK inputs into alternative HMAC computation (410); differentiation of sk-add and such factor (412); and insertion of differential thereof into client storage (414); and then for subsequent AKE-signing interaction (416); with equivalent computation of sk and sk-add factor, subject to similar conditions, in third action of interaction (418); computation of sk-add, as integration of such valuation and differential as recovered from storage as enabling method for equivalence of (sk, sk-add) association with particular user (420); enabling user-associated (sk, sk-add) and (PK, add) as the respective composite sk and PK (422); and protective measure for provider issued sk share associated with singular share of multi signature of n a group with designated address (424).

7. The method (200) according to claim 6, wherein enabling user-associated (sk, sk- add) and (PK, add) as the respective composite sk and PK (422) further comprising steps of (500): extension of EC framework to pairing P operations, for computation of EC-P- based short signatures, PSS (502); with characteristics inclusive of hash and signature outcomes on same EC framework, absence of EC-P operations for client-side signature computation, minimum of EC-P operations for server-side signature verification, and preservation of such minimum for aggregate verification of multiple signatures, contingent on similarity of transaction or PK inputs (504); and further extension of framework to EC-P-identity ID operations, for computation of AKE-ID interaction parameters, computation of PK-ID as full domain hash FDH of user address; with characteristics inclusive of initial sk-add issue, by trusted party as acknowledged by service provider, during user registration; as then applicable to subsequent AKE-ID interaction for client-server secure connectivity; subject to correct sk-add computation in third action of interaction; as equivalent to correct sk computation from POP/K demonstration in same action; as protective measure for client-side PSS computation, subject to positive assessment of AKE outcome; and then server-side PSS verification, also subject to positive assessment of AKE outcome; with further characteristics inclusive of minimum of EC-P operations for client and server engaged in interaction, and PSS of shorter length in comparison to alternative ECC formulations; and enabling AKE- ID interaction as protective measure for PSS share computation and ring signature computation (506).

8. The method (200) according to claim 7, wherein AKE-ID interaction as protective measure for PSS computation (506) further comprising steps of (600): first action by client comprising AKE-ID computations (602); second action by server comprising AKE-ID computations (604); third action by client comprising AKE-ID computations (606); and only on positive outcome thereof

PSS computation, encapsulation thereof as protected by AKE-ID computation, and

KEK encryption thereof, for transmission to server; and fourth action by server comprising AKE-ID computations (608), and only on positive outcome thereof

KEK decryption of incoming transmission from client, and PSS verification of encapsulation; enabling post interaction server action on PSS computation on common transaction by user multiplicity as individually subject to AKE-ID protected submission (610); and enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing (612).

9. The method (200) according to claim 1, wherein identity management, IDM of user credentials (210) further comprising steps of (700): server-side storage of user-associated add, certificate(PK) on corresponding PK, and personally identifiable information (PII) into separate tables (702); establishment of realisation-virtualisation traversal mechanisms between all pairs of tables (704); with traversal from table(PII) to table(add) and separately table(cert) via respective virtualisation operations, with corresponding attachments of respective virtualisation outcomes V(PII) on each of table(add) and table(cert); traversal from table(add) to table(cert) as virtualisation operation, for access to PK for particular PSS verification; and access to table(cert) information relating to initial establishment of cert(PK), and issue of sk-add prior to verification operation; with characteristics inclusive of certificate valuation as index for table(cert) as derivation of address valuation; and if applicable attachment of virtualisation outcome V(add) to table(cert); reciprocal traversal from table(cert) to table(add) as realisation operation, with corresponding attachment of realisation outcome R(PK) to table(add); and reciprocal traversal to table(PII) from each of table(add) and table(cert) via respective realisation operations, with corresponding attachments of realisation outcomes R(add) and R(PK) on table(PII); and enabling identity management, IDM via hash computation (706).

10. The method (200) according to claim 9, wherein IDM via hash computation (706) further comprising: table(add)-table(cert) traversal via set of virtualisation-realisation (VK, RK) keys, with certificate index of table(cert) as hash or HMAC output from add input, with additional input of VK if applicable, and

R(PK) on table(add) as HMAC output from PK input, with additional input of applicable RK; table(add)-table(PII) traversal via another (VK, RK) set, with

V(PII) on table(add) as HMAC output from PII input, with additional input of applicable VK, and

R(add) on table(PII) as HMAC output from add input, with additional input of corresponding RK; and table(cert)-table(PII) traversal via yet another (VK, RK) set, with

V(PII) on table(cert) as HMAC output from PII input, with additional input of applicable VK, and

R(PK) on table(PII) as HMAC output from PK input, with additional input of corresponding RK; as enabling methods for table(cert) access from address input, limitation of reciprocal table(add) access from certificate input, limitation of access to table(add) and table(cert) access from PII input; restrictive limitation of table(PII) access from address or certificate inputs; and IDM of user credentials arising from initial registration interaction.

11. The method (200) according to claim 10, wherein IDM of user credentials arising from initial registration interaction further comprising steps of (800): first action by client comprising AKE computations via EC operations (802); second action by server comprising AKE-EC computations (804); third action by client comprising AKE-EC computations (806); and only on positive outcome thereof composition of encrypted encapsulation; comprising certificate signing request (CSR) for subsequent user association, inclusive of

PSS PK for subsequent signing operations, and

PII if applicable, then

PSS computation on CSR, and address of user choice for subsequent AKE-ID interactions for subsequent transmission to server; and fourth action by server comprising AKE-EC computations (808); and only on positive outcome thereof decryption of incoming encapsulation from client, and

PSS verification on CSR, as establishment for correctness of PK association; and enablement of IDM action (810).

12. The method (200) according to claim 11, wherein enablement of IDM action (810) further comprising steps of (900): first action by client comprising AKE computations via EC operations (902); second action by server comprising AKE-EC computations (904); and only on positive outcome thereof composition of encrypted payload; comprising cert(PK) corresponding to previous CSR(PK) submission, as issued by trusted party acknowledged by service provider, and sk-add corresponding to address of user choice, or if applicable (add, sk-add), as similarly issued by trusted party; for subsequent transmission to client; third action by client comprising AKE-EC computations (906); and only on positive outcome thereof decryption of incoming payload from server; factorisation of sk-add, and commitment of differential thereof to client storage, composition of encrypted encapsulation; comprising acknowledgement of payload received, as hash thereof,

PSS computation on acknowledgement; address as chosen or issued; for subsequent transmission to server; and fourth action by server comprising AKE-EC computations (908); and only on positive outcome thereof decryption of incoming encapsulation from client, and

PSS verification on acknowledgement, as enabling method for subsequent client engagement in AKE-ID interactions and PSS signing.

13. The method (200) according to claim 8, wherein encapsulation thereof as protected by AKE-ID computation (606) further comprising steps of (1000): encapsulation (1002); transaction (1004); itself comprising source (SRC) add, as denotes particular user in present interaction, destination (DST) add, as denotes user or other entity as designated recipient of present interaction, and transaction information, as denotes exchange between SRC and DST entities; and

PSS on transaction (1006).

14. The method (200) according to claim 13, wherein transaction (1004) further including specifying DST within transaction encapsulation and further comprising steps of (1100): summation of user address multiplicity, for specification that all n users in list must contribute signatures (1102); and concatenation of address multiplicity, for specification that 1-of-n users in list must contribute ring signature (1104).

15. The method (200) according to claim 6, wherein computation of client-originated sk, as protective measure for provider-issued sk-add associated with user address is further configured for client-side sk computation as protective measure for provider-issued sk share associated with singular share of multi -signature k-of-n group with designated address and further comprising steps of (1200): receipt of sk-share as encrypted payload, following second action of registration interaction (1202); factorisation of sk-share and commitment of differential thereof into client storage (1204); subsequent AKE-signing interaction (1206); computation for sk-share from integration of factorisation, as presently computed, and differential, as retrieved from storage; as enabling method for equivalence of (sk, sk-share) association with particular user (1208).

16. The method (200) according to claim 7, wherein enabling AKE-ID interaction as protective measure for PSS share computation (506) further comprises steps of (1300): third action by client comprising AKE-ID computations, and only on positive outcome of prior actions in interaction (1302);

PSS share computation, via sk-share computation; encrypted encapsulation thereof; for transmission to server; and fourth action by server comprising AKE-ID computations, and only on positive outcome thereof (1304) decryption of incoming transmission from client, and

PSS verification of encapsulation, via PK corresponding to sk-share associated with particular user.

17. The method (200) according to claim 8, wherein enabling AKE-ID interaction as protective measure for ring signature RS computation (506) further comprising steps of (1400): third action by client comprising AKE-ID computations, and only on positive outcome of prior actions in interaction (1402);

RS computation, via sk as also applicable for PSS computation; then encrypted encapsulation thereof; for transmission to server; and fourth action by server comprising AKE-ID computations, and only on positive outcome thereof (1404), decryption of incoming transmission from client, and

RS verification of encapsulation, via PK corresponding to concatenation of PK as individually associated with user addresses on designated list.

18. The method (200) according to claim 8, wherein enabling post interaction server action on PSS computation on common transaction by user multiplicity as individually subject to AKE-ID protected submission (610) further comprising steps of : summation, according to designated list of user addresses, via EC addition operation of individual PSS computations on common transaction; or alternatively summation, according to weightage of individual users in multi-signature group, of at least k-of-n PSS-share computations on common transaction; such that summation outcome as multi-signature is subject to verification via

PK as aggregate via addition of PK as individually associated with signing users; or alternatively singular PK as associated with particular signing group; as enabling method for multi-signature computation from PSS multiplicity.

19. The method (200) according to claim 8, wherein enabling post interaction server action on transaction, TX multiplicity as individually subject to AKE-ID protected signing (612) further comprises steps of (1500): aggregation into leaf element of all TX encapsulations with positive signature verification outcomes (1502); and computation of PSS on leaf(TX) aggregation, subject to verification via server PK; as enabling method for aggregation and validation of leaf encapsulation of TX multiplicity (1504).

20. The method (200) according to claim 19, further comprises post-aggregation server action, as subject to previous validation by aggregation server and further comprising steps of (1600): computation of PSS on leaf TX by subsequent server, as likewise subject to verification via corresponding PK; as enabling method for joint validation of leaf TX aggregation (1602); and enabling joint post-validation server action (1604).

21. The method (200) according to claim 20, wherein enabling joint post-validation server action (1604) further comprising steps of (1700): aggregation and validation of particular leaf TX as elements in consensus protocol for further aggregation into block encapsulation of leaf multiplicity (1702); and addition thereof to blockchain or distributed ledger, BDL (1704).

22. A system (100) for client-server AKE-ID interaction and client-originated PSS computation comprising: AUTH server (102) for AUTH interaction between client and server, comprising AKE-ID interaction as protection for client-originated PSS signature computation on TX of interest; system interface, SI (104) to BDL network (106) for AUTZ interaction, comprising AUTZ verification on present BDL state as prior requirement for

PSS computation, and then insertion of TX encapsulation into TX multiplicity for validation into subsequent BDL state;

IDM server (108) for IDM interaction with AUTH server comprising AKE-ID add to certificate PK realisation, as enables subsequent PSS verification; and registration server (110) as dependent on prior registration interaction with client, comprising client origination of AKE-ID(add), server origination of cert(PK), and subsequently enablement of add to cert(PK) realisation computation.