Protect your small business from cybercrime

The problem with cybercrime is businesses are often using yesterday’s tools to fight tomorrow’s threats. That’s the opinion of Ramsés Gallego, vice-president of Isaca, the international trade body for information security companies. His clarion call to business is “the future is now” and any company which fails to “connect and protect” its data and systems runs the risk of falling prey to organised criminal gangs.

The truth of the matter is that in the past few years hackers have decided that cracking open a system and posting a message or disrupting files is no longer enough. The game has moved on to stealing data, money and intellectual property from businesses, usually working alongside a larger, organised criminal gang.

At the same time, the tools hackers have at their disposal have been greatly assisted by the weakest point in most organsation’s security – its staff. Employees are more active than ever on both work-related sites and social media.

“If you need to take on board one thing about the landscape that has changed, it’s that today’s threats are blended,” warns Gallego. “Criminals are forever evolving new tools and looking for new vulnerabilities that leave the door open to get them inside systems. But now they are also using social engineering to trick your employees to opening a door for them, by opening rogue messages, visiting sites and putting in a password or downloading some malware that will sit on the corporate systems.

“It’s not just a case of fighting off a virus on its own. Today the task has moved on to ensuring all your defences work together, so your intrusion prevention software talks to your firewall, and that in turn talks to your spam filter, which talks to your anti-virus programme, and so on.”

Persistent threat

The biggest lesson that businesses need to consider is that threats are not only persistent, they are multi-faceted. If hackers cannot get into your systems via one route, they will try another. If one social media site or phishing email does not work, they will try another.

For too long, industry experts would agree, each element of cyber security has operated in a silo, unaware of its greater role within the overall defence system. But today’s blended threats require a blended response.

For small companies it can be advisable to seek out a managed-service provider, a company that can provide access to software and applications to employees and clients through their own infrastructure, which the company protects.

Whether a business passes risk on to a third party or assumes sole responsibility for its cyber security, though, the onus is always on the business to protect its data and infrastructure from outside attack. If an attack is successful, it’s important finding out who is responsible. There are some simple steps that all businesses, of every size, should adopt.

Anti-virus protection is a must and should be kept up to date. Similarly, every piece of software or application should be updated with the latest patch, which guards against the most recent vulnerabilities. Companies should also consider restricting access to the most sensitive data only to whoever truly needs access. Crucially, all employees should be trained in cyber security.

“At Isaca, we have recently unveiled a new framework of how companies can provide cyber security that isn’t just about technology and processes,” says Gallego.

“It’s about culture, structure and strategy, too. All businesses, of all sizes, need to educate their employees about security. They need to talk to people so that they are aware that there are cyber criminals out there who are trying to get access to systems through social engineering, through phishing emails and so on.

“There’s a big move in the cyber security industry to speak to people, to explain the threats and then be an enabler to what people want to do. We [IT security] have been the bad guys for too long, who stop you using a certain app or a particular device, so businesses need to explain to staff the benefits of being enabled to carry out business safely.”

Security is a state of mind

A single word sums up the message Galleho wants to get across: “attitude”. According to him, security is a frame of mind that leads to technology deployments, never the other way around.

“When we’ve done research in to companies that have suffered a breach, very nearly all knew of the advanced persistent attack that hit them,” he says.

“Less than two in three were able to respond to it. Hackers are not magicians who can summon up attacks out of thin air. They are constantly evolving their attacks, but they are using the same programs and technology as businesses. So each company needs a mindset that it is ever vigilant and that never leaves a door open.

“The biggest thing companies at risk of an attack need to change is their attitude because the biggest threats are out there already. “

The worst thing a company can do is buy an anti-virus suite and then consider the job done. Not only does every piece of software need to be constantly updated and patched, but to protect the most valuable data additional layers of security must be added and access given only to those who truly need it.

A trick question often asked of an small business owner is: whose responsibility is it to ensure their systems are safe. Most answer they have an IT guy or an IT partner who looks after that. Truth is, the buck ultimately falls with the business owner if the company crumbles because it has lost its data or customers have lost faith in it.

Security in any company of any size is ultimately everyone’s responsibility.

Sign up to become a member of the Guardian Small Business Network here for more advice, insight and best practice direct to your inbox

McAfee Mobile World Congress 2014 Round-Up

