Commapi / applet erro

Olá

Provavelmente seu sistema funciona legal apesar desta mensagem que aparece no Java Console. Esta exceção é um dos bugs do javax.comm. O lado ruim é que não há meio de retira-la, o lado bom é que não faz diferença nenhuma no funcionamento da aplicação.

[]s
Luca

Só que ele tbm não funciona

Olá

Então existem outros erros e exceções. Imprima tudo, vá rastreando até encontrar o local exato do erro. A exceção acima sempre existirá no Java Console e aparece na hora que inicia o driver.

[]s
Luca

Não apresenta mais nenhum erro alem do mencionado

por que será que não funciona?

Olá

Imprimiu tudo? Rodou o debug? Onde é o erro?

[]s
Luca

Usa java web start
beeeem melhor

Acredito que seje a assinatura do applet que ta dando pau,

Porque numa applicação standalone funciona normal, so no applet que não

Para assinar o applet , eu segui os passos de um link postado no guj

http://www.das.ufsc.br/jacoweb/restrito/documentos/assinatura/

Mas parei no

keytool -import {-alias alias} {-file file} e policytool
na verdade eu não entendi muito bem

Alguem tem alguma dica?

Obrigado

Na verdade voce tem dois problemas…

1 - A JVM do seu Browser tem as classes instaladar da java.comm??

2 - Alem de assinar o applet, voce tem de criar o policy permitindo o acesso a porta serial…

Boa sorte!

Olá

Fantatho

O modelo de segurança do Java precisa ser entendido por todos que desejam programa em Java. Basicamente uma applet não consegue furar o bloqueio de segurança a menos que:

1. tenha permissões explícitas no arquivo java.policy
   ou
2. seja assinado, isto é, contenha um certificado autenticando sua origem.

Um certificado que assina uma applet contém os dados de quem o emitiu e mais uma chave de criptografia. Ele é guardado em um “keystore”, que é como se fosse uma caixa. No “keystore” podem ser armazenados vários certificados e cada certificado é guardado como um par [alias : certificado]. Cada alias é uma chave que permite buscar cada certificado no keystore.

O keytool permite criar um pedido de certificado criando uma chave e também várias outras funções uma delas armazenar o certificado no keystore.

O jarsigner (ou a task análoga do ant) pega o certificado em um “keystore” e assina o arquivo jar da aplicação.

[]s
Luca

Eu consegui fazer tudo certinho ate o arquivo policy

Mas eu não estou entendendo o seguinte,

Na maquina do cliente ele da a mensagem de assinatura do applet tudo certinho, depois de aceito , consigo gravar um txt na maquina mas não consigo a serial.

o arquivo policy tem algum jeito de eu colocar na maquina do cliente?

Obrigado

Olá

Fantatho, as instruções abaixo devem ajuda-lo a entender o que precisa ser feito quando se usa applets. Mas é preciso ficar claro o seguinte:

a) A menos para pequenas features embutidas em páginas html, não se usa mais applets para novas aplicações. Como já foi dito, ao invés do Java Plug in é preferível usar o Java Web Start que a partir do j2sdk 1.4 ficou bastante bom. O JWS usa a mesma infra do browser mas tem muitas outras vantagens que poderiam encher outro post maior do que este.

b) Todo o texto abaixo fala em certificado adquirido de uma autoridade certificadora de raiz confiável. Um certificados destes custa mais ou menos US$ 250 / ano. Se sua aplicação está em uma Intranet você pode obter os mesmos resultados com um certificado auto assinado. Um certificado auto assinado você mesmo cria mas o browser mostra uma tela meio descrente para o usuário assumir a responsabilidade de aceitar ou não.

Modelo de segurança de execução de código Java

