Optimize Address Fetching in the Samsung Blockchain Keystore SDK with Seed Hash

[Samsung Newsroom]

Last June, Samsung introduced Samsung Blockchain Keystore (SBK), a secure built-in cold wallet in Galaxy devices. The cold wallet is isolated with Samsung Knox and encapsulated within a defense-grade Trusted Execution Environment (TEE). The Samsung Blockchain Keystore SDK enables use of this wallet in Android applications.

In this article, we discuss how to optimize the address fetching process with seed hash. Fetching addresses from the Samsung Blockchain Keystore using the SDK is time-consuming, so this blog will help you learn how to store your seed hash values to avoid delays in fetching information whenever you launch your app.

The Samsung Blockchain Keystore (SBK) SDK enables users to get blockchain public addresses from the Samsung Blockchain Keystore and sign a cryptocurrency transaction to authenticate. A public address is the hashed version of the public key and is used to recognize a blockchain cryptocurrency account. As the blockchain protocol goes, anyone can fetch the balance and transaction history of an account with its public address.

Developers can invoke the getAddressList() API of the SBK SDK to fetch the address list. Every time this API is called with the same request, you get the same address list. A change to the list occurs only when the wallet's root seed has been changed. The Programming Guide: API Flow and Use Cases provides more detailed information.

Seed hash

The SDK uses the term Seed Hash (see Figure 1, inside the green rectangle).

Figure 1: SBK SDK API flow and use case

The SDK Glossary says:

Seed Hash: A pseudo seed hash that is generated randomly when the HD wallet is created. If the master seed of a wallet is changed, the seed hash will be changed as well.

The getSeedHash() API gets the current seed hash from the Samsung Blockchain Keystore. Fetching the address list from the Samsung Blockchain Keystore using the SBK SDK initiates an expensive operation that requires a considerable amount of time. To provide the user with a seamless experience, the SBK SDK programming guide recommends that developers store information from the getSeedHash() API. Developers then need to invoke the getAddressList() API only when the stored seed hash is different from the seed hash fetched using the SBK SDK.

Prerequisites

Before you begin, be sure you've met these prerequisites:

• You have already imported the SDK in your Android app

• You have completed Samsung Blockchain Keystore wallet setup

• You meet supported device and regions restrictions

  If not, download the SBK SDK and check out the Programming Guide: Getting Started section to integrate the SBK SDK. I also recommend reading this blog on address fetching basics: "Where's My Crypto Coin? Featuring Samsung Blockchain Keystore SDK” .

  Enable developer mode in the Samsung Blockchain Keystore to bypass API key verification. The sample application in this blog is not a partner app, so you must enable developer mode to run and test the app features.

Store the seed hash

I recommend using Android SharedPreferences to store the seed hash. Remember, the seed hash value is not sensitive data; it's not the wallet's root seed itself. It's a hash value generated to keep track of change in the wallet. Because high-level security is not a concern, and when you have a relatively small collection of key values that you'd like to save, SharedPreferences is an easily implemented solution.

All you need to do is get the SharedPreferences file and then read and write key-value pairs on it. If you prefer another method of storing data, you can select any one of the methods described in the Android: Data and file storage overview.

The following code snippet refers to SharedPreferences:

private static final String seedHashKey = "seed\_hash";
private static final String defaultSeedHashValue = "";
private static SharedPreferences mSharedPreference;

mSharedPreference = getActivity().getPreferences(Context.MODE\_PRIVATE);

public static String getSeedHash() {
    return mSharedPreferences.getString(
                                 seedHashKey, defaultSeedHashValue);
}
public static void setSeedHash(String seedHash) {
        SharedPreferences.Editor editor = mSharedPreferences.edit();
        editor.putString(seedHashKey, seedHash);
        editor.commit();
    }
}

//Fetch SeedHash from SBK and Store on Share Preference
String seedHashSDK = ScwService.getInstance().getSeedHash();
setSeedHash(seedHashSDK);

Get the address list from the Samsung Blockchain Keystore

The getAddressList() API of the SBK SDK requires the HD path list and callback function parameters.

• HD path list parameter: An ArrayList, a list of strings in which every string denotes an HD path. See Understanding Keystore > Key Management for more information.
• Callback function parameter: A callback function of type ScwService.ScwGetAddressListCallback. The address fetching method is performed asynchronously, once the completed onSuccess() or onFailure() method is invoked. onSuccess() holds the required address list as a List, whereas onFailure() holds the error code.

The following code snippet retrieves four addresses at one time:

private ScwService.ScwGetAddressListCallback mScwGetAddressListCallback =
new ScwService.ScwGetAddressListCallback() {
    @Override
    public void onSuccess(List<String> addressList) {
        Log.i(Util.LOG\_TAG,
                       "Accounts fetched from SDK Successfully.");
    }
    @Override
    public void onFailure(int errorCode) {
     // Error Codes Doc:
     // https://img-developer.samsung.com/onlinedocs/blockchain/keystore/
        Log.e(Util.LOG\_TAG,
              "Fetch Accounts Failure. Error Code: " + errorCode);
    }
};

