TzSafe and TZIP27 (2)
The Marigold Dapps team is aligning with the Tezos standard to facilitate integration and maintain uniformity.
TzSafe app now serves on Ghostnet, supporting a partial standard of TZIP-27, enabling dApps to pair and submit operations via beacon-sdk to wallet application. It should fulfill the majority of dApp needs. This post will discuss the remaining topic of TZIP-27: signing and signature, addressing concerns for dApps interested in this aspect.
Notice: Pairing and submitting operations will be available on the Mainnet through the TzSafe app starting on November 30.
Signing and Signature
TZIP-27 establishes a standard for enabling contract accounts to sign a message as a signature, similar to implicit accounts. This is necessary because account abstraction has not implemented at the Tezos protocol level yet. Following TZIP-27, contract accounts seeking to sign must undergo a proof-of-event challenge . Consequently, the emitted event from the accounts will be recognized as the proof of event, abbreviated as the proof, standing as the signature of the contract account.
After introducing new methods of signing and generating signatures, the discussion moves to the next topic: secure message signing. Signing a message serves to demonstrate a user’s authorization for a specific account or to verify the origin of a message from a particular account. However, the message itself can be a random data trunk, giving rise to issues such as abused signatures by malicious dApps and replay attacks.
To address these security concerns, a solution involving constructing message is proposed in the TZIP, "Signing Micheline strings," and ERC-4361, “Sign-In with Ethereum," specifically designed for implicit accounts. To ensure an equivalent level of security as TzSafe, contract account, with the implementation of TZIP-27, the same concept is applied. The following will detail how TzSafe realized this.
Architecture
In the previous post, the discussion covered how TzSafe App, functioning as a wallet application, integrates with TZIP-27. In this post, to facilitate a broader and secure application, modifications have been made to the architecture of TzSafe App and the format of both proof-of-event challenge and proof of event. Therefore, the new adjustment as following:
Proof of event proposal
When processing a proof-of-event challenge, a proof-of-event proposal is created. This is a special proposal in TzSafe. It is created through the proof_of_event_challenge entrypoint, using parameters distinct from those employed in creating a regular proposal. Following its creation, the proof-of-event proposal undergoes the same signing and resolution process as a standard proposal. Upon resolution, the emitted proof serves as a conventional signature.
Constructing message
Referencing the TZIP, “Signing Micheline strings,” and ERC-4361, “Sign-In with Ethereum," for the constructing message, the following information, presented in Michelson syntax, should be included for the proof-of-event challenge:
option string %scheme. The URI scheme of the origin of the request. Its value MUST be a RFC 3986 URI scheme.string %domain. The domain of dApp that is requesting the signing. Its value MUST be a RFC 3986 authority. The authority includes an OPTIONAL port. If the port is not specified, the default port for the providedschemeis assumed (e.g., 443 for HTTPS). Ifschemeis not specified, HTTPS is assumed by default.option string %statement. The human-readable string that the user will sign.string %uri. The resource that is the subject of the signing. Its value MUST be an RFC 3986 URI.nat %version. the current version of the message.bytes %nonce. A random bytes chosen by dApp and used to prevent replay attacks.option timestamp %expiration_time. The time at which the validity of the signed authentication message expires.option timestamp %not-before. The time at which the signed authentication message is set to become valid.option bytes %request-id. It MAY be used to uniquely refer to the request.option (list string) %resouces. A list of information or references to information the user wishes to have resolved as part of authentication by dApp.
The pseudo-code of constructed message to produce a packed message:
type constructed_message =
(pair
(string %prefix)
(string optional %scheme)
(string %domain)
(string option %statement)
(string %uri)
(string %version)
(string %nonce)
(string option %expiration_time)
(string option %not_before)
(string option %request_id)
(string option %resources)
)
let packed_message = PACK(constructed_message)
TZIP-27 specifies that the proof must include both challenge_id and payload. Accordingly:
- Users can choose random bytes for
challenge_id, adhering to the TZIP27 specifications. payloadencompasses the packed message.
DApp
After the proof is emitted, a dApp can retrieve it using the tag “%proof_of_event” from a block explorer like TZKT. Subsequently, the dApp should employ Michelson’s UNPACK operation on the payload to interpret the content of message. As the event is on-chain data, the following information should also be retrieved:
- Address: The address emitting the proof MUST begin with
KTas the abstracted account is a contract account. - Chain_id: The identifier of the chain for network distinction.
- The timestamp of the emitted proof: The time at which the proof was emitted.
The dApp must verify that both the content of message and on-chain information align with expectations to thwart potential attacks from malicious apps and ensure user protection.
