regina@cryptoid.com.br

Estamos em novo endereço. Encontre-nos lá!

Faça parte desse projeto você também!

Conteúdo

O objetivo desse Blog é apresentar essa fantástica e importante tecnologia, de forma simples, para que pessoas que não dominam aspectos técnicos também possam acompanhar a evolução da adoção da Certificação Digital e o universo que gira ao seu redor:

Certificado Digital para Assinatura e Sigilo, Certificado de Atributo, Carimbo do Tempo, Documentos Eletrônicos, Processos Eletrônicos, Nota Fical Eletrônica, TV Digital, Smart Card, Token, Assinador de Documento, Gerenciador de Identidades etc..

Este Blog publica matérias e artigos extraídos da mídia que expressam a opinião dos respectivos autores e artigos escritos por mim que expressam, exclusivamente, minha opinião pessoal sem vínculo a nenhuma organização.

Matérias organizadas por data de publicação

sexta-feira, 14 de outubro de 2011

ITI alerta empresas sobre atualização nas chaves públicas

Leia também:

O Instituto Nacional de Tecnologia da Informação (ITI) começou a alertar as empresas que desenvolvem produtos e soluções nos padrões da Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil) sobre o prazo de atualização aos novos padrões criptográficos. A partir de 1º de janeiro do próximo ano, nenhum novo certificado digital poderá ser gerado sob padrões anteriores.

“Todos os produtos destinados a operar a cadeia de certificados digitais ICP-Brasil, tais como cartões, leitoras, tokens e HSM, devem adotar chaves de no mínimo 2048 bytes e família Sha256. Nessa data, também só serão permitidos dispositivos exclusivamente homologados pela ICP-Brasil não sendo mais aceitos produtos certificados pelo NIST (órgão de padronização dos EUA)”, explica o diretor da Infraestrutura de Chaves Públicas do ITI, Maurício Augusto Coelho.

Ele lembra que as alterações estão previstas em normas emitidas pelo ITI desde junho de 2009, inclusive com a data da mudança. Procurado, o Instituto Nacional de Tecnologia da Informação, no entanto, evitou comentar sobre o grau de preparação das empresas para a adaptação aos novos padrões criptográficos.

O ITI apenas destaca a necessidade de as empresas se movimentarem para homologar produtos de acordo com as normas da ICP-Brasil. De acordo com coordenador técnico de Hardware do LSI TEC, Adilson Eduardo Guelfi, “quanto mais as empresas priorizarem seus processos de homologação, mais o LSI TEC terá condições de atender com qualidade e celeridade todas as demandas”.


Leia também:

Pai de SSL diz que, apesar dos ataques, há vida pela frente


Taher-Elgamal
 11 de Outubro de 2011 às 17:16:03 por computerworld

Auto-actualização do protocolo de segurança ajudaria muito, considera Taher Elgamal. (artigo em inglês)
SSL/TLS, the protocol that protects security of e-commerce, has taken a beating lately, with news items ranging from the violation of certificate authorities to the discovery of an exploit that beats the protocol itself.

With all the noise about SSL/TLS it’s easy to think that something is irreparably damaged and perhaps it’s time to look for something else.

But despite the exploit — Browser Exploit Against SSL/TLS (BEAST) — and the failures of certificate authorities such as Comodo and DigiNotar that are supposed to authenticate users, the protocol has a lot of life left in it if properly upgraded as it becomes necessary, says Taher Elgamal, CTO of Axway and one of the creators of SSL.

The problem lies not in the SSL/TLS itself but in the trust framework built around it and the problems that causes when it comes time to patch the protocol to fix vulnerabilities. Network World Senior Editor Tim Greene spoke recently about these issues with Elgamal. Here is an edited transcript of that conversation.

The flaw exploited by BEAST has been around since 2004. What’s up with that?

The problem is complex. It started with, yeah there is a weakness in the security protocol and we ought to recognize that and we have to go update it and fix it. That was before the whole BEAST thing — the practical attack, so to speak.

All the different browsers in the world are using TLS which is known to have that weakness. It’s important to understand what that attack really is.

