Tuesday, 24 October 2017

PSEUDORANDOM NUMBER A BOON OR A BANE TO CYBER SECURITY

Transaction of information on internet is not a new; it has gone through a lot of transformation. But how much is this transaction secured especially when it comes to critical information related to defense, financial organizations etc. Cyber crooks, network hackers, cyber pirates, internet thieves is an emerging crime category of criminals and threat to online information transactions of data and information.
Not only the Banks and financial institutions but almost every organization who have some critical data have put much effort into internet security measures to protect customer and even themselves from fraud. You’re probably familiar with the “two-factor authentication security method” – the bank provides you with a security token, which generates a pseudo-random number for you to use at login, along with other credentials. What if fraudsters managed to over-rule this security measure during your attempt to log into your online bank account.
Some of the techniques used by cyber-criminals to breach your internet security and get to your money are Man-in-the-browser, Phising Schemes, Money Mules, Keylogger through hardware or software.
The security token which is a onetime pseudorandom number comes to the rescue. But, if this token in the form of a OTP number, if used more than once may prove to be a very bad experience for anyone. So, its use is also required to be protected from cyber-criminals and this may depend on how hard the coding has been done. For example the code given below generates the security token:
$link = JRoute::_('index.php?option=com_comp&view=comview&task=action'&'.JSession ::getFormToken().'=1');
And the code given below is used for validating the token

JSession::checkToken('get') or die( 'Invalid Token' );
This code generates the link which is something like:
 http://localhost/index.php?option=com_comp&view=comview&task=action&231a817c6f53a732b6d70f3e2c3c5fcd=1
In this example, the token generated is not a onetime useable, as a number of request can be sent to on the OTP. Actually the generated token and the check token must be both related to a session such that one can verify the token in the same session and only once. Clicking the back button should amount to as a new session and a new token be generated for verification and previously generated token should be treated as an invalid token.
So through this discussion one thing is very clear that the security threat is only in using the security token and not in its generation procedure or technique.
The security token in discussion can be implemented in hardware or software. A hardware implementation of it is generally done using LFSR (linear feedback shift registers). The two structures of LFSR are many-to-one and one-to-many structure. Block diagram of the many-to-one structure is given below:
Many-to-One Structure
Well, the design of the hardware is little out of the scope of this small article, however, it should be noted that pseudorandom sequence depends on the seed value (Initial value of the LFSR), the tap positions and the feedback type. The choice of taps determines how many values there are in a given sequence before the sequence repeats.
LFSR used as pseudorandom number generated find a number of applications which includes:
  • Data Encryption/Decryption
  • Digital Signal Processing
  • Wireless Communications
  • Built-in Self Test (BIST)
  • Data Integrity Checksums
  • Data Compression
  • Pseudo-random Number Generation (PN)
  • Direct Sequence Spread Spectrum
  • Scrambler/Descrambler
  • Optimized Counters
Conclusion:
The pseudorandom generator is definitely a boon and not a bane to the cyber-security. The number is not repeated until the whole cycle of maximal length of number is over, and this length is very high say for 128-bit it is not until 2128 numbers are generated. The threat is in its improper usage. It should be ensured in the transaction code that the number is not allowed to be used again.

Ravinder Nath Rajotiya
Professor, Department: ECE

No comments:

Post a Comment