Hassane Aissaoui-Mehrez

Pascal Urien
email: pascal.urien@telecom-paristech.fr

Guy Pujolle
email: guy.pujolle@lip6.fr

Framework Implementation Based On Grid of Smartcards To Authenticate Users and Virtual Machines

Keywords: OpenID, Microcontrollers, Secure Elements, User-Centric Identity, Virtualization and Cloud Computing

The Security for the Future Networks (SecFuNet) project proposes to integrate the secure microcontrollers in order to introduce, among its many services, authentication and authorization functions for Cloud and virtual environments. One of the main goals of SecFuNet is to develop a secure infrastructure for virtualized environments and Clouds in order to provide strong isolation among virtual infrastructures, and guarantee that one virtual machine (VM) should not interfere with others. The goal of this paper is to describe the implementation and the experimentation of the solution for identifying users and nodes in the SecFuNet architecture. In this implementation, we also employ low-cost smartcards. Only authorized users are allowed to create or instantiate virtual environments. Thus, users and hypervisors are equipped with secure elements, used to open TLS secure channels with strong mutual authentication.

INTRODUCTION

The IdM system will be based on smartcards OpenID and user-centric attribute control policies. The authentication servers are composed by secure microcontrollers. The objective is to implement the framework, based on the authentication servers and EAP-TLS smartcard model. The proposed SecFuNet framework provides TLS secure channels for establishing trust relationships among Users, VMs, XEN and Grid of Secure Elements (GoSE). The authentication is done directly between smartcards (owned by users or associated to VM) and a GoSE arranged in a SecFuNet IdP. This paper concerns a highly secure authentication server with an array of secure microcontrollers allowing users' or VMs' strong mutual authentication with GoSE. It defines the structure and the components of the authentication server. This paper is organized as follows. Section 2 presents a related work and a brief state-of-art of EAP-TLS Smartcard Concept and Software Architecture. The next section 3 details the use of TLS-Id based on EAP-TLS smartcard in OpenID platforms. In the section 4, we detail how dedicated Service Provider may be used to download tokens in EAP-TLS smartcard?.

RELATED WORK

To address some of the security issues, the project aims to explore the application of secure elements, such as smartcards, to improve the trustworthiness of network infrastructure services for future networks. Two classes of secure microcontrollers have been studied, smartcards and TPMs (Trusted Platform Modules).

These electronics chips have different computing capabilities, smartcards usually run a Java Virtual Machine (JVM) and therefore are able to execute complex procedures (such as the TLS protocol), while TPMs are dedicated to the RSA algorithm. However these devices may be used in order to enforce trust for the TLS protocol or to guarantee secure storage for cryptographic keys.

These security properties are directly provided by smartcards (thanks to dedicated embedded software), but require additional software components for TPMs.

The main goal of this section is to briefly overview the context of the virtualization platforms and EAP-TLS smartcard model.

Extensible Authentication Protocol (EAP) and TLS

The EAP (RFC 3748, 2004) is a flexible framework targeting access control in various network infrastructures such as classical LAN, wireless LAN, or VPNs. Furthermore the EAP-TLS (RFC 5216, 2008) standard enables a transparent transport of TLS in EAP messages; it offers a convenient way to use TLS without TCP flavours, and provides mechanisms for TLS packets segmentation and reassembly. The SecFuNet TLS platform is based on EAP-TLS smartcards, equipped with additional facilities. These devices include a full TLS stack, an entity managing X509 certificates, and provide a secure environment for keys storage and cryptographic procedures execution. The TLS master stack forwards packets, which are thereafter encapsulated in EAP-TLS messages "Figure 1". When it detects the completion of this phase (trigged by finished messages) it uses two ISO7816 commands (APDUs) in order to retrieve CipherSuite and KeyBlock parameters.

EAP-TLS Smartcard Concept

In this section we focus on EAP-TLS smartcard and TLS Identity (TLS-Id) deployed in SecFuNet. A smartcard [START_REF] Jurgensen | Paper Prentice Hall PTR[END_REF] is a tamper resistant device, including CPU, RAM and non volatile memory.

Most of the electronic chips (i.e. smartcard) support a JVM and execute software written in this programming language [START_REF] Chen | [END_REF].

The use of smartcards in TLS authentication has now a rather long history and has been largely developed according to different models.

These devices run the JAVA open stack, introduced in [START_REF] Menon | Proceedings of the annual conference on USENIX '06 Annual Technical Conference, ATEC' 06[END_REF] and which comprises four logical components. The software architecture of the EAP-TLS smartcard [START_REF] Pujolle | WILEY, Security and Privacy for the next Wireless Generation[END_REF] [START_REF] Urien | IETF draft, EAP-Support in Smartcard[END_REF] is the following:  An EAP engine, which implements four fundamental services (EAP messages treatment, identity management, security functions, and personalization) and ensures EAP routing towards authentication methods supported by the card.  EAP-TLS method, which manages fragmentation and reassembly mechanisms.  TLS stack. The Handshake protocol takes responsibility of authentication mechanisms, whereas the record protocol realizes the encryption and the integrity of data securely transported by the TLS tunnel.  A certificates store.

The TLS-Identity (TLS-Id) is a set of five parameters, which comprises:

 X509 certificate and its associated private key;  Certification Authority certificate;  EAP identity parameter (EAP-ID);  Friendly name, used to identify and to activate a given TLS-Id. These parameters are embedded in the secure microcontroller hold by SecFuNet users, during the personalization process.

TLS Choreography with EAP-TLS Smartcard

The TLS-Tandem card is plugged to a SecFuNet host, such as personal computer or mobile handset. Before opening a session with a TLS server, its electronic identity is activated via the Set-Identity command. The host intends to download a file, typically through an HTTP request, which is securely stored in a remote WEB server "Figure 2". The docking host manages TCP/IP operations and opens a connection with a remote TLS server, and then calls the connection procedure.

This latter resets the TLS-Tandem card, and sends an EAP-TLS-Start packet concatenated to Unix-Time; the smartcard produces a response including the first TLS message. A software component acts as a bridge between EAP-TLS and TLS.

It removes EAP-TLS header (typically 10 bytes), and sends TLS messages to remote server. It reads incoming data, detects TLS error, and determines the end of TLS messages such as:

 ServerHelloDone that indicates a four ways handshake associated to a full session.  Finished that indicates a three ways handshake associated to a resume session. Thereafter it packs this set of TLS messages in a single EAP-TLS packet, appends a 6 bytes prefix, and forwards this request to the card. The card generates a response which is processed by the EAP-TLS/TLS bridge and transmits to the server.

