LokDon SDK Documentation

If you want to use this system it could be on Server-Client mode or stand alone. You can set up the SDK on
Linux OS (Centos 7) and Raspberry PI 3(Raspbian buster).



SDK Prerequisite

  • Java installation(JDK)
    • Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
    • Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
  • Java runtime (Oracle Java)
  • Python-3+
  • Python Django 1.11+
  • Py4J library and module for Python 3 and Java Bridge
  • Virtual Environment for Python 3
  • All the class in one package
    • AllCharater.java
    • AllCharacter.class
    • KnightCell.java
    • KnightCell.class
    • KnightSolver.java
    • KnightSolver.class
    • LatinCharsetProvider.java
    • LatinCharsetProvider.class
    • CipherControl.class
    • CipherControl.java

     

  • To use this as a standalone application you will need to download
    • AllCharater.java
    • AllCharacter.class
    • KnightCell.java
    • KnightCell.class
    • KnightSolver.java
    • KnightSolver.class
    • LatinCharsetProvider.java
    • LatinCharsetProvider.class
    • CipherControl.class
    • CipherControl.java

Android SMS module setup on Android studio

End to end SMS encrypted money transfer logic. All users registered on LOKDON would have

  • Phone number
  • Username
  • Email
  • ApiKey
  • Address
  • Picture amongst others

ZKP Triangle Flow 1

Form input data for initiating the SMS based money transfer includes recipient’s email, recipient’s phone number and amount sent.

  • Recipient email – fully encrypted
  • Recipient email – fully encrypted
  • Recipient phone number – fully encrypted
  • Sender email – fully encrypted
  • Amount – fully encrypted

String receiverEmail = CipherControl.getInstance().encryptGenericData(recv_email);
String userPhoneNumber = CipherControl.getInstance().encryptGenericData(number);
String userSendEmail = CipherControl.getInstance().encryptGenericData(send_email);
String sentAmount = CipherControl.getInstance().encryptGenericData(amount);

All data above would be sent as a POST request to this API url For creating a session and profile of transaction.

M3Pin is stripped out by a POST request of these parameters

  • Encrypted recipient email
  • Encrypted recipient phone number
  • With sender API Key

To this API url
1. A send (SND) a message or money to B in the message he includes B’s M3PIN.
“Knock knock am about to send you money for that shoe I seen on fb you put for 10USD. Are you the B”.
2. To reply (Rpy) B must first perform a ZKP by decrypting the M3PIN which is his, in the first place. Once he successfully decrypts this to M2PIN and compare the result to the local store of the M2PIN. If the two matches, then he can read the message and reply with A’ M3PIN.
“I am here, I am the B send it through as long it is 10USD if you are the A I had the discussion with”.

On a successful response, the session ID (from the created session API), sent amount, recipient’s email, recipient’s M3PIN are ‘xored’ with that session ID. All these are encrypted and sent as SMS string (data) to the receiver’s phone number with a keyword CDR for the first leg. All messages are encrypted and unreadable except on the LokDon$ application.

ZKP Triangle Flow 2

The receiver will decrypt the entire message after M3PIN of the receiver is extracted and decrypted to M2PIN. This is compared to the local M2PIN. Thereafter, the receiver will read messages list from the LokDOn$ application (after M2PIN of receiver is matched) the receiver finds the message sent from the sender clearly decrypted by now, recipient takes further step to click on the reply button.
3. To acknowledge (Ack) B’ reply to the initial sent message. A must complete a ZKP by decrypting the accompanying M3PIN which came with B’ reply. After undergoing the process, he can now read the message following acknowledgement, any message sent back by A will carry B’ M3PIN once again. In other words, sent messages must carry the receiver’s M3PIN. “Of course, I am the A and I am sending you the money as discussed”.

The sender’ first zero knowledge proof (ZKP) is completed. The logic behind the Ack click are as follows:

  • Sender M3PIN is extracted from the message body decrypted and compared with the recipient M2PIN for a character length match if it matches to determine a valid M2PIN string

    if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController.getValueFromPerference(Constants.KEY_MPIN).charAt(10)).equalsIgnoreCase(CipherControl.getInstance().decryptTransactionSecurityPin(applicationController.getValueFromPerference(Constants.KEY_MPIN))))
    {
    TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show();
    Return;
    }

  • A session is created by POST parameters comprising of recipient encrypted email, phone number and api key to the API url
  • Session message, M3PIN encrypt, amount and email are concatenated to a string and encrypted with our SMS encryption algorithm
    SmsEncryption.getInstance( ).getEncryptSms(messageText.toString( ), keyList.get(position));
    Once completed SMS is sent to the sender for acknowledgement.

