search

OpenBanking-Brasil / specs-seguranca

Documentação das especificações do GT de Segurança do Open Banking Brasil. As especificações ainda estão em versão draft e não devem ser utilizadas para implementação.
66 stars 46 forks source link

RSA-OAEP-256 vs RSA-OAEP #148

Closed RalphBragg closed 2 years ago

RalphBragg commented 3 years ago

The security profile requires the use of RSA-OAEP as an encryption algorithim. Under the covers this uses SHA1.

Does support for RSA-OAEP-256 want to be phased in?

panva commented 3 years ago

More info

DeiGratia33 commented 3 years ago

I believe for better consistency and more resilience of the ecosystem the profile should encourage the usage of OAEP with SHA256.

I know this could be controversial since we are talking about an encryption property, but inside of the Security Proile for signature there is the usage of PS256(SHA2) and reading the ICP-Brasil Documentation the usage of SHA-1 (Signature) was also removed.

Also important to mention that some libraries could mark it deprecated (if not now, near future?).

Just as references: ICP-Brasil DOC https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-01-v-4-2-padroes-e-algoritmos-criptograficos-da-icp-brasil-copy-pdf

https://datatracker.ietf.org/doc/html/rfc8017#appendix-B.1 "There have also been advances in the cryptanalysis of SHA-1. Particularly, the results of Wang et al. [SHA1CRYPT] (which have been independently verified by M. Cochran in his analysis [COCHRAN]) on using a differential path to find collisions in SHA-1, which conclude that the security strength of the SHA-1 hashing algorithm is significantly reduced. However, this reduction is not significant enough to warrant the removal of SHA-1 from existing applications, but its usage is only recommended for backwards-compatibility reasons."

RalphBragg commented 3 years ago

Extending support to allow Banks to offer 256 in addition to RSA-OAEP would be non breaking but it is a change. I would suggest including this enhancement in Implementers Draft 2 if there is broad support. Migration to 256 would require Banks to support both for a period, give TPPs time to switch and then deprecate support for 256.

This is a good migration exercise for the ecosystem to undertake.

dcreado commented 3 years ago

Both algorithms are semantically secure and are good option for key transport in the context of JWE. From my experience, the masking function with SHA256 might be tricky on legacy systems. Probably defining oaep with sha256 as recommended might be a good option.

TakahikoKawasaki commented 3 years ago

If requirements for encryption algorithms were easily changed like this, it would take time for specifications themselves and implementations to become stable.

"8.6.1. Encryption algorithm considerations" of "FAPI 1.0 Advanced" states as follows.

For JWE, both clients and authorization servers

  1. shall not use the RSA1_5 algorithm.

That is, FAPI 1.0 Advanced allows other encryption algorithms than RSA1_5. However, the OBB FAPI specification imposes a more restrictive requirement which requires RSA-OAEP only.

Considering that the request_object_encryption_alg client metadata is defined in "OpenID Connect Dynamic Client Registration 1.0" as follows,

request_object_encryption_alg

OPTIONAL. JWE [JWE] alg algorithm [JWA] the RP is declaring that it may use for encrypting Request Objects sent to the OP. This parameter SHOULD be included when symmetric encryption will be used, since this signals to the OP that a client_secret value needs to be returned from which the symmetric key will be derived, that might not otherwise be returned. The RP MAY still use other supported encryption algorithms or send unencrypted Request Objects, even when this parameter is present. If both signing and encryption are requested, the Request Object will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that the RP is not declaring whether it might encrypt any Request Objects.

implementations cannot utilize the standard client metadata to meet the OBB requirement. This means that banks and vendors have to customize their implementations to meet the encryption requirement.

If OBB puts restrictions on encryption algorithms and the requirements are different from FAPI 1.0 Advanced, the discussion should be done carefully with deep thoughts. Requirements should not be changed so casually. Otherwise, the requirement on encryption algorithms would impose unnecessary burdens on banks, solution vendors and developers involved, and make the OBB deadlines more difficult to be met by banks.

How did OBB introduce the requirement on encryption algorithms with what reasonings? If OBB does not have strong reasons, OBB should use the same requirement as FAPI 1.0 Advanced and avoid going beyond it.

joaorodolfo commented 2 years ago

Guys, after Phase 2 and Phase 3 started, it wasn't mentioned as an issue from anybody into the ecosystem about this specific point. I believe that all participants have addressed it. We can keep talk OBB improvements, but for the moment, I can't see any problem with it.

pedro-octavio-andrade commented 2 years ago

Item discutido na especificação: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID3-ptbr.md#considera%C3%A7%C3%B5es-de-algoritmo-de-criptografia--cipher