Siltti app - milestone 2

Siltti app (Kampela companion)

The prototype mobile app Siltti was developed to minimal prototype stage. The app was tested on Google Pixel 5 phone with GrapheneOS. It was also tested and found to be not usable on Samsung Galaxy A52, as it does not let 3rd party apps to use NFC interface - solving compatibility issues due to Samsung Pay ecosystem is out of scope for this project.

The conceptual idea of Siltti is to scan QR codes from Parity Signer’s ecosystem and to convert them into Kampela-compatible payloads. We do not intend to develop Siltti further into a full-blown app, as it is just an intermediate layer between proper ecosystem and Kampela; ideally, the functionality demonstrated in this app should be implemented in proper full-feature wallets for seamless integration. Alternatively, a separate app for NFC reader Kampela’s companion should be made a full-feature client or become pluggable into common frameworks like Polkadot.js. Either way, further development of Siltti or similar app beyond necessary functions needed for Kampela prototyping and demonstration is out of scope for this project.

At this milestone release, Siltti can scan most of Parity Signer’s payloads (the QR handling is inherited from Parity Signer’s codebase with improved multiframe handling re-implemented in Rust) and transform them into NFC packages in form of erasure codes, with the same protocol (RaptorQ) as one used for Parity Signer’s metadata. Every payload is signed with unique device-specific secret asymmetric key (stored in hardware strongbox, if available), as discussed in security architecture design targets.

When new metadata or network specifications are scanned, they are saved into Siltti’s database for convenience and re-transmitted into Kampela, where appropriate. There are no verifier safeguards implemented in Siltti, as Kampela should take care of those - although verifier certificate key and signature are passed into NFC payloads. Siltti just re-writes its network information with the last scanned version.

We do not expect Kampela to store metadata, as this would require significant storage size when many networks are used in the same device, and also would result in complicated management scheme similar to one used in Parity Signer, which is, of course, not feasible with our UI limitations. Instead, Kampela is expected to store only public certificate keys. When transaction is converted into NFC fountain payload, metadata and it’s signature data are attached to it. In this manner, we increase payload size significantly, but that should not be noticeable to user, as they have to charge Kampela for longer time that is expected to be needed to transfer this payload.

Another source of NFC payload generation is derivation creation. According to security design targets, addresses should be already known to Kampela before they could be used for signing; to create an address, user would need to switch to “add address” screen and type a derivation. Only the most basic interface is available in Siltti and the protocol for derivation would be refined as the project moves forward. Currently, user needs to type full derivation path and select networks where the key would be available. After that, by pressing “Send” NFC payload is generated.

Thus, the app contains only 3 screens: scanning screen, key derivation screen and transmission screen. User could navigate between these screens by scanning QR codes and pressing navigation buttons on the bottom.

The transmission screen only represents the state where Siltti can transmit the last payload it generated. Transmission starts upon detection of NFC tag and stops upon loss of connection; it could be restarted anytime by bringing NFC tag within the range.

Testing guide

Requirements:

Compatible Android phone (Pixel 5 recommended tested model)

Any NfcA NDEF compatible tag (optional)

Browser that supports Substrate infrastructure

To test the app, first observe its initial state. Upon loading, a camera (user should grant permission) is shown. Upon clicking on “Create address” a derivation field is shown; note that no built-in networks are proposed below. Siltti does not know any yet.

Open the metadata portal. Select a network on the left (Westend, for example), then select “Chain Specs” on top. Scan the static QR code with Siltti. Optionally bring the NFC tag into close proximity of the phone to imitate transmission - phone would indicate successful scanning but would not react in any other way. While NFC tag is detected by the phone, transmission proceeds continuously. Move NFC tag away, then click the button to stop transmission. Click “Create address” button. Note that a new network is available now, but no metadata version is shown.

Select “Metadata” tab on top. Proceed to scan QR movie with Siltti. Once done, admire that it is shown in “Create address” screen. Proceed in similar manner to add more networks. Metadata updates for Siltti are performed in same way.

Once satisfied, try to scan a transaction. If metadata and network specs are available, transmission mode would be engaged immediately (and error would be indicated otherwise).

Create and transmit an address by clicking “add address” button, typing derivation and tapping networks from the list.

Unfortunately there is no way to test the app further yet as Kampela itself still does not exist. Stay tuned for the next milestones results!

Known issues

Siltti is not expected to work with phones using Samsung Pay system.

Siltti is single-threaded for NFC transmission purposes and composition freezes when NFC tag is in reading range, as all processing power is occupied with transmission (and elevated battery consumption and phone heating are expected as well if this continues for extended periods of time - DO NOT leave the smartphone unattended near a tag in transmission mode!). While in transmission mode, the app would also ignore user interaction while tag is communication range and would crash if transmission is interrupted at this time.

Siltti does not support iOS even though the whole system is built with iOS support in mind for future development.