[python-brasil] Encriptação
rui
Estou precisando encriptar uma mensagem usando uma "chave" e do outro
lado da conexão desencriptá-la com essa mesma chave.
A questão não é comparar "encriptados", mas encriptar o texto e
desencriptar depois.
Alguém poderia me dar uma dica de qual algoritmo usar e tal. Os que
vêm por padrão com a Python não resolveram meu problema.
Abraços
--
Rui
http://ruivaldo.wordpress.com
"Rubi? Aquela novela do SBT?"
~ Carla Perez sobre Ruby
"Em Python, tudo é objeto, além de lindo e maravilhoso."
~ Caetano Veloso sobre Python
,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia: |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
| E se você é usuário do BOL lembre-se de cadastrar o |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/python-brasil/
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Marcos Silva
> Estou precisando encriptar uma mensagem usando uma "chave" e do outro
> lado da conexão desencriptá-la com essa mesma chave.
Tem o PyCrypt - Python Cryptography Toolkit[1]. Nunca usei mas parece ser muito bom.
Logo na home tem os algoritmos do tollkit. Para o que você precisa, AES, Blowfish, etc, vão servir.
Até mais!
Marcos
[1] http://www.amk.ca/python/code/crypto
---------------------------------
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
[As partes desta mensagem que não continham texto foram removidas]
Rodrigo Cacilhas
def cryptFunc(datafile, keyfile, outfile):
ifd = open(datafile, 'r')
kfd = open(keyfile, 'r')
ofd = open(outfile, 'w')
c = ifd.read(1)
while c:
k = kfd.read(1)
if not k:
kfd.seek(0)
k = kfd.read(1)
b = ord(c) ^ ord(k)
ofd.write(chr(b))
c = ifd.read(1)
ifd.close()
kfd.close()
ofd.close()
Sinceramente não testei, mas ideia é essa tanto p/cifrar quanto pra
decifrar: a função recebe o nome do arquivo com a mensagem ou a cifra, o
nome do arquivo com a chave e o nome do arquivo de saída.
A partir dessa ideia dá pra desenvolver uma função que funcione em
memória também, sem arquivo.
[]'s
Cacilhas, La Batalema
Leonardo Santagada
On 26/02/2008, at 12:27, Rodrigo Cacilhas wrote:
> Isso talvez ajude:
> [snip]
>
> Sinceramente não testei, mas ideia é essa tanto p/cifrar quanto pra
> decifrar: a função recebe o nome do arquivo com a mensagem ou a
> cifra, o
> nome do arquivo com a chave e o nome do arquivo de saída.
>
> A partir dessa ideia dá pra desenvolver uma função que funcione em
> memória também, sem arquivo.
Mas isso não é criptografia né? Ou se é por alguma definição, não é
seguro certo?
obs: Alguém q entenda de criptografia pode ajudar, eu estou só
chutando, mas se a chave for completamente randomica e do mesmo
tamanho ou maior do que a mensagem até pode ser seguro por ser
inseparavel... mas eu votaria por usar um algoritmo de criptografia de
verdade
--
Leonardo Santagada
Davi Vercillo C. Garcia
Um algorítimo de criptografia que te ajudaria é a RSA. Ela justamente
usa o lance de chave privada/chave pública. Não sei se existe algum
módulo de Python que implemente RSA pois sou newbe ainda.... =D
2008/2/26 Leonardo Santagada <sant...@gmail.com>:
>
>
>
>
>
>
>
> On 26/02/2008, at 12:27, Rodrigo Cacilhas wrote:
>
> > Isso talvez ajude:
>
> > [snip]
>
>
> >
> > Sinceramente não testei, mas ideia é essa tanto p/cifrar quanto pra
> > decifrar: a função recebe o nome do arquivo com a mensagem ou a
> > cifra, o
> > nome do arquivo com a chave e o nome do arquivo de saída.
> >
> > A partir dessa ideia dá pra desenvolver uma função que funcione em
> > memória também, sem arquivo.
>
> Mas isso não é criptografia né? Ou se é por alguma definição, não é
> seguro certo?
>
> obs: Alguém q entenda de criptografia pode ajudar, eu estou só
> chutando, mas se a chave for completamente randomica e do mesmo
> tamanho ou maior do que a mensagem até pode ser seguro por ser
> inseparavel... mas eu votaria por usar um algoritmo de criptografia de
> verdade
>
> --
> Leonardo Santagada
>
>
--
Atenciosamente,
Davi Vercillo Carneiro Garcia
Universidade Federal do Rio de Janeiro
Departamento de Ciência da Computação
DCC-IM/UFRJ - http://www.dcc.ufrj.br
"Good things come to those who... wait." - Debian Project
Marco André Lopes Mendes
parta do princípio que você vai usar um algoritmo conhecido, seja de
criptografia, simétrica, de chave pública, resumo de mensagem ou o que
quer que seja. Criar algo novo é inviável.
Um abraço
Marco André
2008/2/26 Davi Vercillo C. Garcia <davive...@gmail.com>:
--
Marco André
marco...@gmail.com
Luciano Ramalho
Para criptografar mesmo, de modo que um script kiddie entediado não
seja capaz de decifrar, é preciso usar algum algoritmo que já tenha
passado pelo crivo de criptógrafos famosos, e se você não for um
criptógrafo famoso não vai conseguir que outros criptógrafos famosos
analisem o seu algoritmo.
Qualquer algoritmo seguro hoje é um algoritmo famoso porque já foi
amplamente estudao, como IDEA, Blowfish, DES, RC4, RC5 etc. A única
exceção são os algoritmos secretos usados pela NSA, Mossad, FSB, MI-6
e tal, mas estes você não vai encontrar por aí dando sopa.
Se o objetivo é apenas ofuscar, o algoritmo que você sugeriu é tão bom
quanto o ROT-13. Outra alternativa para ofuscar é zipar os dados.
[ ]s
Luciano
2008/2/26 Rodrigo Cacilhas <caci...@maisideias.com.br>:
Luciano Ramalho
> Estou precisando encriptar uma mensagem usando uma "chave" e do outro
> lado da conexão desencriptá-la com essa mesma chave.
> A questão não é comparar "encriptados", mas encriptar o texto e
> desencriptar depois.
Você precisa de um algoritmo criptográfico simétrico. Como bem disse o
Marco André, é inviável inventar um, e é uma péssima idéia usar um
algortimo criptográfico desconhecido, porque ele provavelmente será
tosco e inseguro. Leia sobre algoritmos criptográficos simétricos na
Wikipedia, e escolha um bem famoso, de preferência um implementado
pelo PyCrypt, conforme a dica do Marcos Silva, que até já deu dois
nomes: AES e Blowfish.
[1] http://www.amk.ca/python/code/crypto
[ ]s
Luciano
Marcel Serour
2008/2/26 Davi Vercillo C. Garcia <davive...@gmail.com>:
> Fala cara,
>
> Um algorítimo de criptografia que te ajudaria é a RSA. Ela justamente
> usa o lance de chave privada/chave pública. Não sei se existe algum
> módulo de Python que implemente RSA pois sou newbe ainda.... =D
>
> 2008/2/26 Leonardo Santagada <sant...@gmail.com <santagada%40gmail.com>
[As partes desta mensagem que não continham texto foram removidas]
,-----------------------------------------------------------.
rui
O problema era encriptar esse arquivo para um formato que pudesse ser
distribuído como arquivo .lic.
Consegui com a ajuda de um colega desenvolver um algoritmo, menos
sotisficado que o RSA, AR4 ou DES (olhei todas essas possibilidades).
Infelizmente não posso colar o código, logicamente, mas resolveu muito
bem nosso problema.
Só alguns pontos:
1. Utilizamos base64
2. Utilizamos os métodos ord e chr em demasia.
3. Randomização de letras.
4. Troca de chaves criptografadas.
Ficou bacana :) Só não sei se é seguro o bastante.
Abraços! :)
2008/2/26 Marco André Lopes Mendes <marco...@gmail.com>:
> > ,----------------------------------------------------------.
> > | Antes de enviar um e-mail para o grupo leia: |
> > | http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
> > | E se você é usuário do BOL lembre-se de cadastrar o |
> > | e-mail do grupo na lista branca do seu sistema anti-spam. |
> > `----------------------------------------------------------´
> > Links do Yahoo! Grupos
> >
> >
> >
>
> --
> Marco André
> marco...@gmail.com
>
--
Rui
http://ruivaldo.wordpress.com
"Rubi? Aquela novela do SBT?"
~ Carla Perez sobre Ruby
"Em Python, tudo é objeto, além de lindo e maravilhoso."
~ Caetano Veloso sobre Python
Leonardo Santagada
On 26/02/2008, at 16:53, rui wrote:
> Ficou bacana :) Só não sei se é seguro o bastante.
Eu sei... não é, com certeza absoluta, 100%.
:)
Parece arrogante, mas se tu não trabalha no negócio e não levou anos
desenvolvendo, ou fez minusculas e controladas alterações num
algoritmo comprovadamente seguro dá pra dizer com certeza q não é
seguro.
ps: O fato de tu não ter mandado o código tb é uma dica importante :D
--
Leonardo Santagada
Roberto Alcântara
Espero que seja suficientemente seguro para a sua aplicação ;-)
Abraços,
- Roberto
2008/2/26 rui <ruiv...@gmail.com>:
>
>
> Galera,
>
> O problema era encriptar esse arquivo para um formato que pudesse ser
> distribuído como arquivo .lic.
> Consegui com a ajuda de um colega desenvolver um algoritmo, menos
> sotisficado que o RSA, AR4 ou DES (olhei todas essas possibilidades).
>
> Infelizmente não posso colar o código, logicamente, mas resolveu muito
> bem nosso problema.
> Só alguns pontos:
>
> 1. Utilizamos base64
> 2. Utilizamos os métodos ord e chr em demasia.
> 3. Randomização de letras.
> 4. Troca de chaves criptografadas.
>
> Ficou bacana :) Só não sei se é seguro o bastante.
>
> Abraços! :)
>
Nilton Volpato
[...]
> O problema era encriptar esse arquivo para um formato que pudesse ser
> distribuído como arquivo .lic.
Bem... eu nem sei o que é um arquivo .lic.
> Consegui com a ajuda de um colega desenvolver um algoritmo, menos
> sotisficado que o RSA, AR4 ou DES (olhei todas essas possibilidades).
Você não pode incluir nenhuma dependência externa? Mesmo que você não
possa não é muito difícil implementar um algoritmo de criptografia
conhecido.
> Infelizmente não posso colar o código, logicamente, mas resolveu muito
> bem nosso problema.
Não se consegue segurança ocultando o código, um código aberto tem a
tendência de ser muito mais seguro já que manter as vulnerabilidades
em segredo não faz elas desaparecerem.
> Só alguns pontos:
>
> 1. Utilizamos base64
> 2. Utilizamos os métodos ord e chr em demasia.
> 3. Randomização de letras.
> 4. Troca de chaves criptografadas.
Várias coisas:
1. O algoritmo apresentado pelo Rodrigo Cacilhas não é necessarimente
ruim. Se você usar uma chave tão longa quanto o texto original e
gerada de maneira aleatória então ele é totalmente seguro. Aliás, é o
único algoritmo de criptografia comprovadamente seguro. O problema é
que a chave só pode ser usada uma vez e depois deve ser descartada,
além disso ambas as partes devem possuir a mesma chave que deve ter
sido trocada previamente usando-se um canal seguro. Esse algoritmo é
conhecido como "one-time pad".
2. Por que já não fazer da maneira correta?
>>> import base64
>>> from Crypto.Cipher import Blowfish
>>> o = Blowfish.new('minha-chave-secreta')
>>> texto = 'Lorem ipsum dolor sit amet'
>>> o.encrypt(texto + '\0' * (-(len(texto) % -8)))
'\x03L\xbc\xd4\x0b\xf0\x82D\xb0\xb5\xa0\x8a\x80\x087\x03\xbb\xfa,\xf7*s)\x02\x83\x05\xb154B$\xeb'
>>> base64.encodestring(_)
'A0y81AvwgkSwtaCKgAg3A7v6LPcqcykCgwWxNTRCJOs=\n'
>>> encrypted = _
>>> o = Blowfish.new('minha-chave-secreta')
>>> o.decrypt(base64.decodestring(encrypted))
'Lorem ipsum dolor sit amet\x00\x00\x00\x00\x00\x00'
> Ficou bacana :) Só não sei se é seguro o bastante.
Provavelmente não. Mas depende de quanta segurança você precisa.
Abraço,
-- Nilton
Luciano Ramalho
> 1. O algoritmo apresentado pelo Rodrigo Cacilhas não é necessarimente
> ruim. Se você usar uma chave tão longa quanto o texto original e
> gerada de maneira aleatória então ele é totalmente seguro. Aliás, é o
> único algoritmo de criptografia comprovadamente seguro. O problema é
> que a chave só pode ser usada uma vez e depois deve ser descartada,
> além disso ambas as partes devem possuir a mesma chave que deve ter
> sido trocada previamente usando-se um canal seguro. Esse algoritmo é
> conhecido como "one-time pad".
Certamente o requisito "a chave só pode ser usada uma vez e depois
deve ser descartada" não se aplica neste caso, pois aparentemente o
tema é um arquivo de controle de licença de uso de software, o que
significa que a chave será usada múltiplas vezes pois estará embutida
no software. E se a chave for usada múltiplas vezes, por definição não
é mais um "one-time pad".
[ ]s
Luciano
Luciano Ramalho
> O problema era encriptar esse arquivo para um formato que pudesse ser
> distribuído como arquivo .lic.
> Consegui com a ajuda de um colega desenvolver um algoritmo, menos
> sotisficado que o RSA, AR4 ou DES (olhei todas essas possibilidades).
Em janeiro eu implementei o RC4 (ou AR4) em Python. Está aqui:
http://code.google.com/p/propython/source/browse/pyintro/cripto/rc4.py
Para entender como usar, vale a pena ler os demais arquivos que se
encontram no mesmo diretório.
> Infelizmente não posso colar o código, logicamente, mas resolveu muito
> bem nosso problema.
Vou te contar uma coisa, não tem nada de lógico nisso. Um algoritmo de
criptografia seguro continua sendo seguro mesmo depois de ter seu
funcionamento revelado. Recomendo que você estude um pouco mais o tema
criptografia. Aí vai entender porque os especialistas dizem que não
existe segurança por obscuridade.
> Só alguns pontos:
>
> 1. Utilizamos base64
> 2. Utilizamos os métodos ord e chr em demasia.
Uau!
> 3. Randomização de letras.
> 4. Troca de chaves criptografadas.
Eu acrescentaria uma pitada de números primos, para ficar ainda mais seguro!!!
Perdôe, mas não resisti...
> Ficou bacana :) Só não sei se é seguro o bastante.
Aqui você falou uma coisa bem sensata, Ruivaldo: de fato pode ser que
seja seguro o bastante. Tudo depende do valor do segredo que você está
tentando proteger.
Quanto vale para o seu cliente ter o esquema de proteção intacto por
um ano ou dois? Qual o prejuízo se alguém quebrar na primeira semana?
Quanta gente estaria interessada em quebrar?
Só não acredite que por ter usado um monte de ténicas de
embaralhamento de bits você criou um algoritmo criptográfico. Com
estas coisas não se brinca.
[ ]s
Luciano
Nilton Volpato
> 2008/2/26 Nilton Volpato <nilton....@gmail.com>:
>
> > 1. O algoritmo apresentado pelo Rodrigo Cacilhas não é necessarimente
> > ruim. Se você usar uma chave tão longa quanto o texto original e
> > gerada de maneira aleatória então ele é totalmente seguro. Aliás, é o
> > único algoritmo de criptografia comprovadamente seguro. O problema é
> > que a chave só pode ser usada uma vez e depois deve ser descartada,
> > além disso ambas as partes devem possuir a mesma chave que deve ter
> > sido trocada previamente usando-se um canal seguro. Esse algoritmo é
> > conhecido como "one-time pad".
>
> Certamente o requisito "a chave só pode ser usada uma vez e depois
> deve ser descartada" não se aplica neste caso, pois aparentemente o
> tema é um arquivo de controle de licença de uso de software, o que
> significa que a chave será usada múltiplas vezes pois estará embutida
> no software. E se a chave for usada múltiplas vezes, por definição não
> é mais um "one-time pad".
Sim, eu estava considerando apenas o algoritmo e não o uso pretendido
para ele (na verdade, eu não entendi exatamente qual será o uso).
Aliás, olhando melhor o algoritmo ele tenta re-utilizar a chave várias
vezes durante a codificação de um mesmo arquivo texto, ou seja, já faz
o que não deveria ser feito.
Outro ponto é que se a chave ficará embutida no software então o
sistema já é totalmente falho desde o início. Já que é muito mais
fácil descobrir qual é a chave inspecionando o programa do que usando
alguma técnica de cripto-análise no texto cifrado.
Se for esse o caso, então me parece que a solução apropriada seria
usar um esquema de assinatura digital, que também é possível de se
fazer com o pycrypto. Aliás é bem simples, eu já havia feito isso uma
vez.
Abraços,
-- Nilton
Marco André Lopes Mendes
seria bem mais simples de dar uma sugestão.
Marco André
2008/2/27 Nilton Volpato <nilton....@gmail.com>:
--
Marco André
marco...@gmail.com
Nilton Volpato
> Opa Luciano,
>
> Entendi o recado e realmente já marquei para estudar mais o assunto.
>
> Não disse em nenhum momento que criei um algoritmo criptográfico.
>
> Na verdade, após a leitura das respostas dos colegas percebi que o algoritmo
> que eu desejava era de "obfuscamento", que (corrijam-me se tiver errado) é
> bem diferente de criptografia.
>
> Vamos voltar a conversa para algo produtivo e aqui está o meu código de
> ___obfuscamento___ (não é criptográfico :)). Preciso que vocês me dêem uma
> idéia de como melhorá-lo e manter o código simples.
Você pode explicar exatamente (e claramente) qual seria/será o uso disso?
Valeu,
-- Nilton
rui
Entendi o recado e realmente já marquei para estudar mais o assunto.
Não disse em nenhum momento que criei um algoritmo criptográfico.
Na verdade, após a leitura das respostas dos colegas percebi que o algoritmo
que eu desejava era de "obfuscamento", que (corrijam-me se tiver errado) é
bem diferente de criptografia.
Vamos voltar a conversa para algo produtivo e aqui está o meu código de
___obfuscamento___ (não é criptográfico :)). Preciso que vocês me dêem uma
idéia de como melhorá-lo e manter o código simples.
Pedaço de código:
class .....
def __makePlainString(self, st):
if isinstance(st, unicode):
return st.encode("ascii", "ignore")
else:
return unicode(st, "ascii", "ignore")
def encrypt(self, text, chave):
text = self.__makePlainString(text)
result = ""
chave = md5.new(chave).hexdigest()[:2]
text = urllib2.quote(text)
for char in text:
result += char + chave
return base64.encodestring(result)
Abraços galera.
2008/2/26 Luciano Ramalho <ram...@gmail.com>:
--
Rui
http://ruivaldo.wordpress.com
"Rubi? Aquela novela do SBT?"
~ Carla Perez sobre Ruby
"Em Python, tudo é objeto, além de lindo e maravilhoso."
~ Caetano Veloso sobre Python
[As partes desta mensagem que não continham texto foram removidas]
,-----------------------------------------------------------.
Narcélio Filho
> Alguém poderia me dar uma dica de qual algoritmo usar e tal. Os que
> vêm por padrão com a Python não resolveram meu problema.
Os módulos que vêm com o Python não são usados para cifragem, somente
para hash (como o md5 e o sha). Para cifrar dados, use o PyCrypto:
http://www.amk.ca/python/code/crypto
Um exemplo simples de uso dele seria:
from Crypto.Cipher import AES
from md5 import md5
def padded(s, block_size):
return s.ljust(len(s) + block_size - (len(s) % block_size))
aes = AES.new(md5('secret password').digest(), AES.MODE_ECB)
plaintext = 'secret text'
ciphertext = aes.encrypt(padded(plaintext, AES.block_size))
print 'ciphertext:', `ciphertext`
aes = AES.new(md5('secret password').digest(), AES.MODE_ECB)
plaintext = aes.decrypt(ciphertext).strip()
print 'plaintext:', `plaintext`
... que usa o AES no modo ECB para cifrar o texto 'secret text' com a
chave 'secret password' (na verdade, o MD5 dela) e depois decifra.
Lembrando que esse método serve para fazer uma criptografia
simétrica. Pode não ser o mais recomendado para o seu caso (não sei qual é).
Mais informações na PEP-272:
http://www.python.org/dev/peps/pep-0272/
--
[]s, Narcélio
rui
Na verdade é um sistema de licenciamento (distribuição de demos) do sistema.
Esse "algoritmo" cria um arquivo codificado que contém uma string tokenizada
com alguns dados:
CNPJ da empresa que solicitou o demo e o número de registros máximo.
Há uma aplicação feita em Ruby on Rails que atua como interface web do
sistema e é quem recebe os eventos via webservices, salvando-os no banco de
dados.
Há também um serviço do Windows feito em Python que descriptografa esse
arquivo de licença, lê o número máximo de licenças e coloca no registro do
Windows. Daí, ele inicia o servidor web "Mongrel" que inicia o aplicativo
Ruby on Rails.
Durante o boot do sistema, o aplicativo lê essa chave do Windows e confronta
com o número de registros. Se o máximo foi atingido, uma ação é tomada para
evitar novos registros.
O _problema_ em si não é o algoritmo de criptografia, mas porque ruby não
compila nem em bytecode o seu código. Então ele fica lá o tempo todo
disponível...
É isso, abração Nilton. Dá um retorno com idéias e dizendo se entendeu ou
não o problema.
2008/2/27 Nilton Volpato <nilton....@gmail.com>:
> 2008/2/27 rui <ruiv...@gmail.com <ruivaldo%40gmail.com>>:
>
> > Opa Luciano,
> >
> > Entendi o recado e realmente já marquei para estudar mais o assunto.
> >
> > Não disse em nenhum momento que criei um algoritmo criptográfico.
> >
> > Na verdade, após a leitura das respostas dos colegas percebi que o
> algoritmo
> > que eu desejava era de "obfuscamento", que (corrijam-me se tiver errado)
> é
> > bem diferente de criptografia.
> >
> > Vamos voltar a conversa para algo produtivo e aqui está o meu código de
> > ___obfuscamento___ (não é criptográfico :)). Preciso que vocês me dêem
> uma
> > idéia de como melhorá-lo e manter o código simples.
>
> Você pode explicar exatamente (e claramente) qual seria/será o uso disso?
>
> Valeu,
> -- Nilton
>
>
--
Rui
http://ruivaldo.wordpress.com
"Rubi? Aquela novela do SBT?"
~ Carla Perez sobre Ruby
"Em Python, tudo é objeto, além de lindo e maravilhoso."
~ Caetano Veloso sobre Python
[As partes desta mensagem que não continham texto foram removidas]
,-----------------------------------------------------------.
Pinguim Azul
proporcional ao número de licenças / registros, e é importante ter o
algoritmo de criptografia / ofuscação pra impedir que o cliente altere por
conta própria o número de licenças sem pagar vocês.
Se eu entendi certo, então o seu modelo de negócios depende de ninguém te
crackear. Sendo esse realmente o caso, então não fique brincando com código
inseguro, contrate um consultor que entenda bastante de segurança e peça pra
ele fazer o serviço. A longo prazo, o investimento com as horas do consultor
compensam com o que você ganhará em licenças compradas, e não crackeadas.
Alternativamente, compre o livro do Schneier e estude segurança a fundo
antes de implementar você mesmo. Esse caminho demora mais; se o seu sistema
já estiver no mercado, o consultor ainda é uma solução melhor.
2008/2/27 rui <ruiv...@gmail.com>:
--
----------------------------------------------------------------
Ricardo Bittencourt http://www.mundobizarro.tk
ric...@700km.com.br "Save the trees. Eat more woodpeckers"
------ União contra o forward - crie suas proprias piadas ------
Paul Eipper
A parte do registro do Windows é tão simples de alterar que
simplesmente anula qualquer segurança colocada na string tokenizada.
--
Paul Eipper
Em 28/02/08, Pinguim Azul<bluep...@gmail.com> escreveu:
Leonardo Santagada
On 28/02/2008, at 00:25, Paul Eipper wrote:
> A parte do registro do Windows é tão simples de alterar que
> simplesmente anula qualquer segurança colocada na string tokenizada.
Exatamente o q eu pensei. Leia o livro e chame o consultor, eu sei q
doi mas vale a pena.
--
Leonardo Santagada
Nilton Volpato
> Blz Nilton. Vou tentar explicar.
>
> Na verdade é um sistema de licenciamento (distribuição de demos) do sistema.
> Esse "algoritmo" cria um arquivo codificado que contém uma string tokenizada
> com alguns dados:
>
> CNPJ da empresa que solicitou o demo e o número de registros máximo.
>
> Há uma aplicação feita em Ruby on Rails que atua como interface web do
> sistema e é quem recebe os eventos via webservices, salvando-os no banco de
> dados.
>
> Há também um serviço do Windows feito em Python que descriptografa esse
> arquivo de licença, lê o número máximo de licenças e coloca no registro do
> Windows. Daí, ele inicia o servidor web "Mongrel" que inicia o aplicativo
> Ruby on Rails.
>
> Durante o boot do sistema, o aplicativo lê essa chave do Windows e confronta
> com o número de registros. Se o máximo foi atingido, uma ação é tomada para
> evitar novos registros.
>
> O _problema_ em si não é o algoritmo de criptografia, mas porque ruby não
> compila nem em bytecode o seu código. Então ele fica lá o tempo todo
> disponível...
>
> É isso, abração Nilton. Dá um retorno com idéias e dizendo se entendeu ou
> não o problema.
Acho que entendi sim. Como o Ricardo disse, é meio complicado fazer um
sistema como esse que seja difícil de quebrar e o melhor mesmo é
contratar uma solução pronta para isso. Se o seu código for fácil de
modificar, então não importa qual seja o esquema de segurança que você
usar, basta remover a checagem e simular que deu tudo certo.
Criptograficamente, parte da solução para isso é criar esse arquivo de
licença, que pode até ser em texto claro, mas incluir um trecho
adicional que é uma assinatura eletrônica. A assinatura eletrônica é
baseada num esquema de chaves criptográficas assimétricas (uma pública
e outra privada), a privada só você tem, a pública você pode
distribuir para os clientes (ou pra quem mais você quiser). Como o
programa tem a posse da chave pública ele é capaz de verificar se o
arquivo de licença é autêntico e ter certeza que foi você quem criou
ele.
No entanto mesmo esse sistema vai por água a baixo se for fácil
modificar o código. E geralmente essa é a parte mais fácil mesmo, e o
que os crackers costumam fazer.
Eu conheço um sistema que usa licença por máquina controlada pelo MAC
adress da interface ethernet. As máquinas licenciadas e a data de
validade da licença ficam num arquivo com assinatura digital. Cada
máquina licenciada pode rodar um número máximo de instâncias, e isso é
controlado por um serviço de gerenciamento de licença. O binário
(provavelmente compilado a partir de C) tem os trechos relativos à
licença ofuscados para dificultar que seja analisado ou debugado de
alguma forma. Esse sistema de segurança que eles usam é vendido por
uma outra empresa (se não me engano), e mesmo assim é passível de ser
quebrado.
Contratar um consultor é uma boa idéia. Mas pode ser que o projeto ou
o preço do software sejam pequenos e não compense esse tipo de coisa.
Então a decisão sobre o que fazer mesmo é de vocês. Se eu fosse
obrigado a fazer um serviço para gerenciamento de licenças eu faria
algo como descrito acima.
Abraço,
-- Nilton