The way the BEAST thing’s deployed is you have to have a piece of malware on the browser that can inject certain things to force the browser to produce cookies so that these cookies are passed into the channel. Then they have to have a man-in-the-middle point that allows them to actually get the encrypted data. So you have what is called a chosen plaintext attack — you choose the plaintext and you read the ciphertext and you try to match these up and find out what the keys are. It’s very, very clever. There’s no question about it.

Now, from a practical standpoint, the real problem is you have to have malware on the machine. Honestly, if I can put malware on your machine, I’m not going to be bothering with your SSL because I can see all the data before it gets encrypted.

It became very public because there are some 2 billion browsers and all of them use SSL for one thing or another and all e-commerce uses it and we should be careful. But obviously if you have a protocol that does not have any security problems — that does not exist.

So on the one hand you have a bunch of smart guys who did a very clever thing. It is clever and it uses a known vulnerability and it shows what you can do with these things. On the other hand, the real issue is Windows is a really terrible operating system — what can you say. It’s pretty amenable to malware that can redirect stuff. It’s a combination of a lot of things.

What’s the practical step to take? Go to TLS 1.1?

Unfortunately no. That is the problem. The browsers still do not support TLS 1.1. That is actually the real problem. TLS 1.1 is more than two years old. It’s not like it came out last week.

What can a corporate user do about the problem?

You have to watch out for malware. What can I say? You should watch out for it in any case. Make sure you’re running your machine in a good state, and you’re running a/v and that kind of stuff, anti-malware spotting things — which you do in any case. If you’ve got malware on your machine somebody’s reading your data regardless of SSL.

Are there downsides to TLS 1.1?

Not that is known today, but the issue with security is that as human beings we all want something that is secure forever. We want to feel safe about it and move onto the next thing, and unfortunately that is the wrong thing to do because security is always relative to something or another. Ten years from now computers will be a lot faster so today’s safe things may not be safe, and we will be doing exactly the same thing again. It’s not because it’s bad or good and doesn’t have anything to do with a particular setup or protocol or operating system. It’s just the truth of the matter, since we have to always look out for these things. We have to monitor for what the weaknesses are. We have to update things. This continues to happen basically forever and ever. There’s honestly no one-time solution to this issue. It has nothing to do with SSL in particular. SSL becomes the poster child for this because SSL is being used in all of e-commerce. Replacing SSL by itself as a protocol doesn’t solve any problem.
How about those certificate authority breaches against Comodo and that wiped out DigiNotar?

It’s a combination of PKI and trust models and all that kind of stuff. If there is a business in the world that I can go to and get a digital certificate that says my name is Tim Greene then that business is broken, because I’m not Tim Greene, but I’ve got a certificate that says this is my name. This is a broken process in the sense that we allowed a business that is broken to get into a trusted circle. The reality is there will always be crooks, somebody will always want to make money in the wrong way. It will continue to happen until the end of time.

Is there a better way than certificate authorities?

The fact that browsers were designed with built-in root keys is unfortunate. That is the wrong thing, but it’s very difficult to change that. We should have separated who is trusted from the vendor. If we cannot separate the root of trust from the vendor then the best we can do is build a side reputation system that everybody consults. When a browser gets a certificate from an unknown CA it says what the heck is this? Tell me if the reputation of this thing is OK, and if it is OK, it’s fine. And if that particular CA is doing bad things its reputation will go down and the browser should actually refuse the connection. We want the consumer to get ease of access a lot more than we want to protect them. So we allow the consumer to trust random things. After somebody trusts something it’s very difficult for them to untrust it in the current setup. So the browser guys needed to undo things. This is unfortunate but it only has to do with the way the PKI was implemented inside of the browser system rather than any particular protocol. You could have removed SSL and put in IPSec and the exact same problem would actually come out because they all use PKI.
What can be done?

If there is a way that we can separate who we trust from the vendor of the browsers then that would be the best thing to do. And the root of the trust should be the Internet with its built-in reputation ecosystem. All the CAs will have reputations built in because that’s how the Internet runs, and then you have a better trust model that way. Rather than build it into the browser itself, that’s what I’m saying. And I’m not saying I know how to implement this, but it’s a better model.

