130 lines
5.2 KiB
Markdown
130 lines
5.2 KiB
Markdown
# Beta Test Plan
|
|
|
|
## Core Functionalities
|
|
|
|
---
|
|
### Action Plan review:
|
|
|
|
In our previous Action Plan, we listed the following functionnal specifications:
|
|
- Phone call encryption between two known pairs, that exchanged keys in person. *Mandatory*
|
|
- Phone dialer that is discret and functional, and should not disturb a normal use (clear phone call). *Mandatory*
|
|
- Phone call encryption between two unknown pairs, with key exchange on the go. Optional.
|
|
- SMS encryption between two known pairs (in person key exchange). Optional.
|
|
|
|
We now retain only the two first functional specifications.
|
|
|
|
### Core Functionalities
|
|
|
|
Based on this review, here are all the core functionnalities we set:
|
|
|
|
#### Icing protocol
|
|
- Advanced protocol documentation, paving the way for a full RFC.
|
|
|
|
The protocol definition will include as completed:
|
|
- Peer ping
|
|
- Ephemeral key gestion
|
|
- Perfect Forward Secrecy
|
|
- Handshakes
|
|
- Real-time data-stream encryption (and decryption)
|
|
- Encrypted stream compression
|
|
- Transmission over audio stream
|
|
- Minimal error correction in audio-based transmission
|
|
- Error handling and user prevention
|
|
|
|
And should include prototype or scratches functionalities, among which:
|
|
- Embedded silent data transmission (silently transmit light data during an encrypted phone call)
|
|
- On-the-fly key exchange (does not require prior key exchange, sacrifying some security)
|
|
- Strong error correction
|
|
|
|
#### Kotlin Lib ?
|
|
|
|
#### The Icing dialer (based on Icing kotlin library, an Icing protocol implementation)
|
|
|
|
The Icing dialer should be a fully transparent and almost undistinguishable smartphone dialer.
|
|
Any Icing-unaware user should be able to use the dialer smoothly to make calls to anyone.
|
|
|
|
The dialer should propose a full set of functionnalities to handle its Icing protocol implementation.
|
|
|
|
- Call
|
|
- Encrypted if public key available
|
|
- Allows users to share their public keys
|
|
- Normal call if conditions unment
|
|
- Encrypted and clear DTMF transmission
|
|
- SIM choice on call
|
|
- Call history
|
|
|
|
- Contacts
|
|
- Contact creation / editing
|
|
- Contact sharing via QR code / VCF
|
|
- Contact search
|
|
- Favorite contacts
|
|
- Storage of user public keys
|
|
- Blocked number
|
|
- Contact preview (picture, number, public key...)
|
|
|
|
- Visual voicemail
|
|
- Play / Pause
|
|
- Notification
|
|
- Quick link to call, text, block, share number...
|
|
|
|
- SIM settings
|
|
- Default SIM choice
|
|
|
|
- Asymetric Keys
|
|
- Secure storage
|
|
- Generation at startup if missing
|
|
- Full key management
|
|
- Secure generation
|
|
- Exportation on creation (insecure generation)
|
|
- Importation
|
|
- Trust shift
|
|
|
|
|
|
## Beta Testing Scenarios
|
|
- Clear call from Icing dialer to another dialer (Google, Apple...)
|
|
- Clear call from Icing dialer to another Icing dialer
|
|
- Clear call from Icing dialer to an icing pubkey-known contact but without Icing dialer
|
|
- Encrypted call from Icing dialer to a known contact with Icing dialer
|
|
- Encrypted call from Icing dialer to an unknown contact with Icing dialer
|
|
- Create / Edit / Save contact with(out) public key
|
|
- Share contact as QR code / Vcard
|
|
- Import contact from QR code / Vcard
|
|
- Listen to voicemail
|
|
- Record encrypted call and check the encryption
|
|
- Change default SIM
|
|
|
|
## User Journeys
|
|
|
|
Mathilda, 34 years-old, connects to her PayPal account from a new device.
|
|
To authenticate herself, PayPal sends her a code on her voicemail.
|
|
Mathilda being aware of the risks of this technology, she has set up strong Icing authentication with her network provider by registering a pair of her Icing public keys.
|
|
When she calls her voicemail, Icing protocol is triggered and checks for her key authentication ;
|
|
it will fail if the caller does not pocesses the required Icing keys.
|
|
Mathilda is thus the only one granted access, and she can retreive her PayPal code securely.
|
|
|
|
Jeff, 70 years-old, calls his bank after he had a problem on his bank app.
|
|
The remote bank advisor asks him to authenticate, making him type his password on the phone dialer.
|
|
By using the Icing protocol, not only would Jeff and the bank be assured that the informations are transmitted safely,
|
|
but also that the call is coming from Jeff's phone and not an impersonator.
|
|
|
|
Elise is a 42 years-old extreme reporter.
|
|
After interviewing Ukrainian opposition's leader, the SBU (ex KGB) are looking for her accross the whole country.
|
|
She hides in western moutains near Romania, and she barely receive cellular network.
|
|
She suspects her phone line to be monitored, so the best she can do to call for extraction safely, is to use her Icing dialer.
|
|
|
|
Paul, a 22 years-old developer working for a big company, decides to go to China for vacations.
|
|
But everything goes wrong! The company's product he works on, is failling in the middle of the day and no one is
|
|
qualified to fix it. Paul doesn't have WiFi and his phone plan only covers voice calls in China.
|
|
With Icing dialer, he can call his collegues and help fix the
|
|
problem, safe from potential Chinese spies.
|
|
|
|
## Evaluation Criteria
|
|
- Can a private key be generated
|
|
- Can a normal call be made?
|
|
- Can an encrypted call be made?
|
|
- Can a contact be created / edited / imported / exported?
|
|
- Can a voicemail be listened to?
|
|
- Is the encryption fast enough, light enough to be usable (audible call)
|
|
- Is the encryption strong enough not to be deciphered by a modern (as of 2025)
|
|
supercomputer?
|