Engineering @Zeta

Zeta Tech Stack

Zeta is in the business of providing a full-stack, cloud-native, API-first neo-banking platform including a digital core and a payment engine for issuance of credit, debit, and prepaid products. These products enable legacy banks and new-age fintech institutions to launch modern retail and corporate fintech products. 

Zeta currently provides its platform and products to BFSI issuers in India, Asia, and LATAM. Zeta’s products are used by banks such as RBL Bank, IDFC First Bank, and Kotak Mahindra Bank, 14000 corporates, and over 2 million users. Zeta is a SOC 2, ISO 27001, ISO 9001:2008, PCI DSS certified company.

How does Zeta continuously deliver at these high levels without compromising on security? Let us take a look at Zeta’s tech stack to find out.

Server Applications

A server application is designed to install, operate, and host applications and associated services for end-users.

Compute Runtimes

Technology usedKubernetes, GitOps, Apache Openwhisk, Apache Flink, and Camunda. 

Following are the runtime applications in Zeta.

  • Atlantis is a docker runtime container deployed using GitOps based end-to-end orchestration with the help of Kubernetes.
  • Aster is an open-source serverless platform run on Apache Openwhisk that runs various short-lived jobs on-demand. 
  • Rhea is an application used to execute BPMN workflows that run on the Camunda platform.
  • Perseus is an adaptation of Apache Flink to run complex event processing tasks. Apache Flink is a framework and processing engine used for computations at any scale.

We use Camunda to define workflows and automate decision-making. 

Apache Flink provides a high-throughput, low-latency streaming engine and supports event-time processing and state management. It has allowed us to perform computations at any scale.

Cluster Management

Technology usedKubernetes, Kong, and Calico. 

A cluster management tool is an essential service used to group the clusters and nodes. This is used to:

  • Monitor nodes in the cluster.
  • Configure services.
  • Administer cluster services. 

We prefer using open-source systems in our tech stack. That is why we use Kubernetes as our orchestration system to efficiently manage and deploy containers. 

Ingress and API Gateways run using Kong. Kong supports high availability clusters and an extensive range of plugins to address various concerns like authentication, security, and monitoring.

We have also developed 2 in-house tools, Sprinkler and Hades. Sprinkler is our Egress gateway and Hades is our file input/output gateway. 

We use the Calico plugin to manage the container network interface.

We are evaluating Istio to adopt it as our open service mesh. A service mesh controls how different parts of an application share data with each other.

Messaging Infrastructure

Technology usedApache Kafka, Apache Nifi, Apache Flink, KSQL, and Kafka.

A messaging system transfers data from one application to another. We use the following components to seamlessly transfer messages within Zeta’s various applications and clusters.

  • Apache Kafka is used as a message broker. It allows us to handle high volumes of data and passes messages from one end to the other. 
  • Atropos is a message-based integration bus based on Kafka developed by Zeta.
  • Apache Nifi is used to implement ETL Pipelines. 
  • Perseus, developed by Zeta, uses Apache Flink to process complex events. 
  • Sinope uses KSQL and Kafka connectors to bridge the message/event world and the batch/file world. KSQL and Kafka connectors enable rich data integration and streaming.

Data Stores

Technology usedPostgresql, Amazon S3, Amazon RedShift, ClickHouse, and Redis.

Postgresql is used to store transactional data and Amazon S3 is our data lake. We use Amazon RedShift and ClickHouse as our data warehouse and Redis, an open-source memory data structure, to store cache.

Application Performance Monitoring (APM) and Business Performance Monitoring (BPM) uses the ElasticSearch engine.

Data Processing

Technology usedPresto SQL, Sparta, and Apache Superset.

The data processing unit is an essential part of any server application. It converts data available in the system (machine-readable data) to a human-readable format. 

We use the Presto SQL query engine to process big data and Sparta for stream processing. Stream processing allows us to convert data in motion directly to continuous streams. 

The Power Centre stores various data models and allows us to modify data and enables the reuse of data. The Power Centre is an adaption of Apache Superset.

CI/CD

Technology usedJenkins, ArgoCD, and Sonarqube.

Jenkins is used for Continuous Integration (CI) and ArgoCD for Continuous Deployment (CD).

Our servers use Sonarqube, an open-source platform, for static code analysis.

Observability

Technology usedGrafana, Kibana, Fluentd, and Hypertrace.

Observability is defined as the ability of the internal states of a system to be determined by its external outputs. External outputs can be anything such as alerts, visual representation, and  infrastructure tracing.

We have developed Prometheus as our event monitoring system. Prometheus stores all metrics in the database. 

We use Grafana for our dashboards and alerts and Kibana for log analysis. The purpose of both these applications is to visualize and navigate data. We also use Fluentd, an open-source data collector, for logs and metrics collection.

All applications should have a distributed tracing system. Hypertrace is our tracing system. It helps us debug applications and log information about their execution.

Security Monitoring

Technology usedHELK and Jackhammer.