Things have come to an end at Mobile World Congress 2014, where industry experts gathered to talk all things mobile and security. We had a great time discussing the future of mobile trends and how they will affect consumers and the enterprise, as well as sharing some exciting new ways we aim to help protect your mobile devices. On the show floor and online, we enjoyed talking with mobile security enthusiasts about our latest offerings as well as the company’s dedication to helping users protect their mobile devices, data, and digital identities.


Take a look at some of the electrifying things happening around mobile technologies and McAfee at Mobile World Congress 2014:

Free Mobile Security App for Android and iOS Devices 

On Monday, February 24, we announced something exciting: Free mobile protection for consumers on Android and iOS devices. McAfee® Mobile Security is now available to all consumers at no cost as part of an Intel Corporation initiative to make security an integrated part of the consumer experience.

This comprehensive security app helps prevent data loss even in the event of device theft through a unified, award-winning product. Additionally, Intel-based Android users will also have the opportunity to integrate their McAfee app with Intel(r) Device Protection Technology.

The Android version of McAfee Mobile Security can now secure your data from risky and unprotected Wi-Fi network connections. As well, users can activate the new CaptureCam to snap a picture of whoever is holding your device after multiple incorrect attempts are made to unlock it.

Expanded Security Solutions for Verizon Customers

We also announced the expansion of our partnership with Verizon. Verizon now offers multi-device security to Verizon’s 9 million-plus FiOS Internet and High Speed Internet customers with the Verizon Internet Security Suite Multi-Device solution. Powered by McAfee, consumers and small businesses can protect all of their PCs, Macs, and Android smartphones and tablets, with an easy-to-use centralized console.

With Verizon Internet Security Suite Multi-Device, users can protect their entire digital life with comprehensive, award-winning antivirus and anti-malware technology. The service is currently available to residential consumers for $6.99 a month or $11 a month when purchased as part of the Verizon Multi-Device Security and Backup Bundle. To learn more, check out Verizon’s informational page here.

We Dared Attendees To Crack the PIN

To help demonstrate just how vulnerable mobile devices are, we challenged Mobile World Congress attendees to try their luck at our Crack the PIN kiosk where they had a chance to break into a locked tablet and if guessed correctly, take the device home. Five lucky people succeeded and walked away with a brand new Samsung Galaxy tablet. Additionally, for users following the action on Twitter, we held a “PIN It” contest, where entrants tweeted us a screenshot of their PIN lock screen and 10 winners received a $50 Amazon gift card and a one-year subscription to McAfee LiveSafe™ service.



winner3Discussed the Future of Mobile Security

Mobile devices are a tremendous source of productivity, entertainment, and connection, but they are also a treasure trove of personal and private information that’s irresistible to hackers. McAfee vice president and Security Connected CTO, Michael Sentonas, along with other industry experts discussed this and a variety of other mobile security and consumer mobile safety-related issues during three panel sessions that took place within the Intel booth.



A lot of great things were covered and accomplished this year at Mobile World Congress 2014, and we’re looking forward to achieving even more in tackling the next wave of mobile security threats this year and beyond. Here’s looking forward to next year!

For the latest updates on consumer threats and mobile security, follow us on Twitter at @McAfeeConsumer and on Facebook and tell us what you think!


The post McAfee Mobile World Congress 2014 Round-Up appeared first on McAfee Blogs.

7 Ways to Tell If It’s a Fake

Unfortunately in today’s world, scammers are coming at us from all angles to try and trick us to get us to part with our hard earned money. We all need to be vigilant in protecting ourselves online. If you aren’t paying attention—even if you know what to look for—they can get you.