Upon, the docking host collects two parameters from the smartcard: CipherSuite and Key-Block. The procedure is over. Thereafter smartcard is not used, and the docking host encrypts and decrypts information, which are sent and received to/from remote server. These operations are done via the TLS-write and TLS-read() functions.

EAP-TLS SMARTCARD AND OPENID

OpenID is a Single Sign On system made of three entities, the consumer site requiring a user authentication, the OpenID server performing the user authentication, and an internet user equipped with a terminal. The OpenID identifier is an URL that comprises two parts the name of the OpenID server and the user alias.

There are many ways to perform authentication between the user and the OpenID server. The most popular is the simple password mechanism.

In the SecuFuNet context we use a strong mutual authentication based on a TLS session running in the EAP-TLS device, in which all resources (i.e. client, VM, server…) are identified by their X509 certificates and associated private keys.

Service Discovery and Shared

Secret Computing.

In the OpenID context the user identity is associated to an URL. The SecFuNet user equipped with a secure element, logs to the Service Provider (SP) WEB site, where he gives his identity and indicates the solicited service. The SP deduces from the user's identity the OpenID server name. The consumer starts a discovery (XRI) procedure with the provider and collects the XRDS server address. These two entities exchange thereafter resource descriptors encoded according to the XRDS format.

Afterward the server and the consumer perform a classical Diffie-Hellman key exchange (DH) of their public keys, in order to compute a symmetric shared secret used to enforce message integrity thanks to a HMAC procedure.

Authentication with the SEs

The OpenID authentication server receives the Authentication Request, as an HTML POST message issued by the user's terminal. It thereafter returns an HTML form "Figure 3".

In a classical provider implementation, the user would be identified by a password collected by this form, the login page being protected via a TLS session. In the SecFuNet platform we suppress this password, and we replace it by a TLS session with mutual authentication (i.e. both sides hold X509 certificate and RSA private key), initiated by the EAP-TLS secure element.

The login page is associated to an HTTP header including a cookie whose value is the session identifier (sid), and the associated URL also comprises this value, i.e. looks like: When the user clicks on the AutoLogin button it opens via its EAP-TLS token the https//server.com/login.php?sid link, and is consequently authenticated by its X509 certificate.

The HTTP response to this request will set the cookie (sid) for the proxy address (dealing with the loopback address such as 127.0.0.1:8080).

A second optional exchange occurs between the provider and the browser (secured by the EAP-TLS token), in order to confirm the association with the consumer site. This step may be used for downloading attributes in the EAP-TLS secure element.

Authentication Response

After a successful authentication, the Authentication Response is returned by the OpenID server to the user's terminal. It is thereafter redirected to the consumer site, which finally delivers a welcome page. As detailed "Figure 4" an Authentication Response message is delivered by the SP.

It is a set of response parameters included in location MIME header. Data integrity is enforced by an HMAC field associated with the OpenID secret key, computed from the previous DH exchange.

LOADING CRYPTOGRAPHIC TOKENS IN SMARTCARD.

The goal of this section is to detail how dedicated SP may be used to download tokens in EAP-TLS smartcard. The user attributes instantiated by tokens are stored in a secure element. Two use cases are described in order to load cryptographic token in smartcard: the use of a classical WEB interface to authenticate user with its EAP-TLS Secure Element based on the AJAX technology, and the use of GoSE operations to authenticate VM.

User Authentication Using SE

As described in previous sections the SecFuNet user is equipped with an EAP-TLS secure element "Figure 5". In order to collect tokens, it performs a connection with the appropriate service provider. He enters his identity and is thereafter redirected to "adhoc" OpenID server. The server forwards a login page and an authentication is performed by the EAP-TLS secure element. Afterwards the OpenID server delivers a page that interacts with the EAP-TLS secure element. The interaction between the server and the EAP-TLS Secure Element is based on the Asynchronous JavaScript and XML (AJAX).

AJAX is a set of technologies for executing applications on the browser side, triggered by user's interactions, typically mouse clicks associated with HTML forms, and processed by JavaScript procedures. AJAX pages are downloaded by the user's terminal. The user's terminal is running a TCP daemon that we call the Proxy Server (PS), opened on the loopback address (127.0.0.1), usually with the port 8080. Its interface is made by two kinds of URLs, used for network exchange and EAP-TLS secure element.

The first class of URLs (Class I), such as: http://127.0.0.1:8080/~url=www.server/path/file.htm l, opens an HTTPS session the remote server (i.e. is equivalent to https://www.server/path/file.html).

The TLS session is booted from the EAP-TLS secure element and then transferred back to the PS. As a result the browser opens HTTP session with remote servers that are authenticated via the USIM. The second class of URLs (Class II), such as: These requests transport ISO7816 commands, executed afterwards by the EAP-TLS secure element. The proxy returns ISO7816 responses, embedded in XML pages. These XML contents are parsed and thanks to the DOM (Document Object Model for JavaScript) the initial page is modified, typically with a success status.

"Figure 6" illustrates AJAX interaction with the EAP-TLS secure element. An ISO7816 command is hidden in an HTML form; it is thereafter executed by the proxy server.

Thanks to these mechanisms the OpenID server pushes content in the EAP-TLS secure element. During the authentication procedure the OpenID server collects the certificate of the EAP-TLS secure element, which contains a public key.

This cryptographic material may be used to build a container, able to securely convey token to be downloaded in the EAP-TLS secure element. A set of ISO7816 commands, embedded in AJAX pages, realizes operations needed for container downloading. A container is made of three parts:

 A header, which is the encrypted value of a symmetric AES key, with the EAP-TLS secure element public key, according to the PKCS#1 standard.  A body, which is the encrypted value of the token, according to an AES-CBC procedure.  A trailer, which is the signature by a trusted authority (identified by its public key) of the header concatenated to the body, according to the PKCS#1 standard. Upon downloading, the signature of the container is checked; the AES key is recovered from the EAP-TLS private key, the token is afterwards decrypted and stored in the smartcard.

VM Authentication Using GoSE

As previously mentioned, each VM is associated to an identifier (VM ID , i.e. a certificate), and the VM Authorization Token (VM-Auth-Token) establishing the link with the hypervisor (identified by its identifier HV ID ) that hosts the VM. Each VM is also associated to a secure element, plugged in a grid, which securely stores its private key.

In order to remotely work with its private key, the VM must interact the service provider that interface the GoSE. The VM is authenticated by the VM ID , and the hypervisor private key and VM-Authtoken. This use case is illustrated by "Figure 7".

