2FA proposal for DeWeb Massa

Massa Improvement Proposals
1

2FA design specification for Massa blockchain

  1. Existing transaction signing system in MassaStation
    _
    PrivateKey and PublicKey are stored in an encrypted file that the user decrypts with a WalletPass password
    WalletAddress is the public address
    The user must have imported the file and use WalletPass to decrypt the PrivateKey and sign operations using it

  2. New 2FA method using Station2FA module
    _
    Station2FA is a new module that interfaces with the Wallet module
    When linking, the user must enter WalletPass to decrypt the file and the Station2FA module will only read from it:
    1/5 of the length of the PrivateKey
    WalletAddress
    This process ensures that the complete PrivateKey remains safe inside the MassaStation

Design of the encryption mechanism for 1/5 of the PrivateKey

  • Creating an asymmetric key for encryption on the Station2FA side
    When the Station2FA module is first connected to the Wallet module, an asymmetric key pair is generated directly within the Station2FA module:
    PubKey2FA will be used to encrypt 1/5 PrivateKey when sending to the DeWeb2FA dApp
    PrivKey2FA will remain securely stored within the Station2FA module and will never leave the MassaStation
    This key pair will be generated automatically and the user will not need to set any new password, and it will not be exportable from the Station2FA module
  • Encryption and sending 1/5 PrivateKey
    After decrypting the file in the Station2FA module using WalletPass, the 1/5 PrivateKey will be encrypted using PubKey2FA (generated when the modules are linked)
    The encrypted 1/5 PrivateKey will then be sent to the DeWeb2FA dApp along with the WalletAddress
    This asymmetric encryption process ensures that only the Station2FA module will have access to decrypt the 1/5 PrivateKey during subsequent transaction authentication

  1. Registration in the DeWeb2FA dApp
    _
    The Station2FA module sends the following in encrypted format:
    WalletAddress
    1/5 PrivateKey
    The data is stored in the DeWeb2FA dApp, which runs on the Massa (DeWeb) blockchain
    The user in MassaStation receives a one-time registration password from Station2FA, which they must enter in the DeWeb2FA dApp. This password has an expiration date
    During registration, the user selects the delivery method for the one-time 2FA codes:
    Email
    Push notifications via a special app tied to the device hardware (iOS, Android, PC)

  2. Performing a 2FA operation
    _
    Whenever the user performs an operation in MassaStation, he/she normally enters WalletPass to decrypt the file
    Subsequently, Station2FA contacts the DeWeb2FA dApp with:
    WalletAddress
    1/5 PrivateKey
    Operation number
    The DeWeb2FA dApp generates a one-time authentication code directly for the transaction and sends it by the chosen method (email, push notification)
    The user must enter this code in the Station2FA module in MassaStation to confirm the operation or confirm the notification
    Again, the verification code and notifications have an expiry time

  3. Security guarantees
    _
    PrivateKey leaves MassaStation only partially (1/5 of its length), which significantly increases security
    Another security chain could be created instead of PrivateKey to increase security
    User cannot perform an operation without entering both WalletPass and one-time code or confirmation notification

  4. Deactivation of 2FA
    _
    Deactivation of 2FA takes place exclusively within MassaStation via the Station2FA module
    The user sends a request to deactivate 2FA, which must be signed with WalletPass
    Once the request is submitted, the user will immediately receive a 2FA deactivation notification on the MassaStation, in the app or even by email with a warning about 2FA deactivation
    Deactivation of 2FA will be delayed for 48 hours, during which the user can:
    Cancel the deactivation if he/she suspects abuse using his/her WalletPass
    Move their funds to another secure WalletAddress and authorize this transaction using WalletPass and a one-time code from DeWeb2FA

  5. Advantages of the proposed 2FA system
    _
    Increased security: the PrivateKey never leaves the MassaStation in its full form > Only 1/5 is sent in encrypted form, or another unique string is created tied to each WalletAdress within the blockchain
    Flexibility in authentication: the user can choose between several ways of delivering 2FA codes (email, push notifications) I think it would be realistic to use end-to-end encryption of messages and data and use a Telegram bot to deliver authentication codes, provided that a very short expiration time of the codes is used
    Protection against unauthorized deactivation: deactivation of 2FA is not immediate and gives the user enough time to react in case of suspected attack or misuse of the password and PrivateKey file

Another option instead of a dedicated application would be a web application hosted on DeWeb that would use unique identifiers tied to the hardware when registering DeWeb2FA, such as

TPM (Trusted Platform Module)
Secure Enclave or TrustZone

This solution could use only the web application and device hardware keys to display one-time confirmation codes

Is such a solution suitable for the Massa blockchain? Or is it not compatible with your security policy and plans?