Fix #705: Remove functions related to recovery codes

wultra · Feb 10, 2025 · 6170f31 · 6170f31
1 parent d757730
commit 6170f31
Show file tree

Hide file tree

Showing 17 changed files with 6 additions and 1,016 deletions.
diff --git a/docs/Activation-via-Activation-Code.md b/docs/Activation-via-Activation-Code.md
@@ -139,7 +139,6 @@ Note that the activation commit step can be skipped in case activation is commit
 ## Related Topics
 
 - [Activation Code Format](Activation-Code.md)
-- [Activation via Recovery Code](./Activation-via-Recovery-Code.md)
 - [Activation via Custom Credentials](./Activation-via-Custom-Credentials.md)
 - [Checking Activation Status](./Activation-Status.md)
 - [Key Derivation](./Key-derivation.md)

diff --git a/docs/Activation-via-Custom-Credentials.md b/docs/Activation-via-Custom-Credentials.md
@@ -69,7 +69,6 @@ However, if the particular use case requires different handling, the enrollment
 ## Related Topics
 
 - [Activation via Activation Code](./Activation-via-Activation-Code.md)
-- [Activation via Recovery Code](./Activation-via-Recovery-Code.md)
 - [Checking Activation Status](./Activation-Status.md)
 - [Key Derivation](./Key-derivation.md)
 - [Advanced Activation Flows](./Advanced-Activation-Flows.md)
diff --git a/docs/Activation-via-Recovery-Code.md b/docs/Activation-via-Recovery-Code.md
diff --git a/docs/Activation.md b/docs/Activation.md
@@ -27,12 +27,9 @@ The activation credentials may be arbitrary and selected by a customer. We call
 
 More commonly, the activation credentials are managed by our systems. The typical activation type uses an **activation code**. An activation code is a temporary, single use token that is strongly connected to specific user and to pre-initialized activation record. Activation code is issued for a given user via an application where the user already is authenticated, such as the Internet banking.
 
-Another type of credentials our systems manage are **recovery codes**. When enabled, our systems generate recovery codes during a successful activation. The mobile device then store them on the mobile device, protected by a secure vault mechanism (the secure vault requires the PIN code to unlock).
-
 You can read more about specific activation types in dedicated chapters:
 
 - [Activation via Activation Code](./Activation-via-Activation-Code.md)
-- [Activation via Recovery Code](./Activation-via-Recovery-Code.md)
 - [Activation via Custom Credentials](./Activation-via-Custom-Credentials.md)
 
 ## Application-Level Encryption
@@ -41,7 +38,7 @@ Since the activation process transfers extremely sensitive data payloads and use
 
 The end-to-end application-level encryption is actually performed twice on a single payload.
 
-The first layer of encryption protects the data transfer between the mobile app and intermediate Enrollment Server component (accessible from the Internet). After unwrapping the first encryption layer, the Enrollment Server gains access to the activation type and activation specific credentials. However, the Enrollment Server cannot unwrap the second encryption layer. Instead, the Enrollment Server passes the encrypted activation data to PowerAuth Server alongside either the user ID (for custom credentials), activation code (for activation via activation code) or recovery code (for activation via recovery code). The PowerAuth Server then decrypts the second encryption layer and it stores the activation data from the client. In response, it sends an encrypted server-side activation payload (again, the Enrollment Server cannot decrypt this payload). The Enrollment server finally re-encrypts the response and sends it to the mobile app.
+The first layer of encryption protects the data transfer between the mobile app and intermediate Enrollment Server component (accessible from the Internet). After unwrapping the first encryption layer, the Enrollment Server gains access to the activation type and activation specific credentials. However, the Enrollment Server cannot unwrap the second encryption layer. Instead, the Enrollment Server passes the encrypted activation data to PowerAuth Server alongside either the user ID (for custom credentials) and activation code (for activation via activation code). The PowerAuth Server then decrypts the second encryption layer and it stores the activation data from the client. In response, it sends an encrypted server-side activation payload (again, the Enrollment Server cannot decrypt this payload). The Enrollment server finally re-encrypts the response and sends it to the mobile app.
 
 Detailed documentation of [End-to-End Encryption](./End-To-End-Encryption.md) is available in a dedicated chapter.
 
@@ -78,7 +75,6 @@ The following diagram shows transitions between activation states:
 ## Related Topics
 
 - [Activation via Activation Code](./Activation-via-Activation-Code.md)
-- [Activation via Recovery Code](./Activation-via-Recovery-Code.md)
 - [Activation via Custom Credentials](./Activation-via-Custom-Credentials.md)
 - [Checking Activation Status](./Activation-Status.md)
 - [Key Derivation](./Key-derivation.md)