The VM may access to the private key of the hypervisor stored in a secure element. It establishes a session with the grid service provider, and provides the HV ID , VM ID and VM-Auth-Token parameters. It also request cryptographic operation with the GoSE, such as encryption or decryption with the VM private key. It is thereafter redirected toward the OpenID server that performs the authentication process with the HV secure element.

Strictly speaking the OpenID authenticates the hypervisor, and it is not aware of an existing functional link with the VM.

At this step the service provider knows that the remote entity has access to the HV private key and is supplied with the appropriate credential (VM-Auth-Token). The GoSE service provider realizes the requested operation and returns the result.

Obviously the session between the VM and the GoSE service provider must be secured by the TLS protocol (i.e. HTTPS requests are used).

In order to get a greater security level, the GoSE service provider may pack the result in a container, which is made of three parts:  A header, which is the encrypted value of a symmetric AES key, with the HV public key, according to the PKCS#1 standard.  A body, which is the encrypted value of the result of the requested operation, according to an AES-CBC procedure.  A trailer, which is the signature by a trusted authority (identified by its public key) of the header concatenated to the body, according to the PKCS#1 standard. Some trust issue may exist between the grid SP and the VM, because they don't necessarily share the same ring of confidence. In that case the container could be directly generated by the VM secure element, previously bound to an HV ID . This operation is performed by administrator of secure element thanks to Global Platform mechanisms.

TLS sessions with strong mutual authentication are mandatory for all virtual machines (VM). Thus, we implement the TLS Application in VM-side and the Secure Middleware in Xen-side, including a very simple facility to access GoSE, in order to enforce a remote VM access to secure element and to secure connections and transactions.

CONCLUSION

The architecture proposed and implemented in this deliverable presents a secure solution for user or VM connection in the context of the SecFuNet, based on grid of secure elements. This integration provides a higher level of security when compared to traditional password authentication, and establishes trust relationships among the resources, and eliminates the vulnerabilities like phishing attacks.

Strong authentication is done directly between smartcards (owned by user or associated to VM) and a GoSE.

We have seen in this paper that the use of secure elements can make a real highlight in the certificate management and the application of a security policy.

For large infrastructure, add our Secure Middleware brings the real simplicity of management. In parallel, can be very interesting solution to access securely to a remote specific area of GoSE.

The experimental results of the platform developed for SecFuNet demonstrates that the scalability performances are compatible with today constraints.

Furthermore, the smartcard shall be a great addition to virtual architecture and will be as well as a key asset to securing Cloud Computing infrastructures.

Figure 1 :

 1 Figure 1: The EAP-TLS Header

Figure 2 :

 2 Figure 2: A TLS session dealing with EAP-TLS smartcard

Figure 3 :

 3 Figure 3: OpenID form used for user authentication

Figure 4 :

 4 Figure 4: OpenID Authentication Response Message

Figure 5 :

 5 Figure 5: User token generation and downloading

Figure 6 :

 6 Figure 6: Interaction between EAP-TLS SE and OpenID

Figure 7 :

 7 Figure 7: Grid SP operations in an OpenID context

ACKNOWLEDGEMENTS

This work has had financial support from CNPQ through process 590047/2011-6 (SecFuNet project) and also through processes 307588/2010-6 and 384858/2012-0. We also thank CAPES for the financial support with PhD scholarship.


Hassane Aissaoui

Pascal Urien
email: pascal.urien@telecom-paristech.fr

Guy Pujolle
email: guy.pujolle@lip6.fr

Low Latency of Re-Authentication During Handover: Re-Authentication Using a Signed Token in Heterogeneous Wireless Access Networks

Keywords: Wirless, Roaming, Handover, Digital Signature, Signed Token, Trusted Infrastructure, (Re)-authentication, (Re)-association, Mobility Anytime Anywhere, Ubiquitous Access, Low Latency, Real-Time Applications, AAA Framework, IEEE802.1x/EAP Protocol

Wireless networks provide several advantages over wired networks. They offer: a satisfactory bandwidth, mobility, easy deployment in difficult areas, long-term savings and the speed more and more higher. However, they also have some disadvantages in regard to security, performances during re-authentication, execution of real-time applications and interference from other electromagnetic sources (Bluetooth, microwave, etc.).

The existing solutions to reduce delays of Handover intercellular are specific solutions to a particular network or manufacturer of this technology.

The main objective of this paper is to propose novel mechanisms based on digital signatures to obtain low latency re-authentication during Handover in Wireless Access Networks. Our infrastructure will be based on trusted relationship between the heterogeneous access points and the authentication servers, in order to allow the mobility anytime anywhere to any user, and the ubiquitous access to the Future Internet, while ensuring the right level of security to both the end users as well to the wireless networks.

In this context, the main issues are to resolve the seamless Handover and the re-authentication during mobility of station. By using a signed token in our trusted infrastructure, we achieve a unique authentication and a fast re-authentication. Therefore, the requests to the authentication server are considerably limited.

INTRODUCTION

Unlike the Global System for Mobile Communications (GSM), the concepts of "Roaming and Handover" represent different actions.

In general, the process of handover is natively implemented in Mobile Station (MS), Base Station Controller (BSC) and Mobile Switching Center (MSC). The handover process in GSM involves four steps: the measurement, the request, the decision and the execution of handover. The request of the handover is generated by the BSC, and the decision is provided by the MSC. the other steps can be maintained by the BSC.

In wireless technologies, the Handover is a process that represents a mobility of the mobile node (MN) to another target Point of Attachment (PoA), which offers a higher radio link quality.

The Handover is a fundamental mechanism in the inter-cellular communication; involving a set of operations that allows the mobile station to change the PoA without losing the connectivity and the session. These operations generate several steps and every single step causes delays and has an impact on the real-time applications such as Voice over IP (VoIP).

The rest of this paper is structured as follows: In (Section 2), we present an overview of the constraints and the causes of the inter-cellular delays and the impact of security on the Handover. In (Section 3), we examine proprietary solutions and improvements to the Wireless Local Area Networks (WLAN) or IEEE 802.11 Standards (WLAN 1997).

We will analyze, (Section 4), the WLAN Standards and Authentication, Authorization and Accounting Framework (AAA, 2000) which is based on Extensible Authentication Protocol [START_REF] Eap | Extensible Authentication Protocol[END_REF]. In (Section 5), we illustrate the advantages and properties of digital signature that allow privacy and authenticity of a message, freshness against replay attacks / anti-replay, non-repudiation and anonymity (ISO 7498-2:1989). In (Section 6), we present our contribution which involves the use of asymmetric cryptography to sign tokens after client authentication, how this token save the context of a user session and how the stations perform a fast reauthentication during a Handover with this token?

