Usuário com melhor resposta
Protegendo DLLs

Pergunta
-
Pessoal,
Alguém sabe a técnica de proteger uma DLL contra uso indevido?
Encontrei várias dicas na WEB utilizando CAS - Code Access Security, utilizando chave prublica/privada para assinar e proteger DLLs.
Porém, TODOS os exemplos que encontrei são incompletos e a maioria não funciona, pois falta sempre alguma coisa q não sei o que é. E tem mais um agravante, os exemplos na maioria é para VS2003 e não para VS2005 que aparentemente é diferente.
Como não tenho conhecimento prévio do assunto não consigo decifrar o que é preciso fazer.
Pois bem, vamos ao resumo do que consegui até o momento, espero que alguém que entenda do assunto possa me ajudar, e desde de já agradeço.
--> Meu objetivo:
Proteger minhas DLLs pra evitar que outras pessoas não autorizadas possam utiliza-las.
--> Método para proteger:
Assinar minhas DLLs e meus aplicativos com um conjunto de chaves publica/privada. Desta forma, eu posso chamar minhas DLLs sem restrições, mas, caso alguém queira utilizar minhas DLLs terá de ter um aplicativo (chamador) assinado com minha chave, que não vou passar claro ;-)
--> Procedimento
1. Criar um conjunto de chaves utilizando o seguinte comando do prompt do VS:
** Este passo funciona.
sn - k chave.snk
2. Assinar minha aplicação e DLL adicionando o seguinte item ao assemblyInfo.vb da aplicação e da DLL :
** Este passo funciona
<assembly:Assemblykeyfile("c:\projeto\chave.snk")>
3. Descobrir a chave publica contida no arquivo chave.snk:
** Aqui aparece um problema, toda documentação que encontrei informa que devo usar o comando "sn -tp chave.snk" para visualizar a chave pública, porém este comando dá o seguinte erro "Failed to convert key to token". Em um forum americano encontrei uma solução e foi a que adotei, e devo fazer em 2 comandos:
sn -p chave.snk chavepub.snk
sn -tp chavepub.snk
O resultado é algo deste tipo:
Public key is
00240000048000009400000006020000002400005253413100040000010001002d84fd878122c7
b01191c83c6b35aa12a729989cfb3054d1cc08fd7a8b60b650ba35008048a6f4da014ccc54583a
9f71cc32a44cb8321fa8b0ebf55e988dcea8f089bc6425949a154612a0e71cae2d78df7de66e3d
9d53c6cfa0c84dc8a0767aee142a9f752bd34274d5c0409c8975fceba2664df5dab01c9dd485b0
7f0ede9fPublic key token is dea3e7825a88aa9f
4. Inserir nas classes da DLL um atributo que cause restrição desejada:
<System.Security.Permissions.StrongNameIdentityPermission(Security.Permissions.SecurityAction.LinkDemand, PublicKey:= _
"00240000048000009400000006020000002400005253413100040000010001002d84fd878122c7" + _
"b01191c83c6b35aa12a729989cfb3054d1cc08fd7a8b60b650ba35008048a6f4da014ccc54583a" + _
"9f71cc32a44cb8321fa8b0ebf55e988dcea8f089bc6425949a154612a0e71cae2d78df7de66e3d" + _
"9d53c6cfa0c84dc8a0767aee142a9f752bd34274d5c0409c8975fceba2664df5dab01c9dd485b0" + _
"7f0ede9f")> _
Public Class UserControl1
...
5. Fiz tudo isso, mas não funciona.
- Criei uma DLL com um user control dentro. Assinei a DLL com minha chave.snk, coloquei a atributo de restrição na classe que gera o user control (como descrito acima.)
- Criei uma aplicação e assinei com minha chave.snk, chamei a DLL e carreguei o user control sem nenhum problema.
- Criei outra aplicação e não assinei, chamei a DLL e carreguei o user control sem nenhum problema também.
A proteção não funcionou!
6. Alguém, por favor, pode me dizer o fiz de errado?? Ou se está tudo errado??
Desde já agradeço pela ajuda! Obrigado.
Respostas
-
Não confundamos bananas com laranjas.
Dotfuscator embaralha o assembly, mas não modifica seu comportamento em termos de segurança.
"In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. In the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case."
Veja bem, isso tem um motivo: Se você disse que seu assembly é full trust, você está passando por cima de todas as permissões possíveis.
Daí temos duas opções:
1-Tirar o full trust
2-Usar reflection no código e investigar a identidade do assembly que faz a chamada.
;)
Todas as Respostas
-
-
Eu também estou nesse barco !!! Por favor, se alguém encontrar por favor me enviem um e-mail...
biogenoma99@hotmail.comvaleu
-
Podem dar uma olhada.
Acho que é isso que querem.
http://www.remotesoft.com/salamander/obfuscator.html
Abs
Diogo Gomes
-
-
Estou com o mesmo problema.
Até onde sei, o "DOTFUSCATOR" embaralha o código, dificultando a engenharia reversa (me corrijam se estiver errado), mas o que queremos é prevenir o acesso indevido. Não adianta nada o código fonte estar protegido se qualquer um que conheça os parâmetros pode usar a bilioteca.
Usando o StrongNameIdentityPermission também não adianta, pois qualquer um que tenha acesso "Full Trusted" pode usar a assembly livremente. Pelas minhas pesquisas, o ASP.NET 2.0 simplesmente não permite este tipo de proteção.
Aceito outras sugestões.
-
Não confundamos bananas com laranjas.
Dotfuscator embaralha o assembly, mas não modifica seu comportamento em termos de segurança.
"In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. In the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case."
Veja bem, isso tem um motivo: Se você disse que seu assembly é full trust, você está passando por cima de todas as permissões possíveis.
Daí temos duas opções:
1-Tirar o full trust
2-Usar reflection no código e investigar a identidade do assembly que faz a chamada.
;)
-
Caro Mateus,
Obrigado pela resposta e atenção. E desculpe pelo desabafo a seguir.
Mas eu desisti de proteger meus projetos simplesmente pela extrema falta de documentação e suporte em relação a esse assunto.
Esse assunto sobre 'como proteger DLLs' eu encontro em dezenas de fóruns e NUNCA encontrei uma resposta realmente funcional. Só existe teoria e NENHUM exemplo prático. Parece tabu falar sobre proteção, pois até hoje ninguém foi capaz de dar um exemplo de como isso funciona...
Enfim estou aqui de volta a esse assunto, pois o que eu temia aconteceu! Estão usando minhas DLLs sem minha permissão.
Peço, por gentileza, que me de as dicas para conseguir proteger uma DLL contra o uso não autorizado.
(Utilizo VB 2005)
Vamos as dúvidas:
- Você fala em tirar o 'full trust', mas eu não consegui achar onde fazer isso. O único lugar que encontrei essa opção é na configuração de segurança do Click-Once, mas eu não estou utilizando Click-Once. Tem outro lugar?
- Usar reflection e investigar a identidade... como faço isso?
Desde já agradeço pela ajuda.
Caso você conheça algum livro ou site que tenha um 'passo-passo' (que funcione
)de como implementar esse tipo de segurança, ficaria muito agradecido pela dica.
Grato.
-
Fulltrust é uma configuração na sua máquina. Ferramentas adminstrativas, .Net Framework Configuration, my computer, runtime security policy. Por default, tudo que roda local tem full trust a menos que você mude.
Para saber quem chamou seu assembly você pode fazer assim:
System.Reflection.
Assembly.GetCallingAssembly().FullNameOu você pode pegar assim, se quiser saber qual o executável que começou toda a conversa até chegar no seu assembly:
System.Reflection.
Assembly.GetEntryAssembly().FullNamePor esse caminho você pode pegar o nome do assembly, sua chave, versão e até saber em que diretório ele está rodando.
Livro passo a passo eu não sei te falar, mas tem alguns cursos Microsoft interessantes nessa parte de segurança de aplicações...
-
Muito obrigado Mateus pela resposta.
Vou fazer alguns testes com suas dicas, e agora que algumas coisas ficaram mais claras vai ficar mais fácil procurar documentação a respeito.
Vou tb entrar em contato com a MS para ver que tipo de curso é mais interessante sobre esse assunto.
Valeu! ;-)
-
Galera,
Existe um livro que trata somento de segurança de DLL's, o nome desse livro é Programming .NET Security.
Segue algumas partes do índice do livro:
Part I: Fundamentals
Chapter 1. Security Fundamentals
Section 1.1. The Need for Security
Section 1.2. Roles in Security
Section 1.3. Understanding Software Security
Section 1.4. End-to-End SecurityChapter 2. Assemblies
Section 2.1. Assemblies Explained
Section 2.2. Creating Assemblies
Section 2.3. Shared Assemblies
Section 2.4. Strong Names
Section 2.5. Publisher Certificates
Section 2.6. Decompiling ExplainedChapter 3. Application Domains
Section 3.1. Application Domains ExplainedChapter 4. The Lifetime of a Secure Application
Section 4.1. Designing a Secure .NET Application
Section 4.2. Developing a Secure .NET Application
Section 4.3. Security Testing a .NET Application
Section 4.4. Deploying a .NET Application
Section 4.5. Executing a .NET Application
Section 4.6. Monitoring a .NET ApplicationPart II: .NET Security
Chapter 5. Introduction to Runtime Security
Section 5.1. Runtime Security Explained
Section 5.2. Introducing Role-Based Security
Section 5.3. Introducing Code-Access Security
Section 5.4. Introducing Isolated StorageChapter 6. Evidence and Code Identity
Section 6.1. Evidence Explained
Section 6.2. Programming Evidence
Section 6.3. Extending the .NET Framework
Chapter 7. Permissions
Section 7.1. Permissions Explained
Section 7.2. Programming Code-Access Security
Section 7.3. Extending the .NET Framework
Chapter 8. Security Policy
Section 8.1. Security Policy Explained
Section 8.2. Programming Security Policy
Section 8.3. Extending the .NET FrameworkChapter 9. Administering Code-Access Security
Section 9.1. Default Security Policy
Section 9.2. Inspecting Declarative Security Statements
Section 9.3. Using the .NET Framework Configuration Tool
Section 9.4. Using the Code-Access Security Policy ToolChapter 10. Role-Based Security
Section 10.1. Role-Based Security Explained
Section 10.2. Programming Role-Based SecurityChapter 11. Isolated Storage
Section 11.1. Isolated Storage Explained
Section 11.2. Programming Isolated Storage
Section 11.3. Administering Isolated StoragePart III: .NET Cryptography
Chapter 12. Introduction to Cryptography
Section 12.1. Cryptography Explained
Section 12.2. Cryptography Is Key Management
Section 12.3. Cryptographic AttacksChapter 13. Hashing Algorithms
Section 13.1. Hashing Algorithms Explained
Section 13.2. Programming Hashing Algorithms
Section 13.3. Keyed Hashing Algorithms Explained
Section 13.4. Programming Keyed Hashing Algorithms
Section 13.5. Extending the .NET FrameworkChapter 14. Symmetric Encryption
Section 14.1. Encryption Revisited
Section 14.2. Symmetric Encryption Explained
Section 14.3. Programming Symmetrical Encryption
Section 14.4. Extending the .NET FrameworkChapter 15. Asymmetric Encryption
Section 15.1. Asymmetric Encryption Explained
Section 15.2. Programming Asymmetrical Encryption
Section 15.3. Extending the .NET FrameworkChapter 16. Digital Signatures
Section 16.1. Digital Signatures Explained
Section 16.2. Programming Digital Signatures
Section 16.3. Programming XML Signatures
Section 16.4. Extending the .NET FrameworkChapter 17. Cryptographic Keys
caso alguém queira o PDF do livro pode entrar em contato pelo e-mail leandro_lopez12@yahoo.com.br
Section 17.1. Cryptographic Keys Explained
Section 17.2. Programming Cryptographic Keys
Section 17.3. Extending the .NET Framework
Espero ter ajudado. -
-
-
-
Como o Mateus Veloso falou, os ofuscadores de código fazem com que quando você usa uma ferramenta para descompilar o código, o nome das variaveis fique diferente. Por exemplo se vc usar o .Net reflector, as variaveis vão aparecer como a, b, c, porém isso não garante que eles não vao olhar e copiar o seu código.
Já quando você assina um assembly, e usa apenas assemblies assinados em seu projeto, isso garante que o programa só ira rodar se vc utilizar aquele assembly, com aquela assinatura. Por exemplo se alguma pessoa mal intencionada tentar modificar alguma dll sua, e compilar novamente e jogar no diretorio de sua aplicação, a aplicação vai lançar uma exceção pois a assinatura da dll, não é a mesma. Por isso é muito importante assinar todas as suas dlls do projeto. Você faz isso nas propriedades do projeto, na Aba Signing -> Sign the Assembly, é bem simples de se fazer.
E por terceiro, o Full trust, Medium trust se refere as permissões que o seu programa necessita do sistema operacional, em full trust, significa que o seu programa pode fazer o que quiser. Essas configurações podem mudar de maquina para maquina, pois se vc configurar que apenas assemblies assinados, rodam em Full trust na sua maquina, vc terá que assinar o seu assembly para que ele rode na maquina do cliente.
É mais ou menos isso.
Quem sabe um dia os DataSets se extinguirão?