Secure Mobile Signature Service Platform

The MSSP standards were originally defined at ETSI at the beginning of this millennium. One of the MSSP design key objectives was a secure system by design. This blog unwraps those underlying design principles.

General security principles such as confidentiality, integrity, and availability do not change over application area. These principles have been described in the OWASP Development Guide. Therefore, we have used these security principles in this blog.

Design decisions should be practical and easy to understand. However, we should question and strengthen the security design continuously. For example, it’s a good practice to implement data validation to include a validation routine for all forms of input and service access. However, it is more advanced to see data validation at each tier for any input, joined with appropriate error handling and access control based on demand.

Asset Classification

To be able to protect a sensitive data it must be classified. The security controls are based on this classification. The key security assets in the MSSP solution have been divided into four groups:

1. Mobile user assets
   1. Mobile user identity attributes
   2. SIM card access credentials (SIM card’s SSD OTA keys and counters)
   3. WPKI protocol credentials (Alauda encryption keys and counters)
   4. Mobile user logs
2. Registration and validation controls assets
   1. Resource access credentials (CA, etc.)
   2. Identity validation registers etc.
   3. Registration logs
3. Application Provider access assets
   1. AP access credentials
   2. AP access logs
4. System credentials
   1. Remote system credentials (DB passwords, CA connection credentials)
   2. Local identity (TLS credentials (server/client) and MSSP identity credentials

Especially logs are often forgotten from the classification.

Attackers

When we design controls to prevent the MSSP service abuse, we try to identify the most likely attackers:

1. Fraudulent staff or developers,
2. Random attacks, such as side effects of bugs or viruses, worms or Trojan attacks,
3. Motivated criminal attackers,
4. Criminal attackers without motive against the service, such as occasional offenders, etc.

Security Architecture

The architects of the original MSSP standards at ETSI have constructed an MSSP design to adequately cover risks from both typical usage, and from extreme attack. The MSSP solution vendors are responsible to implement their solutions utilizing these principles and other relevant security principles.

The MSSP security architecture refers to the following fundamental pillars:

The MSSP must provide controls to protect the confidentiality of information, integrity of data, and provide access to the data when it is required (availability) – and only to the right users.

All provided services need to be considered from a security point of view:

• Are the feature requirements safe?
• Can some process have an unknown attack surface?
• Could the process leak information?
• If there were an adversary, how would it abuse this feature?
• Is the feature required to be enabled by default? If so, are there limits or options that could help reduce the risk from this feature?

The MSSP system architecture design shall provide security considerations in each and every new feature, how the risks are going to be mitigated, and what was actually done during implementation or deployment.

Security architecture starts on the day the business requirements are modeled, and never finishes until the last copy of your application is decommissioned. Security is a continuous integration process, not a one-shot task.

MSSP security principles

The MSSP security relies on the following general information security core principles:

1. Confidentiality – Allow access only to data the user is permitted.
2. Integrity – Ensure data is not altered by unauthorized users.
3. Availability – Ensure services are available to authorized users on demand.

The following MSSP security principles are derived from these three core principles.

1. Principle of minimal attack surface

The aim for MSSP security is to reduce the overall risk by reducing the attack surface area. Therefore,

• AE MSSP provides only an AP access to the service, the AP needs to use mutual TLS encryption and only well-defined messages are permitted. All other traffic including wireless, registration and certification services are handled elsewhere.
• ME MSSP takes care of administration and registration. For example, intrusion detection is easier when there is no high volume signature request traffic in the same server. Only standard SOAP traffic protected with TLS is allowed between MSSPs. Special VPN connections and security controls can be added when there is no high service load at the ME servers.
• HomeMSSP holds the key security assets. Therefore, the HomeMSSP locates in the high-secure zone. All access from APs to the HomeMSSP comes over TLS secured SOAP messages via AEs.

2. Principle of secure defaults

MSSP solution itself contains extensive security mechanisms for initialization and administration of user security. There are no defaults for a user. Signature based authentication, certificate based identity management, revocation procedures, and validation interfaces provide the basis for the security.

All default credentials can be easily detected and altered at the MSSP solution at installation time. Additionally, the MSSP solution provides excellent tools to protect all application credentials against accidental disclosure or hostile out digging.

3. Principle of least privilege

The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions.

For example, if a middleware server only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the middleware be granted administrative privileges.

The overall MSSP solution architecture follows the principle of least privilege which requires that every module (such as a process, a user, or a program) must be able to access only the information and resources that are necessary for its legitimate purpose.

4. Principle of defense in depth

Defense in depth is an information security principle in which multiple layers of security controls are placed throughout the MSSP system. The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.

In the MSSP system, this principle takes the form of system splitting between AE, ME and HMSSP. Each MSSP implements its own security controls and only controlled messages flow through the system.

5. Principle of fail securely

MSSP may fail to process transactions for many reasons. At the same time service should be user-friendly and secure. In many cases, the service tries to be extensively helpful and allow user mistakes as long as possible. Alternatively, the service could fail in every circumstance when some detail did not match.

The MSSP solution tries to implement high-security service with an excellent user experience. Therefore, the fail management has used the following principles:

1. Create intuitive and simple user interface – minimize places for user errors.
2. Define detailed service interface for the AP – minimize misunderstandings
3. Prepare detailed failure logging – disclose only relevant parts to outsiders
4. Make failures monitorable – monitor failures as well as normal usage

6. Principle of don’t trust services

Many MSSP deployments need to utilize the processing capabilities of third party partners like CA or Registration Agents, who may have differing security policies and posture than the MSSP operator. It is unlikely that the MSSP can influence or control any of these third parties.

Therefore, MSSP does not provide an implicit trust to any external systems. All external systems are treated in a similar fashion.

7. Principle of separation of duties

A key fraud control is separation of duties. For example, if the AP can send signature requests to the AE MSSP it cannot also send requests directly also to the HMSSP. This prevents the AP from requesting many MSSP simultaneously and claiming some requests never succeeded.

Certain AP roles like RA and CA have different levels of trust than normal Application Providers. In particular, AP accounts used for the service administration are different to normal APs. In general, normal APs do not have the same roles as any administrator.

8. Principle of avoid security by obscurity

Security through obscurity is a weak security control, and nearly always fail when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.

All MSSP interfaces are based on open standards and interfaces are well documented. No obscurity is used for any functionality. For example, the MSSP security does not rely upon knowledge of the source code or the specification being kept secret.

A practical example is Linux. Linux’s source code is widely available, and yet when properly secured, Linux is a hardy, secure and robust operating system.

10. Principle of keep security simple

Attack surface area and simplicity go hand in hand. MSSP developers have avoided the use of complex software architectures when a simpler approach or a design pattern is available.

For example, although it might be fashionable to use Java Enterprise Edition for business logic implementation, Java EE has been discarded in the Kiuru MSSP because it adds software complexity and opens unknown number of new attack surfaces for attackers.

11. Principle of fix security issues properly

Once a security flaw has been identified, it is important to understand the root cause of the issue and to prepare a test for the issue. When some specific design pattern has been used, it is likely that the same security issue is spread among all code base. The right software resolution, which does not a return to a former or less developed state, is needed.

In the Kiuru MSSP development process this means three things:

1. Kiuru MSSP development uses Continuous Integration development practices. Each security fix check-in is verified by an automated building engine in several software branches, and several different test sets are executed automatically and reported to a developer multiple times per day.
2. All changes are logged into a revision control system. Any change can be tracked afterwards. If the fix has been applied multiple times, all those fixed instances can be located.
3. Additionally, software vendors should refrain from ad-hoc changes during software maintenance, especially during night time or weekends. Therefore, it is essential to have proper built-in controlling mechanisms in the software. In the Kiuru MSSP, we use a built-in scripting language for security controls and temporary workarounds.

Written and Edited by: Jarmo Miettinen