Finally, we present in (Section 7), a conclusion and perspectives for future work.

INTERCELLULAR HANDOVER PROBLEMS

Delays Due to Technology IEEE 802.1X Protocol

Delays due to Handover have been for a long time a recognized problem in wireless networks.

Certain experimental studies [START_REF] Mishra | An empirical analysis of the IEEE 802.11 mac layer handoff process[END_REF] & [START_REF] Velayos | Techniques to reduce the IEEE 802.11b handoff time[END_REF], attributed the delay in the IEEE 802.11 networks to the following phases: scanning, re-initialisation, reassociation and re-authentication, during which a wireless station discovers neighboring access points.

According to [START_REF] Zrelli | Experimental evaluation of EAP performance in roaming scenarios[END_REF], the use of EAP authentication causes significant delays regarding the re-authentication phase. Indeed, the EAP is a component of the AAA Framework to secure and control access to different networks.

In this centralized Framework, the delays due to the EAP protocol, during re-authentication phase of a mobile station can become a problem, especially in the use of real-time applications.

When the mobile station moves to a new AP, it loses its attributes and continuity of the session, and must re-authenticate again with the centralized Framework. This process of the re-authentication greatly increases latency during the Handover.

Constraint of Real-Time Applications

VoIP is a real-time application, which imposes itself as the main application to test the validity of the performance of Handover in the wireless network. Indeed, the main constraint of VoIP is the continuity of the flow so that there is no break in the conversation [START_REF] Da Conceicão | Is IEEE 802.11 ready for VoIP?[END_REF], because human ear perceives a break of the voice greater than 50 ms during a VoIP communication.

OVERVIEW OF SOLUTIONS THAT IMPROVE HANDOVER

In real-time applications, it is important to reduce the time of re-authentication and re-association during the Handover process while supporting advanced security mechanisms. (IEEE 802.11i), but it is not easily adaptable to the mobility of real-time applications [START_REF] Bangolae | Performance study of fast BSS transition using IEEE 802.11r[END_REF]. Implementing a caching mechanism in 802.11i has not improved the time roaming, it is around 350 milliseconds. This time of switching to a new AP is 7 times higher than the maximum latency for VoIP (which is about 50 ms).

In (Table 1), it shows the average time roaming (525 ms) and packet loss (1.8%) using basic authentication 802.11i, especially when there is a traffic load of the back-end (eg: Remote Authentication Dial In User Service) [START_REF] Radius | Remote Authentication Dial In User Service[END_REF].

The first solution developed to reduce the latency in Handover is the Inter Access Point Protocol (IAPP). Based on IAPP, the Institute of Electrical and Electronics Engineers (IEEE) in 2003 led to the drafting of a "Trial-Use Recommended Practice" which presents the 802.11f [START_REF] Iapp | IEEE Trial-Use Recommended Practice for Multi Vendor Access Point Interoperability Via an Inter Access Point Protocol (IAPP) Across Distribution Systems Supporting IEEE 802.11 Operation[END_REF]. The deployment of this recommendation has been virtually no communication. Despite this ratification, the manufacturers have continued to methods of Roaming in their w technologies. It was abandoned in reasons, in particular the very latency.

IEEE 802.1X / EAP AN FRAMEWORK

IEEE 802.1X

The Port Based Access Control protocol is developed by the IEE control ports (IEEE 802.1X, 2001) to a network after authentication wireless network. The main com mechanism are presented as followi Supplicant: the system authenticated (station: STA).

Authentication Server (AS) user accounts (AAA Framework, Authenticator: network equi the role of mediator between th Point, Switch ...) and AS.

Each AP shares a secret with AS to perform mutual authentication secure channel.

AND AAA

rol or IEEE 802.1X EEE based on the 1). It allows access n from a wired or omponents of this wing:

that will be S): that manages rk, RADIUS). uipment that plays the STA (Access AS, to enable them on and establish a f authentication. cret with the AS, ssword, as the STA not allow it access anges related to ed to the AS by the ted, the AP permits ure 1".

IEEE 802.1i and E

IEEE 802.1X is based on methods that are specified in th and respect the requirements 4017, in order to provide m between a station (STA) and There are two kinds of traffic E EAP over LAN (EAPoL (EAPoW): EAP is t specific frames between and Authenticator (AP). EAP over RADIUS (EA frames transported betw authentication server between both is a simple EAP packets without m of the package by the AP EAP is a transport protoco defines mechanisms for exch between devices. In order to wireless network infrastructur authenticated.

As shown in phase 0, "Figu of course, the association 802.1 which must be done pre authentication phase.

DIGITAL SIGNAT

One of the main advant cryptography is that it offers th digital signatures. According signatures are used to ve properties: the authenticity o electronic message, but also t and non repudiation.

The digital signature (M Chapter 11) proves to the recip it has been signed by the a authentic and difficult to imita and is an integral part of the do The Asymmetric Cryptogr asymmetric keys (public / pr mathematically related. An e decryption key are different; calculated from the other.

In general, one of the keys by everyone. This key will be encrypt a message. The o extremely difficult to find decrypted by the person who secret key called the private ke

ATURES

antages of asymmetric s the possibility of using g to ISO 7498-2, these verify the following of the author of an o to ensure its integrity [START_REF] Menezes | Handbook of Applied Cryptography[END_REF], cipient of a message that e author, because it is itate. It is not reusable, document.

graphy consists of two private). The keys are encryption key and a nt; one key cannot be eys is public and known be used by any person to original message is d as it can only be ho possesses the second key.

ption with an Asymmetric mmetric encryption is crypts the text using the an decrypt the text with rypt a message securely nly the person with the l Signature. the opposite principle of 4".

Alice encrypts a message with The result obtained can be decrypted the associated public key. This con has signed the content of this mess repudiate it and can be verified by a When the document is volumi first hashed into just few lines. This a message digest. Then, the messag encrypted using the private key. T digital signature. This digital signa to the document and sent to the recip First, the recipient decrypts the (using public key) and obtains the Then, the recipient hashes the rec into a new message digest. If th digests are the same, the recipient signed data has not been changed.

CONTRIBUTIONS

As mentioned above, in order to to a wireless network infrastructure be authenticated and must share with a PoA (an AP) "Figure 3". T has no role and exchanges continue STA. The AP makes decisions on g the LAN.

Our approach consists to reuse between the STA and the AP authentication to ensure the continu of the STA.

Principle of Virtual ES

At the beginning of wireles protocol exchanges between STA much simpler. The packet numbe connection, was mainly of four secure standards, the number of me considerably.

Our proposes e IEEE 802.11i standard, which allo switch faster and seamlessly from o target. The idea is based on the sign Asymmetric Cryptography to est infrastructure. This trusted infras considered as a wireless network the same ISP "Figure 5" and consist AS & AP.

In this large infrastructure of di we use multiple AS to simplify m ensure the scalability of the infrastru ith her private key. ted by anyone with confirms that Alice essage. She cannot y a third party. minous, it must be his process is called sage digest must be . The result is the nature is appended cipient.

he digital signature the message digest. received document the two message ent knows that the to obtain an access ture, the STA must e the MSK secret . Therefore, the AS ue between AP and n granting access to se the MSK, shared AP, in each renuity of the session

ESS (VESS)

less network, the TA and AP were ber, to establish a r messages. With messages increased enhancements to allows a station to one AP to another igned token with an establish a trusted rastructure can be rk infrastructure of sists of one or more distributed access, y management and tructure.

Each AS handles APs or (BSS), which are deployed However, the public key is de We have restricted the deplo keys only to AS and APs.

The private key is used to each authentication of the ST saves the context of a user sess particular: "Time-Stamps" (to time), the message (EAP.Suc shared between the STA and th this token may also contain: profile, etc. The V.ESS is an extension the role of an approval auth infrastructure, one of the "AS" the private key and the AP public key.

In other words, when a ST AS-1 in BSS-1 "Figure 5"; th with attributes of the STA, negotiated as seen in (Section and this token is sent via AP-1

When the STA moves to A present the token. The AP authenticate the STA, because key of VESS infrastructure. token to retrieve all attributes, Once the MSK is recovered derived by AP-3 and STA a "Figure 2 We notice that the AS-2 in DS-2 is not involved in this process of re-authentication because the reauthentication service has been delegated partially to the APs. This is to avoid the Back-End authentication, and to simplify considerably the number of authentication request between the Back-End and the STA.

Use case: (Re)-authentication Process in VESS

We illustrate in "Figure 6" the authentication process and, during mobility, the re-authentication process of the STA in VESS infrastructure. Phase 1-2-3-4: authentication of STA and negotiation of the secret key (MSK). In these phases, nothing changes.

Phase 5: AS-1 signs the token containing (attributes, user profile, "Time-stamps", message EAP.Success and MSK) with the private key, and transmits to the AP-1 the token signed in Access.Accept : K -1 = is private key, Access.Accept(EAP.Success+MSK+K -1 {MSK…})

Then the AP-1 forwards the EAP.Success and signed token packet to the STA: EAP.Success+K -1 {MSK…} Phase 6: the "4-way handshake" protocol, STA and AP-1 derived from the MSK, a bunch of keys used only in this session with AP-1.

Remark 2:

In this scenario, "Figure 6 (A)", the exchanges between the STA, AP-1 and AS-1 are almost identical as in "Figure 2". The only difference consists in signing a token after the authentication process of the STA. This signed token ensures continuity of service and the session of the STA.

Scenario 2: STA re-authentication with AP-3 "Figure 6

(B)"

In this scenario of mobility, the STA transits the AP-1 to AP-3. Phase 0: during this phase reinitialization and re-association, the STA and AP-3 negotiate the EAP method with token signed.

Phase 1-2: STA presents the signed token to the AP-3. The AP-3 decrypts it, using the public key: verifies the authenticity of the token and extract the MSK.

Phase 3: with the "4-way handshake" protocol, AP-3 and STA proceed to the derivation of other keys.

Phase 3: with the "4-way handshake" protocol, AP-3 and STA proceed to the derivation of keys, from the MSK.

The new derivated keyring is different from that obtained with AP-1. This keyring will be used only in this session with AP-3.

Remark 3:

In this scenario, the STA did not need to initiate a re-authentication process with AS-2, but it was meant only to present a signed token to the AP-3 to be authenticated. With this delegation of the reauthentication process to the AP-3, we avoided the invocation of the AS-2, so we reduced sufficiently the number of requests of EAP authentication; therefore, the Handover latency will be also low. The keys negotiation is done in four passes instantly and seamless.

Justification of our Approach

In comparison with other existing solutions (IEEE 80211f,802.11r,etc.), our approach is very easy to implement, can use strong authentication (asymmetric or symmetric cryptography) and does not require many modifications of EAP authentication methods. The implementation of our EAP methods consists in modifying :

The beacon at the time of the negotiation of the Robust Security Network Information Element (RSN IE) to notify the client 802.1x that wireless infrastructure supports the negotiation of the tokens signed.

The requests of (re)-association: the STA 802.11 must notify its choice of security policy by RSN IE included in these requests.

The Access.Accept method to sign the token and transfer it to the STA and the AP.

CONCLUSION AND PERSPECTIVES

This text describes the impact of security on the mobility and session continuity. We have identified the limitations of the EAP protocol in combination with the AAA Framework. This standard is used in the access control to different network technologies.

Several stages of the Handover process can be improved. In this paper, we proposed a fast Handover scheme; taking into consideration only delays in re-authentication during a transition in the same VESS.

To do this, we identified our needs in terms of security in relation to mobility. Thus we proposed to implement security components at the APs, to delegate the re-authentication service to APs in the VESS infrastructure.

In our scheme, the AAA Framework is ignored during the process of re-authentication. Therefore, we use a signed token that ensures trust in the VESS and manages mobility and continuity of the single session of STA. This proposition can solve the problem of intercellular delays (see Section II A).

In the next step, our main focus will be to resolve all technical barriers, evaluate the pertinence of our approach to meet the constraints of real-time applications. Finally, we propose improvements to the EAP protocol and we implement the new methods for managing virtual organizations with our signed tokens.

Figure 1 :

 1 Figure 1: 802.1X architecture of auThe STA also shares a secre usually it is an username and passw is not authenticated, 802.1X does no to the network, only exchan authentication processes are relayed AP. Once the STA is authenticated the traffic related to this STA "Figur

Figure

  Figure 2: EAP Exc The authentication phase traffic (EAPoW): Phase 1: (EAP-Reques request from the AP to the ST

Figure 3 :

 3 Figure 3: Encryption and Decrypti Key. The operation of asymm simple "Figure 3": Bob encry public key of Alice. Alice can the associated key. So it is possible to encryp with the public key, and only private key can decrypt it.

Figure 4 :

 4 Figure 4: Digital S The digital signature is the public key encryption "Figure

Figure 5 :

 5 Figure 5: Virtual ESS I These APs are interconnec System (DS), usually is LAN interconnected. These differen via a DS in the same LAN (Extended Service Set). An ES ESSID.The V.ESS is an extension the role of an approval auth infrastructure, one of the "AS" the private key and the AP public key.In other words, when a ST AS-1 in BSS-1 "Figure5"; th with attributes of the STA, negotiated as seen in (Section and this token is sent via AP-1When the STA moves to A present the token. The AP authenticate the STA, because key of VESS infrastructure. token to retrieve all attributes, Once the MSK is recovered derived by AP-3 and STA a "Figure2" Phase 6).

  " Phase 6). or a Basic Service Set d on the private key. deployed only on APs. loyment of asymmetric to sign the tokens after STA. The signed token ession and can contain in (to limit the token in uccess), and the MSK d the AP. For other uses, : STA attributes, user Infrastructure. nected by a Distribution N on which the APs are rent BSS interconnected AN are called an ESS ESS is identified by an ion of the ESS. It plays uthority. In this trusted S" signs the token with P decrypts it with the STA is authenticated by this AS

Figure 6 :

 6 Figure 6: Virtual ESS: Approved Infrastructure. Scenario 1: STA authentication with AP-1 "Figure 6 (A)" Phase 0: during this phase initialization and association, STA and AP-1 negotiate the EAP method with token signed.

Table 1 :

 1 Effect of roaming on Packet loss (Exact copy from a Source:Bangolae et al. 2006, p.6)

	Authentication	Average	Average	Maximum
	method	Roaming	Packet	Consecutive
		time (ms)	Loss %	lost datagrams
				(Average)
	Baseline -Full	525	1.8	53
	802.1x EAP
	Authentication
	Fast Transition	42	0.2	6
	using 802.11r
	Many enhancements have been made to the
	802.11 standard


Gilles Aubert
email: gaubert@unice.fr

Audric Drogoul
email: drogoula@unice.fr

Topological gradient for fourth order PDE and application to the detection of fine structures in 2D images

In this paper we describe a new approach for the detection of fine structures in an image. This approach is based on the computation of the topological gradient associated to a cost function defined from a regularization of the data (possibly noisy). We get this approximation by solving a fourth order PDE. The study of the topological sensitivity is made both in the cases of a circular inclusion and a crack. We illustrate our approach by giving two experimental results.

les plus simples adaptés à l'étude de structures fines sont ω ǫ = B(x 0 , ǫ) la boule de centre x 0 et de rayon ǫ et ω ǫ = x 0 + ǫσ(n) où σ(n) est un segment de droite de normale n. Nous montrons pour ces exemples que j(Ω ǫ ) admet le développement asymptotique (1) où I(x 0 ) est, par définition, le gradient topologique au point x 0 . Par conséquent si on veut minimiser j(Ω ǫ ) il est souhaitable d'insérer des petites boules ou des cracks aux points x 0 où I(x 0 ) est "le plus négatif" possible. D'un point de vue de l'analyse d'images ces petites structures correspondent aux structures fines qu'on veut détecter. La question est : quelles fonction coût et EDP doit on utiliser pour détecter de telles structures ? Si pour la détection de contours d'objets dans une image il est classique d'utiliser des opérateurs construits à partir du gradient spatial, ce choix est complètement inopérant pour la détection de structures fines : le gradient "ne voit pas" ces structures. Pour détecter ce type de structures il est connu ( [START_REF] Steger | An Unbiased Detector of Curvilinear Structures[END_REF], [START_REF] Morales | Vesselness enhancement diffusion[END_REF]) qu'il faut utiliser des opérateurs différentiels d'ordre 2. Nous avons choisi pour cela la fonction coût définie en (2) liée à la modélisation de l'équilibre d'une plaque mince soumise à des forces extérieures. Le calcul très technique du gradient topologique revient à estimer la différence

J ǫ (u ǫ ) -J 0 (u 0 ) où J ǫ (u) = J Ωǫ (u). u ǫ est l'unique solution du problème variationnel a ǫ (u ǫ , v) = l ǫ (v), pour tout v dans H(Ω ǫ ) = u ∈ L 2 (Ω ǫ ), ∇ 2 u ∈ L 2 (Ω ǫ ) où a ǫ (u, v) et l ǫ (v)
sont définis respectivement par (3) et [START_REF] Belaid | Application of the topological gradient to image restoration and edge detection[END_REF]. L' expression du gradient topologique est donnée en ( 16), (15) pour le cas du crack et (17) pour le cas d'une inclusion circulaire. On conclut cette note en illustrant l'approche par deux résultats expérimentaux.

Introduction

In medical, biological or satellite imaging the detection of fine structures (filaments, particles ...) is an important task. In this note we show how it is possible to solve this problem by using topological optimization tools. Initially used for cracks detection [START_REF] Amstutz | Crack detection by the toplogical gradient method[END_REF] the notion of topological gradient has been recently applied in imaging problems such as the restoration, the segmentation or the classification of images ( [START_REF] Belaid | Application of the topological gradient to image restoration and edge detection[END_REF], [START_REF] Auroux | Image restoration and classification by topological asymptotic expansion, Variational Formulations in Mechanics: Theory and Applications[END_REF]). Roughly speaking, the topological gradient approach performs as follows : let Ω be an open bounded set of R 2 and j(Ω) = J(Ω, u Ω ) be a cost function where u Ω is the solution of a given PDE. For small ǫ > 0, let (a) Ω ǫ = Ω\{x 0 + ǫω} or (b) Ω ǫ = Ω\{x 0 + ǫσ(n)}, where x 0 ∈ Ω, ω = B(O, 1) is the unit ball of R 2 and σ(n) is a straight segment with normal n (a crack). The topological sensitivity provides an asymptotic expansion of j(Ω ǫ ) when ǫ → 0. In many cases it takes the form :

j(Ω ǫ ) = j(Ω) + ǫ 2 I(x 0 ) + o(ǫ 2 ) (1)
I(x 0 ) is called the topological gradient at x 0 . Thus if we want to minimize j(Ω ǫ ) it would be preferable to insert small balls or cracks at points x 0 where I(x 0 ) is "the most negative " . In imaging applications, the main question is the choice of the cost function and the PDE that u Ω has to verify. If for edge detection the usual spatial gradient is classicaly used, it is totally inefficient for the detection of points or filaments. It "does not see"these structures. It is known ( [START_REF] Steger | An Unbiased Detector of Curvilinear Structures[END_REF], [START_REF] Morales | Vesselness enhancement diffusion[END_REF]) that for the detection of fine structures we need to use algorithms based on second order derivatives. In section 2 we introduce the cost function j(Ω ǫ ) and the variational formulation for u Ω . Then in section 3 we give the expression of the associated topological gradient in cases (a) and (b). In section 4, we briefly describe the numerical approximation of the problem and we conclude by giving two experimental results.

Definition of the cost function and of the variational formulation for the detection of fine structures

Let Ω ⊂ R 2 be the image domain and f ∈ L 2 (Ω) the grey levels of a 2-D image for which we want to detect fine structures that we liken to points or straight lines. The simplest choice of the cost function would be J Ω (u) = Ω |∇ 2 u| 2 but for eventual other applications, we introduce a more general cost function stemming from the Kirchhoff model in the theory of thin plates (0 ≤ ν < 1 denotes the Poisson ratio) :

J Ω (u) = Ω (∆u) 2 + 2(1 -ν) ∂ 2 u ∂x 1 ∂x 2 2 - ∂ 2 u ∂x 2 1 ∂ 2 u ∂x 2 2 dx (2)
We remark that for ν = 0 we retrieve the square of the norm of the Hessian matrix. In the sequel Ω ǫ is defined as in (a) or (b); for ǫ = 0, Ω 0 = Ω. We denote u ǫ = u Ωǫ . Now, for the definition of u ǫ , in order to study the variations of J Ωǫ (u ǫ ) it is coherent and natural to search for u ǫ = argmin

u∈H 2 (Ωǫ) J Ωǫ (u) + f -u 2 L 2 (Ωǫ)
or equivalently as the solution of the variationnal problem :

find u ǫ ∈ H 2 (Ω ǫ ) such that a ǫ (u ǫ , v) = l ǫ (v), ∀v ∈ H 2 (Ω ǫ ) a ǫ (u, v) = Ωǫ ∆u∆v + (1 -ν) 2 ∂ 2 u ∂x 1 ∂x 2 ∂ 2 v ∂x 1 ∂x 2 - ∂ 2 u ∂x 2 1 ∂ 2 v ∂x 2 2 - ∂ 2 u ∂x 2 2 ∂ 2 v ∂x 2 1 + uv (3)
l ǫ (v) = Ωǫ f vdx (4)
Thanks Lax-Milgram Lemma, u ǫ is unique in H 2 (Ω ǫ ). Moreover u ǫ satisfies the Euler equation

∆ 2 u ǫ + u ǫ = f, in Ω ǫ B 1 (u ǫ ) = 0, B 2 (u ǫ ) = 0 on ∂Ω ǫ (5)
with

       B 1 (u) = ∂ n (∆u) -(1 -ν)∂ σ n 1 n 2 ∂ 2 u ∂x 2 1 - ∂ 2 u ∂x 2 2 -(n 2 1 -n 2 2 ) ∂ 2 u ∂x 1 ∂x 2 B 2 (u) = ν∆u + (1 -ν) n 2 1 ∂ 2 u ∂x 2 1 + n 2 2 ∂ 2 u ∂x 2 2 + 2n 1 n 2 ∂ 2 u ∂x 1 ∂x 2 (6)
where n = (n 1 , n 2 ) is the outside normal to ∂Ω ǫ and σ = (σ 1 , σ 2 ) is the tangent vector with |n| = |σ| = 1. Remark 1 The study of topological sensitivity for fourth order operators is not new. In [START_REF] Amstutz | Topological asymptotic analysis of the Kirchhoff plate bending problem[END_REF], the authors in a different context, compute the topological gradient for the Kirchhoff plate bending problem in case (a) of a circular inclusion. Our model is simpler and we are able to give explicit expressions of the topological gradients both in the cases of circular inclusions and of cracks.

Computation of the topological gradient associated to J Ωǫ (u ǫ )

We denote J ǫ (u) = J Ωǫ (u) and to shorten the presentation we only give the main idea in case (b) : Ω ǫ = Ω\{x 0 + ǫσ}, with x 0 = 0 i.e Ω ǫ = Ω\{ǫσ} where σ is the straight crack σ = {(s, 0), -1 < s < 1}. We denote σ ǫ = ǫσ. For a detailed version of the calculus we refer the reader to [START_REF] Aubert | A topological gradient based model for the detection of fine structures in 2D images[END_REF]. We have to estimate the difference J ǫ (u ǫ ) -J 0 (u 0 ). By using equations ( 5) and ( 6) for u ǫ and u 0 , we get

J ǫ (u ǫ ) -J 0 (u 0 ) = L ǫ (u ǫ -u 0 ) + I ǫ with L ǫ (v) = Ωǫ (f -2u 0 )vdx and I ǫ = - Ωǫ (u ǫ -u 0 ) 2 dx (7)
The first key point is to introduce v ǫ ∈ H 2 (Ω ǫ ) as the unique solution of the dual problem (see [START_REF] Sokolowski | On the Topological Derivative in Shape Optimization[END_REF] and [START_REF] Amstutz | Crack detection by the toplogical gradient method[END_REF])

a ǫ (u, v ǫ ) = -L ǫ (u), ∀u ∈ H 2 (Ω ǫ ) (8)
By extending σ to a closed curve, by using integration by parts and the equation verified by u 0 , we obtain

J ǫ (u ǫ ) -J 0 (u 0 ) = σǫ (B 1 (u 0 ) -α∂ n u 0 ) [v ǫ ] -B 2 (u 0 )[∂ n v ǫ ] + I ǫ (9)
where [v ǫ ] and [∂ n v ǫ ] denote respectively the jump of v ǫ and ∂ n v ǫ across σ ǫ . Then we set w ǫ = v ǫv 0 where v 0 is the solution of ( 8) with ǫ = 0 (Ω 0 = Ω), thus :

J ǫ (u ǫ ) -J 0 (u 0 ) = σǫ (B 1 (u 0 ) -α∂ n u 0 ) [w ǫ ] -B 2 (u 0 )[∂ n w ǫ ] + I ǫ = I A -I B + I ǫ ( 10
)
with

I A = σǫ (B 1 (u 0 ) -α∂ n u 0 ) [w ǫ ] , I B = σǫ B 2 (u 0 )[∂ n w ǫ ] ( 11
)
The estimation of the two terms of (11) needs to approximate w ǫ . It is classical (see [START_REF] Amstutz | Crack detection by the toplogical gradient method[END_REF]) to approximate w ǫ by the solution of the exterior problem

∆ 2 P = 0, in R 2 \σ B 1 (P ) = g 1 , B 2 (P ) = g 2 on σ (12)
where g 1 end g 2 are known functions defined from second derivatives of v 0 at point 0. The solution of (12) is the sum of triple and quadruple layer potentials (see [START_REF] Aubert | A topological gradient based model for the detection of fine structures in 2D images[END_REF] for more details). We can show that w ǫ = v ǫv 0 can be written as w ǫ (x) = ǫ 2 P x ǫ + e ǫ with e ǫ 2,Ωǫ = 0(-ǫ 2 log(ǫ)) and then the three terms in [START_REF] Steger | An Unbiased Detector of Curvilinear Structures[END_REF] have the following expansion :

I A = o(ǫ 2 ) , I B = ǫ 2 γ σ λ 2 (y)dσ y + o(ǫ 2 ) , I ǫ = o(ǫ 2 ) (13) with γ = ∂ 2 u0 ∂x 2 2 (0) + ν ∂ 2 u0 ∂x 2 1 (0) and λ 2 (s) = -4β (1-ν)(3+ν) √ 1 -s 2 , ∀s ∈] -1, 1[, where β = ∂ 2 v0 ∂x 2 2 (0) + ν ∂ 2 v0
∂x 2 1 (0). Gathering estimates [START_REF] Steger | An Unbiased Detector of Curvilinear Structures[END_REF] and (13) we get the expression of the topological gradient for the case Ω ǫ = Ω\σ ǫ and x 0 = 0:

I(0) = - 2π (1 -ν)(3 + ν) ∂ 2 u 0 ∂x 2 2 (0) + ν ∂ 2 u 0 ∂x 2 1 (0) ∂ 2 v 0 ∂x 2 2 (0) + ν ∂ 2 v 0 ∂x 2 1 (0) (14)
Remark 2 Thanks to a basis change, the topological gradient for a straight crack centered at x 0 ∈ Ω and of normal n is given by

I(x 0 , n) = -2π (1 -ν)(3 + ν) ∇ 2 u 0 (x 0 )(n, n) + ν∇ 2 u 0 (x 0 )(τ, τ ) ∇ 2 v 0 (x 0 )(n, n) + ν∇ 2 v 0 (x 0 )(τ, τ ) (15)
with τ the tangent vector such as (τ, n) is an orthonormal basis of R 2 and the topological gradient at point x 0 ∈ Ω is defined as :

I(x 0 ) = min n =1 I(x 0 , n) (16)
Remark 3 In the case of the ball : Ω ǫ = Ω\x 0 + ǫB(0, 1), the computation is identical (see [START_REF] Aubert | A topological gradient based model for the detection of fine structures in 2D images[END_REF] and [START_REF] Amstutz | Topological asymptotic analysis of the Kirchhoff plate bending problem[END_REF]) :

I(x 0 ) = π (f (x 0 ) -u 0 (x 0 )) (v 0 (x 0 ) -u 0 (x 0 )) - π(1 + ν) 1 -ν ∆u 0 (x 0 )∆v 0 (x 0 ) - 2π(1 -ν) 3 + ν ∂ 2 u 0 ∂x 2 1 (x 0 ) - ∂ 2 u 0 ∂x 2 2 (x 0 ) ∂ 2 v 0 ∂x 2 1 (x 0 ) - ∂ 2 v 0 ∂x 2 2 (x 0 ) + 4 ∂ 2 u 0 ∂x 2 ∂x 1 (x 0 ) ∂ 2 v 0 ∂x 2 ∂x 1 (x 0 ) (17)

Numerical approximation and experimental results

The computation of the topological gradient only need to compute the solutions of the two following variational problems :

a 0 (u 0 , v) = l 0 (v), ∀v ∈ H 2 (Ω) a 0 (u, v 0 ) = -L 0 (u), ∀u ∈ H 2 (Ω) (18)
where l 0 and L 0 are respectively defined by ( 4) and ( 7) with ǫ = 0. To discretize (18), we used Morley finite elements (see [START_REF] Brenner | The Mathematical Theory of Finite Element Methods[END_REF] and [START_REF] Ming | Nonconforming tetrahedral finite elements for fourth order elliptic equations[END_REF]). If (T h ) h is a regular triangulation of Ω, let X h be the Morley finite elements space associated with (T h ) h . We define on X h the bilinear and linear forms :

a 0,h (u, v) = K∈T h K 2 i,j=1 ∂ 2 u ∂x i ∂x j ∂ 2 v ∂x i ∂x j dx l 0,h = K∈T h K f vdx L 0,h (v) = K∈T h K (f -2u 0,h )vdx
We denote respectively by u 0,h and v 0,h the solution of the problems

a 0,h (u 0,h , v h ) = l 0,h (v h ), ∀v h ∈ X h a 0,h (u h , v 0,h ) = -L 0,h (u h ), ∀u h ∈ X h
Then the discrete topological gradient is computed thanks to formula (16) evaluated at vertices of (T h ) h . We illustrate our approach by giving two experimental results in Figure 1 and Figure 2. To determine the size of the structures to be detected, we add in front of the bilaplacian operator a regularizing parameter α > 0 to be tuned by the user; for example for structures of size 1 to 6 pixels α = 0.1 and for structures of size 6 to 17 pixels α = 3. Note also that our topological gradient (TG) is able to distinguish between fine structures and jumps (edges). In a neighborhood of an edge the TG is not equal to 0 but it is weak. On the other hand in a neighborhood of a fine structure it is big, so with a correct threshold we can easily detect fine structures and eliminate jumps.

Figure 1 .Figure 2 .

 12 Figure 1. Robustness of the topological gradient with respect to noise on a synthesis image using (16), (a) : Image without noise, (b) : Noisy image with Gaussian noise, PSNR=26dB, (c) : Noisy image with Gaussian noise, PSNR=14dB, top : Initial image, down : Topological gradient using (16), Robustesse du gradient topologique par rapport au bruit pour une image synthétique en utilisant (16),(a) : Image sans bruit, (b) : Image bruitée par du bruit Gaussien, PSNR=26dB, (c) : Image bruitée par du bruit Gaussien, PSNR=14dB, en haut : Image initiale, en bas : Gradient topologique utilisant (16)