Permissioned viewing is entirely unique to Secret Network with its encrypted state. It gives you ability to have precise control over who has access to what data. In order to determine when data is allowed to be released however, you need to have a way to prove who is trying to access it. Our two ways of doing this are through Viewing Keys and Permits/Certs.

How To Choose Between Viewing Keys and Permits

With the new Shockwave alpha update, Permits have become more efficient in almost every application. The exception is inter-contract communication permissions. Here, viewing keys still hold a lead. However, in some cases you may want to include an option to use both in your smart contract and leave the decision up to the users. Some users will have a preference for one over the other.

What is a Permit?

Permits are simply a dummy transaction signed by a wallet. The wallet is able to use this signature as proof that the transactor is who they say they are. Any wallet capable of using Tendermint is able to carry out this process.

Generating a permit happens outside of the smart-contract, but checking them in your smart contract is extremely simple. Once again the Secret-Toolkit provides a package for us, aptly named permit. The function that checks the permit is called validate shown below.

pub fn validate<Permission: Permissions, S: Storage, A: Api, Q: Querier>(
    deps: &Extern<S, A, Q>,
    storage_prefix: &str,
    permit: &Permit<Permission>,
    current_token_address: HumanAddr,
    hrp: Option<&str>,
) -> StdResult<String> {
    let account_hrp = hrp.unwrap_or("secret");

    if !permit.check_token(&current_token_address) {
        return Err(StdError::generic_err(format!(
            "Permit doesn't apply to token {:?}, allowed tokens: {:?}",
            current_token_address.as_str(),
            permit
                .params
                .allowed_tokens
                .iter()
                .map(|a| a.as_str())
                .collect::<Vec<&str>>()
        )));
    }

    // Derive account from pubkey
    let pubkey = &permit.signature.pub_key.value;

    let base32_addr = pubkey_to_account(pubkey).0.as_slice().to_base32();
    let account: String = bech32::encode(account_hrp, &base32_addr, Variant::Bech32).unwrap();

    // Validate permit_name
    let permit_name = &permit.params.permit_name;
    let is_permit_revoked = RevokedPermits::is_permit_revoked(
        &deps.storage,
        storage_prefix,
        &HumanAddr(account.clone()),
        permit_name,
    );
    if is_permit_revoked {
        return Err(StdError::generic_err(format!(
            "Permit {:?} was revoked by account {:?}",
            permit_name,
            account.as_str()
        )));
    }

    // Validate signature, reference: https://github.com/enigmampc/SecretNetwork/blob/f591ed0cb3af28608df3bf19d6cfb733cca48100/cosmwasm/packages/wasmi-runtime/src/crypto/secp256k1.rs#L49-L82
    let signed_bytes = to_binary(&SignedPermit::from_params(&permit.params))?;
    let signed_bytes_hash = sha_256(signed_bytes.as_slice());

    let verified = deps
        .api
        .secp256k1_verify(&signed_bytes_hash, &permit.signature.signature.0, &pubkey.0)
        .map_err(|err| StdError::generic_err(err.to_string()))?;

    if !verified {
        return Err(StdError::generic_err(
            "Failed to verify signatures for the given permit",
        ));
    }

    Ok(account)
}

To use this, simply call validate inside of your query provided with the necessary permit variables.

When is it Best to Use Permits?

Permits can be used at any time, and are amazing for almost every permissioned viewing application. The only time it may be more efficient to use viewing keys instead is during inter-contract communication.

Viewing Keys Introduction

Viewing keys are passwords meant to validate users at times when the blockchain cannot. Specifically in queries, the query sender isn't authenticated and the contract doesn't know who is the querier. Therefore viewing keys were invented to provide a way of access control for users:

1. Alice sends a transaction set_viewing_key(password)

2. The contract stores (alice,password)

3. Later on, a query is sent to the contract query("balance",alice,password)

   • If (alice,password) matches what's in storage, the contract returns Alice's balance to the querier.

Importing Secret Toolkit

Secret Network developed the for creating and managing viewing keys in Secret smart contracts. The methods provided include:

• set_seed: Sets an initial pseudorandom number generator (PRNG) seed for the store.

• create: Creates a new viewing key, saves it to the storage, and returns it.

• set: Sets a new viewing key based on a predetermined value.

• check: Checks if a viewing key matches an account.

To make use of the secret-toolkit viewing keys package, import it into your cargo.toml file:

Viewing Keys Implementation

This function stores a secret message at a specified index in the contract's storage, which is mapped to a viewing key. This ensures that the secret message can only be accessed by the correct viewing key, and that each secret message has its own unique viewing key.

Let's go over it in more detail:

1. A new viewing key is created by calling ViewingKey::create. The parameters passed include the mutable dependencies (which includes the storage), the environment env, the MessageInfo, the sender account, and a hard-coded entropy value b"entropy".

2. The secret message is then stored in the contract's storage and is mapped to the viewing key. The SECRET_MESSAGE.insert line is performing this task.

3. Next, the viewing key itself is stored in the contract's storage, but this time indexed with a user-defined index parameter and prefixed by the sender's account address. This is done by VIEWING_KEY.add_suffix(info.sender.as_bytes()).insert(deps.storage, &index, &viewing_key).

4. Finally, the function returns a default Response instance indicating successful execution of the function.

Additional Viewing Keys methods

check

set

set_seed

Summary