If that were to happen and people have noticed that a particular CA is issuing bad certs the reputation will kick it out immediately. Nobody will have to issue patches, we don’t have to wait for somebody to send something over for us to update. It will just be done in the ecosystem.

How would that work?

We have to build a mechanism to automatically update things. We did not do that. The right way to design, if we were to update things an updating protocol that automatically updates itself so when the next version comes up it knows where to find the next version rather than having to wait for a Windows update or whatever. I think there is technology that is known to the world to do that. And I hope people look for these things because honestly, every protocol will have roles for self-updating things. Nothing will remain secure forever. It’s a bad idea actually to shoot for something that will be secure forever because we won’t find any.

Do you see a way automatic updating could take place with SSL/TLS?

I think it’s not just TLS, I think it’s the self-updating thing in general. It’s a good idea, right?

Are you working on that?

Am I working on that? No. It’s something that exists but I’m not actually working on it.

What do you know about what’s being worked on?

The beauty of living in Silicon Valley is that you talk to people every day, and people tell you interesting ideas. I’m not sure I’m allowed to say. People have approached me with some ideas of that type.




quinta-feira, 13 de outubro de 2011

Novo amigo da espionagem corporativa: servidor web incorporado

Muitos tipos de fotocopiadoras, scanners e servidores de VoIP conectados na web não possuem senha padrão ou outra garantia para impedir escutas remotas


Muitos modelos de impressoras, fotocopiadoras e aparelhos de voz sobre IP (VoIP) estão conectadas à internet. Mas seus servidores incorporados costumam usar senhas padrões bem conhecidas, ou firmwares que apresentam vulnerabilidades. Isso pode ser um problema, já que ambos podem ser usados por espiões remotos para interceptar comunicações internas.

Essa advertência foi emitida por Michael Sutton, vice-presidente de pesquisa e segurança da Zscaler Labs, durante conferência de segurança organizada pela Black Hat. Sutton apresentou os resultados das pesquisas, baseadas no uso de múltiplas engenharias de impressão digital em mais de um milhão de servidores de web, e para identificar como os servidores estão incorporados. Curiosamente, a pesquisa do Google parece suprimir resultados para servidor de rede incorporado. Mas outros mecanismos de busca, como Shodan, não.

Do total de um milhão de servidores de impressoras digitais na web, 34,2% rodam Microsoft IIS e 33,6% Apache. Além disso, existem 2.737 cabeçalhos de servidores exclusivos nas máquinas restantes. “Muitos deles embutidos nos servidores”, lembrou Sutton. Muitos desses servidores também não possuem o melhor nível de segurança como senha de acesso aos documentos armazenados ou chamadas VoIP. Como resultado, Sutton foi capaz baixar inúmeros documentos gratuitamente, incluindo conselhos de voto da organização Pro-Tea Party, cópias de cheques assinados e digitalizados em relatórios técnicos. “Meu favorito absoluto”, constatou. “Esta documentação nos deixa saber que Jim é, na verdade, um inspetor certificação de moldes”.

Segundo Sutton, fotocópias e similares são, essencialmente, repositórios de documentos recentes ou comunicação de interesse, e, portanto, poderiam servir como tesouro de inteligência competitiva. Certos modelos de fotocopiadoras Sharp, por exemplo, podem ser configuradas para enviar todos os documentos digitalizados ou copiados para um site externo via FTP ou e-mail. Enquanto isso, algumas impressoras da HP tem recursos chamado webscan, que permite a qualquer pessoa com browser, baixar tudo o que está na mesa do scanner.

Curiosamente, a maioria dos dispositivos conectados aos serviços web encontrou câmeras de segurança, incluindo as pequenas. “Eu encontrei um monte de câmeras do McDonald na web; não sei porquê”, disse. Muitas delas, entretanto, parecem ter sido configuradas para monitorar funcionários.

De todos os dispositivos de impressões digitais, no entanto, “o mais preocupante é a copiadora Ricoh”, avaliou Sutton. Em particular, 2% das impressoras Ricoh são incorporadas nos servidores web e usam a senha “admin”. Enquanto os dispositivos oferecem criptografia SSH, muitos incluindo serviços telnet, no qual um invasor pode facilmente ativar para acessar diretamente dados antigos das máquinas. Alguns desses aparelhos também tornam documentos recentemente digitalizados disponíveis para downloads imediatos em formato TIFF ou PDF.