Security monitoring is another essential unit to analyze data to detect any suspicious behavior or changes to the network. 

HELK is an ELK (Elasticsearch, Logstash & Kibana) stack with advanced hunting analytic capabilities provided by the implementation of Spark and Graphframes technologies.

Kratos, an in-house adaption of Jackhammer, is our Security CI.

We are evaluating RockNSM, a premier sensor platform for Network Security Monitoring (NSM) hunting and incident response (IR) operations. 

Hardware Security Module (HSM)

Technology usedSafenet, Gemalto and nCipher/ Entrust nShield Solo.

HSM manages digital keys, encryption and decryption, and provides strong authentication. We use the following HSMs:

  • Safenet and Gemalto as Network HSM.
  • nCipher/ Entrusy nShield Solo.
  • Harpocrates, developed by Zeta, is our HSM as a service interface. 

Mobile Application

Technology usedFirebase Hosting, Websockets, HTTPS.

Languages usedKotlin, Java, Objective C, Swift.

We develop mobile applications as native apps, React Native apps, and web apps.

Kotlin and Java are used to develop our Android applications and Objective C and Swift for our iOS applications.

Firebase Hosting helps with Analytics and Crash detection in the server. Websockets and HTTPS make it possible for two-way communication between the server and the user.

Web Applications

Technology usedTypescript, SCSS transpilers, Vue.js, Bulma, Buefy, Webpack, Rollup, Verdaccio, Lerna, and Sentry.

Languages usedHTML, CSS, Javascript, Node JS, and Express JS

We use HTML, CSS, Javascript, Node JS, and Express JS to develop our web applications.

Typescript and SCSS transpilers convert program code from one language to another.

Vue.js is our Javascript framework and Bulma is our CSS framework. Buefy is a user interface component and is made using both Bulma and Vue js. Webpack and Rollup are the JavaScript build tools. 

Verdaccio, an NPM registry, serves the purpose of a Private NPM repository. The repository is managed by Lerna, a workflow optimization tool. Sentry, an Application monitoring tool, is used to monitor errors.

Cyber Security

Technology usedTrivy, Clair, CloudSploit, MobSF, ZAP

The challenge when building a product is how we balance ease of use with security. At Zeta, we use Trivy for CI docker scanning and Clair for CD docker scanning.

CloudSploit is our Cloud Security Posture Management.  We use MobSF for mobile application security.

ZAP for web applications is all in CI/CD.

Best Tech Stack = Best Performance?

Building a system that can provide these functionalities and process over 1 million transactions per second is not easy. While Zeta uses the best tech stack, building a robust framework to continuously deliver at the highest levels without compromising on security would not have been possible without Zeta’s talented engineers.

Security Principles for Mobile Applications

The challenge when building a secure mobile application is how we balance ease of use with security. Applications that are easy to use are the ones that succeed. However, any compromise on security could have disastrous consequences. Mobile applications that handle payments have more stringent security protocols when compared to utility applications. However, to succeed, it has to be just as easy to use.

These were the topics of discussion at Rootconf’s Data Privacy Conference held in April 2021. The roundtable, moderated by Suman Kar, included Madhusudhan Sambojhu from Able.do, Chirayu Desai from Calyx Institute, and Apurva Jaiswal, Engineering Manager at Zeta.

Zeta develops cloud-native mobile-first banking and payment platforms that meet these exact requirements. We aim to move away from lengthy checkout forms and OTP-based payment authorization. Our platform allows merchants to securely accept payments from around the world and allows customers to make these payments with a single swipe.

Let us discuss some of the security principles we follow at Zeta when designing our mobile applications.

Zero-trust Principle

Adopting a zero-trust approach is important when it comes to securing data on applications. Organizations building the application should ensure they have implemented all necessary security measures to protect user data. They should not depend on the application hosts for this.

There are 2 types of data that we need to secure in mobile applications:

  • Data at rest.
  • Data at motion.

All sensitive data should be saved in vault storage and should be accessible with explicit consent from the user.

Since mobile devices are sandboxed from day one, it helps protect application data, stored on the device’s internal storage, from hackers and other applications on the device. Some tools that can be used to secure data are Charles proxy, Wireshark, Firebase, and SonarQube.