There are numerous ways to detect fake sites or emails, phishing, etc. Here are 10 you should know about:

  1. Incorrect URL. Hackers use fake sites to steal your information. Watch to make sure the URL is actually the one you want to be going to— if you notice the URL is different, that’s a good indication that the site is fake and you should NOT enter your information. There’s a number of ways you can protect yourself from this:
    • If you’re on a computer, hover your mouse over the link to see a preview of the link URL in the status bar. Then check to see if the link site matches the site that it should be from. So for example if your email comes from North Bank or you type in North Bank into the Google search bar and the link is not going to but something like you should not click.
    • If you’re on a mobile device, use a link preview to see the actual URL before you click.
    • You can also use McAfee® SiteAdvisor® on both your computer and mobile device to make sure the links you are going to are not bad links.
  2. Nosy Requests. Your bank won’t ask via email for your PINs or card information. Be suspicious of sites (or emails) requesting your Social Security number, identification number or other sensitive information.
  3. Sender’s Email Address. You can also check who sent the email by looking at the send address. It may say it’s from North Bank, but the email may be something strange like The sender’s email should not be using a public Internet account like Hotmail, Gmail, Yahoo!, etc.
  4. Your Name. A legitimate email from your bank or business will address you by name rather than as “Valued Customer” (or something similar).
  5. Typos. Misspellings or grammatical errors are another sure sign that the message or site is fake.
  6. Fake Password. If you’re at a fake site and type in a phony password, a fake site is likely to accept it.
  7. Low Resolution Images. A tip-off to a false site is poor image quality of the company’s logo or other graphics.

Additionally…Hit delete. How about just hitting the delete button whenever an email comes to you from an unfamiliar sender? After all, if any legitimate entity needs to contact you about something urgent or crucial, they would have your phone number, right? They know your name, too. Remember, “just say no” to opening unfamiliar or suspicious looking emails.


Robert Siciliano is an Online Security Expert to McAfee. He is the author of 99 Things You Wish You Knew Before Your Mobile was Hacked!  Disclosures.


The post 7 Ways to Tell If It’s a Fake appeared first on McAfee Blogs.

Automatic App Installation from Google Play Poses Big Risk

Android users usually download and install applications from the Google Play store through several interactions with the service–including viewing the app’s description and granting permission requests by the app. This confirmation procedure helps us avoid installing malicious and potentially unwanted apps.

However, McAfee recently found a suspicious app on Google Play that almost automatically downloads, installs, and launches other apps from Google Play without these interactions. This automatic installation occurs with the Google account’s authorization tokens, provided by the user only once, which communicates with Google Play URLs in an unofficial way.


A badly behaved app that automatically installs other apps from Google Play.


This app, which has been removed from Google Play, targets Japanese users and allows them to download and view adult movies in return for installing at least five apps among a list of more than 10 provided by a remote server. None of these apps are malicious. It appears the app does this just to get pay-per-install affiliate rewards in an easy–and possibly prohibited–way that betrays advertisers. It’s possible the remote server might later change the list of apps and replace them with malicious ones, though we have not yet seen such behavior.


The app offers adult movies in return for installing five more apps.


Next the app grabs the Google account information on the device and requests that the user authorize the app to access Google services using the AccountManager.getAccountsByType() and AccountMangaer.getAuthToken() APIs. In this case, two privileges, SID and LSID, are requested; these allow the app to access various Google services including the store. These authorization tokens are stored by the app for later use and are also cached for a while by the Android system. Thus until they expire, this authorization request will not be repeated when user next launches the app.


The app requests users authorize to access to the SID and LSID of the Google account.


Once these privileges are granted, the app accesses and interacts several times in an unofficial way with the URLs managed by Google Play. We suspect that the app developer somehow reverse-engineered the protocol used in the Google Play service. Through these HTTP communications, such as retrieving cookies, the app obtains a token to directly request the download of any free apps on Google Play and initiates their automated installation.


The app triggers the automatic installation of five selected apps from Google Play.


Normally users install apps manually from Google Play and can open an app’s description page, check the permission requests, and reject an installation. None of that is possible with this app. Finally the app launches all the installed apps once their installations have finished.


Installing the five apps succeeds without any permission confirmations by the user.


Allowing this kind of app installation invites terrible results if this technique is abused by malicious developers; they can silently install other malicious apps on Google Play onto a user’s device and automatically launch them to run harmful code, without giving the user any opportunity to reject the installation. Users can still bar access to the SID and LSID of their Google accounts when prompted, but malware could offer a legitimate reason or a reward to convince users to approve requests, and allow the app to later install other malware or unwanted apps using the stored authorization tokens.

This automatic installation is allowed thanks to users granting GET_ACCOUNTS and USE_CREDENTIALS permission requests by the app. As previously mentioned, granting these permissions gives the app a powerful position on users’ accounts (and possibly the accounts of services other than Google). Users should be very careful when any unfamiliar app requests these permissions at installation, and also when such apps request access to privileges to a device’s Google account at runtime. Allowing privileges to malicious apps could cause terrible damage to devices and privacy.


The GET_ACCOUNTS and USE_CREDENTIALS permission requests.


McAfee Mobile Security detects this potentially risky app as Android/BadInst.A.

The post Automatic App Installation from Google Play Poses Big Risk appeared first on McAfee Blogs.

Unlocking Android devices using an OTP via NFC

Our last post showed how to use a contactless smart card to sign email on Android. While storing cryptographic keys used with PKI or PGP is one of the main use cases for smart cards, other usages are gaining popularity as well. Additionally, the traditional ‘card’ format has evolved and there are different devices that embed a secure element (basically, the smart card chip), and make its functionality available without requiring a bulky card reader. One popular and affordable device that embeds a secure element is the YubKey Neo from Yubico. In this post we’ll show how you can use the YubiKey Neo to unlock your Android device over NFC.

One-time passwords

Before we discuss how the YubiKey NEO can be used to unlock an Android device, let’s say a few words about OTPs. As the name implies, one-time passwords are passwords that are valid for a single login or transaction. OTPs can be generated based on an algorithm that derives each next password from the previous one, or by using some sort of challenge-response mechanism. Another approach is to use a shared secret, called a seed, along with some dynamic value such as a counter or a value derived from the current time. While OTP generation based on a shared seed is usually fairly easy to implement, the dynamic values at the OTP token (called a prover) and the verifier (authentication server) can get out of sync and validation algorithms need to account for that. 
Many OTP schemes are proprietary and incompatible with each other. Fortunately, widely adopted open standards exist as well, most notably the HMAC-based One Time Password (HOTP) algorithm developed by the Initiative for Open Authentication (OATH). HOTP uses a secret key and a counter as input to the HMAC-SHA1 message authentication code (MAC) algorithm, truncates the calculated MAC value and converts it to a to human readable code, usually a 6-digit number. A later variation is the TOTP (Time-Based One-Time Password) algorithm, which substitutes the counter for a value derived from the current Unix time (i.e., the number of seconds since midnight of January 1, 1970 UTC). The derived value T, is calculated using an initial time T0 and a step X as follows: T = (Current Unix time - T0) / X. Each generated OTP is valid for X seconds, by default 30. TOTP is used by Google Authenticator and the Yubico OATH applet which we will use in our demo.

YubiKey Neo

The original YubiKey (now called YubiKey Standard), was an innovative token for two-factor authentication (2FA). It has a USB interface and presents itself as a USB keyboard when pulgged in, and thus does not require any special drivers to use. It has a single capacitive button that outputs an OTP when pressed. Because the device functions as keyboard, the OTP can be automatically entered in any text field of a desktop or Web application, or even terminal window, requiring very little modification to exiting applications. The OTP is generated using a 128-bit key stored inside the device, either using Yubico’s OTP algorithm, or the HOTP algorithm.
The YubiKey Neo retains the form factor of the original YubiKey, but adds an important new component: a secure element (SE), accessible both via USB and over NFC. The SE offers a JavaCard 3.0/JCOP 2.4.2-compatible execution environment, an ISO14443A NFC interface, Mifare Classic emulation and an NDEF applet for interaction with Yubikey functionality. When plugged into a USB port, depending on its configuration, the Neo presents itself either as a keybord (HID device), a standard CCID smart card reader, or both when in composite mode. As the SE is fully compatible with JavaCard and GlobalPlatform standards, additional applets can be loaded with standard tools. Recent batches ship with pre-installed  OATH, PGP and PIV applets, and the code for both the OATH and PGP applets is available. Yubico provides a Google Authenticator compatible Android application, Yubico Authenticator that allows you to store the keys used to generate OTPs on the Neo. This ensures that neither attackers who have physical access to your Android device, nor applications with root access can extract your OTP keys. 

The Android lockscreen

Before we can figure out how to unlock an Android device using an OTP we need to understand how the lockscreen works. The lockscreen is formally known as the keyguard and is implemented much like regular Android applications: with widgets laid out on a window. What makes it special is that its window lives on a very high window layer that other applications cannot draw on top of or get control over. Additionally, the keyguard intercepts the normal navigation buttons, making it impossible to bypass and thus ‘locking’ the device. The keyguard window layer is not the highest layer however: dialogs originating from the keyguard itself, and the status bar, can be drawn over the keyguard. You can see a list of the currently shown windows using the Hierarchy Viewer tool available with the ADT. When the screen is locked the active windows is the Keyguard window, as shown in the screenshot below.
Before Android 4.0, it was possible for third-party applications to show windows in the keyguard layer, and this approach was often used in order to intercept the Home button and implement ‘kiosk’ style applications. Since Android 4.0 however, adding windows to the keyguard layer requires the INTERNAL_SYSTEM_WINDOW signature permission, which is available only to system applications.

For a long time the keyguard was an implementation detail of Android’s window system and was not separated into a dedicated component. With the introduction of lockscreen widgets, dreams (i.e., screensavers) and support for multiple users, the keyguard gained quite a lot of functionality and was eventually extracted in a dedicated system application, Keyguard, in Android 4.4. The Keyguard app lives in the process, along with the core Android UI implementation. Most importantly for our purposes, the Keyguard app includes a service with a remote interface, IKeyguardService. This service allows its clients to check the current state of the keyguard, set the current user, launch the camera and hide or disable the keyguard. As can be expected, operations that change the state of the keyguard are protected by a system signature permission, CONTROL_KEYGUARD.

Unlocking the keyguard

Stock Android provides three main methods to unlock the keyguard: by drawing a pattern, by entering a PIN or password, or by using image recognition, aka Face Unlock, also referred to as ‘weak biometric’. The pattern, PIN and passphrase methods are essentially equivalent: they compare the hash of the user input to a hash stored on the device and unlock it if the values match. The hash for the pattern lock is stored in /data/system/gesture.key as an unsalted SHA-1 value. The hash of the PIN/password is a combination of the SHA-1 and MD5 hash values of  the user input, salted with a random value. It is stored in the /data/misc/password.key file. The Face Unlock implementation is proprietary and no details are available about the format of the stored data. Normally not visible to the user are the Google account password unlock method (used when the device is locked after too many incorrect unlock attempts) and the unlock method that uses the PIN or PUK of the SIM card. The Google unlock method uses the proprietary Google Login Service to verify the entered password, and the PIN/PUK method simply sends commands to the SIM card via the RIL interface.

As you can see, all unlock methods are based on a fixed PIN, password or pattern. Except in the case of a long and complex password, which is rather hard to input on a touchscreen keyboard, all unlock secrets usually have low entropy and can easily be guessed or bruteforced. Android partially protects against such attacks by permanently locking the device after too many unsuccessful attempts. Additionally security polices introduced by a device administrator application can enforce PIN/password complexity rules and even wipe the device after too many unsuccessful attempts.

One approach to improve the security of the keyguard is to use an OTP in order to unlock the device. While this is not directly supported by Android, it can be implemented on production devices by using a device administrator application that periodically changes the unlock PIN or password using the DevicePolicyManager API. One such application is TimePIN (which this post was in part inspired by) which sets the unlock password based on the current time. TimePIN allows you to set different modifiers that are applied when calculating the current PIN. Modifiers can be stacked, so the transformation can become complex, but still easy to remember. A secret component, called an offset can be mixed in for added security.

Unlocking via NFC

Authentication methods are usually based on something you know, something only you have, or a combination of the two (two-factor authentication, 2FA). The pattern and PIN/password unlock methods are based on something you know, and Face Unlock can be thought of as based on something you have (your face or a really good picture). However, Face Unlock allows for a fallback to PIN or password when it cannot detect a face, so it can still be unlocked by something you know.

An alternative way to use something you have to unlock the device is to use an NFC tag. This is not supported by stock Android, but is implemented in some devices, for example the Motorola X (marketed as Motorola Skip). While the Motorola Skip is a proprietary solution and no implementation details are available, apps that offer similar functionality such as NFC LockScreenOff Enabler compare the UID of the read tag to a list of stored values and unlock the device if the UID is in the list. While this is fairly secure as the UID of most NFC tags is read-only, cards that allow for UID modification are available, and a programmable NFC card emulator can emit any UID.

One problem with implementing NFC unlock is that by default Android does not scan for NFC devices when the screen is turned off or locked. This is intended as a security measure, because if the device reads NFC tags while the screen is off, vulnerabilities can be triggered without physical access to the device or the owner noticing, as has been demonstrated. NFC LockScreenOff Enabler and similar applications can get around this limitation when running on rooted devices by installing hooks into system methods, thus allowing the NFC system service configuration to be modified at runtime.