As aplicações Java são executadas em um ambiente de execução conhecido como máquina virtual Java (JVM = Java Virtual Machine). Os navegadores web ou browsers já incluem uma máquina virtual Java. Mas a JVM básica embutida no browser não é muito evoluída e precisa de auxílio extra para executar corretamente códigos Java mais modernos com ricas interfaces gráficas. O auxilio extra da JVM vem do chamado “Java Plug in” que precisa ser instalado e adicionado ao browser antes de usar os aplicativos Java. A aplicação Java executada dentro da máquina virtual do browser (“JVM+Plug in”) é chamada de applet. Em termos de segurança, as applets carregadas a partir de código local têm um tratamento diferente daquelas carregadas a partir de código remoto vindos da Internet (ou Intranet). O ambiente “JVM+Plug in” propicia total segurança. As aplicações desconhecidas carregadas a partir de código remoto normalmente ficam restritas aos recursos locais do sistema. Elas não têm permissão para alterar nada no computador onde a “JVM+Plug in” está em execução a menos que sejam previamente autorizadas.

O modelo de segurança do Java permite configurar uma política local de segurança de modo que as applets remotas possam executar tarefas previamente autorizadas fora do confinamento do ambiente “JVM+Plug in”. Esta autorização é explicitada em cada máquina cliente. Nas máquinas com Java instalado existe um arquivo de configuração no qual pode ser definida uma política de segurança adequada para cada aplicação. Isto é válido tanto para código local como para código remoto. No ambiente “JVM+Plug in” um gerenciador de segurança determina e filtra as permissões de acesso de acordo com a política previamente estabelecida. O gerenciador (security manager) garante que somente códigos autorizados tenham acesso aos recursos.

O estabelecimento de políticas de segurança em cada máquina cliente é um inconveniente muito grande quando se precisa instalar aplicações remotamente. O gerenciador de segurança precisa de uma alternativa para confiar em aplicações remotas sob determinadas circunstâncias e a estas permitir a execução sem restrições. As aplicações devem oferecer uma garantia aos ambientes “JVM+Plug in” de que realmente são de total confiança para ter acesso irrestrito ao ambiente. A garantia que torna uma applet remota confiável é dada pela assinatura digital da applet usando um certificado digital emitido por uma autoridade certificadora de raiz confiável. Deve ser uma autoridade reconhecida entre aquelas incluídas em uma lista de autoridades credenciadas no próprio browser.

Criptografia

A criptografia é uma tecnologia crítica que serve para desenvolver mecanismos provendo proteção quanto a integridade e confidencialidade de dados e ainda garantias de identificação, autenticação e não repudiação. Encriptação é a transformação de um texto livre em um texto cifrado e decriptação é o processo inverso. Os algoritmos de encriptação e decriptação em geral usam uma chave. Os algoritmos podem ser do tipo chave secreta ou chave simétrica onde a mesma chave é usada tanto para encriptar como decriptar. E podem também ser do tipo com chaves assimétricas que usam um par de chaves diferentes.

Os algoritmos de encriptação podem ser usados para calcular um valor a partir de uma seqüência de bytes usando uma chave secreta através de uma função de uma única via. Esta função é dita de uma única via porque produz um valor fácil de ser obtido, mas muito difícil de ser revertido. Este valor em linguagem de criptografia é conhecido como “message digest” ou “hash”. Esta função é considerada de boa qualidade se a mensagem (seqüência de bytes) que produz o valor “message digest” não pode ser obtida de volta revertendo o uso da função. E também se além disto, é computacionalmente improvável existirem duas mensagens diferentes produzindo os mesmos valores “message digest”.

O uso de “message digest” ou “hash” é um excelente meio de verificar se a mensagem foi alterada acidentalmente ou mesmo deliberadamente. Entretanto não mostra quem criou a mensagem. É o uso da criptografia de chaves assimétricas que permite garantir quem foi o criador da mensagem.

Quando se usa criptografia de chaves assimétricas, também chamada de criptografia de chave pública, na verdade se usam 2 chaves criptográficas, uma pública que se envia para todo mundo e outra privada que se guarda a sete chaves. Os algoritmos funcionam de modo que a mensagem encriptada usando a chave privada só pode ser desencriptada usando a chave pública. E vice-versa, a mensagem encriptada usando a chave pública só pode ser desencriptada usando a chave privada. Assim, quando usada uma chave privada para encriptar o valor “message digest” calculado pela função, o valor só poderá ser desencriptado usando a chave pública correspondente ao par de chaves. Então se pode dizer que este valor é a assinatura digital.

Assinatura digital

Assinar digitalmente uma mensagem segue os seguintes passos:

1. Um valor “message digest” é calculado por uma função de uma via de boa qualidade. O algoritmo da função precisa ser conhecido por quem vai verificar a assinatura;
2. Este valor é encriptado usando a chave privada de um par de chaves pública/privada produzindo a assinatura digital da mensagem.

Verificar a assinatura digital de uma mensagem segue os seguintes passos:

1. A assinatura é desencriptada usando a chave pública do mesmo par usado na encriptação. Produz-se assim o valor “message digest”;
2. Usando a mensagem se calcula o valor “message digest” e se compara com o valor recebido como assinatura;
3. Se ambos os valores coincidem, a assinatura é autêntica.

Até agora nada foi dito sobre como se passa a chave pública para o Mundo. Isto faz parte do conteúdo do certificado digital.

Certificados para assinatura digital de código

Os certificados possibilitam garantir o autor e o conteúdo de mensagens. As applets assinadas com um certificado reconhecido pelo browser e pelo ambiente “JVM+Plug in” são garantidas de modo que realmente foram carregadas a partir da origem de quem as criou e que seu conteúdo não foi alterado ou corrompido. Sendo assim elas são seguras e confiáveis podendo acessar o sistema local de forma irrestrita.

Os certificados digitais são mensagens assinadas por uma autoridade certificadora que certifica o valor de uma chave pública. Uma autoridade certificadora é uma entidade credenciada internacionalmente para confirmar que outras entidades são realmente quem dizem ser e que usa uma chave pública associada com um determinado algoritmo. Para obter um certificado digital é necessário submeter à autoridade certificadora documentos que provem a identidade de quem solicita o certificado. Existem muitos níveis de autoridades certificadoras formando o que convencionalmente se chama de cadeia de certificação. Os certificados têm uma estrutura de árvore com a autoridade máxima servindo como raiz. O browser e o Plug in Java precisam reconhecer a cadeia de certificação para aceitar o certificado como válido.

Normalmente um certificado contém as seguintes informações:

• Versão do formato ISO X.509 usado no certificado (1, 2 ou 3)
• Nome da entidade e chave pública
• Período de validade do certificado
• Número serial assinalado pela autoridade certificadora
• Nome da autoridade certificadora
• Assinatura digital criada pela autoridade certificadora

Passos efetuados para adquirir um certificado da Thawte (o certificado Thawte é um dos poucos que serve para applets)

Como explicado anteriormente, usamos a chamada criptografia assimétrica e então existem 2 chaves criptográficas. Uma privada que fica conosco e outra pública que é enviada junto com o certificado. O que é criptografado com a nossa chave privada, só pode ser descriptografado com a chave pública (e vice-versa, o que é criptografado com a chave pública só pode ser aberto com a chave privada). Para obter o certificado é preciso criar o par de chaves da criptografia assimétrica e passar a chave pública junto com um pedido de certificado para a autoridade certificadora. Os passos a efetuar são os seguintes:

1. Criação do par de chaves e armazena-las em um arquivo
2. Criar um arquivo com a chave pública para solicitar o certificado
3. Obter as informações da empresa e passar para a Thawte (autoridade certificadora)
4. Solicitar o certificado para a Thawte
5. Usar o certificado recebido da Thawte para assinar a aplicação

Os detalhes de cada passo estão a seguir:

1. Criação do par de chaves e armazenar em um arquivo

É usada uma ferramenta Java chamada keytool para criar as chaves e armazena-las em um arquivo chamado qqnome.keystore. O arquivo onde ficam as chaves precisa de uma senha para ser acessado e cada par de chaves guardado neste arquivo corresponde a uma entidade ou alias no exemplo abaixo chamado de meu_alias. O keytool é usado no prompt do DOS em um micro com Java instalado de acordo com o que está abaixo onde estão escondidas a senha do arquivo keystore e a senha do alias meu_alias:

C:\Arquivos de programas\JavaSoft\JRE\1.3.1\lib\security>keytool -keystore meu.keystore -genkey -keyalg rsa -alias meu_alias
Enter keystore password: XXXXXXXXXX
What is your first and last name?
[Unknown]: meu_dominio
What is the name of your organizational unit?
[Unknown]: meu_depto_ou_meu_sistema
What is the name of your organization?
[Unknown]: minha_empresa
What is the name of your City or Locality?
[Unknown]: minha_cidade
What is the name of your State or Province?
[Unknown]: minha_UF
What is the two-letter country code for this unit?
[Unknown]: sigla_do_meu_pais_que_para_mim_eh_BR
Is <CN=meu_dominio, OU=meu_depto_ou_meu_sistema, O=minha_empresa, L=minha_cidade, ST=minha_UF, C=sigla_do_meu_pais_que_para_mim_eh_BR> correct?
[no]: yes

Enter key password for <senha_deste_alias>
(RETURN if same as keystore password): XXXXXXXXXX

C:\Arquivos de programas\JavaSoft\JRE\1.3.1\lib\security>

O campo CN foi preenchido de acordo com a recomendação do representante da Thawte no Brasil. Os demais campos OU, O, L, ST e C foram preenchidos com os dados de quem detém a titularidade da aplicação. As senhas de acesso ao arquivo e de acesso ao alias deverão ser mantidas em lugar seguro.

2. Criar um arquivo com a chave pública para solicitar o certificado

Usando o mesmo aplicativo Java chamado keytool, se exporta a chave pública para um arquivo aqui chamado de certreq_thawte. Este passo precisa das senhas escolhidas no passo anterior.

C:\Arquivos de programas\JavaSoft\JRE\1.3.1\lib\security>keytool -keystore meu.keystore -alias meu_alias -certreq -file certreq_thawte
Enter keystore password: XXXXXXXXXX
Enter key password for <meu_alias>: XXXXXXXXXX

C:\Arquivos de programas\JavaSoft\JRE\1.3.1\lib\security>

3. Obter as informações da empresa e passar para a Thawte (autoridade certificadora)

Na ocasião deste pedido, a empresa Thawte era a única autoridade certificadora que dispunha de um certificado servindo para assinar aplicações desenvolvidas em Java. O representante deles no Brasil intermediou a compra feita pelo cliente e exigiu uma série de documentos e informações sobre a empresa. Estas informações foram passadas diretamente pela empresa para a Thawte/Brasil.

4. Solicitar o certificado para a Thawte usando o conteúdo do arquivo certreq_thawte

Cumpridos os acertos e tramites burocráticos, o passo seguinte foi efetuado diretamente no site da Thawte, http://www.thawte.com/html/RETAIL/devel/index.html clicando no botão buy. Os demais passos são os seguintes:

Depois de clicado em buy, aparece uma nova página mostrando um fluxograma;
Clicar em next

Na página seguinte com título “Buy a certificate”, selecionar JavaSoft Developer Certificate (These certificates can be used with JavaSoft’s JDK 1.3 and later to sign applets).
Clicar em next

Na página seguinte com título “Certificate signing request”, copiar o conteúdo do arquivo certreq_thawte para onde diz: “Paste your Certificate Signing Request (CSR) here, as generated by your software. Make sure you include the full BEGIN and END lines and all dashes.”
Preencher as condições de pagamento tal como acordado com o representante da Thawte
Clicar em next

Depois de processado o pedido, a Thawte enviou o certificado para a empresa que o repassou para a equipe de desenvolvimento assinar a aplicação.

5. Usar o certificado recebido da Thawte para assinar a aplicação
   A equipe de desenvolvimento poderia usar o aplicativo jarsigner para incluir o certificado na aplicação. Na verdade é usada uma task ant com a mesma função do jarsigner onde são assinados todos os arquivos jars correspondentes à applet a ser executada no cliente.

[]s
Luca

:shocked!:

:shock: :drinking: