draft: a practical example

[aleeusgr]

list the deliverables from:

• [ ] Part 1: Introduction and general model CC2022PART1R1.pdf
• [ ] Part 2: Security functional requirements CC2022PART2R1.pdf
• [ ] Part 3: Security assurance requirements CC2022PART3R1.pdf
• [ ] Part 4: Framework for the specification of evaluation methods and activities CC2022PART4R1.pdf
• [ ] Part 5: Pre-defined packages of security requirements CC2022PART5R1.pdf

[aleeusgr]

Reviewed artifacts:

- [ ] Guardian-CCS Blockchain Secure Authentication (BSA) [Security Target](https://www.commoncriteriaportal.org/files/epfiles/FNS%20-%20Guardian%20-%20CCS%20Blockchain%20Secure%20Authentication%20(BSA)%20Security%20Target%20-%201.1.pdf) - [ ] 6.3 Security Assurance Requirements - [x] Common Criteria Protection Profile [Cryptographic Service Provider](https://www.commoncriteriaportal.org/files/ppfiles/pp0104b_pdf.pdf) - [x] 3. Security Problem Definition: - [ ] Magic SSO V4.0 [Security Target](https://www.commoncriteriaportal.org/files/epfiles/Magic_SSO_V4.0-ST-v1.4_EN.pdf) - [x] Microsoft SQL Server 2022 Database Engine Enterprise Edition x64 (English), [version 16.0.4025.1 ](https://www.commoncriteriaportal.org/files/epfiles/2022-34_ST.pdf) - [x] CEM - [ ] [Part 2](https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART2R1.pdf) - [ ] [Part 3](https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART3R1.pdf) - [ ] [plutus-use-cases](https://github.com/input-output-hk/plutus-apps/tree/main/plutus-use-cases) for assets and threats. https://github.com/aleeusgr/testing-cardano/issues/1 https://github.com/aleeusgr/stellar-vesting/pull/26

[aleeusgr]

Today I tested a couple of existing projects using psm and nix. Build takes quite a long time and to find something that works seems like a lot of effort.

[aleeusgr]

Many thanks to https://github.com/Ali-Hill for the example repo.

https://github.com/aleeusgr/minimal-ptt-examples

[aleeusgr]

https://github.com/Plutonomicon/plutonomicon

[aleeusgr]

dots and arrows

Security concepts and relationships  Evaluation concepts and relationships    if you are an evaluator, you need to go through all the docs required, link them to the doc produced, evaluate that everything matches, evaluate that nothing is missed. This is why it's easier when you have a PP you can refer to. You just need to take that and ensures that you're compliant. Otherwise you really need to prove that everything has been considered in terms of security. they look like this:  From CEM: 

[aleeusgr]

Thanks for the conversation, @RSoulatIOHK

Reviewing:

• [ ] Guardian-CCS Blockchain Secure Authentication (BSA) Security Target
  • [ ] 6.3 Security Assurance Requirements
• [ ] Common Criteria Protection Profile Cryptographic Service Provider
  • [x] 3. Security Problem Definition:
• [ ] Magic SSO V4.0 Security Target
• [ ] Microsoft SQL Server 2022 Database Engine Enterprise Edition x64 (English), version 16.0.4025.1

[aleeusgr]

• [ ] ToE
  • validator
  • source code
  • PIR
  • UPLC
  • dApp: {validators, transactions, ??}
• [ ] 3. Security Problem Definition:
  • [ ] Threats,
  • ? T.DataCompr Compromise of communication data (Datum?)
  • T.Masqu Masquerade authorized user
  • T.FaUpD Faulty Update Code Package
  • developer makes an error in transaction building which causes unrecoverable funds.
  • [ ] assumptions,
  • secure practices around private keys
  • [ ] assets
  • Value locked at the validator
  • Data in the Datum
  • [ ] security requirements

[RSoulatIOHK]

Just because I was the one that made the mistake during our conversation, I think I should clarify. CEM contains Evaluation methods (hence the acronym) and not requirement templates. Part 2 and Part 3 contains them.

[aleeusgr]

Oh, I missed the indent🤯. Its a separate item, not a subitem of CEM.

Part 2 and 3 can be found here

Details

- [ ] Security Targets in the on-chain certificate - [x] https://www.commoncriteriaportal.org/products/ has a list of all CC certified products, and you can check the Security Targets. So if you want to see concrete Threats, assumptions, assets, security requirements and so on you can go through a few of them - [x] To establish a security target, you want to consider first what you have to protect. So for example in vesting you want to protect the vested funds. But maybe you also want to consider your datum as valuable because people might try to hijack it. Maybe you want to consider some special private keys that have some special permission as valuable. Maybe you have nft that gives some special permission as valuable etc. Once you have that, you can try to define what threats exist against those. It can even be from legitimate users, like your design needs the user to do this specific step in order for the security to be ensured. Well what happens if he doesn’t? But it can obviously also be from attackers. - [x] https://www.youtube.com/watch?v=PSAlyxhaf5c - [x] https://www.youtube.com/watch?v=Png3J4dlQ04&list=WL&index=9 - [ ] Protection Profiles would be so sweet for like "standard" scripts/Dapps such as Swaps, Dex, DAOs, etc - [ ] have a look at CEMs - [x] CEM is a large document that gives a large amount of "standardized" template requirements that you can take from And it is advised to use them, especially if they are relevant to your product. - [ ] security requirement templates. - [ ] https://github.com/input-output-hk/Certification-working-group/pull/34 - [ ] overview of what was verified by the evaluator and certified by the national scheme. - [ ] a document that describes the asssets to be considered for Cardno smart contracts and - [ ] a list of common threats associated https://www.commoncriteriaportal.org/cc/

[aleeusgr]

https://www.youtube.com/watch?v=Png3J4dlQ04&list=WL&index=9

CC is a language for specifying security requirements and a methodology for testing them.

security, but not functions or performance. CCRA 28 countries mutually recognizing certificates.

Scheme of the certificate, protection profile (set of functional requirements)

[aleeusgr]

Consider vesting validator. Our assets is Value: the bag of coins we define in the fund locking transaction. One threat is that the vulnerability where funds become unrecoverable. One implementation of Vesting is to have user pubKeyHash stored in the Datum. This is entail an assumption: users have secure practices around their keys.

[aleeusgr]

EXAMPLE Target of Evaluation TOE: ✅ a list of files in a configuration management system; ❔ — a single master copy that has just been compiled; ✅ the source code for a specific version of an open-source distribution; ❔ a box containing physical media and a manual, ready to be shipped to a customer; ❔ a binary file available for secure download; ❓ an installed and operational version.

[aleeusgr]

attack surface of a validator: X context, ✔️Redeemer, ✔️Datum

What can a hacker study to try and get the valuables locked at the validator?

[aleeusgr]

https://iohk.io/en/blog/posts/2022/01/27/simple-property-based-tests-for-plutus-validators/

[aleeusgr]

to Organisational practices: MSFT SQL.

An assumption could be: a programmer uses a trusted API to access the plutus script.

There was some talking about creating a validator that is a self-contained product: it could be used by different backends..

If a hacker wants cause damage they would build a transaction to steal funds from a validator.

So our level of analysis at this point is transaction building, I think.

Threats exist at multiple levels.

But what about the Redeemer and transaction context?

[aleeusgr]

Could an assumption be: the developer uses a trusted API for building transactions?

[aleeusgr]

An error a programmer could make is to add private information to the Datum. A Datum is public, it offers no cryptographic protection, and can't be used to store secrets.

So a threat would be "a developer can store private information in the Datum"

An assumption we have is that the user follows safe practices for managing secrets: does not lose his private key.

[aleeusgr]

A developer can build their system to meet a specific protection profile. EAL: evaluation assurance level

Details

  

https://www.youtube.com/watch?v=U81_psRHw90

[aleeusgr]

1. Protection Profile is a request for a specific security solution
2. Target of Evaluation is the product
3. Security Target is vendors explanation of: a. Security functionality requirements b. security Assurance requirements
4. Evaluation is testing the product against claimed specifications
5. Evaluation assurance level

[aleeusgr]

🤔

T.Masqu Masquerade authorized users

"A malicous attacker can duplicate an authorization token by doing X and Y when interacting with the product"

[aleeusgr]

• [ ] contract,
• [x] tests,
• [ ] requirements.

example

[aleeusgr]

https://www.youtube.com/watch?v=2Rr-u1iFbhY

[aleeusgr]

Consider which is the project that is related to this ST?

Adderall | Stellar-Vesting.

TODO

[RSoulatIOHK]

It's usually the other way around. You define a ST from an existing product. But as an exercise this could be fine as well.

[aleeusgr]

Ah.

Well, they are both vesting in Helios, but stellar vesting is built on a framework that implements UUT, "thread token" architecture.

The goal of aderall is to give a developer a mental model of eUTXO in code: to empower the developer to experiment with transaction building, dApp architecture and dApp models to understand how to architect a Web3 product.

Helios allows writing both validators and transactions (via blockfrost): the architecture need not contain the node.

So a goal of an audit would be to answer the question "can it be used on mainnet?"

[aleeusgr]

https://github.com/aleeusgr/potential-robot/issues/134