ZKP Triangle Flow 3

4. To acknowledge (Ack), A’ acknowledgement to the previous message. B must complete a ZKP by decrypting the accompanying M3PIN which came with A’ Ack. This is B’ second time of undergoing the process. He has fully established himself in the triangle. He can thus read the message following A’ acknowledgement, any message sent back will carry A’ M3PIN once again.
“I accept the money as B as I know you are A already and we agreed on 10USD”.
This is handled by receiver after a successful ZKP: Receiver completes the first triangle and establishes a tenured message link. Further Response follows the application protocols.

  • Sender’s M3PIN is extracted from the message body decrypted and compared with the recipient’ M3PIN for a character length of 10 if it matches to determine a valid M2PIN string

    if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController.getValueFromPerference(Constants.KEY_MPIN).charAt(10)).equalsIgnoreCase(CipherControl.getInstance().decryptTransactionSecurityPin(applicationController.getValueFromPerference(Constants.KEY_MPIN))))
    {
    TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show();
    Return;
    }

  • The confirm payment API is accessed LEG A with parameters like sent amount, session message, sender phone number and receiver phone number all encrypted.
  • M3Pin is stripped out from the other message body all encrypted with the SMS encryption algorithm
    SmsEncryption.getInstance( ).getEncryptSms(messageText.toString( ), keyList.get(position));
  • SMS is sent with a confirm keyword to the recipient for the final leg of the SMS transaction.

/*
Leg 3. Every sender receives its own M3PIN which typically lies with the message string conditionally. To read the . message the sender must first decrypt M3PIN to M2PIN-> the is compared to the locally held M2PIN. If they match then the sender should be able to read the message otherwise the process terminates. An improvement was added with the xor of the whole encrypted string with the current session ID. The message is formatted this way ([Message] + [SliPass]^ [MessageKTpn]^[SilPassKTp]^[RCVM3PIN]) xor Session ID
*/

ZKP Triangle Flow 4

5. A must confirm the transaction in flow 3 by undergoing another ZKP.
“I am A sealing that I did this transfer for you as agreed”
This is second and the last ZKP by A.

  • Sender M3Pin is extracted from the message body decrypted and compared with the recipient M3Pin for a character length of 10 if it matches to determine a valid m3pin string

    if(!CipherControl.getInstance().decryptMpinFromSinglePosition(m3Pin+applicationController.getValueFromPerference(Constants.KEY_MPIN).charAt(10)).equalsIgnoreCase(CipherControl.getInstance().decryptTransactionSecurityPin(applicationController.getValueFromPerference(Constants.KEY_MPIN))))
    {
    TastyToast.makeText(context,”Mpin Not Match”,TastyToast.LENGTH_SHORT,TastyToast.ERROR).show();
    Return;
    }

  • The confirm payment API is accessed LEG B with parameters like sent amount, session message, sender phone number and receiver phone number all encrypted.
  • On success complete payment is made and all necessary debit and credit would be initiated on both accounts i.e, the sender would be debited from the LOKDON wallet with sent amount while the recipient would be credited accordingly.

FYI

There is not much to write about. It’s just that where you have matching. Should be receivers m3pin added to the message is extracted, decrypted to the next mode m2pin. This is compared to m2pin held locally or by the server.

ZKP Triangle Flow 5

6. B must also second the confirmation by yet another ZKP to finalize the transaction.

Wallet to wallet cloud transfer

POST params receiver email, phone number, sender email, sent amount, sent phone all encrypted with our algorithm.

String receiverEmail = CipherControl.getInstance().encryptGenericData(recv_email);
String userPhoneNumber = CipherControl.getInstance().encryptGenericData(number);
String userSendEmail = CipherControl.getInstance().encryptGenericData(send_email);
String sentAmount = CipherControl.getInstance().encryptGenericData(m_amount);
String sentPhone = CipherControl.getInstance().encryptGenericData(phoneNo);

API URL

On success a wallet object response is returned with data values related to the successful wallet to wallet cloud transfer

Enterprise Cloud File sharing

How to get Azure portal connection string for Lokdon DWA: Click Here

How to get the access key and secret key from AWS console for Lokdon DWA: Click Here