public void getPublicAddress(ArrayList<String> hdPathList) {
    mScwService.getAddressList(
              mScwGetAddressListCallback, hdPathList);
}
ArrayList hdPathList = new ArrayList<>();
hdPathList.add(ScwService.getHdPath(ScwCoinType.ETH, 0));       //m/44'/60'/0'/0/0
hdPathList.add(ScwService.getHdPath(ScwCoinType.ETH, 1));       //m/44'/60'/0'/0/1
hdPathList.add(ScwService.getHdPath(ScwCoinType.ETH, 2));       //m/44'/60'/0'/0/2
hdPathList.add(ScwService.getHdPath(ScwCoinType.ETH, 3));       //m/44'/60'/0'/0/3

//  BTC -> "m/44'/0'/0'/0/0";

getPublicAddress(hdPathList);

Representation

For an Accounts info demonstration, I've used Android's RecyclerView. For detailed information, see Create a List with RecyclerView and this android recyclerview example.

Figure 2: Fetching an address list from the Samsung Blockchain Keystore

Store address information on an application database

Once you have fetched the required addresses from the Samsung Blockchain Keystore, design your mechanism to store this information. Let’s look at requirements at this stage:

• Storage for account information: Accounts presented at app launch have to remain consistent on subsequent app launches, unless the wallet has been changed.
• Provide users with a seamless experience: Information should not be fetched from Samsung Blockchain Keystore using SDK every time the app launches, because it causes delays.

This leads us to Android Room. Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.

The three major Room components are:

• Database: Contains the database holder
• Entity: Represents a table within the database.
• DAO interface: Contains the methods used for accessing the database.

For more information about Android Room, see the documentation, blogs, and samples.

Database

Database class extends the RoomDatabase and builds the required database file.

@Database(entities = {AccountModel.class}, version = 1)
public abstract class AccountsDB extends RoomDatabase {

    private static AccountsDB accountsDB;
    public abstract IAccountsDAO iAccountsDAO();

    public static AccountsDB getInstance(Context context) {
        if (accountsDB == null || !accountsDB.isOpen()) {
            accountsDB = Room.databaseBuilder
                       (context, AccountsDB.class, Util.DB\_NAME)
                                                         .build();
        }
        return accountsDB;
    }
}

Entity

Here, we have declared our Model Class as a Room Entity using annotations. Room converts “the members of the class” to “columns of the table,” reducing boilerplate code.

@Entity
public class AccountModel {
    // accountID used as primary key & indexing, Auto Generated
    @PrimaryKey(autoGenerate = true)
    private int accountID;

    private String publicAddress;
    private String hdPath;
    // Getter & Setter Methods     
      .. ..
}

DAO interface

Here, you have to declare methods and corresponding database SQL queries to be run. This interface is implemented by the Room persistence library; corresponding codes are generated automatically to perform required database operations.

@Dao
public interface IAccountsDAO {
    @Query("SELECT \* FROM AccountModel")
    List<AccountModel> fetchAccounts();

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    void insertAccounts(ArrayList<AccountModel> accountModels);

    @Query("DELETE FROM AccountModel")
    void removeAccounts();
}

On invoking the Java method, corresponding queries are performed on the database. For example, invoking the removeAccounts() method executes the DELETE FROM AccountModel query.

Database operations

Room doesn’t allow you to issue database queries on the main thread, as it can cause delays. Database CRUD operations must be performed on a separate thread.

I’ve used AsyncTask on this example to perform database operations. AsyncTask allows you to perform background operations and publish results on the UI thread without manipulating threads and/or handlers yourself. AsyncTask gives a high-level wrapper over multithreading, so you don't need expertise in concurrent threads or handlers.

• doInBackground(Params...): Performs a computation on a background thread.
• onPostExecute (result): Posts on the UI thread once doInBackground() operation is completed. The result parameter holds the execution result returned by doInBackground().
• execute(Params...): On invocation, executes the task specified with given parameters.

See the API reference for details.

The following example code snippet shows the database retrieve data task:

private static class fetchAsyncTask extends
                   AsyncTask\> {
   @Override
   protected ArrayList<AccountModel> doInBackground(Void...voids){
       ArrayList<AccountModel> accountModels = new                 
           ArrayList<AccountModel>(accountsDB.iAccountsDAO().fetchAccounts());
        return accountModels;
    }

    @Override
    protected void onPostExecute   
                        (ArrayList<AccountModel> accountModels) {
        Log.i(Util.LOG\_TAG, "DB Fetch Successful");
        AccountRepository.setmAccountModels(accountModels);
    }
}

public static void fetchAccounts() {
    // DB CRUD operations has to be performed in a separate thread
    new fetchAsyncTask().execute();
}

Figure 3: Fetching an address list from database

Next steps

It's a lot of technical info for one blog. However, it will be worth it to have your apps launch quickly and seamlessly once you've optimized address fetching in the Samsung Blockchain Keystore SDK. For more detailed information, see the following references, and don't hesitate to reach out with any queries and feedback.

• Source code for Sample application "Optimize Address Fetching with Seed Hash"
• "Where's My Crypto Coin?” Featuring Samsung Blockchain Keystore SDK
• Samsung Blockchain Keystore Programming Guide: API Flow and Use Cases
• Android data and file storage: SharedPreferences
• Save data in a local database: Android Room

View the full blog at its source