Secure Execution

[rdluffy]

Hello,

I was reading your requirements and i found them quite good.

I m working on contactless payment, for mobile and we have some security requirements that implies that even the execution has to be protected.

In our team we referred that as the confidential execution requirement. Do you think it should appear in your requirements ?

[commjoen]

Hi @rdluffy , what do you mean by confidential/protected execution? Do you mean that it can only run on a protected environment, such as an TEE or something?

[rdluffy]

Hello,

Yes, possible implementations technologies are TEE or WhiteBox cryptography.

[rdluffy]

Hi, yes concerning the implementation i was thinking of whiteboxing or yes the tee.

Le 27 oct. 2016 12:10 PM, "Jeroen Willemsen" notifications@github.com a écrit :

Hi @rdluffy https://github.com/rdluffy , what do you mean by confidential/protected execution? Do you mean that it can only run on a protected environment, such as an TEE or something?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OWASP/owasp-masvs/issues/52#issuecomment-256601895, or mute the thread https://github.com/notifications/unsubscribe-auth/ACL4oODRwT-jCl3pePeCdo94LnSJNyNGks5q4HiogaJpZM4KiJww .

[commjoen]

Maybe we can setup a requirement in architecture, that some components might have to run within a protected area of the device (E.g. not same operating system). @b-mueller what do you think? But I have to say that, in my opinion, it might not be something that is a "standard approach" which one should make obligatory for a large set of apps. One thing I am wondering though: how does whitebox encryption help in hiding the execution? After all, the process is then still in user space right?

[rdluffy]

Good to hear, and of course we have to discuss about it.

First I think it suits best for the "financial & insurrance" threat profile. I guess it can be also applied for the healthcare sector but I m not an expect in it.

In order to convince you, you can look at solutions that are providing HCE payment system; they are using such techniques.

Secondly, concerning the Whitebox itself. I agree that the process is still in the user space. The idea behind that kind of technology is in short that the keys are never in plaintext in memory so that an attacker cannot extract it. In order to be effecient you also have to ensure "device binding" and "anti code lifting" techniques.

[muellerberndt]

Hey guys this is all part of V8 - Resiliency Against Reverse Engineering.

Level 4 is specifically meant for apps that run sensitive functionality that must be isolated from the rest of the OS. At the moment, the requirement is this:

"V8.16: Verify that sensitive computations are obfuscated using advanced methods, and that the obfuscating transformations significantly increase the algorithmic complexity and apparent randomness of the relevant code and/or data."

This requirement will allow for both white-box crypto and other forms of obfuscation being used. I'm currently writing a paper on the exact requirements and how they are to be verified. There will still be some changes to V8 in the coming weeks as I'm working out the details.

If you want to help with the obfuscation assessment part, check out this:

https://github.com/b-mueller/kolmogorov-metric

I'll post some more details on V8 on the Slack channel soon.

[rdluffy]

Hello,

For me Whitebox cryptography is more related to the TEE objectives as stated in [1]. It is a very specific domain that is not using standard obfuscation techniques like control flow,... Plus there is some company that are providing TEE support and Whitebox in case the TEE is not available.

Yes, i would also like to participate to the obfuscation part, i will look into it.

[1] Efficient and Provable White-Box Primitives. Pierre-Alain Fouque and Pierre Karpman and Paul Kirchner and Brice Minaud https://eprint.iacr.org/2016/642

[muellerberndt]

We'll have to make MASVS L4 all about TEE and allow for different obfuscation methods (and define with minimum requirements for the obfuscation parameters) if hardware TEE is not available. Something along the lines:

• Use a cryptographic white-box that satisfies a,b,c,... OR
• use virtualization, with an interpreter of minimum absolute complexity X OR
• use a form of control flow / data obfuscation that satisfies e,f,g,...

This is something where lots of different solutions are available and we should have metrics that are as simple as possible. Agreed that white-box crypto is a special case. Let's work that out together?

[rdluffy]

Good, working together sounds great.

How do you want to proceed ?

[muellerberndt]

Do you have specific experience with white-box crypto? What do you think could be minimum requirements or methods to assess the effectiveness of a white-box? My original hope was that it would be possible to apply the Kolmogorov metric to white-box crypto as well (measure the complexity of the mixing bijections / data lookups used), not sure if that's feasible. Maybe we can extend the "Evaluating Obfuscators" project to include some different approaches? I've got to know some other researchers during the last few months, will ask them to join the project as well. We need to find a definition and testing process for "strong" obuscation first before we have another go at the V8 requirements. Again, here is the link, I can add you as a collaborator if you give me your github ID.

[rdluffy]

In my team we have some experience on Whitebox. Concerning the requirements, it is hard to say; is it proprioritary or not ? DCA, DFA resistant ?

I don't think you can apply kolmogorov metric on it, but it has to be verified.

From an audit point of view, the obfuscation testing is treated as a different part, Whitebox has its own attacks (DCA,DFA, specific cryptanalysis).

And by the way, here is my id 2291872

thx

[muellerberndt]

I made some changes throughout the guide to clarify the role of SE, TEE and software protections. The main difference between L3 and L4 is that in L4, sensitive computation must run in an isolated environment. The L4 requirements are now as follows:

8.15 Verify that the app uses at least two additional, functionally different checks to detect whether it is running in an emulator, and responds appropriately when an emulator is detected.

8.16 Verify that sensitive computations take place in a trusted environment that is isolated from the mobile operating system. Hardware-based SE or TEE should be used whenever available.

8.17 If hardware-based isolation is unavailable, verify that an acceptable form of obfuscation is being used to isolate sensitve data and computations, and verify that the obfuscation parameters result in a sufficient increase in algorithmic complexity of the obfuscated function.

@rdluffy Can you look into the requirements we should add for cryptographic white-boxes. We'll also need a testing process to add to the MSTG!

[muellerberndt]

Hey @rdluffy, the obfuscation metrics project is up. Let's figure out the requirements there - your input on white-box crypto would be helpful!