Unlocking using the YubiKey Neo

As we mentioned in the ‘YubiKey Neo’ section, Yubico provides both a JavaCard applet and a companion Android app that together implement TOTP compatible with Google Authenticator. The Yubico Authenticator app is initialized just like its Google counterpart — either manually or by scanning a QR code. The difference is that the Yubico Authenticator saves the OTP seed on the device only temporarily, and once it’s written to the Neo, deletes it. To display the current OTP, you need to touch the Neo while the app is active, and touch it again after the OTPs expire. If you don’t want to enter keys and accounts manually you can use a QR code generator such as the one provided by the ZXing project to generate a URI that includes an account name and seed. The URI format is available on the Google Authenticator Wiki.

While unlocking the keyguard certainly doesn’t need the full functionality of the Google Authenticator app, displaying the current OTP is useful for debugging and initializing with a QR code is quite convenient. That’s why for our demo we will simply modify the Authenticator app slightly, instead of writing another OTP source. As we need to provide the OTP to the system NFC service, which runs in a different process, we add a remote AIDL service with a single method that returns the current OTP:

interface IRemoteOtpSource {

String getNextCode(String accountName);


The NFC service can then bind to the OTP service that implements this interface and retrieve the current OTP. Of course, providing the OTP to everyone is not a great idea, so we protect the service with a signature permission that can only be granted to system apps by signing our  RemoteAuthenticator app with the platform certificate:

<manifest ...>
<application ...>
<service android:enabled="true" android:exported="true"


The full source code of the RemoteAuthenticator app is available on Github. Once installed, the app needs to be initialized with the same key and account name as the OATH applet on the YubiKey Neo. Our sample NFC unlock implementations looks for an account named ‘lockscreen’ when it detects the OATH applet. The interface of the modified app is identical to that of Google Authenticator:

Before we can use an NFC tag to unlock the keyguard, we need to make sure the system NFC service can detect NFC tags even when the keyguard is locked. As we mentioned earlier, that is not the case in stock Android, so we change the default polling mode from SCREEN_STATE_ON_UNLOCKED to SCREEN_STATE_ON_LOCKED in


public class NfcService implements DeviceHostListener {
/** minimum screen state that enables NFC polling (discovery) */


With this done, we can hook into the NFC service tag dispatch sequence, and, borrowing some code from the Yubico Authenticator app, check whether the scanned tag includes an OATH applet. If so, we read out the current OTP and compare it with the OTP returned by the RemoteAuthenticator app installed on the device. If the OTPs match, we dismiss the keyguard and let the dispatch continue. If the tag doesn’t contain an OTP applet, or the OTPs don’t match, we do not dispatch the tag. To unlock the keyguard we simply call the keyguardDone() method of the system KeyguardService. The unlock process might look something like this:

Full source code for the modified NFC service is available on Github (in the ‘otp-unlock’ branch). Note that while this demo implementation handles basic error cases like OATH applet not found or connection with tag lost, it is not particularly robust. It only tries to connect to remote services once, and if  either of them is unavailable, NFC unlock is disabled altogether. It doesn’t provide any visual indication that NFC unlock is happening either, the keyguard simply disappears as seen in the video above. Another missing piece is multi-user support: in order to support multiple users, the code needs to look for the current users’s account on the NFC device, and not for a hardcoded name. Finally, the NFC unlock as currently implemented is not a full unlock method: it cannot be selected in the Screen security settings, but simply supplements the currently selected unlock method.


As of Android 4.4, the Android keyguard can be queried by third party applications and dismissed by apps that hold the CONTROL_KEYGUARD permission. This makes it easy to implement alternative unlock mechanisms, such as NFC unlock. However, NFC tag polling is disabled by default when the screen is locked, so adding an NFC unlock mechanism requires modifying the system NFC service. For added security, NFC unlock methods should rely not only on the UID of the scanned tag, but on some secret information that is securely stored inside the tag. This could be a private key for use in some sort of signature-based authentication scheme, or an OTP seed. An easy way to implement OTP-based NFC unlock is to use the Yubico OATH applet, pre-installed on the YubiKey Neo, along with a modified Google Authenticator app that offers a remote interface to read the current OTP.