Dll- c#

Oct 12, 2013 at 11:03 PM
ola a todos. este é o meu 1 post nesta comunidade. a razão deste post é que eu preciso da vossa ajuda.

preciso de desenvolver uma aplicação windows em c# para leitura dos dados gravados no cartao do cidadão.

Andei a ler aqui no site, e o que preciso é a vossa orientação sobre o caminho a seguir.

Li algo sobre a necessidade a instalação do Middleware do Cartão de Cidadão. mas essa questão eu tenho de descartar, necessidades do projecto.

Sera que nao existe uma dll em c# ou penso que se for noutra linguagem sera possivel fazer o pinvoke como é referido neste exemplo: http://www.moythreads.com/wordpress/2008/02/04/pinvoke-how-to-call-c-from-c/

agradecia a vossa ajuda nesta minha tarefa.
Coordinator
Oct 14, 2013 at 4:43 AM
Caro expressdual,

Que eu tenha conhecimento, tal biblioteca não existe, em qualquer linguagem !

Ao definirmos os requisito (ou necessidades) do projecto, temos de avaliar são realistas e exequíveis.
Com isto vou tentar enumerar da melhor maneira as operações necessárias para interagir com SmartCards (SC) e Leitores de Cartões (CR).

SC <-> CR <-> Kernel <-> Win32 API <-> App Nativa
SC <-> CR <-> Kernel <-> Win32 API <-> .NET <-> App .NET

Com isto o que é necessário desenvolver é:
1 - Aplicação (ou biblioteca) que interage com a Win32 API (em concreto o "subset" para interacções com SC e CR)
Detectar leitores de cartões, detectar cartões inseridos, enviar comandos APDU para o cartão (a fim de obter a informação nele contida, escrever informação, efectuar outras operações)
Comandos APDU são comandos de Hardware enviados ao CR para efectuar operações no SC, que estão implementadas na biblioteca (C:\Windows\System32\pteidlib.dll) disponibilizada pelo Middleware do Cartão de Cidadão.

2 - A "aplicação de negócio" que decide o que fazer aos dados (MAS a aplicação de interacção com o SmartCard pode ser a nossa própria!)

Se juntarmos a questão de segurança (criptografia), além de comandos aos SC é necessário no caso de Windows, interagir com CSPs (Cryptografic Service Providers) ou a CriptoAPI.
Exemplo: Quando um aplicação que necessita de (utilizar a chave privada de cada cartão para) encriptar dados invoca uma "função" que o que faz é utilizar um CSP que pede ao cartão a chave privada, o cartão diz "não não, preciso de um pin", o CSP exibe uma janela ao utilizador para introduzir o PIN, e só depois é que o cartão disponibiliza a chave para encriptação e o resultado da operação criptográfica é retornado à nossa aplicação.
No caso do Cartão de Cidadão, a caixa de diálogo exibida, consta da biblioteca (pteiddlg.dll) que o CSP utiliza para pedir ao utilizador o PIN, (não é a janela standard do windows).


Como pode ver, isto é desenvolvimento de baixo nível, com várias componentes para diferentes operações, o qual hoje em dia está por regra abstraído em bibliotecas e frameworks.
Além do mais no caso de SmartCards para identificação e com criptografia avançada, podem existir especificidades para operações em cada tipo de cartão (como é o caso do nosso Cartão de Cidadão) que para tal em vez de utilizar a OpenSC, utiliza a mesma ajustada ao nosso cartão (C:\Windows\pteidlibopensc.dll). No entanto, desde a versão 0.12.0 da OpenSC, as funções do nosso cartão já são suportadas.

Ou seja, o próprio Middleware, utiliza bibliotecas na sua implementação (para as operações criptográficas) e apenas os comandos APDU, foram implementados por eles. (Sim também desenvolveram interacções com CSP e outros, o apenas não é diminutivo, serve como "resumo").

Escrevo isto tudo, para registo futuro, e para lhe explicar que a meu ver o seu requisito de não ser possível instalar UM middleware do Cartão de Cidadão, não me parece ser realista.
Eu digo, UM middleware, porque existe o Oficial e o Open Source

Não digo que não é exequível, porque não há impossíveis, mas a exequidade é relativa a certas variáveis, as quais eu desconheço no caso do seu projecto.

Espero ter sido útil e se tiver mais alguma pergunta avise.

Cumprimentos,
Fernando Nunes
Mar 10, 2014 at 1:38 PM
Boa tarde,

Estou a trabalhar num projecto onde neste momento estamos a integrar o cartão do cidadão, e o facto de ter de instalar o middleware está-nos a causar um problema nos nossos clientes que não vão dar utilidade à funcionalidade, isto é, nos clientes onde não vamos ter um SmartCards para leitura dos dados do cartão do cidadão não é muito prático ter que instalar o middleware. Mas não instalando o middleware irá sempre ocorrer uma excepção

Existe alguma maneira de ultrapassar esta situação?

Cumprimentos,
Luís Garcia
Mar 10, 2014 at 3:26 PM
Olá.

A solução que arranjei foi ter uma configuração que indica se a aplicação deve usar o cartão de cidadão ou não no PC onde está instalada. No meu caso, essa configuração está na base de dados.
Se a configuração indicar que naquele PC a aplicação não deve usar o cartão de cidadão, código que usa o cartão de cidadão nunca é invocado, evitando assim a ocorrência de excepções resultantes do facto de o software do cartão de cidadão não estar instalado.

Outra hipótese é ter código que verifique se o middleware do cartão de cidadão está instalado no PC e não executar código do cartão de cidadão no caso de o middleware não estar instalado. Não sei se haverá problemas no caso de o utilizador não ser administrador do PC porque o código que conheço implica aceder ao registry, o que poderá não ser permitido pelo sistema operativo.

Cumprimentos,
Álvaro Alves
Coordinator
Mar 10, 2014 at 5:14 PM
Boas tardes,

Caro Luís, a situação que refere é passível de ser efetuada mas é trata-se de Arquitetura de Software.

O que o Luís pode fazer é criar uma abstração para a leitura dos dados do cartão (acções efetuadas), bem como dos dados lidos (as classes Id, Address, Picture, etc...) e isso faz-se pelo uso de Interfaces e Dependency Injection.

1 - O luis passa toda a funcionalidade de leitura de dados do cartão para uma biblioteca "isolada" (Assembly A).
2 - Cria interfaces em uma outra biblioteca que já exista (ex, Assembly B)
3 - A biblioteca / console app / win app, que precisa, ou não dos dados, referência a biblioteca B e nunca a A diretamente, que é o que ocorre atualmente.
4 - A win app que utiliza os interfaces, faz uso de um Dependency Container (Autofac, Funq, Castle Windsor, Unity, etc...) para registar e utilizar as implementações.

Deste modo, cria-se uma abstração da implementação, ou seja, de qualquer biblioteca que utilize o Middleware do Cartão como é o caso da eidpt. A biblioteca

A eidpt não foi pensada para esse cenário, mas o código fonte está ai e pode sempre ser alterado, ou essa indirecção/abstracção, pode ser criada ainda em mais alto nível, depende tudo do projeto em questão e da respetiva arquitetura do mesmo.

Se necessitar de mais algum esclarecimento avise.

Cumprimentos,
Fernando Nunes
Mar 10, 2014 at 6:01 PM
Obrigado a ambos pela ajuda.

Cumprimentos,
Luís Garcia
Mar 14, 2014 at 11:35 AM
Boa noite,

Agora estou com um problema em algumas máquinas com Windows a 64 Bits. Em máquinas com instalações "limpas" do windows não tenho esse problema.
Está a dar o erro "Could not load file or assembly 'eidpt.dll' or one of its dependencies. Impossível localizar o módulo especificado." e não consigo encontrar uma solução.

O projecto está a ser compilado para x86, tenho a middleware oficial, a redistributable package 2012 e a .framework 4.0 instalados, mas mesmo assim continuar a dar o erro.


Cumprimentos,
Luís Garcia
Coordinator
Mar 16, 2014 at 2:36 AM
Edited Mar 21, 2014 at 6:46 PM
Caro Luis, O Middleware oficial que está instalado é o de 32bits ?