diff --git a/docs/Advanced-Activation-Flows.md b/docs/Advanced-Activation-Flows.md
@@ -21,7 +21,6 @@ We will describe each situation in detail in the separate chapters:
 3. [Activation confirmation using OTP](#activation-confirmation-using-otp)
    - [Confirm regular activation with OTP](#confirm-regular-activation-with-otp)
    - [Confirm custom activation with OTP](#confirm-custom-activation-with-otp)
-   - [Confirm activation recovery with OTP](#confirm-activation-recovery-with-otp)
 
 ## Changing the Commit Phase
 
@@ -90,7 +89,7 @@ There are multiple ways how to implement custom activation with an additional au
 
 ## Activation Confirmation using OTP
 
-In this common scenario, an additional activation OTP helps with the final activation confirmation, so the OTP is required in the later stages of the activation process (during the commit). In this case, it doesn't matter how the activation process was initiated. You can confirm regular, custom and also recovery activations with the OTP.
+In this common scenario, an additional activation OTP helps with the final activation confirmation, so the OTP is required in the later stages of the activation process (during the commit). In this case, it doesn't matter how the activation process was initiated. You can confirm regular and custom activations with the OTP.
 
 ### Confirm Regular Activation With OTP
 
@@ -152,32 +151,3 @@ There are multiple ways how to implement custom activation and confirm it with a
    1. Commits the activation by calling PowerAuth Server's [`commitActivation`](https://github.com/wultra/powerauth-server/blob/develop/docs/WebServices-Methods.md#method-commitactivation) method.
 
 After the response from the commit is received on the mobile side, the application can check whether the activation's state is ACTIVE.
-
-### Confirm Activation Recovery With OTP
-
-The confirmation of activation recovery is very similar to custom activation confirmation.
-
-1. In the mobile application:
-
-   1. The user enters recovery code and PUK.
-   1. Mobile application then initializes the recovery activation with provided code and PUK.
-
-1. Intermediate Server Application receives a recovery activation request:
-
-   1. The recovery code and PUK is verified by the PowerAuth Server, by calling [`recoveryCodeActivation`](https://github.com/wultra/powerauth-server/blob/develop/docs/WebServices-Methods.md#method-recoverycodeactivation).
-   1. Intermediate Server Application generates random activation OTP and update the activation record, by calling [`updateActivationOtp`](https://github.com/wultra/powerauth-server/blob/develop/docs/WebServices-Methods.md#method-updateactivationotp) method.
-   1. At the same time, Intermediate Server Application initiates the delivery of activation OTP.
-
-1. Back in the mobile application:
-
-   1. The mobile application receives the response from the server and completes the keys-exchange on the mobile side.
-   1. The user waits for OTP delivery via the out-of-band channel.
-   1. The user retypes OTP.
-   1. Mobile application then commits the activation with OTP, by calling a custom RESTful endpoint, protected with our [ECIES encryption](End-To-End-Encryption.md) scheme.
-
-1. Intermediate Server Application then receives the commit request:
-
-   1. Decrypts OTP from the request.
-   1. Commits the activation by calling PowerAuth Server's [`commitActivation`](https://github.com/wultra/powerauth-server/blob/develop/docs/WebServices-Methods.md#method-commitactivation) method.
-
-After the response from the commit is received on the mobile side, the application can check whether the activation's state is ACTIVE.
diff --git a/docs/End-To-End-Encryption.md b/docs/End-To-End-Encryption.md
@@ -257,7 +257,6 @@ PowerAuth protocol defines following `SHARED_INFO_1` (also called as `sh1` or `s
 | `/pa/v3/upgrade`                      | activation   | `/pa/upgrade`             |
 | `/pa/v3/vault/unlock`                 | activation   | `/pa/vault/unlock`        |
 | `/pa/v3/token/create`                 | activation   | `/pa/token/create`        |
-| `/pa/v3/recovery/confirm`             | activation   | `/pa/recovery/confirm`    |
 
 On top of that, following constants can be used for application-specific purposes:
 

diff --git a/docs/List-of-Used-Algorithms.md b/docs/List-of-Used-Algorithms.md
@@ -11,7 +11,6 @@ The following algorithms are used in the PowerAuth cryptography scheme.
 | Algorithm     | Impacts        | Note                                                                                                                                                                                                                                                      |
 |---------------|----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `AES-128`     | mobile, server | Symmetric encryption with 128 bit keys. Used in `AES/CBC/PKCS7Padding` or `AES/CBC/NoPadding`, depending on use-case.                                                                                                                                     |
-| `Argon2`      | server         | Iterative hash used for storing recovery PUK values associated with recovery codes (`argon2i`).                                                                                                                                                           |
 | `CRC-16`      | mobile, server | Checksum algorithm, used to add a validation to the activation code (2 bytes out of 12 are allocated for checksum).                                                                                                                                       |
 | `ECDH`        | mobile, server | Key agreement algorithm for ECC-based Diffie-Hellman, uses `secp256r1` curve.                                                                                                                                                                             |
 | `ECDSA`       | mobile, server | Asymmetric signatures based on ECC, with `secp256r1` curve and `SHA256` hash function (`SHA256withECDSA`).                                                                                                                                                |

diff --git a/docs/Recovery-Postcard.md b/docs/Recovery-Postcard.md