icing/monorepo
4
0
Fork 0
Code Pull Requests 3 Actions Packages Releases 1 Activity

doc #67

Open
stcb wants to merge 5 commits from doc into dev
pull from: doc
merge into: icing:dev
Conversation 0 Commits 5 Files Changed 12 +234 -384
12 changed files with 234 additions and 384 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
README.md
View File

@ -1,21 +1,72 @@
# Icing
---
gitea: none
include_toc: true
---
## Encrypting phone calls on an analog audio level
# Icing – end-to-end-encrypted phone calls without data
Experimental α-stage • Apache-2.0 • Built at Epitech
 
> **Icing** runs a Noise-XK handshake, Codec2 and 4-FSK modulation over the plain voice channel, so any GSM/VoLTE call can be upgraded to private, authenticated audio - **no servers and no IP stack required.**
An Epitech Innovation Project
*By*
**Bartosz Michalak - Alexis Danlos - Florian Griffon - Ange Duhayon - Stéphane Corbière**
---
The **docs** folder contains documentation about:
#### Epitech
- The Beta Test Plan
- The Delivrables
#### Icing
- The project
- A user manual
- Our automations
## 📖 Detailed design
See [`docs/Icing.md`](docs/Icing.md) for protocol goals, threat model, and technical architecture.
## 🔨 Quick start (developer preview, un-protocoled dialer)
```bash
# on an Android phone (Android 12+)
git clone https://git.gmoker.com/icing/monorepo
cd dialer
# Requires Flutter and ADB or a virtual device
flutter run
```
> ⚠️ This is an **alpha prototype**: expect crashes, missing UX, and incomplete FEC.
You can join us in Telegram or Reddit !
https://t.me/icingdialer
https://www.reddit.com/r/IcingDialer/
## ✨ Features (α1 snapshot)
- [DryBox Only] Noise *XK* handshake (X25519, AES-GCM, SHA-256)
- Static keys = Ed25519 (QR share)
- [DryBox Only] Voice path: Codec2 → encrypted bit-stream → 4-FSK → analog channel
- GSM simulation in DryBox for off-device testing
## 🗺️ Project status
| Stage (roadmap) | Dialer app | Protocol | DryBox | Docs |
| --------------------- | -------------------------- | ------------------ | ----------------- | ----------------- |
| **Alpha 1 (Q3-2025)** | 🚧 UI stub, call hook | Key gestion | ⚠️ Qt demo, Alpha 1 Working | 📝 Draft complete |
| Alpha 2 (Q4-2025) | 🛠️ Magisk flow | 🔄 Adaptive FEC | 🔄 Stress tests | 🔄 Expanded |
| **Beta 1 (Feb 2026)** | 🎉 Public release | 🔐 Audit pass | ✅ CI | ✅ |
## 🤝 How to help
- **Crypto researchers** – Poke holes in the protocol draft.
- **Android security hackers** - Review our Kotlin integrations.
- **ROM maintainers** - Let's talk about an integration !
Open an issue or report here [![Give Feedback](https://img.shields.io/badge/Feedback-Form-blue)](https://cryptpad.fr/form/#/2/form/view/Tgm5vQ7aRgR6TKxy8LMJcJ-nu9CVC32IbqYOyOG4iUs/)
## License
Apache License 2.0 - see [`LICENSE`](LICENSE).
---
Made with ☕ by four Epitech students.

39
docs/Icing.md
View File

@ -3,7 +3,7 @@
An Epitech Innovation Project
*By*
**Bartosz Michalak - Alexis Danlos - Florian Griffon - Ange Duhayon - Stéphane Corbière**
**Bartosz Michalak - Alexis Danlos - Florian Griffon - Stéphane Corbière**
---
@ -17,13 +17,25 @@ An Epitech Innovation Project
## Introduction to Icing
Icing is the name of our project, which is divided in **two interconnected goals**:
1. Provide an end-to-end (E2E) encryption **code library**, based on Eliptic Curve Cryptography (ECC), to encrypt phone-calls on an **analog audio** level.
2. Provide a reference implementation in the form of a totally seamless Android **smartphone dialer** application, that anybody could use without being aware of its encryption feature.
Icing is the name of our project, which is divided in **three interconnected goals**:
1. Build a mutual-authentication and end-to-end encryption protocol, NAAP, for half and full-duplex audio communication, network agnostic. Network Agnostic Authentication Protocol.
2. Provide a reference implementation in the form of an **Android Package**, that anybody can use to implement the protocol into their application.
3. Provide a reference implementation in the form of an **Android Dialer**, that uses the android package, and that could seamlessly replace any Android user's default dialer.
This idea came naturally to our minds, when we remarked the lack of such tool.
Where "private messaging" and other "encrypted communication" apps flourish, nowadays, they **all** require an internet access to work.
### Setting a new security standard
#### ***"There is no way to create a backdoor that only the good guys can walk through"***
> (*Meredith Whittaker - President of Signal Fundation - July 2023, Channel 4*)
Enabling strong authentication on the phone network, either cellular or cable, would change the way we use our phone.
Reduced phone-related scams, simplified and safer banking or government services interactions, reduced dependency to the internet, and more, are the benefits both consumers and organizations would enjoy.
Encrypting the data end-to-end increases security globally by a considerable factor, particularly in low-bandwidth / no internet areas, and the added privacy would benefit everyone.
---
### Privacy and security in telecoms should not depend on internet availability.
@ -35,21 +47,6 @@ So in a real-world, stressful and harsh condition, affording privacy or security
Our solution is for the every-man that is not even aware of its smart phone weakness, as well as for the activists or journalists surviving in hostile environment around the globe.
### Setting a new security standard
#### ***"There is no way to create a backdoor that only the good guys can walk through"***
> (*Meredith Whittaker - President of Signal Fundation - July 2023, Channel 4*)
If the police can listen to your calls with a mandate, hackers can, without mandate.
Many online platforms, such as online bank accounts, uses phone calls, or voicemails to drop security codes needed for authentication. The idea is to bring extra security, by requiring a second factor to authenticate the user, but most voicemails security features have been obsolete for a long time now.
**But this could change with globalized end-to-end encryption.**
This not only enables obfuscation of the transmitted audio data, but also hard peer authentication.
This means that if you are in an important call, where you could communicate sensitive information such as passwords, or financial orders, using Icing protocol you and your peer would know that there is no man in the middle, listening and stealing information, and that your correspondent really is who it says.
---
### Icing's strategy

193
docs/UserManual.md
View File

@ -1,71 +1,182 @@
# User Manual for Icing Dialer
# User Manual
## Introduction
The Icing Dialer is an open-source mobile application designed to enable end-to-end encrypted voice calls over GSM/LTE networks, ensuring privacy without reliance on the internet, servers, or third-party infrastructure. This manual provides comprehensive guidance for three audiences: average users, security experts, and developers. A final section outlines our manual testing policy to ensure the application's reliability and security.
**Utilization documentation.**
Written with chapters for the average Joe user, security experts, and developers.
The average-user section is only about what the average-user will know from Icing: its dialer reference implementation.
The security expert section will cover all the theory behind our reference implementation, and the Icing protocol. This section can serve as an introduction / transition for the next section:
The developer section will explain our code architecture and concepts, going in-depth inside the reference implementation and the Icing protocol library.
This library will have dedicated documentation in this section, so any developer can implement it in any desired way.
Lastly, as a continuation of the developer section, the Manual Test section will cover our manual testing policy.
- **Average User**: Instructions for using the Icing Dialer as a transparent replacement for the default phone dialer.
- **Security Expert**: Technical details of the Icing protocol, including cryptographic mechanisms and implementation.
- **Developer**: In-depth explanation of the code architecture, Icing protocol library, and integration guidelines.
- **Manual Tests**: Overview of the manual testing policy for validating the application and protocol.
---
## Summary
- [Average User](#averageuser)
- [Security Expert](#icingsstrategy)
- [Average User](#average-user)
- [Security Expert](#security-expert)
- [Developer](#developer)
- [Manual Tests](#manualtests)
- [Manual Tests](#manual-tests)
---
## Average User
Use the Icing dialer like your normal dialer, if you can't do that we can't help, you dumb retard lmfao.
The Icing Dialer is a privacy-focused mobile application that replaces your default phone dialer, providing secure, end-to-end encrypted voice calls over GSM/LTE networks. It is designed to be intuitive and indistinguishable from a standard dialer, ensuring seamless use for all users.
### Key Features
- **Seamless Dialer Replacement**: Functions as a full replacement for your phone’s default dialer, supporting standard call features and encrypted calls.
- **Cryptographic Key Pair Generation**: Automatically generates an ED25519 key pair during setup for secure communications, stored securely using the Android Keystore.
- **Secure Contact Sharing**: Adds and shares contacts via QR codes or VCF files, ensuring privacy.
- **Automatic Call Encryption**: Encrypts calls with compatible Icing Dialer users using the Noise protocol, encoded into the analog audio signal via Codec2 and 4FSK modulation.
- **On-the-Fly Pairing**: Detects other Icing Dialer users and offers encrypted pairing during calls (optional, under development).
- **Call Management**: Includes call history, contact management, visual voicemail, and features like mute, speaker, and SIM selection.
- **Privacy Protection**: Safeguards sensitive communications with secure voice authentication and encrypted voicemail.
### Getting Started
1. **Installation**: Install the Icing Dialer from a trusted source (e.g., a partnered AOSP fork or Magisk module for rooted Android devices).
2. **Setup**: Upon first launch, the app generates an ED25519 key pair using the Android Keystore. Follow prompts to complete setup.
3. **Adding Contacts**: Use the QR code or VCF import feature to securely add contacts. Scan a contact’s QR code or import a VCF file to establish a secure connection.
4. **Making Calls**: Dial numbers using the full dialer interface (numbers, *, #). The app uses the Android Telephony API to detect compatible users and automatically encrypts calls when possible.
5. **Encrypted Calls**: Calls to known contacts with public keys are automatically encrypted. A data rate and error indicator provide real-time feedback. Use the disable encryption button if needed.
6. **Call History and Contacts**: Access call history with filters for missed, incoming, and outgoing calls. Tap a call to view details or open a contact modal. Manage contacts with search, favorites, and blocklist features.
7. **Visual Voicemail**: Play, pause, or manage voicemails with quick links to call, text, block, or share numbers.
8. **Settings**: Configure default SIM, manage public keys, and access the blocklist via the settings menu.
### Troubleshooting
- **FAQs**: Available on our Reddit and Telegram channels for common issues and setup guidance.
- **Feedback**: Submit feedback via our anonymous CryptPad form for prompt issue resolution.
### Example Scenarios
- **Secure Voicemail Access**: Mathilda, 34, uses Icing to securely retrieve a PayPal authentication code from her voicemail, protected by her registered Icing public key.
- **Authenticated Calls**: Jeff, 70, authenticates with his bank using encrypted DTMF transmission, ensuring secure and verified communication.
- **Private Communication**: Elise, 42, a journalist, uses Icing to make discreet, encrypted calls despite unreliable or monitored networks.
- **Emergency Calls Abroad**: Paul, 22, a developer, uses Icing to securely assist colleagues with a critical issue while abroad, relying only on voice calls.
---
## Security Expert
SecUriTy eXpeRt
The Icing Dialer is the reference implementation of the Icing protocol, an open, decentralized encryption protocol for telephony. This section details the cryptographic and technical foundations, focusing on security principles.
### Icing Protocol Overview
The Icing protocol enables end-to-end encrypted voice calls over GSM/LTE networks by encoding cryptographic data into the analog audio signal. Key components include:
- **End-to-End Encryption**: Utilizes the Noise protocol with XX (mutual authentication) and XK (known-key) handshake patterns for secure session establishment, using ED25519 key pairs.
- **Perfect Forward Secrecy**: Ensures session keys are ephemeral and discarded after use, with future sessions salted using pseudo-random values derived from past calls.
- **Codec2 and 4FSK**: Voice data is compressed using Codec2 and modulated with 4FSK (Four Frequency Shift Keying) for transmission over GSM/LTE.
- **Secure Contact Pairing**: Uses QR codes or VCF files for secure key exchange, preventing man-in-the-middle attacks.
- **Encrypted DTMF**: Supports secure transmission of DTMF signals for authentication scenarios.
- **Forward Error Correction (FEC)**: Detects up to 50% of transmission errors in Alpha 1, with plans for stronger FEC (>80% detection, 20% correction) in future iterations.
- **Decentralized Design**: Operates without servers or third-party intermediaries, minimizing attack surfaces.
- **Voice Authentication**: Implements cryptographic voice authentication to verify caller identity.
### Security Implementation
- **Cryptographic Framework**: Uses ED25519 key pairs for authentication and encryption, generated and stored securely via the Android Keystore. The Noise protocol ensures secure key exchange and session setup. AES-256 and ECC (P-256, ECDH) are employed for data encryption.
- **Analog Signal Encoding**: Codec2 compresses voice data, and 4FSK modulates encrypted data into the analog audio signal, ensuring compatibility with GSM/LTE networks.
- **Threat Model**: Protects against eavesdropping, interception, replay attacks, and unauthorized access. Includes replay protection mechanisms and assumes adversaries may control network infrastructure but not device endpoints.
- **Data Privacy**: Minimizes data storage (only encrypted keys and minimal metadata), with no unencrypted call metadata stored. Sensitive data is encrypted at rest.
- **Current Status**: Protocol Alpha 1, tested in DryBox, validates peer ping, ephemeral key management, handshakes, real-time encryption, stream compression, and 4FSK transmission. Alpha 2 will enhance FEC and on-the-fly key exchange.
### Future Considerations
- Develop a full RFC for the Icing protocol, documenting peer ping, handshakes, and FEC.
- Optimize Codec2 and 4FSK for improved audio quality and transmission reliability.
- Implement embedded silent data transmission (e.g., DTMF) and on-the-fly key exchange.
- Enhance interoperability with existing standards (e.g., SIP, WebRTC).
---
## Developer
int main;
The Icing Dialer and its protocol are open-source and extensible. This section explains the code architecture, Icing protocol library, and guidelines for integration into custom applications.
---
### Code Architecture
The Icing Dialer is developed in two implementations:
- **Root-app**: For rooted Android devices, deployed via a Magisk module (~85% complete for Alpha 1).
- **AOSP-app**: Integrated into a custom AOSP fork for native support, pending partnerships with AOSP-based projects (e.g., GrapheneOS, LineageOS).
The application is written in Kotlin, leveraging the Android Telephony API for call management and a modular architecture:
- **UI Layer**: A responsive, intuitive interface resembling a default phone dialer, with accessibility features, contact management, and call history.
- **Encryption Layer**: Manages ED25519 key pair generation (via Android Keystore or RAM for export), Noise protocol handshakes (XX and XK), Codec2 compression, and 4FSK modulation.
- **Network Layer**: Interfaces with GSM/LTE networks via the Android Telephony API to encode encrypted data into analog audio signals.
### Icing Protocol Library
The Kotlin-based Icing protocol library (~75% complete for Alpha 1) enables third-party applications to implement the Icing protocol. Key components include:
- **KeyPairGenerator**: Generates and manages ED25519 key pairs, supporting secure (Android Keystore) and insecure (RAM) generation, with export/import capabilities.
- **NoiseProtocolHandler**: Implements XX and XK handshakes for secure session establishment, ensuring Perfect Forward Secrecy.
- **QRCodeHandler**: Manages secure contact sharing via QR codes or VCF files.
- **AudioEncoder**: Compresses voice with Codec2 and modulates encrypted data with 4FSK.
- **CallManager**: Uses the Android Telephony API to detect peers, initiate calls, and handle DTMF transmission.
- **FECModule**: Implements basic FEC for detecting 50% of transmission errors, with plans for enhanced detection and correction.
#### Integration Guide
1. **Include the Library**: Add the Icing protocol library to your project (available upon Beta release).
2. **Initialize KeyPairGenerator**: Generate an ED25519 key pair using Android Keystore for secure storage or RAM for exportable keys.
3. **Implement NoiseProtocolHandler**: Configure XX or XK handshakes for authentication and session setup.
4. **Integrate QRCodeHandler**: Enable contact sharing via QR codes or VCF files.
5. **Use AudioEncoder**: Compress voice with Codec2 and modulate with 4FSK for GSM/LTE transmission.
6. **Leverage CallManager**: Manage calls and DTMF via the Android Telephony API.
7. **Test with DryBox**: Validate implementation using the Python-based DryBox environment for end-to-end call simulation.
### Development Status
- **Protocol Alpha 1**: Implemented in DryBox, supporting peer ping, ephemeral keys, handshakes, encryption, Codec2 compression, and 4FSK modulation.
- **Kotlin Library**: 75% complete, with tasks remaining for Alpha 1 completion.
- **Root-app**: 85% complete, with Magisk deployment in progress.
- **AOSP-app**: In development, pending AOSP fork partnerships.
Developers can join our Reddit or Telegram communities for updates and to contribute to the open-source project.
---
## Manual Tests
1. Call grandpa
2. Receive mum call
3. Order 150g of 95% pure Bolivian coke without encryption
4. Order again but with encryption
5. Compare results
The Icing project employs a rigorous manual testing policy to ensure the reliability, security, and usability of the Icing Dialer and its protocol. This section outlines our testing approach, incorporating beta testing scenarios and evaluation criteria.
### Testing Environment
- **DryBox**: A Python-based environment simulating end-to-end encrypted calls over a controlled network, used to validate Protocol Alpha 1 and future iterations.
- **Root-app Testing**: Conducted on rooted Android devices using Magisk modules.
- **AOSP-app Testing**: Planned for custom AOSP forks, pending partnerships.
### Manual Testing Policy
- **Usability Testing**: Beta testers evaluate the dialer’s intuitiveness as a drop-in replacement, testing call initiation, contact management, and voicemail. Initial tests confirm usability without prior instructions.
- **Encryption Validation**: Tests in DryBox verify end-to-end encryption using Noise protocol (XX/XK handshakes), ED25519 key pairs, Codec2, and 4FSK. Includes encrypted DTMF and FEC (50% error detection).
- **Contact Pairing**: Tests QR code and VCF-based contact sharing for security and functionality.
- **Call Scenarios**: Tests include clear calls (to non-Icing and Icing dialers), encrypted calls (to known and unknown contacts), and DTMF transmission.
- **Performance Testing**: Ensures minimal latency, low bandwidth usage, and high audio quality (clarity, minimal distortion) via Codec2/4FSK.
- **Privacy Testing**: Verifies encrypted storage of keys and minimal metadata, with no unencrypted call logs stored.
- **Integration Testing**: Validates Android Telephony API integration, permissions (microphone, camera, contacts), and background operation.
### Beta Testing Scenarios
- Clear call from Icing Dialer to another dialer (e.g., Google, Apple).
- Clear call between two Icing Dialers.
- Clear call to a known contact (with public key) without Icing Dialer.
- Encrypted call to a known contact with Icing Dialer.
- Encrypted call to an unknown contact with Icing Dialer (optional, under development).
- Create/edit/save contacts with/without public keys.
- Share/import contacts via QR code/VCF.
- Listen to voicemail and verify encryption.
- Record and verify encrypted call integrity.
- Change default SIM.
### Evaluation Criteria
- **Security**: Validates AES-256/ECC encryption, ED25519 key management, Perfect Forward Secrecy, replay protection, and end-to-end encryption integrity.
- **Performance**: Measures call setup latency, bandwidth efficiency, and audio quality (clarity, consistency).
- **Usability**: Ensures intuitive UI, seamless call handling, and robust error recovery.
- **Interoperability**: Tests compatibility with GSM/LTE networks and potential future integration with SIP/WebRTC.
- **Privacy**: Confirms encrypted data storage, minimal permissions, and no unencrypted metadata.
- **Maintainability**: Reviews code quality, modularity, and documentation for the protocol and library.
### Current Testing Status
- **Protocol Alpha 1**: Validated in DryBox for encryption, handshakes, Codec2/4FSK, and FEC.
- **Root-app**: 85% complete, undergoing usability, performance, and security testing.
- **Feedback Channels**: Anonymous feedback via CryptPad and FAQs on Reddit/Telegram inform testing.
### Future Testing Plans
- Test Protocol Alpha 2 for enhanced FEC and on-the-fly key exchange.
- Conduct AOSP-app testing with partnered forks.
- Incorporate NPS/CSAT metrics from AMAs to assess user satisfaction.
---
## Conclusion
The Icing Dialer and its protocol offer a pioneering approach to secure telephony, leveraging ED25519 key pairs, the Noise protocol, Codec2, 4FSK, and the Android Telephony API. This manual provides comprehensive guidance for users, security experts, and developers, supported by a robust testing policy. For further details or to contribute, visit our Reddit or Telegram communities.

243
docs/beta_test_plan.md
View File

@ -1,243 +0,0 @@
# 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 (at least one modulation type)
- First steps in FEC (Forward Error Correction): detecting half of transmission errors
And should include prototype or scratches functionalities, among which:
- Embedded silent data transmission (such as DTMF)
- On-the-fly key exchange (does not require prior key exchange, sacrifying some security)
- Stronger FEC: detecting >80%, correcting 20% of transmission errors
#### 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.
Here is the list of all the functionnalities our dialer will integrate:
- Call
- Ringtone on incoming call
- Incoming and ongoing call notification
- Complete dialer with all numbers, star *, pound #
- Mute button
- Speaker button
- Normal call
- DTMF transmission
- SIM choice on call
- Encrypted Call
- Encrypted call if pair public key is known
- Encrypted DTMF transmission
- Data rate indicator
- Data error indicator
- Disable encryption button
- Call history
- Call details (timedate, duration, ring number)
- Missed calls filter
- Outgoing calls filter
- Incoming calls filter
- Call back function
- Contact modal on history tap
- Block call number
- Contacts
- Sorted contact listing
- Contact creation / editing buttons
- Contact sharing via QR code / VCF
- Contact search bar (application wide)
- Favorite contacts
- Contact preview (picture, number, public key...)
- Visual voicemail
- Play / Pause
- Notification
- Quick link to call, text, block, share number...
- Miscellanous
- Settings menu
- Version number
- Storage of user public keys
- Blocklist gestion (list / add / del / search)
- Default SIM choice
- Asymetric Keys
- Secure storage
- Generation at startup if missing
- Full key management (list / add / del / search / share)
- Secure generation (Android Keystore generation)
- Insecure generation (RAM generation)
- Exportation on creation (implies insecure generation)
- Importation
- Trust shift (shift trust from contacts)
## 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, 42 years-old, is a journalist covering sensitive topics.
Her work draws attention from people who want to know what she's saying - and to whom.
Forced to stay discreet, with unreliable signal and a likely monitored phone line,
she uses Icing dialer to make secure calls without exposing herself.
Paul, a 22 years-old developer, is enjoying its vacations abroad.
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 his country.
With Icing dialer, he can call his collegues and help fix the problem, completely safe.
## Evaluation Criteria
### Protocol and lib
1. Security
- Encryption Strength: Ensure that the encryption algorithms used (AES-256, ECC)
are up-to-date and secure.
- Key Management: Evaluate the mechanism for generating, distributing, and
storing encryption keys (P-256 keys, ECDH).
- Forward Secrecy: Confirm that the protocol supports forward secrecy, meaning
that session keys are discarded after use to prevent future decryption of
past communication, and that future sessions are salted with a pseudo-random salt
resulting or derived from the past calls.
- End-to-End Encryption Integrity: Verify that no clear data is exposed
outside the encryption boundary (client-side only).
- Replay Protection: Ensure that the protocol includes strong mechanisms to prevent replay
attacks.
2. Performance
- Latency: Measure the round-trip time (RTT) for call setup and audio quality
during the call. The system should aim for the lowes latency possible.
- Bandwidth Efficiency: Evaluate the protocol’s ability to optimize bandwidth
usage while maintaining acceptable audio quality.
- Audio Quality: Assess the audio quality during calls, including clarity,
consistency, and minimal distortion.
3. Usability
- Ease of Integration: Evaluate how easy it is to integrate the library into an
Android application, including the availability of well-documented APIs and
clear examples.
- Seamless User Experience: Check for smooth call initiation, handling of
dropped calls, and reconnection strategies. The app should handle background
operation gracefully.
- UI/UX Design: Assess the user interface (UI) of the Android dialer for intuitiveness,
accessibility, and if it could be a drop-in replacement for the original dialer.
- Error Handling and Recovery: Evaluate how the system handles unexpected
errors (e.g., network issues, connection drops) and recovers from them.
4. Interoperability
- Support for Multiple Protocols: Verify if the protocol can
integrate with existing standards (e.g., SIP, WebRTC) for interoperability
with other services.
- Cross-device Compatibility: Ensure that calls encryption can be initiated and received
across different devices, operating systems, and network conditions.
- Backward Compatibility: Test whether the protocol is backward compatible.
5. Privacy
- Data Storage: Evaluate how the system stores any data (user details, identities).
Ensure that sensitive information is encrypted.
- Data Minimization: Ensure that only the minimum necessary data is used
for the protocol to function.
- No Call Metadata Storage: Ensure that no metadata (e.g., call logs, duration,
timestamps) is stored unless necessary, and, if stored, it should be
encrypted.
6. Maintainability
- Code Quality: Review the library for clarity, readability, and
maintainability of the code. It should be modular and well-documented.
- Documentation: Ensure that the protocol and library come with thorough
documentation, including how-to guides and troubleshooting resources.
- Active Development and Community: Check the active development of the
protocol and library (open-source contributions, GitHub repository activity).
### Dialer
1. User Interface
- Design and Layout: Ensure that the dialer interface is simple, intuitive, and
easy to navigate. Buttons should be appropriately sized, and layout should
prioritize accessibility.
- Dialer Search and History: Ensure there’s an efficient contact search,
history logging, and favorites integration.
- Visual Feedback: Verify that the app most usefull buttons provides visual feedback for actions,
such as dialling, calls available interactions for example.
2. Call Management
- Call Initiation: Test the ease of initiating a call from contact list, recent
call logs, contact search or direct number input.
- Incoming Call Handling: Verify the visual and audio prompts when receiving
calls, including notifications for missed calls.
- Call Hold/Transfer/Forward: Ensure the dialer supports call hold, transfer,
and forwarding features.
- Audio Controls: Check whether the app allows users to adjust speaker volume,
mute, and switch between earpiece/speakerphone.
3. Integration with System Features
- Permissions: Ensure the app requests and manages necessary permissions
(microphone, camera for scanning QR codes, contacts, call history, local storage).
- Integration with Contacts: Ensure that the app seamlessly integrates with the
Android contacts and syncs correctly with the address book.
- Notifications: Ensure that call notifications and ringtone works even when the app is in
the background or the phone is locked.
4. Resource Management
- Resource Efficiency: Ensure the app doesn’t excessively consume CPU or memory
while operating, during idle times or on call.
5. Security and Privacy
- App Encryption: Ensure that any stored and sensitive data is
encrypted, or protected.
- Secure Call Handling: Verify that calls are handled securely through the
encrypted voice protocol.
- Minimal Permissions: The app should ask for the least amount of permissions
necessary to function.
6. Reliability
- Crash Resistance: Test for the app’s stability, ensuring it doesn't crash or
freeze during use.

62
docs/non-functional_delivrables.md
View File

@ -1,62 +0,0 @@
# Project Deliverables
---
## Common
### Develop and retain a user community
We plan to create a user community where users can share their experiences with the project and provide feedback on some social platforms such as Telegram, Discord, or Matrix.
The goal is to promote our project in different open-source and security and privacy-focused communities to gather experienced users capable of interesting feedbacks.
As we do not focus on selling a product to anyone, but rather to develop an open-source protocol, user retention is not a priority, and it will be more of a KPI of the project's pertinence than a goal; this means we will focus on listening and taking into account good feedback rather than publishing funny posts on social media.
### Work on user experience
We will work on making the dialer user-friendly and easy to use.
We are confident in our current UX development path, and user feedback will be taken into account.
---
## Specifications
### Enhance credibility and grow project's reputation
- **Transparent Development:**
Maintain a public roadmap and changelog to document every update and decision during the project's lifecycle.
- **Security Audits:**
We will rely on our automatic tests and community experts to have organic and constant auditing.
- **Community Engagement:**
Actively involve our user community in discussions, bug reports, and feature requests. Regularly update the community on progress and upcoming changes.
- **Open Source Best Practices:**
Adhere to industry-standard coding practices, thorough documentation, and continuous integration/deployment pipelines to ensure high-quality, maintainable code.
- **Visibility in Key Forums:**
Present and share our work in open-source, cybersecurity, and privacy-focused conferences and events to enhance credibility and attract constructive feedback.
### optimize relationships with the target audience
### Establish strategic partnership
- **Academic Collaborations:**
Partner with academic institutions for research initiatives and validation of our protocol, leveraging their expertise for further improvements.
- **Industry Alliances:**
Seek partnerships with established players in the open-source software industry to benefit from their wide community coverage, such as AOSP / GrapheneOS / LineageOS.
- **Integration Opportunities:**
Explore collaborations with mobile operating systems (e.g., AOSP) and VoIP providers to integrate Icing into existing communication infrastructures.
- **Joint Innovation Projects:**
Engage in co-development efforts that align with our mission, ensuring that both parties contribute to and benefit from technological advancements.
- **Funding and Support:**
Identify and pursue grants, sponsorships, and research funding that align with the project's objectives, ensuring sustainable development.

BIN
gonogo-review/Beta_Test_Plan.pdf Normal file
View File

Binary file not shown.

BIN
gonogo-review/Roadmap_PGE-5.pdf Normal file
View File

Binary file not shown.

BIN
gonogo-review/Roadmap_PGE-5_fr.pdf Normal file
View File

Binary file not shown.

BIN
gonogo-review/demo_material.pdf Normal file
View File

Binary file not shown.

BIN
gonogo-review/kpi_report.pdf Normal file
View File

Binary file not shown.

BIN
gonogo-review/kpi_report_fr.pdf Normal file
View File

Binary file not shown.

4
website/tmpl/vars.tmpl
View File

@ -2,10 +2,6 @@
<a href="https://github.com/AlexisDanlos" target="_blank">Alexis DANLOS</a>
{{end}}
{{define "ange"}}
<a href="https://yw5n.com" target="_blank">Ange DUHAYON</a>
{{end}}
{{define "bartosz"}}
<a href="https://github.com/Bartoszkk" target="_blank">Bartosz MICHALAK</a>
{{end}}