Daqui para frente, Suton disse que espera acumular mais informações – que irá dividir gratuitamente – para cada tipo de servidor web embarcado em impressoras digitais, como forma de ajudar empresas a entenderem como dispositivos internos podem apresentar vulnerabilidades.

Mas o que pode ser feito para impedir as vulnerabilidades desses sistemas embarcados? Primeiro, servidores web precisam ser incluídos no plano de correção da corporação, e fornecedores devem contribuir com essas correções. “A indústria do hardware esta ao menos uma década atrás das indústrias de software em termos de segurança”,explicou. “Nós definitivamente precisamos mover o sistema para algo mais comum, como, por exemplo, a Apple TV, onde as correções são levadas até o cliente.” Por exemplo, um dos servidores de web incorporado mais usados é o Allegro RomPager, e seu fabricante diz rodar em 75 milhões de dispositivos. Durante sua pesquisa, Sutton encontrou pelo menos três mil dispositivos rodando a versão do RomPager que contém vulnerabilidades conhecidas e que podem ser usadas para derrubar o servidor.

Em segundo lugar, dispositivos precisam se comprometer com os recursos de segurança, como a habilidade de enviar documentos para um site FTP. “Eu realmente coloco a culpa nos fornecedores”, provocou Sutton. “Essa funcionalidade na maioria das vezes não tem propósito nenhum. Quando é útil, no entanto, a funcionalidade deve ser ativada por padrão, utilizando senha única, como o número de série dos dispositivos MAC.”

Até que essas mudanças ocorram, gerentes de TI devem considerar qualquer servidor de web incorporado como uma ameaça em potencial. “Na empresa você precisa tratar uma copiadora ou qualquer dispositivo de rede ativado como se fosse um computador”, concluiu.

segunda-feira, 10 de outubro de 2011

Confirmado: Carta de Correção em papel desaparece em 2012


Por Roberto Dias Duarte
7 de outubro de 2011 10:20


A sistemática da Nota Fiscal Eletrônica sofreu mais uma alteração: a partir de 1º de julho de 2012 as empresas não poderão mais utilizar a Carta de Correção em papel para sanar erros em campos específicos da NF-e, conforme determina parte do Ajuste Sinief 10/2011 (*), promovido após reunião entre representantes do Conselho Nacional de Política Fazendária e da Receita Federal, no último dia 30 de setembro, em Manaus (AM), e publicado em 05-10 no Diário Oficial da União (DOU).

 
A progressiva adoção dos meios eletrônicos em substituição ao papel é a essência do processo que envolve o Sistema Público de Escrituração Digital (SPED), do qual faz parte a NF-e.

A chegada da Carta de Correção Eletrônica (CC-e) traduz-se em uma nova ferramenta, mais ágil e segura, para a regularização de transações comerciais com erros técnicos de procedimento.

Vale lembrar que as regras de validação da CC-e, tal qual ocorre com toda a NF-e, na verdade são sumárias e não garantem a plena conformidade fiscal tributária da operação. Ou seja, uma CC-e poderá muito bem ser aprovada, mesmo que promova na transação comercial em si modificações incompatíveis com a legislação.

 
Permanecem inalteradas, por exemplo, as circunstâncias em que ela não pode ser adotada, ou seja, modificação das variáveis que determinam o valor do imposto, tais com base de cálculo, alíquota, diferença de preço, quantidade, total da operação ou prestação; dados cadastrais que impliquem mudança do remetente ou do destinatário, assim como data de emissão ou saída.



Tentar fazer com a CC-e o que muitos fazem hoje em relação à Carta de Correção em papel, ou seja, alterando indiscriminadamente qualquer campo do documento fiscal, poderá ser um péssimo caminho a seguir. O fisco é implacável nesses casos. Ressalto ainda que não mudam em nada as normas fiscais e tributárias vigentes, mas apenas e tão somente a velocidade na propagação de erros e acertos.



(*) Ajuste Sinief 10/2011: