Sola-Haugesund .1 Haugesund

Vedlegg E. Status og anbefalinger per kommune

SPESIELLE ARTER

11.6 Sola-Haugesund .1 Haugesund

Conceptualmente, o S3L e o SKIP (nas suas variantes ponto{a{ponto8), s~ao bastante seme- lhantes. Contudo, importa desde ja assinalar que o S3L e o SKIP operam a nveis distintos em termos da Arquitectura do Sistema Operativo e do Modelo de Comunicac~oes. O SKIP, recorde{se (rever secc~ao 3.4.2), e uma abordagem ao nvel da Camada de Rede, integra- da directamente no kernel e oferecendo, por isso, Privacidade, Autenticac~ao, Integridade, Sequenciac~ao (contra ataques{de{repetic~ao) e Compress~ao de uma forma transparente as camadas superiores. O S3L constitui, grosso modo, uma transposic~ao do modelo de ope- rac~ao do SKIP para a Camada de Aplicac~ao, tendo como objectivo fundamental facilitar a utilizac~ao daquelas qualidades de servico pelas aplicac~oes que adoptam os sockets de Berkeley como mecanismo de comunicac~ao.

As semelhancas entre o SKIP e o S3L resultam evidentes da comparac~ao da estrutura dos cabecalhos das respectivas mensagens (gura 5.1 versus gura 5.3, respectivamente). Todavia, um cabecalho S3L consome 93 bytes, ou seja, mais 33 bytes que um cabecalho SKIP na sua dimens~ao maxima. A justicac~ao para tal facto encontra-se na introduc~ao dos novos campos Source IP Address e Delta bem como nos 32 bits adicionais para o

campo n e nos 24 bytes adicionais consumidos pelo campo Kp, em relac~ao aos mesmos

campos do cabecalho SKIP. As raz~oes que ditaram a introduc~ao de novos campos bem como o incremento da dimens~ao de outros ser~ao esclarecidas, oportunamente, ao longo desta secc~ao.

Os camposVer,Rsvd,n,Kij Alg,Crypt Alg,MAC Alg,Comp AlgeKijn(Kp)desem-

penham a mesma func~ao que os campos homologos do cabecalho SKIP, mas n~ao assumem, necessariamente, os mesmo valores que tomariam no contexto desse protocolo. Situando-se o S3L e o SKIP em nveis hierarquicos completamente distintos, ent~ao a quest~ao da inte- roperabilidade entre implementac~oes de ambos n~ao se coloca. Por consequ^encia, n~ao foi feito nenhum esforco para garantir a compatibilizac~ao dos valores assumidos pelos campos comuns. Nomeadamente, a identicac~ao dos diversos algoritmos de encriptac~ao (Kij Alg

eCrypt Alg) e de produc~ao de MACs (MAC Alg) seguiu, no caso do S3L, notac~oes impor-

tadas do SecuDE, por raz~oes obvias de conveni^encia. Para os algoritmos de compress~ao (Comp Alg) usaram-se representac~oes criadas expressamente para o efeito, no ^ambito do

S3L. Os valores possveis para estes campos encontram{se discriminados na secc~ao B.2.1 do ap^endice B.

Uma diferenca fundamental entre o S3L e o SKIP diz respeito ao esquema de identi- cac~ao da origem e do destino das mensagens. O S3L simplica o esquema de identicac~ao 8A m de facilitar a exposic~ao, considerar{se{~ao, ao longo deste captulo, apenas as variantes ponto{a-

0 1 2 . . . 16

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Ver | Rsvd | Dest ID (16 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 17 18 19 . . . 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 33 34 35 36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 37 38 . . . 41 . . . 45 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Delta (32 bits) | n (64 bits) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

49 50 51 52

53 54 55 . . . 92

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kijn(Kp) - Kp encrypted in Kijn (40 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 5.3: Estrutura do cabecalho de uma mensagem S3L.

originalmente proposto pelo SKIP. Assim, o S3L opta pela utilizac~ao de um unico tipo de identicadores os quais consistem na sntese MD5 do nome distinto que identica o sujeito dos certicados X.509 das chaves publicas RSA das entidades comunicantes9. Consequen- temente, dispensam-se os campos Source NSID e Dest NSID do SKIP, denindo o S3L os campos Dest ID eSource ID, equivalentes aos camposDestination Master Key-ID e Source Master Key-ID, do SKIP. No contexto do presente trabalho, julga-se que esta perda de exibilidade em termos de possibilidades de identicac~ao n~ao constitui em si uma limitac~ao signicativa, ja que o esquema de certicac~ao importado do SecuDE (e ao qual o Skeyx e o S3L se encontram, de base, indissociavelmente ligados) implica a identicac~ao das diversas entidades com base nos nomes distintos X.500 encerrados nos respectivos certicados X.509. Assim sendo, questiona-se a necessidade de outro esquema de iden- ticac~ao. Um benefcio adicional da utilizac~ao de snteses MD5 consiste na preservac~ao do anonimato das entidades comunicantes caso as mensagens sejam interceptadas, uma vez que o mapeamento reverso das snteses MD5 e, por denic~ao de func~ao de hashing unidireccional, inviavel10.

Pelo exposto, parece n~ao se justicar a introduc~ao de um campo adicional com o ende- reco IP de origem (Source IP Address) na mensagem S3L. Na secc~ao 5.4 a necessidade 9Recorde-se que a disponibilidade deste tipo de certicac~ao e fundamental e e, inclusivamente, o unico

requisito previo (em termos de infra{estrutura de certicac~ao) para que o Skeyx possa efectuar a troca de chaves publicas de Die{Hellman n~ao certicadas.

10Desde que o domnio de partida | neste caso o conjunto de todos os nomes distintos X.500 | seja

deste campo sera devidamente fundamentada.

Comparado com o campoKp do cabecalho SKIP, o mesmo campo no cabecalho S3L consome, pelo menos, mais 24 bytes. Ora, o SKIP reserva, no maximo, 16 bytes (128 bits) paraKp. O S3L reserva o dobro, ou seja, 32 bytes (256 bits). Desta forma ca acautelada a possvel utilizac~ao futura de chaves simetricas de 256 bits. Quanto aos 8 bytes adicionais que perfazem os 24, eles n~ao fazem parte da chave, resultando da forma particular como o SecuDE implementa a variante CBC dos algoritmos simetricos (como e o caso do DES): s~ao produzidos blocos de 64 bits e, no caso das variantes CBC, e ainda adicionado mais um bloco de 64 bits. Este bloco adicional e absolutamente necessario para permitir decifrar correctamente a chave Kp contida nos 32 bytes que o precedem.

0 1 2 . . . 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S3L header (93 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 94 95 . . . 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC - Message Authentication Code (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

109 110 111 112

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| sizeof of data (32 bits) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

113 114 115 ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| data (? bits) ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figura 5.4: Estrutura de uma mensagem S3L.

A especicac~ao do SKIP [AMP95c] n~ao dene a localizac~ao do MAC, nem t~ao pouco dos dados a transportar na mensagem, deixando essa tarefa ao criterio do protocolo de- nido no campo NEXT HEADER. No caso do S3L, a estrutura completa de uma mensagem pode ser observada na gura 5.4.

O MAC e calculado pela aplicac~ao do algoritmo denido porMAC Alge da chaveAKp 11 sobre a totalidade da mensagem, considerando o campo MACinicializado a zero, uma vez que este campo e o ultimo a ser denido.

O camposize of datacontem a dimens~ao do campo de dadosdata. Essa dimens~ao e especicada em bits por forma a tornar mais expedita a utilizac~ao das func~oes de encrip- tac~ao e desencriptac~ao do SecuDE, as quais medem as entradas e as sadas em bits. Este campo e, aparentemente, sobredimensionado, dado que o IP reserva apenas 16 bits para a dimens~ao do campo de dados, sendo essa dimens~ao especicada em bytes. Todavia, uma mensagem S3L n~ao e produzida forcosamente com o objectivo de ser enviada atraves da rede. O S3L disp~oe de func~oes na sua API (ver secc~ao 5.3.3) para a produc~ao de mensagens S3L de uma forma independente dos seu metodos de transmiss~ao ou armazenamento. Por exemplo, uma mensagem S3L pode ser depositada num cheiro e entregue manualmen- te ao destinatario. Com 32 bits e possvel o processamento de dados do utilizador com

11Derivada de

dimens~ao maxima de (2 )/8 bytes, ou seja, 32768 Mbytes.

Uma mensagem S3L tem, no mnimo 114 bytes, uma vez que o campo de dadosdata n~ao pode ser vazio. Rera{se que o facto de a dimens~ao do cabecalho12 ser de dimens~ao xa n~ao e acidental. Tal facilitou bastante a codicac~ao da variante S3L das func~oes de leitura sobre socketsde Berkeley.

5.2.1 Criterios de Rejeic~ao de Mensagens S3L Repetidas

O S3L combate ataques{de{repetic~aoatraves de um mecanismo semelhante ao do SKIP e que dispensa preservar, para cada origem possvel, a ultima marca temporal13 valida. A utilizac~ao de tal mecanismo esta, alias, em plena concord^ancia com o caracterstatelessque o S3L pretende assumir. Adicionalmente, s~ao evidentes os ganhos de desempenho que se conseguem ao adoptar uma estrategia que evita a pesquisa de marcas temporais (mesmo emcache) associadas a um originador, de cada vez que se recebe uma mensagem S3L.

Os campos Delta e n de uma mensagem S3L sustentam o referido mecanismo de combate a ataques{de{repetic~ao. O campo n continua a preservar o \instante UTC" em que a mensagem e marcada pelo originador. Porem, relativamente ao mesmo campo do cabecalho SKIP, a sua dimens~ao e agora de 64 bits uma vez que a resoluc~ao dos valores temporais usados pelo S3L e o microsegundo. O novo campo Delta destina{se a parametrizar o desvio maximo admitido entre o tempo instant^aneo na recepc~ao e o tempo instant^aneo na produc~ao da mensagem (este ultimo dado por n). Relembrando que o SKIP xa o desvio numa hora14, n~ao so o S3L permite variar esse desvio, como a sua resoluc~ao e muito mais na, sendo, comon, da ordem do microsegundo. O valor deDelta pode ser encarado como uma especie de \prazo de validade" da mensagem, por forma a que repetic~oes da mensagem sejam detectadas ao vericar{se que o seu tempo de vida expirou. Quando Delta e zero isso signica que a mensagem S3L foi gerada tendo em vista um tempo de vida innito. Tal pode ser util em determinadas circunst^ancias como por exemplo: quando e completamente imprevisvel o atraso na entrega da mensagem S3L ou quando se pretende criar uma mensagem S3L e mant^e-la arquivada num cheiro por tempo indeterminado.

Podera questionar{se a necessidade de usar uma granularidade t~ao na na medic~ao de tempos e desvios entre relogios. Tal opc~ao constitui uma tentativa para contrariar as possveis janelas de ataque abertas por desempenhos cada vez maiores ao nvel das tec- nologias de rede e do poder de processamento das maquinas onde residem as entidades comunicantes. Simultaneamente, e importante lembrar que as trocas de mensagens S3L podem ser feitas entre entidades comunicantes na mesma maquina pelo que, nestas cir- cunst^ancias, o factor rede e, praticamente, irrelevante, sendo necessario reduzir ao mnimo as oportunidades de ataque.

O calculo do tempo de vida (Delta) a atribuir a uma mensagem no acto da sua pro- duc~ao n~ao e trivial. Por um lado, e difcil prever o tempo de propagac~ao atraves da rede,

12Onde, a partir de agora, se consideram tambem includos os campos

MACesize of data. 13Usada, portanto, como numero de sequ^encia.

14Na pratica, esse desvio pode ser quase de duas horas. Admitam-se, por exemplo, tempos UTC, tal que

no emissornE= 1000 horas, resultante da convers~ao, para horas, do tempo 9993600 + 1 segundos, e no

receptorn

R= 1001, resultante da convers~ao, para horas, do tempo 1001

3600 segundos |i.e., o ultimo

segundo da hora 1001 |; neste caso nR,nE = 1 mas, em segundos, a dist^ancia temporal corresponde

uma vez que o seu estado e, por natureza, imprevisvel. Adicionalmente, os relogios das en- tidades comunicantes n~ao se podem supor, no caso mais geral, sincronizados. Ainda assim, e possvel estabelecer estimativas parapor forma a minimizar a vulnerabilidadeaataques- -de{repetic~ao. De seguida, apresentam{se os casos tpicos possveis em termos de sincro- nizac~ao dos relogios do emissor e do receptor, bem como os criterios de aceitac~ao/rejeic~ao das mensagens S3L, incluindo as respectivas estimativas para . Todos os tempos em causa se sup~oem normalizados para o respectivo valor UTC.

Emissor e Receptor Sincronizados

O caso mais simples (e tambem o menos provavel) corresponde a situac~ao em que os relogios do emissor e do receptor est~ao sincronizados (ver a gura 5.5).

Emissor tE0 Receptor tp tR tR’ tE0

Figura 5.5: Emissor e Receptor sincronizados. Sendo t

p o tempo de propagac~ao, ent~ao o criterio de aceitac~ao de uma mensagem originalmente produzida no instante t

E0 e recebida no instante t R sera t R ,t E0 , com =t

p. A repetic~ao recebida no instante t

0 n~ao e aceite dado que t R 0 ,t E 0 >.

Emissor Atrasado Relativamente ao Receptor

tE0 tp tR tR’ Emissor Receptor tE0 av tE0 + av

Figura 5.6: Emissor atrasado relativamente ao Receptor. Neste caso (ver gura 5.6), a aplicac~ao do criterio de aceitac~ao t

R ,t

e valido desde que o emissor tenha estimado = av+t

p, sendo

av o avanco que o relogio do receptor tem sobre o relogio do emissor.

Emissor Adiantado Sobre o Receptor

Emissor tE0 Receptor tE0 - at at tE0 tR tR’ tp Emissor Receptor tE0 tE0 - at tp tR tE0 tR’ at tp < at tp >= at

Figura 5.7: Emissor adiantado relativamente ao Receptor.

Existem dois casos possveis (ver gura 5.7), conforme a relac~ao entre o tempo de propagac~ao e o atraso entre os relogios:

1. tempo de propagac~ao superior ao atraso dos relogios (t p at): a aplicac~ao do criterio de aceitac~ao t R ,t E 0

ainda e valido desde que o emissor tenha estimado =t

,at, sendoato atraso que o relogio do receptor tem relativamente ao relogio do emissor;

2. tempo de propagac~ao inferior ao atraso dos relogios (t p < at): o criterio de acei- tac~ao e agora t E 0 ,t R

desde que o emissor tenha estimado =at,t p.

Estimativas para

Uma vez que a determinac~ao correcta dos desfazamentos av e at e do tempo de propa- gac~aot

pe difcil, podem usar{se aproximac~oes para

tendo, todavia, a consci^encia de que se abrem janelas de ataque cuja dimens~ao depende, obviamente, da qualidade da aproxi- mac~ao. Assim, quando o criterio de aceitac~ao et

R ,t

E 0

, pode usar{se um majorante de . Quando o criterio de aceitac~ao et

E 0

,t R

, fornece{se um minorante de .

In document Veileder til startpakkene for kartlegging av marint biologisk mangfold (sider 43-68)