0.0.6

This is the 6th article/week 6 progress report of my journey at EthIndia Fellowship 3.0, EIF3.0 building Blockchain Powered eSIM.

Here’s the link of the fifth article of this series, a thesis on Blockchain Powered eSIM.

And with this article I’m starting with the Implementation of eSIM, mainly AOSP setup and understanding methods from EuiccManager.java, EuiccSevice.java, EuiccController.java.

But before that, There’s one concern in the design that has been troubling me,

So the current structure proposes,

A novel approach to link a crypto wallet(EOA) with mobile number in such a manner that a person gets associated with a crypto wallet(EOA) in a similar way the person gets associated to a mobile number with the help of eSIM/SIM technology. The proposed method employs the concept of account abstraction to establish a virtual account for non crypto users that serves as a purely cryptographic foundation layer. This approach enables secure access to users' crypto wallets without exposing their private keys, which is particularly beneficial for users unfamiliar with crypto wallets and the underlying technology. With the feasibility of the proposed concept and outlining how it can provide carrier app services to network carrier providers and Local Profile Assistant (LPA) services to mobile OEMs and end-users. The activation of the eSIM will take place through the Ethereum blockchain, and all relevant details will be sent to the Ethereum blockchain using a smart contract.

Now this seems to be a critical point to implement these three,

1. Wallet Creation: Create a crypto wallet within the LPA.

2. Key Management: Generate a private key and a corresponding public key for the crypto wallet.

3. Key Storage: Store the private key securely in the LPA.

So thinking about to associate a smart contract rather than a crypto wallet(EOA).

The Smart Contract will be inspired by Account Abstraction and act as a safe that puts a relief on managing and storing private keys of EOA wallets in the LPA and other drawbacks of EOA wallet.

To achieve this, the eSIM will be used to link the mobile number with the Smart Contract address, which will serve as a secure wallet. Users will be able to gain access to decentralized applications by connecting their wallet with a fingerprint scan or default app lock method, which will enable them to execute transactions in a secure and efficient manner.

Pros and cons of EOA and Smart Contract wallet

Pros of EOA wallets:

1. Easy to use and set up.

2. Can be used to store any type of Ethereum-based cryptocurrency.

3. Can be accessed using a private key, which can be backed up and stored securely.

Cons of EOA wallets:

1. The security of the wallet is solely dependent on the user's ability to keep their private key secure. If the private key is lost or stolen, the wallet cannot be recovered.

2. There is no way to limit the amount of funds that can be sent from the wallet, making it less secure in the event of a hack or theft.

Pros of Smart Contract wallets:

1. Can be designed to incorporate additional security features, such as multisig transactions and time locks, which make it more secure than EOA wallets.

2. Can be customized to meet specific requirements, such as automatic recurring payments or conditional transactions.

3. The funds in a Smart Contract wallet are not accessible unless the conditions specified in the Smart Contract are met.

Cons of Smart Contract wallets:

1. Can be more complicated to set up and use than EOA wallets.

2. Can only be used to store specific types of cryptocurrencies that are compatible with the Smart Contract language used to create the wallet.

3. Smart Contract wallets are dependent on the underlying blockchain technology, which can be subject to bugs and security vulnerabilities.

I’ll be implementing the smart contract wallet in the next week.

For now let’s begin with the current implementation as there steps to be climbed before associating a wallet.

Building LPA

As we are woking on building the LPA to let the end user manage eSIM profiles with wallet and networks.

To start implementing an eSIM we first need to build Android Open Source Project (AOSP).

NOTICE: Platform development on MacOS isn't supported as of June 22, 2021.

Proceeded with this guide for Building AOSP on mac OS.

Step 1: Setting up File system

The default file system on macOS 10.13 and later which is called Apple File System (APFS) is case-insensitive. But to build AOSP, we need a case-sensitive file system. Created a case-sensitive file system "aosp" using Disk Utility in mackbook pro 14" 2442, before we can start downloading the code.

Step 2: Downloading the source

Android team has made an utility called repo, which helps in managing multiple repositories. We will be using this utility to download android source.

Installed repo using brew successfully.

Created and base directory inside the new volume, where we want to clone all the repos required for building inside the volume we created in first step.

❯ cd /Volumes/aosp

❯ mkdir source

❯ cd source

Initialised the repo.

This will create a .repo/ directory with Git repositories for the Repo source code and the manifest files which specifies where the various repositories included in the Android source.
repo init -u <https://android.googlesource.com/platform/manifest>

Successfully downloaded Repo source from repo.

Now, cloning the source using repo sync -c -j8 and it took more than 8 hours in macbook pro with Apple M1 Pro chip.

Step 3: Environment setup and build configuration

Before, we can start the build, we need to some configuration steps.

• Commands Setup

Android source offers some helper commands for building, we can add them to our path in current session with below command.

❯ source build/envsetup.sh

You can use the hmm command to list all the helper commands that are added.

• Selecting Build target

We can select the build target, i.e for which product and architecture we want to build for using the lunch command. Just run lunch without any arguments, it will show you some of the available configurations.

And our Build Target is aosp_cf_x86_64_phone-userdebug

Now, Building the code:

To build Android, you must select a target device type to build with the lunch command. A target is a device permutation, such as a specific model or form factor.

The device target included below, aosp_cf_x86_64_phone-userdebug, enables you to build the Cuttlefish virtual Android device for testing without a physical device.

Passed build target successfully using lunch aosp_cf_x86_64_phone-userdebug

Then,

Tried many things after this but unable to pass through this successfully, got to know that there maybe chances where this target requires more RAM.
So i’m looking into different targets for implementation of eSIM.
If I failed to build the Cuttlefish virtual Android device for testing without a physical device. Then i’ll proceed to get a supported device making a Flashing Device and pass the respective target.