[su_youtube_advanced url=”https://www.youtube.com/watch?v=f-boD_oQ5ts&ab_channel=PhaniMarpaka” autoplay=”no”]

At Zeta, we ensure user data is opaque to the cloud provided and is end-to-end protected. We distill and sanitize the network edges. We ensure end-to-end authentication and access control using IAM and RBAC.

Listed below are some best practices we have adopted at Zeta when building mobile applications.

Mobile Application Security

Mobile application security is the measures taken by the application developer to secure the applications from external threats. A breach in mobile security gives hackers access to the user’s personal information, their current location, banking information, and much more. Some best practices are:

  • Perform root checks using Google SafetyNet API and Rootbeer. On iOS devices check for functions that should not be available in a non-rooted device.
  • Use SSL Pinning to prevent attackers from analyzing your application functionality and the way it communicates with the server.
  • Build strong and customizable authentication flows: — Phone number + OTP, Phone number + OTP + password
  • Do not allow concurrent logins.
  • Analyze user behavior and trigger re-authentication in case of risks.
  • Have a strong device binding ID (Device ID + Sim ID)
  • Do not issue tokens when the device binding ID changes.
  • Server triggered data wipeout.
  • Screen record and screen capture protection.
  • Launcher image protection.

APK Security

It is not enough to secure your application while it is being used. It is critical to ensure your application is hosted and distributed from a secure platform. This prevents hackers from gaining access to your code repository and exploiting it to gain unauthorized access to user data. Some best practices are:

  • Never distribute APKs through APK/IPA files. Use standard firebase app distribution/testflight.
  • Never release debug builds.
  • Assume whatever goes in APK is public information :- The Native Development Kit (NDK), Prefer server-side secrets
  • Implement code obfuscation.
  • Incorporate proguard rules in your builds.

Identity Establishment and Authentication

When onboarding a customer on your mobile application, it is important to establish their identity. This allows us to ensure only that person has access to the application on their device. Some best practices are:

  • Challenge a user using multiple identity vectors such as phone number, email, bank account number, and password. Challenges should be sent on different communication channels
  • Each vector is identified by a specific IdP.
  • Implement Social Authentication.
  • Use penny testing to verify a user’s account.
  • Successful authentication leads to a 256 bit AES symmetric key between server and client using ECDHE-ECDSA-AES256 bit key exchange.
  • Subsequent device sessions are established using OATH-based HOTP of monotonically increasing session count.
  • 256 bit Symmetric Keys.
  • OATH-based HOTP for authentication.
  • Key setup using ECDHE-ECDSA-AES256 bit.
  • Real-time locating system (RTLS) optimized transport based on TLS 1.2. : — Key exchange through ECDHE-ECDSA-AES256 bit key (Equivalent to RSA 372 bit), Encryption, authentication, and integrity check through AES 128 bit in counter mode with SHA-256 based HMAC.

Transaction

Securing transaction data is the most important aspect of mobile security. Any vulnerabilities here can lead to the application user losing money and cause irrevocable setbacks to your application.

  • Non-repudiable transactions.
  • Private keys protected using Secure Module on Device or Password+Scrypt.
  • Non-verifiable random key material on the device.
  • Key rotation after every successful online transaction.

Assume the mobile application code/library is public

This should be the basic assumption an organization makes when building a mobile application. To ensure there are no compromises to an application’s security, organizations need:

  • Ensure their mobile team is kept up to date with and implements the latest security guidelines and practices in the industry.
  • Ensure all security checks and protocols are enforced when deploying code.
  • Have their mobile application regularly audited by external auditors.

[su_youtube url=”https://www.youtube.com/watch?v=VRBPbQYoytY&ab_channel=PhaniMarpaka”]

At zeta, we believe in building and nurturing a strong team that understands security and follows the importance of:

  • Code peer reviews.
  • Static application security testing.
  • Regular security testing team by Zeta’s internal security team.
  • Regular application security testing by 3rd party vendors such as SISA.

Conclusion

There cannot be any compromise in terms of security when building mobile applications. Apart from setting up security protocols, organizations should ensure their employees are kept up to date with the latest trends in security. Organizations can use tools to enforce security protocol and ensure their applications are secure.

It is also important to educate end-users about best practices around mobile applications. Users should only download applications from trusted application hosts. Downloading applications directly from a website or elsewhere could lead to security breaches.

Zeta Suite is rethinking payments from core to the edge, algorithms to form factors, applications to solutions. Having built a modern stack that Financial Institutions (FIs) can use for debit, credit, and prepaid cards, loans, authentication, and Fraud and Risk Management (FRM), Zeta invites you to join their journey in democratizing payments. Check out the openings on < careers.zeta.tech >

Thanks

Cipher CIAM for a reasonably complex enterprise AAAC scenario

Cipher is Zeta’s mobile-first advanced Access Control Server (ACS) that offers seamless and secure payments with best-in-class success rates. Superior integration, risk-based authentication, and superior OTP experience guarantee increased customer stickiness and higher profits. Cipher also offers powerful APIs, advanced SDKs, and innovative features like Swipe2Pay and SuperPIN to provide an unparalleled payment experience.

Cipher does not require or store any payment sensitive data, like Card PAN, Expiry, CVV to perform authentication. It requires minimal data depending on the various modes of authentication you may want to enable.

Cipher CIAM (Customer Identity & Access Management) is a point for multiple Sign In and SSO use cases externally and within Zeta. Cipher CIAM is OAuth 2.0 and Open ID Connect 1.0 compliant. The primary objective of Cipher CIAM is to reduce the complexity of access management by 10X. In this blog, we’ll be covering 3 key concepts:

  • Access management in a role-based world
  • Cipher CIAM’s approach to access management
  • Access management with Cipher CIAM

Without Cipher CIAM

Let’s look at a scenario without Cipher. Consider a hypothetical organization named Theta (a series A funded B2B startup). The company has a prospective client who is interested in their fully cooked product. With a team of talented engineers to handle all the coding requirements, the only thing needed from an authorization standpoint is ensuring access to the repository rests only with the engineering team. They need to ensure that the product can be accessed only by the prospective customer in a secure way. Additionally, if there are exits/additions to the engineering team, the admin i.e founders in this scenario need to ensure access to the repository has been revoked/granted respectively.

Roles within Theta can be divided into admin and developer. Furthermore, roles within the product are divided into admin and users.

As Theta grows in size, they have teams of HR, IT, finance, engineering, and an expanding customer base. The functions within the company have changed over time. HR requiring payroll access translates to the need for an authorization structure. The authorization scope is now isolated as there are groups of customers each requiring a tenant. Each team is further divided into specific roles i.e HR Admin, HR Update, and HR viewer.

Theta decides to launch another product with a new sales and engineering team. This product comes with a unique set of customers. As the company continues its expansion, the roles start getting increasingly complex.

System integrators and mobile app development partners enter the foray at some point, requiring access management. At this stage, Theta delivers products to customers who in turn deliver them to their end-users. Additionally, development partners need to be given access to APIs, specific SDKs, tokens, etc., thus increasing the load on the authentication and authorization system.

Fast forward a few years, Theta decides to go public and begins the process of setting up a team in the US. The company, at this point, has 200+ roles!

Using Cipher CIAM

Enter, Cipher CIAM(Customer Identity and Access Management) approach (previously called Cipher SSO).

Here, we look at how Cipher is about to solve the complexities in roles every time a new set of customers are onboarded.

The improvised journey ….

This is how Theta’s access management would look like on Cipher. For every business unit and functional unit whose access controls need to be assigned together, Theta can create a Sandbox. Within the Sandbox, they can further create object types or actions and assign specific roles to people. And, this doesn’t stop here! Customers too can create a Sandbox to manage employees (like Sodexo).

Here is a list of Pros and Cons of doing authorization and access control through the Cipher Model.

Pros

  • Managing roles is isolated within a container.
  • Apps/Products need not be re-written with growth in every new dimension.
  • Flexibility to design authorization and access control in isolations.

Cons

  • Relatively higher learning curve.
  • Not suitable for simple AAAC situations (ex: Theta in Series A and B times).
  • “Roles bloat” is possible if the sandbox is not used with careful thought.

Sample Use cases used for narration:

  1. HR wants new employees to get access to the payroll system faster as the investment declaration deadline is approaching
  2. IT Security team wants ex-employee access revoked on last day

Use case 2 — Company functions grow

  1. As a small startup grows and hires a Finance Controller, manager wants to ensure only his team can access fin data and not everyone in Tech team

Use case 3 — MNC

  1. India and US admins are able to provision artifacts on their time zones with no need for email/coordination etc

Thank You

Speaker: Bharathi Shekar , Bharathi Shekar

Edited by: Phani Marupaka

Passwords as Second Factor: To mitigate risks of password data compromise

Password based authentication is known to have many weaknesses. The weaknesses are chiefly attributable common human behavior of reusing the same password across services, using passwords that can be easily remembered, etc. There is a lot of advice in information security books on how to safeguard password data so that even if a service is compromised the attacker will not be able to retrieve passwords of its users and then use them elsewhere. Some of the good services follow the textbook advice of using key derivation functions and enforce password complexity. However, for some time now it is known that password complexity and key derivation functions are not sufficient defenses. Large databases of passwords used by users across services are easily available to attackers. This really simplifies the password matching. It is also observed that about 13,000-15,000 patterns represent close to 100% of the passwords used by users. In one of the Fortune 100 companies, 47% of the passwords used matched top 5 patterns. So, system architects cannot assume that:

  1. Users will choose strong passwords
  2. They are immune to password compromises on other sites
  3. If their data is compromised, attackers will not be able to derive user passwords

Therefore, many services started adopting second-factor authentication. This additional factor acts as a defense when user’s password is compromised. However, the attacker will be able to confirm the password of the user before the second-factor kicks in. Also, the second factor does not eliminate or reduce the risks due to compromised data of the service.

At Zeta, we handle very sensitive information for our users. It is crucial to protect access to this information. Given the limitations of passwords discussed above, we realized that we have to go beyond the traditional practices to protect our user data.

It is common to use a one-time token (TOTP, HOTP, SMS/EMAIL OTP) as a second factor after the user is authenticated using a password. We believe OTPs are not widely used as the first factor because:

  1. of the low level of randomness, they offer
  2. people historically used passwords as the first factor and continued with it
  3. it introduces a dependency on additional devices and alternative channels of communication
  4. the potential for abuse of Email/SMS communication by attackers
  5. they are not suitable for use as the only factor of authentication

The advantage of short-lived tokens delivered to phone or Email is that the service will be able to enforce a certain minimum level of randomness. Such tokens are also not vulnerable to compromise of user’s data at other services. Given the ubiquity of SMS-capable mobile phones and accessibility of email on the web, we felt we could rely on SMS and email delivery. Therefore, we devised a mechanism using short-lived OTPs as first factor and relatively static passwords as the second factor.

In our approach, a user is partially authenticated with an OTP. After OTP authentication, we provide a cryptographically secure random salt to the user agent to perform client-side key derivation with the salt and the password provided by the user and use the derived hash as the user’s password on the server. This avoids the inherent weaknesses of the passwords used by users.

[The following content assumes prior knowledge of SHA-256, HMAC, scrypt and ECDSA]

Our Scheme

  1. When a user enters her identity (usually an email address or a phone number) to log in, the user agent generates a public and private key pair using a secure random generator on the device and communicates identity and public key to the server requesting for an authentication session.
  2. After successful initiation of the authentication session, the user is prompted for an OTP delivered to Email/SMS or a TOTP generated using software/hardware token.
  3. When the user provides the OTP, the user agent makes a request to validate this first factor provided by the user. This request for validation is digitally signed using the private key generated in step 1.
  4. On successful verification of the OTP, the first-factor validator sends a signed request to a second-factor validator. This request includes the public key shared by the user agent.
  5. The second factor authenticator passes a user specific 128-bit salt (UserSpecificSalt), to the user agent. The user agent is expected to prompt the user for the password. After accepting the password, user agent generates an HMAC SHA256 of the password using UserSpecificSalt as the key. A validation request is made to second-factor validator with the computed HMAC as the user’s password. [Given that UserSpecificSalt is cryptographically secure, the derived HMAC is also equally random, irrespective of the password used by the user]
  6. The second-factor validator considers the HMAC provided by the client as the user’s secret and performs scrypt using another user specific 256 bit key as salt (ScryptSalt). (The derived hash from the scrpyt is stored and authentication is performed against this has for all requests).
  7. Once authenticated, second-factor validator issues a digitally signed certificate for the public key presented by the user agent in the step-1, associating the public key to the user. The authentication session initiated in step-1 ends. The resultant certificate can be used to establish a data and transaction session.

Note:

  • Salts and keys are generated using the most secure source of random data available in the host environment.
  • UserSpecificSalt, ScryptSalt and the result of scrypt are encrypted using AES 256 and stored in separate data zones.
  • ECDSA with 256-bit private keys is used for all signatures and certificates. The private keys used by first-factor validator and second-factor validator for signing certificates are backed by hardware security modules.
  • Password check attempts of a user are rate limited to 5 in a window of 5 hours.
  • TLS 1.2 with Diffie-Hellman is used for data exchange between all entities involved.

Summary

The above scheme ensures that:

  1. A reusable/static password cannot be used directly on Zeta to verify if it is the user’s chosen password.
  2. Irrespective of the complexity of the password chosen by the user, the password used for authentication at the server is cryptographically secure.
  3. Zeta servers never see the password of the user.
  4. No information stored on any of the data centers is sufficient to arrive at the user’s passphrase or to impersonate the user.
  5. Compromise of all data from all servers is also insufficient to arrive at user’s chosen password.

As with almost all client-server authentication schemes, a compromised or non-compliant user agent or a compromised network will make the scheme vulnerable to a variety of threats. However, the impact of any such exploit will be limited to the user accessing the systems from such compromised environment.

 

Please share your comments on our approach.

 

SecureShield: Campaign for Secure Transactions

As Indians, we are desensitized to certain social evils. Corruption. Dowry. Black Money. We see them often, and yet we may not really process them, until they injure us or our loved ones directly. I feel there’s another social evil, one that’s heavily hushed and downplayed by the industry and media: terrible practices in electronic payment security.

When I talk about this to my friends who use cards, I see the same level of indifference one might see about corruption. But once in awhile, I talk to someone who had to request a chargeback. Their story, of course, is very different. They quickly relate the pain of investigative questions that they were subjected to and the countless, diligent follow-ups they had to make before the money reappeared in their account. And it is far worse if they’d been travelling or if that was the only money they had.

At Zeta, we take security very seriously. We don’t allow users to add money to their Zeta account without a second-factor authentication (usually, OTP sent by the user’s bank like ICICI or SBI). And yet, every day, we get half a dozen messages from our users telling us that someone cheated them of their PIN, OTP and card details, charged their cards and added funds to some Zeta account. We process dozens of chargeback requests a day.

Honestly, far more people pay using cards than the number of people who use Zeta. If we see so many cases of card payment fraud on a daily basis, we can only imagine how many people lose money every day because of this.

In my previous post on payment security, I have described in detail card payment insecurities and how the prevailing practices are fundamentally flawed. For example, it is not uncommon for banks to say the following:

campaign_for_secure_transactions_-_google_docs

But every user knows that they cannot do a card transaction online or at a store without giving the card or card information to the merchant. The user has limited control over where he is entering the PIN, OTP or other details.

This must change. By default, users should have secure transactions. Nothing that the user is asked to share should make him vulnerable to fraud.

We built Zeta Super Card with this fundamental rule. We have now made it available for everyone.

Zeta Super Card with SecureShield

Zeta Super Card is a prepaid card that you can load at your will. It is available in digital form the moment you install our Android or iOS apps. You can request for a plastic card on our website or through our apps. You can use this card online for eCommerce transactions or at any stores with a swipe machine that accepts MasterCard. Although it can work at any card accepting merchant as any normal debit or credit card, it is the SecureShield feature of the Super Card that makes it incomparably more secure than traditional magnetic stripe or chip cards with PIN.


 

turn-off

With SecureShield we have brought security into your hands and delivered unprecedented controls that prevent card frauds without compromising your convenience. It acts like a remote control for your card.You can turn your cards on and off anytime. When the card is off, no transactions will go through! You can turn it on whenever you want to pay.

superpin

SuperPIN

You can use dynamic SuperPIN in place of traditional 4 digit PINs. This ensures that even if the waiter at the restaurant speaks/shouts out your PIN or a CCTV camera watched you enter the PIN, you needn’t be worried. SuperPIN is valid only for 2 minutes and exactly for one transaction. SuperPIN will be available on your phone even when you are offline. You can safely transact any time at all shops that accept cards.

 

settingssecureshield_1

LocationShield

With LocationShield on, you can be sure that no fraudster can transact using your card details even if you inadvertently shared them over phone or email. The system will allow transaction only from machines close to you. If you are in Bangalore and if a fraudster in Mumbai gets your card details and OTP or PIN, he will still not be able to transact using them unless he is also in Bangalore. Irrespective of whether the fraudster is trying to do an e-commerce transaction or doing a transaction with skimmed card on a POS terminal, the transaction will be rejected and you will be notified!

Swipe2Pay

If you transact on ecommerce sites, you would be happy to know that you need not wait for OTP and enter your passwords. By now, you might know the vulnerabilities in that process. With Swipe2Pay, you just need to swipe on the secure dialog presented by Zeta on your phone to complete ecommerce transactions. It is fast, convenient and insanely secure.

Traditional PIN

If you still want to use a traditional 4 digit PIN, you can do so with an increased level of security offered by quick and instant PIN change mechanism available in your app.

 

secureshieldTracking Score

The SecureSheild also keeps track of the security strength of your settings. You can tweak them as you like and know how secure your card is, at any point in time.

Some of these security features are firsts of their kind in the world. But more importantly, they are made to be friendly and easy-to-use, not only for people like our friends but for people like our parents and grandparents, who are not technically inclined.

You must start using Zeta Super Card over any other card if you care for the safety of your funds. You should also give it to your mom, dad, grandparents or anyone else whose financial security you care about. Get your cards today!

Join the campaign of secure electronic transactions! #SecurityFirst @ZetaIndia

Today, Payments are generally insecure

Have you ever been asked by a waiter at a restaurant for your card PIN? Has he ever written it down on a piece of paper? Have you ever noticed a CCTV camera watching you enter the PIN at a shop? Have you ever used an app to buy something, and got redirected to your bank’s web page to enter the PIN? Have you ever given permission to an app to read all your SMS messages, some of which may contain payment OTPs? 

By now, you might have guessed that your PIN and OTPs are easily compromised.

The many technological advancements since the time card based payment systems were introduced have made the systems defenseless. Fundamentally, card based systems require every machine and all intermediaries involved in the transaction to be secure. There are way too many of those machines and intermediaries across the world to ascertain security of them. Many people who use those machines, like merchants, have little idea about their role in securing the entire system. Any breach at any one machine can cause unrecoverable damage to several users. The card details once captured can be reused several times for many transactions.

To overcome some of the limitations of the payment cards, a PIN is mandated for every transaction. A 4 digit PIN offers protection against many trivial threats. But given the reusable nature of the PIN and also the poor choice of PIN made by users, it is not a strong enough defense.

It is hard for the user to know if the card machine at a retail store or the ATM on which she is entering the PIN is tampered with. Banks providing these machines can’t practically keep a watch, as several machines are deployed in unmonitored physical environments.

In case of personal devices like phones, users will have far better visibility and control on tampering. However, most of these devices and the software that’s running on them are also vulnerable to a range of threats. Android users can easily notice that many programs can read the SMS messages on their phone. These programs can also export the OTPs in messages to a fraudster’s machine without user’s knowledge. Also, almost all mobile apps that accept card and netbanking payments can read and store the passwords, OTPs and PINs entered by the user. It may appear to the user that she is entering the PIN on the bank’s payment page. It is nearly impossible for the user to know if her password or PIN is captured and stored by the app.

It is not easy to trace the fraud back to the fraudulent app or merchant. The information captured by one app can be used by anyone from anywhere in the world. If one ATM is compromised, the cards used on that machine can be replicated and used on any other ATM. These vulnerabilities are just the low hanging targets for a fraudster.

To overcome vulnerabilities in operating systems, applications, hardware components and to defend against powerful machines and programs that can exploit the minutest of the vulnerabilities, it is essential to make security a foundational aspect of the system. The payment system providers should be fanatic about security.

Secure Foundation for a Modern Payment System

When we started work on Zeta in April 2015, we had the opportunity to consider a great expanse of devices and applications the modern connected world is currently using and is likely to use. We studied the state of the art secure protocols, services and algorithms and designed several core components of our payment system quite differently from that of legacy bank or card systems. We spent the first 3 months of our time in arriving at a secure architecture at the core. We used asymmetric encryption and signature algorithms to defend our systems against large scale fraud.

We arrived at the following ground rules to secure transactions against many of today’s threats:

  • 3rd party devices: System should not rely on any non-personal devices of the user for transaction security. The card reading machines, POS machines, ATMs or any other machines that don’t belong to either the transacting user or zeta should be assumed as vulnerable.
  • User provided data: Users are prone to use easily retrievable personal data for passwords, pins or for such other key material. System should not solely rely on such information to secure transactions.
  • Data Persistence and Transmission: Every transaction must require information that is never persisted on any device involved in the transaction. Information transmitted for a transaction should not be reusable to do any other transaction.
  • Visible Information: If information is visible to user, we assume that it can be shared or can be stolen through techniques like social engineering. No data the user may be able to share during the course of a transaction or otherwise should be sufficient to do a new transaction.
  • Data Location: No amount of data at rest on any one machine, or if possible in any one location (data center), should be sufficient to complete a transaction
  • Hardware Security Modules: Always use hardware security modules to secure the key material. On users’ devices that don’t support access to secure elements, use encrypted stores for key material.
  • Channel Sensitivity: System should strive to use the highest entropy algorithms and keys suitable for each transaction channel.

These rules guide the protocols and algorithms we use on Zeta. They influence many user interactions on our mobile and web applications as well.

Securing Card Payments

We provide Super Cards to many of our users. These are traditional plastic cards with magnetic stripe, provided to make payments to millions of card accepting merchants. This is our approach to make Zeta backward compatible with the present day payment systems. However, we didn’t want to limit ourselves to the insecure practices widely prevalent across industry. Using the ground rules discussed, we have adopted a different security model for Super Card transactions.

In-Store Payments


img_20161023_113108_664

Dynamic OTP on the phone can be used as PIN

When a user transacts using his Super Card at a retail store, instead of a 4 digit static PIN, she can use the dynamically generated Zeta Code as her PIN. Using the Zeta Code ensures that even if the card reading machine or any of the intermediaries are compromised, no fraudulent party can make use of the PIN for another transaction.  

Online Payments


Zeta SecureCode Page    img_20161023_114134_700

User need not enter OTP for online payments

When a user starts a payment on an ecommerce website, she will be greeted by our custom SecureCode* page. Parallely, she is prompted with a dialog on her phone with an option to ‘swipe to pay’. If the user wants to confirm the payment, she swipes the slider on the screen and enters her PIN through a custom secure keyboard provided on the phone.  The payment page on the browser proceeds to the merchant website with payment success. The user wouldn’t have entered any input on the SecureCode page in the browser. As the user need not read and enter the input, we can now use significantly more secure algorithms like digital signatures to represent authorisation for the payment. This approach also offers a better user experience and quicker payment completion.

If the user is offline on her phone when she is on our SecureCode page, she can generate a Zeta Code on her phone and enter that on the SecureCode page. Each such 9 digit Zeta Code is valid only for 2 minutes. This eliminates the need for static passwords, PINs and SMS messages and thus their vulnerabilities.

Security in Mobile App Interactions

We believe relying on user’s personal device is better for security than relying on any 3rd-party device.  However, it is important to defend the information on the device not only against the possible loopholes of the hardware and the software, but also from the user’s ignorance. Failing to do so could allow for exploits in the form of malware and social engineering.

Therefore, when defining the security model of Zeta apps we assumed that on users’ phones:

  1. Keyboards are compromised
  2. SMSes are compromised
  3. Data at rest is vulnerable
    (Even though stored in application specific stored provided by OS)
  4. Text labels on the screen are compromised

We built a model that can maintain security and integrity of the transaction against such compromised components. A specific example is the Zeta code that is generated on phone to make a payment.


img_20161023_120833_837     img_20161023_121133_893

  1. To generate a Zeta code, user has to press and hold on an area on the screen until a ring is fully drawn.
  2. When the device is online, the code is generated against a digitally signed request from the user. We use ECDSA to achieve reliable encryption strength.
  3. The private keys used for signing the code generation request are encrypted and stored on disk. On phones that don’t have a secure element backed user authentication mechanism, the encryption key is derived from user’s PIN. On phones that have a secure element on, the keys are generated using high entropy sources available on phone and are stored in a secure element backed storage+.
  4. When we ask for PIN, we take user input through a custom keyboard that obfuscates every key press. The labels of the on-screen keyboard do not represent the actual data captured on each key press. Thus, the PIN of the user is virtually never captured in the form user remembers or reproduces it. Also, the derived input from those key presses never leaves the phone. 
  5. Once the code is fetched from the server, although the code appears like text, it is rendered on screen as an image. No malware or screen reader in the device will be able to trivially parse the text on the screen. 

Summing up the Card Payment Security

We must acknowledge that the card based payments can be made significantly more secure than how they currently are. MasterCard, Visa and Rupay have provisions for better security, but many of the prevailing implementations do not make good use of these provisions. We hope all of the industry players will adopt more secure options in the wake of the recently observed 3.2 million debit card compromise.

Although the recent breach is related to in-store and ATM transactions, we also hope that it serves as a wake-up call to reconsider some of the insecure practices related to online card payments as well.

We must constantly strive to earn the confidence that our users place in us. In the payment industry, it is extremely hard to win back a user’s trust after it is lost. We at Zeta will be happy to help everyone in the industry in this endless and rewarding journey of building and running secure payment systems.

* SecureCode is a trademark of MasterCard.
+ Our Android/Windows apps currently do not recognise secure element. The data is protected using keys derived from user’s PIN.

Trusted Contacts

Protecting access to sensitive information and providing strong authentication for all financial transactions is expected of any financial app. However the hardware limitations, platform semantics and the lack of knowledge of most users make the hard problem of securing access harder.

Authentication is usually done based on either what user knows (password, PIN, etc.), what user has (token, chip card, etc.), or what user is (biometric data). The password based model that is still being used by many financial apps and services is fraught with security vulnerabilities. Services often rely on additional, second factor authentication in the form of a one time password (OTP) sent through SMS. This model is reasonably secure in the desktop browser world, but it is broken in the android world, since most apps and most human attackers can access the data stored on an Android device, such as the SMS messages.

We believe that the password model, the OTP model and models that combined the two are unreliable for a financial application. Biometrics based approaches are impractical for a large number of Android users. We couldn’t always rely on what user knows, as it was impractical to expect all the users to be cautious in both specifying what they know and to not share the same information with others. We brainstormed a few approaches that rely on what user has and what user is. Trusted Contacts is one such model that relies on both what user has and what user is in an interesting and simple way.

Trusted Contacts relies on humans as the challengers and the verifiers of identity. Humans naturally use biometrics and other ambient signals to authenticate people in everyday interactions. This process is too complex for a machine to emulate and is practically infeasible. With Trusted Contacts, we wanted to rely on this natural power of humans and convert the result of such authentication to a value which is easily representable, transmittable and has sufficient entropy. Such a value, can then be presented to the system and be used for authentication by the user who was challenged.
A user first sets up his Trusted Contacts by nominating a set of at least 3 contacts identified by their mobile numbers. The nominated contacts need not be users of our system. The contacts are informed about their nomination and their role in securing the user’s account. They are told that when the user attempts to re-login from a clean state they will receive a code from Zeta. The contacts are requested to ascertain the identity of the user before they share the code they received.

Select a subset of contacts you Trust to Setup "Trusted Contacts"

When an existing user attempts to login, he is challenged with OTP based first factor. After successful authentication with an OTP, if the user has his Trusted Contacts setup, he is challenged to provide authentication codes from at least 2 of the nominated contacts. The User indicates the contacts he would like to rely on in this particular instance. Zeta sends codes to those contacts along with a brief reminder about their role in this exercise. The user is expected to get in touch with his trusted contacts and receive the codes. If the user provides the right codes, he is given access to his account with Zeta.

Select the Trusted Contacts to authenticate with Enter code given by Trusted Contacts to complete authentication

During authentication, the interaction between User and his contacts is unknown to the system. The system does not provide any hints other than the name (and possibly a picture, in the future) of the contact as known to Zeta, on how to contact and/or how to establish identity. Authentication codes are securely generated 4 digit random numbers and are specific to the current authentication session of the user. As of now, the authentication codes are sent to contacts by SMS. If the contact is a Zeta user as well, we intend to use secure channels to communicate authentication codes. We intend to provide hints to the contacts on how they could challenge the user, so that they are alerted to the sensitivity of the role and can fulfil it meaningfully.

If the contacts play their role reasonably well, we believe this model will be highly reliable. Given the required human interaction involved, it will also be a very unattractive target for computerised attacks. While the contacts are also likely to have Android phones, we have tried our best to make the auth code SMS messages not usable by malware and spyware.

The success of this feature and thereby the reliability of the security it can offer hinges a good deal on the user education and the overall user experience. We have done several iterations to arrive at the current interactions. We do believe that there is a lot of room for improvement in the overall Trusted Contacts experience. However, we think it is sufficiently ready for initial adopters and to gather feedback. We would love to hear what you think!
NOTE: Trusted Contacts in isolation is not sufficient security measure or a complete authentication approach. This is only one of the elements of a more elaborate system and application security model and relies quite heavily on other modules of the model to provide the security we rely upon.