As i was stuck here, so proceeded to note down the methods for:

EID Retrieval: Retrieve the EID of the eSIM that will be used for coupling with the crypto wallet(EOA) or Smart Contract Wallet.

Get EID (public)

This API can be found in the EuiccManager EuiccManager.java.

• Gets the EID identifying the eUICC hardware.

• This may be null if the eUICC is not ready.

• The caller must have carrier privilege or the READ_PRIVILEGED_PHONE_STATE permission.

  String eid = mgr.getEid();
  if (eid == null) {
    // Handle null case.
  }
  

• Diving deep in the method by going through EuiccManager.java

  /**
       * Returns the EID identifying the eUICC hardware.
       *
       * <p>Requires that the calling app has carrier privileges on the active subscription on the
       * current eUICC. A calling app with carrier privileges for one eUICC may not necessarily have
       * access to the EID of another eUICC.
       *
       * @return the EID. May be null if the eUICC is not ready.
       */
      @Nullable
      public String getEid() {
          if (!isEnabled()) {
              return null;
          }
          try {
              return getIEuiccController().getEid(mCardId, mContext.getOpPackageName());
          } catch (RemoteException e) {
              throw e.rethrowFromSystemServer();
          }
      }
  

So as we can see,

• The method requires that the calling app has carrier privileges on the active subscription on the current eUICC.

  • If the calling app does not have the required privileges, the method will return null.

• Note that even if an app has carrier privileges for one eUICC, it may not necessarily have access to the EID of another eUICC.

• The getEid() method checks if the eUICC is enabled.

  • If it is not enabled, the method will return null. If the eUICC is enabled, the method will attempt to retrieve the EID by calling the getEid() method on the IEuiccController interface.

  • The mCardId parameter specifies the ID of the eUICC card to retrieve the EID from, and mContext.getOpPackageName() specifies the package name of the calling app.

• If an error occurs during the process of retrieving the EID, the method will throw a RemoteException and rethrow it as a RuntimeException. Otherwise, the EID of the active eUICC will be returned as a String.

From the above it seems like getIEuiccController() is an important method so diving deep into it and noting down all the methods that uses getIEuiccController

getIEuiccController()

/**
     * Whether embedded subscriptions are currently enabled.
     *
     * <p>Even on devices with the {@link PackageManager#FEATURE_TELEPHONY_EUICC} feature, embedded
     * subscriptions may be turned off, e.g. because of a carrier restriction from an inserted
     * physical SIM. Therefore, this runtime check should be used before accessing embedded
     * subscription APIs.
     *
     * @return true if embedded subscriptions are currently enabled.
     */
    public boolean isEnabled() {
        // In the future, this may reach out to IEuiccController (if non-null) to check any dynamic
        // restrictions.
        return getIEuiccController() != null && refreshCardIdIfUninitialized();

1. The isEnabled() method checks whether embedded subscriptions are currently enabled on the device.

   Even on devices with the PackageManager.FEATURE_TELEPHONY_EUICC feature, embedded subscriptions may be turned off due to carrier restrictions or other reasons.
   Therefore, this runtime check should be used before accessing embedded subscription APIs.

   The isEnabled() method first checks whether the IEuiccController interface is available by calling the getIEuiccController() method. If the interface is not available, the method will return false.

   If the IEuiccController interface is available, the method will call the refreshCardIdIfUninitialized() method to initialize the eUICC card ID if it is not already initialized. This method is called to ensure that the eUICC card ID is valid before proceeding with any operations that require it. If the eUICC card ID is not initialized, the method will return false.

   If the IEuiccController interface is available and the eUICC card ID is initialized, the method will return true, indicating that embedded subscriptions are currently enabled on the device.

2. Used in getOtaStatus() in this way getIEuiccController().getOtaStatus(mCardId);

   The getOtaStatus() method returns the current status of the eUICC (embedded Universal Integrated Circuit Card) OTA (over-the-air) update process, which is used to update the eUICC software and data.

   The method requires the WRITE_EMBEDDED_SUBSCRIPTIONS permission to be granted to the calling app.

   If the eUICC is not ready, the method returns EUICC_OTA_STATUS_UNAVAILABLE. If the eUICC is ready, the method calls the getIEuiccController().getOtaStatus() method to retrieve the OTA status from the IEuiccController interface.

   If an exception occurs during the method call, it will be caught and rethrown as a RemoteException to the calling app.

3. And it is used in many methods because EuiccController is because it provides an interface for managing eUICCs (embedded Universal Integrated Circuit Cards). It is responsible for handling various eUICC-related tasks such as activating, deactivating, and managing the installation and removal of eUICC profiles.

   The EuiccController service runs in the system process and exposes an interface through which other system components and apps can interact with eUICCs. The service is responsible for communicating with the eUICC hardware and coordinating the installation and removal of eUICC profiles with the relevant carrier servers.

   The EuiccController interface includes methods for various eUICC operations, such as retrieving information about the eUICC hardware, managing profiles and their related operations, and triggering eUICC OTA (over-the-air) updates.

   The EuiccController service is not directly accessible to third-party apps. Instead, it is accessed through the EuiccManager class, which is a high-level API provided by the Android system for managing eUICCs.

So I’ll stop here because if i continue this article will become technical documentation on Euicc Manager,Service and Controller.
In the next article i’ll be simplifying the explanation of implementation of eSIM, building a LPA and a carrier app.

So That’ll be all for now.
This is me on twitter and linkedIn, I’m more than happy to discuss any aspect of this solution. And any comments, advice and feedbacks are much appreciated.