Strong password authentication with AKA authentication

Click here to load reader

  • date post

    14-Feb-2022
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of Strong password authentication with AKA authentication

untitledLibor Dostalek Department of Computer Science and Engineering
University of West Bohemia Pilsen, Czech Republic [email protected]
Jiri Safarik Department of Computer Science and Engineering
University of West Bohemia Pilsen, Czech Republic
[email protected]
Abstract – This contribution discusses algorithms for strong authentication of applications in mobile devices. The current LTE and IMS networks provide strong authentication using USIM smart cards based on AKA algorithm. The problem of this authentication is that this authentication is under the sole control of Telco operators. We can expect that more applications will be placed into the IMS environment in the future. These applications will be based either on SIP (video on demand etc.) or HTTP-based protocols (e.g. as government applications or banking applications etc.). They will be provided not only by Telco operators, but also especially by independent third parties - application (content) providers (e.g. government, banks etc.). This contribution proposes new authentication algorithms that combine AKA algorithm with other authentication algorithms. Therefore, the authentication is not under the sole control of Telco operators, still using strong authentication AKA protocol.
Keywords - Authentication, AKA, Mobile Application, IMS, Robust Two-factor Authentication, Mobile authentication
I. INTRODUCTION
At present, mobile applications use a number of authentication methods, e.g.: 1. Native authentication methods in 3G/4G networks
based on AKA mechanism [1]. This authentication is undoubtedly a cryptographically strong authentication. Its disadvantage is that it is used for authenticating of mobile device to the network (often called equipment authentication).
2. Password authentication is typical user authentication. Generally, this authentication method is unfortunately considered weak, so applications such as home banking or eGov seek other mechanisms.
3. Strong password authentication are more sophisticated password authentication methods resistant against known attacks (sniffing or elicitation of password, password-file compromise attack, guessing attack, forgery attack, impersonation attack, stolen-verifier attack, replay attack etc.).
4. Authentication based on public key certificates (PKI). The problem is, where the mobile device securely stores the private keys.
5. External devices such as authentication calculators generating one-time passwords. The main disadvantage of this solution is that a user must take care about an additional device, what he/she can find disagreeable.
Using multiple authentication method independently does not increase security. Our idea is to combine (to breed) methods 1 and 3 in a common multifactor authentication. The first factor is an equipment authentication based on AKA mechanisms and the second factor is strong password authentication.
II. USIM AND ISIM
In the 4th generation of mobile networks (Figure 1), LTE (Network Long Term Evolution) provides communication between the mobile device and base station (eNB) at the link layer. The base stations (eNB) are connected to the core network EPC (Evolved Packet Core) that will ensure that mobile devices can communicate through the Mobility Management Entity (MME) to IP networks. At the application layer, the mobile device communicates with IMS network which provides multimedia services.
The client authenticates towards LTE/EPC using the shared secret K, which he/she has stored in the Universal Subscriber Identity Module (USIM) application on his/her Universal Integrated Circuit Card (UICC)by AKA mechanism. The network has the shared secrets stored in the Authentication Center (AuC) of LTE/EPC networks. The AKA authentication mechanism is used.
At the application layer, the client authenticates towards IMS using the shared secret K that has stored in IP Multimedia Services Identity Module (ISIM) application to his/her Universal Integrated Circuit Card (UICC). The network has it stored in the AuC of IMS network. The authentication is also used AKA mechanism, however be encapsulated into another protocol.
AuC is jointly operated with subscriber database by the Home Subscriber Server (HSS).
brought to you by COREView metadata, citation and similar papers at core.ac.uk
provided by DSpace at University of West Bohemia
III. AKA MECHANISM
AKA (Authentication and Key Agreement) mechanism is a security protocol used in 3G/4G mobile networks for mutual authentication and cryptographic material agreement (Figure 2).
There are three communication parties:
– A (mobile), mobile equipment usually equipped with USIM/ISIM containing shared secret K.
– B (network), usually A-SBC in IMS. – Authentication center (part of a Home
Subscriber Server - HSS).
Parties A (mobile) and Authentication center (AuC):
– share a secret K (shared secret) different for each smart card,
– maintain sequence number SEQ of authentication.
– Both parties support the AKA mechanism using one way functions f 1, f 2, f 3, f 4 and f5 (Figure 3).
AKA mechanism (Figure 2) is the following:
AKA-1: A (mobile) will grant access (sends its identity to B).
AKA-2: B (network) sends identification of A to Authentication center.
AKA-3: Authentication center on behalf of B:
– Generates random number RAND. – Generates next sequence number SEQ of
authentication.
– Runs Authentication functions f 1−f 5. (Figure 3) and generates Authentication vector AV = (RAND, RES, CK, IK, SQN ⊕AK, AMF, MAC). While RES is one time password for authentication of A and MAC is one time password for authentication of B.
– Sends AV to B.
AKA-4: B cut and sore RES form Authentication
vector AV. Next, RAND, SQN ⊕AK, AMF and MAC sends to A.
TABLE 1 Notation of AKA mechanisms
AKA-5: Through the function f5, A computes SQN. A runs the rest of authentication functions and:
– If MAC, computed by A, is equal to MAC from AV, than B (network) is authenticated.
Symbol Meaning K Shared secret AMF Well known string SQN Sequence number of authentication RAND Random number MAC One time password for network authentication RES One time password for user equipment
authentication CK Cyphering key IK Integrity key AK Anonymization key for SEQ anonymization f 1-f 5 One way functions
Figure 1 Authentication in mobile networks
– Generates RES and sends it to B. AKA-6: B compares the RES, obtained from A,
with saved RES from AV (step AKA-4). If equal, A is authenticated.
IV. RELATED WORK
Method combining Secure Hash-Based Password Authentication Protocol Using Smartcards [3] and AKA mechanism [1] was introduced in [2] This method supports:
1. Multi-factor security - the security of the scheme is guaranteed when either the user’s password or his data bearer token or USIM/ISIM is compromised, but not all.
2. Content provider keeps control over authentication to its applications.
3. Authentication is associated with USIM/ISIM i.e. AKA mechanisms used.
4. Roaming support - authentication is possible both in a home network and in a visited network.
5. Password change - a user can freely update his/her password.
6. Password change without communication with a server - a user can freely update his/her password without any interaction with a server.
7. Mutual authentication - a user and a server are sure about the identity of each other. Both the server and the user can verify the legality of its counterpart.
8. No time synchronization - The scheme does not require additional clock synchronization mechanisms
9. Anti-desynchronization both a user and a server cannot be desynchronized against
their shared secrets or values, which could result in the user’s denial of any future access to the server.
10. Data bearer revocation. In the case of data bearer token loss, invalidating the further use of the lost data bearer token should be provided to prevent an adversary from
Figure 3
Figure 2 AKA mechanism
impersonating the registered user with the lost s data bearer token.
11. Password protection (eavesdropping, elicitation etc.) - except the user, no another party can get any information of the user’s password. More specially, the user’s password will not be revealed to the server during registration, and there are no variation tables such as plain text or hashed passwords stored in the server.
Method described in [2] has some disadvantages. The method does not supports:
12. Session key agreement - A session key is established between the user and the server during the authentication process, which is known only to the user and the server. Then, the session key is used to create a secure communication channel between the user and the server.
13. Perfect forward secrecy - a potential attacker cannot know any information about previously established session key, even when the long-term keys of the server and the user are disclosed.
14. Forward and backward secrecy - Forward secrecy means, that even though for some reason some session keys are exposed, the secrecy of any previous session key will be still maintained. Backward secrecy means, that even though some previous session keys are exposed, the secrecy of any future session key will be still maintained.
15. Key freshness. Neither party can guess the next shared session key.
V. THE PROPOSED SOLUTION
The proposed solution (Figure 4) creates multifactor authentication by merging AKA authentication mechanism [1] and Robust Two-factor Authentication [4]. Assume that the user is registered: – In terms of Robust Two-factor
Authentication: Parameter Generation phase was done. Mobile user U and Application function S (server) exchange messages R1 and R2.
– In terms of AKA mechanism [1]: A user equipped with USIM shares the secret K with Authentication Center (AuC).
In the proposed solution, the mobile user U and the Application function S during authentication exchange three messages Y1, Y2 and Y3:
Step Y1: U inserts its data bearer token with parameters IM0 and V into its equipment and inputs its password PW. Next, a random integer rC from [1, n − 1] is generated and GC=rC × G is computed. Then it continues to compute V’=V– H(PW) = H(IDKS) and G’C=GC+V’. At the end, U sends its identity (for AKA mechanisms) and {IM0,G’C} to S.
Step Y2: This step consists of the step A1 (Robust Two-factor Authentication) and the steps AKA1, AKA2 and AKA3. Upon receiving message Y1, S asks AuC for AV generation for the user U. AuC sends AV to S. S cuts off RES from AV and stores it.
In the meantime, S handles message {IM0,G’C}, S decrypts the parameter IM0 with KS and obtains the value IDr. Then, S verifies whether the identifier ID is valid. If the verification fails, S terminates the session. Otherwise, S computes V’=H(IDKS) and recovers GC=G’C-V’.
After that, S generates GC=G’C-V’, where rS is a random integer within range [1, n − 1], and then computes IM1=EKs(IDr’), KSU=h1(H(IDKS)(rS×GC)), IM’1=h(KSU) ⊕ IM1
and MS=h2(KSUGCGSIM’1MAC-A).
S sends to U: MS, GS, IM’1, RAND, SQN⊕AK and AMF .
Step Y3: First, U’s equipment runs function f5 and obtains SEQ. Subsequently, it runs function f1, f2, f3 and f4 and obtains MAC, RES and cryptographic material IK, CK.
Upon receiving {MS,GS,IM’1}, the U’s equipment computes the session key KSU=h1(V’(rC×GS)) and then, it checks whether the value MS is equal to h2(KSUGCGSIM’1MAC-A). If it is not, it terminates this session. Otherwise, it computes IM1=h(KSU) ⊕ IM’1 and replaces IM0 by IM1, then, it computes MU=h2(KSUGSRES) and sends {MU} to S.
Step Y4: Upon receiving {MU}, S checks whether the value MU is equal to h2(KSUGSXRES). If yes, U and S successfully authenticate each other and share the session key. Otherwise, S terminates this session.
TABLE 2 Notation of Robust Two-factor Authentication Symbol Meaning p A large prime E An elliptic curve equation over Zp Fp Finite field with notions of addition (+),
subtraction (-), multiplication (x) and division G A generator point of a large order S Server U User ID Login ID of U PW PW Password of U Ekey(m) Encryption of message m with key Dkey(m) Decryption of message m with key h1(); h2(); h3()
Cryptographic hash function
H() Cryptographic map-to-point (on elliptic curve) hash function, e.g. [5] ⊕ Denotes the bitwise XOR operation Denotes concatenation
VI. ANALYSIS
Table 3 compares properties of the described algorithm. Table 4 summarizes the computation costs comparison between our scheme and the previous schemes (in authentication phase).
Figure 4 Proposed solution
AK A
n
1 Multi-factor security Yes Yes Yes Yes Yes 2 Content provider maintains control over authentication to its
applications No Yes Yes Yes Yes
3 Authentication is associated with USIM/ISIM Yes No No Yes Yes 4 Roaming support Yes Yes Yes Yes Yes 5 Password change n/a Yes Yes Yes Yes 6 Password change without any interaction with the server n/a No Yes No Yes 7 Mutual authentication Yes Yes Yes Yes Yes 8 No time synchronization Yes Yes Yes Yes Yes 9 Anti de-synchronization Yes Yes Yes Yes Yes 10 Data bearer revocation n/a Yes Yes Yes Yes 11 Password protection (eavesdropping, elicitation etc.) n/a Yes Yes Yes Yes 12 Session key agreement Yes No Yes No Yes 13 Perfect forward secrecy n/a n/a Yes No Yes 14 Forward and backward secrecy n/a n/a Yes No Yes 15 Key freshness n/a n/a Yes No Yes
TABLE 4 Computation costs
n
Computation costs of the user 4h, 1A 3h, 1H, 2PM 4h, 1A, AKA 3h, 1H, 2PM, AKA Computation costs server
of the 4h, 2A 4h, 1H, 2S, 2PM 4h,2A, AKA 4h, 1H, 2S, 2PM, AKA
Communication round be- tween the user and server
3 3 3 3
- h is defined as the time complexity of the hash computation; - H is defined as the map-to-point hash computation; - S is defined as the time complexity of the symmetric encryption/decryption;
- PM is defined as the time complexity of the EC point multiplication; - A is defined as the time complexity of the asymmetric (e.g. RSA) encryption/decryption. - AKA is defined as the time complexity of the AKA algorithm
VII. CONCLUSION
The proposed solution enables applications, running on IMS environments to use authentication, which brings: – Evidence that the user is authenticated in the
device that he/she uses, with the particular USIM (proof of ownership).
– Evidence that a concrete person who knows the password performed the authentication.
– Generating cryptographic material for securing subsequent communication
----------- This work was supported by project SGS-2016-018
VIII. REFERENCES
[1] „3G security; Security architecture; 3GPP TS 33.102; 3GPP TS 33.102,“ 3GPP TS 33.102, September 2016. [Online]. Available: http://www.3gpp.org.
[2] L. Dostalek a J. Ledvina, „Strong Authentication for Mobile Application,“ International Conference of Applied Elecronics, . IEEE CFP1569A-PRT, pp. 23-26, September 2015.
[3] H. Jung, H. S. Kim, B. Murgante, O. Gervasi a A. Iglesias, „Secure Hash-Based Password Authentication Protocol Using Smartcards,“ v 11th International Conference on Computational Science and Its Applications (ICCSA), PT V Book Series: Lecture Notes in Computer Science, Volume: 6786, Pages: 593-606, 2011.
[4] Q. Jiang, J. Ma, G. Li a L. Yang, „ Robust Two-Factor Authentication and Key Agreement Preserving User Privacy,“ IJ Network Security, 16(4), pp. 321-332, 2014.
[5] T. Icart, „How to hash into elliptic curves,“ v CRYPTO 2009, Santa Barbara, California, USA, 2009.
[6] „Universal Subscriber Identity Module (USIM) application; 3GPP TS 31.102 V14.1.0,“ 2017. [Online]. Available: http://www.3gpp.org.
<< /ASCII85EncodePages false /AllowTransparency false /AutoPositionEPSFiles true /AutoRotatePages /None /Binding /Left /CalGrayProfile (Gray Gamma 2.2) /CalRGBProfile (sRGB IEC61966-2.1) /CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2) /sRGBProfile (sRGB IEC61966-2.1) /CannotEmbedFontPolicy /Error /CompatibilityLevel 1.7 /CompressObjects /Off /CompressPages true /ConvertImagesToIndexed true /PassThroughJPEGImages true /CreateJobTicket false /DefaultRenderingIntent /Default /DetectBlends true /DetectCurves 0.0000 /ColorConversionStrategy /LeaveColorUnchanged /DoThumbnails false /EmbedAllFonts true /EmbedOpenType false /ParseICCProfilesInComments true /EmbedJobOptions true /DSCReportingLevel 0 /EmitDSCWarnings false /EndPage -1 /ImageMemory 1048576 /LockDistillerParams true /MaxSubsetPct 100 /Optimize true /OPM 0 /ParseDSCComments false /ParseDSCCommentsForDocInfo true /PreserveCopyPage true /PreserveDICMYKValues true /PreserveEPSInfo false /PreserveFlatness true /PreserveHalftoneInfo true /PreserveOPIComments false /PreserveOverprintSettings true /StartPage 1 /SubsetFonts true /TransferFunctionInfo /Remove /UCRandBGInfo /Preserve /UsePrologue false /ColorSettingsFile () /AlwaysEmbed [ true /AbadiMT-CondensedLight /ACaslon-Italic /ACaslon-Regular /ACaslon-Semibold /ACaslon-SemiboldItalic /AdobeArabic-Bold /AdobeArabic-BoldItalic /AdobeArabic-Italic /AdobeArabic-Regular /AdobeHebrew-Bold /AdobeHebrew-BoldItalic /AdobeHebrew-Italic /AdobeHebrew-Regular /AdobeHeitiStd-Regular /AdobeMingStd-Light /AdobeMyungjoStd-Medium /AdobePiStd /AdobeSongStd-Light /AdobeThai-Bold /AdobeThai-BoldItalic /AdobeThai-Italic /AdobeThai-Regular /AGaramond-Bold /AGaramond-BoldItalic /AGaramond-Italic /AGaramond-Regular /AGaramond-Semibold /AGaramond-SemiboldItalic /AgencyFB-Bold /AgencyFB-Reg /AGOldFace-Outline /AharoniBold /Algerian /Americana /Americana-ExtraBold /AndaleMono /AndaleMonoIPA /AngsanaNew /AngsanaNew-Bold /AngsanaNew-BoldItalic /AngsanaNew-Italic /AngsanaUPC /AngsanaUPC-Bold /AngsanaUPC-BoldItalic /AngsanaUPC-Italic /Anna /ArialAlternative /ArialAlternativeSymbol /Arial-Black /Arial-BlackItalic /Arial-BoldItalicMT /Arial-BoldMT /Arial-ItalicMT /ArialMT /ArialMT-Black /ArialNarrow /ArialNarrow-Bold /ArialNarrow-BoldItalic /ArialNarrow-Italic /ArialRoundedMTBold /ArialUnicodeMS /ArrusBT-Bold /ArrusBT-BoldItalic /ArrusBT-Italic /ArrusBT-Roman /AvantGarde-Book /AvantGarde-BookOblique /AvantGarde-Demi /AvantGarde-DemiOblique /AvantGardeITCbyBT-Book /AvantGardeITCbyBT-BookOblique /BakerSignet /BankGothicBT-Medium /Barmeno-Bold /Barmeno-ExtraBold /Barmeno-Medium /Barmeno-Regular /Baskerville /BaskervilleBE-Italic /BaskervilleBE-Medium /BaskervilleBE-MediumItalic /BaskervilleBE-Regular /Baskerville-Bold /Baskerville-BoldItalic /Baskerville-Italic /BaskOldFace /Batang /BatangChe /Bauhaus93 /Bellevue /BellMT /BellMTBold /BellMTItalic /BerlingAntiqua-Bold /BerlingAntiqua-BoldItalic /BerlingAntiqua-Italic /BerlingAntiqua-Roman /BerlinSansFB-Bold /BerlinSansFBDemi-Bold /BerlinSansFB-Reg /BernardMT-Condensed /BernhardModernBT-Bold /BernhardModernBT-BoldItalic /BernhardModernBT-Italic /BernhardModernBT-Roman /BiffoMT /BinnerD /BinnerGothic /BlackadderITC-Regular /Blackoak /blex /blsy /Bodoni /Bodoni-Bold /Bodoni-BoldItalic /Bodoni-Italic /BodoniMT /BodoniMTBlack /BodoniMTBlack-Italic /BodoniMT-Bold /BodoniMT-BoldItalic /BodoniMTCondensed /BodoniMTCondensed-Bold /BodoniMTCondensed-BoldItalic /BodoniMTCondensed-Italic /BodoniMT-Italic /BodoniMTPosterCompressed /Bodoni-Poster /Bodoni-PosterCompressed /BookAntiqua /BookAntiqua-Bold /BookAntiqua-BoldItalic /BookAntiqua-Italic /Bookman-Demi /Bookman-DemiItalic /Bookman-Light /Bookman-LightItalic /BookmanOldStyle /BookmanOldStyle-Bold /BookmanOldStyle-BoldItalic /BookmanOldStyle-Italic /BookshelfSymbolOne-Regular /BookshelfSymbolSeven /BookshelfSymbolThree-Regular /BookshelfSymbolTwo-Regular /Botanical /Boton-Italic /Boton-Medium /Boton-MediumItalic /Boton-Regular /Boulevard /BradleyHandITC /Braggadocio /BritannicBold /Broadway /BrowalliaNew /BrowalliaNew-Bold /BrowalliaNew-BoldItalic /BrowalliaNew-Italic /BrowalliaUPC /BrowalliaUPC-Bold /BrowalliaUPC-BoldItalic /BrowalliaUPC-Italic /BrushScript /BrushScriptMT /CaflischScript-Bold /CaflischScript-Regular /Calibri /Calibri-Bold /Calibri-BoldItalic /Calibri-Italic /CalifornianFB-Bold /CalifornianFB-Italic /CalifornianFB-Reg /CalisMTBol /CalistoMT /CalistoMT-BoldItalic /CalistoMT-Italic /Cambria /Cambria-Bold /Cambria-BoldItalic /Cambria-Italic /CambriaMath /Candara /Candara-Bold /Candara-BoldItalic /Candara-Italic /Carta /CaslonOpenfaceBT-Regular /Castellar /CastellarMT /Centaur /Centaur-Italic /Century /CenturyGothic /CenturyGothic-Bold /CenturyGothic-BoldItalic /CenturyGothic-Italic /CenturySchL-Bold /CenturySchL-BoldItal /CenturySchL-Ital /CenturySchL-Roma /CenturySchoolbook /CenturySchoolbook-Bold /CenturySchoolbook-BoldItalic /CenturySchoolbook-Italic /CGTimes-Bold /CGTimes-BoldItalic /CGTimes-Italic /CGTimes-Regular /CharterBT-Bold /CharterBT-BoldItalic /CharterBT-Italic /CharterBT-Roman /CheltenhamITCbyBT-Bold /CheltenhamITCbyBT-BoldItalic /CheltenhamITCbyBT-Book /CheltenhamITCbyBT-BookItalic /Chiller-Regular /Cmb10 /CMB10 /Cmbsy10 /CMBSY10 /CMBSY5 /CMBSY6 /CMBSY7 /CMBSY8 /CMBSY9 /Cmbx10 /CMBX10 /Cmbx12 /CMBX12 /Cmbx5 /CMBX5 /Cmbx6 /CMBX6 /Cmbx7 /CMBX7 /Cmbx8 /CMBX8 /Cmbx9 /CMBX9 /Cmbxsl10 /CMBXSL10 /Cmbxti10 /CMBXTI10 /Cmcsc10 /CMCSC10 /Cmcsc8 /CMCSC8 /Cmcsc9 /CMCSC9 /Cmdunh10 /CMDUNH10 /Cmex10 /CMEX10 /CMEX7 /CMEX8 /CMEX9 /Cmff10 /CMFF10 /Cmfi10 /CMFI10 /Cmfib8 /CMFIB8 /Cminch /CMINCH /Cmitt10 /CMITT10 /Cmmi10 /CMMI10 /Cmmi12 /CMMI12 /Cmmi5 /CMMI5 /Cmmi6 /CMMI6 /Cmmi7 /CMMI7 /Cmmi8 /CMMI8 /Cmmi9 /CMMI9 /Cmmib10 /CMMIB10 /CMMIB5 /CMMIB6 /CMMIB7 /CMMIB8 /CMMIB9 /Cmr10 /CMR10 /Cmr12 /CMR12 /Cmr17 /CMR17 /Cmr5 /CMR5 /Cmr6 /CMR6 /Cmr7 /CMR7 /Cmr8 /CMR8 /Cmr9 /CMR9 /Cmsl10 /CMSL10 /Cmsl12 /CMSL12 /Cmsl8 /CMSL8 /Cmsl9 /CMSL9 /Cmsltt10 /CMSLTT10 /Cmss10 /CMSS10 /Cmss12 /CMSS12 /Cmss17 /CMSS17 /Cmss8 /CMSS8 /Cmss9 /CMSS9 /Cmssbx10 /CMSSBX10 /Cmssdc10 /CMSSDC10 /Cmssi10 /CMSSI10 /Cmssi12 /CMSSI12 /Cmssi17 /CMSSI17 /Cmssi8 /CMSSI8 /Cmssi9 /CMSSI9 /Cmssq8 /CMSSQ8 /Cmssqi8 /CMSSQI8 /Cmsy10 /CMSY10 /Cmsy5 /CMSY5 /Cmsy6 /CMSY6 /Cmsy7 /CMSY7 /Cmsy8 /CMSY8 /Cmsy9 /CMSY9 /Cmtcsc10 /CMTCSC10 /Cmtex10 /CMTEX10 /Cmtex8 /CMTEX8 /Cmtex9 /CMTEX9 /Cmti10 /CMTI10 /Cmti12 /CMTI12 /Cmti7 /CMTI7 /Cmti8 /CMTI8 /Cmti9 /CMTI9 /Cmtt10 /CMTT10 /Cmtt12 /CMTT12 /Cmtt8 /CMTT8 /Cmtt9 /CMTT9 /Cmu10 /CMU10 /Cmvtt10 /CMVTT10 /ColonnaMT /Colossalis-Bold /ComicSansMS /ComicSansMS-Bold /Consolas /Consolas-Bold /Consolas-BoldItalic /Consolas-Italic /Constantia /Constantia-Bold /Constantia-BoldItalic /Constantia-Italic /CooperBlack /CopperplateGothic-Bold /CopperplateGothic-Light /Copperplate-ThirtyThreeBC /Corbel /Corbel-Bold /Corbel-BoldItalic /Corbel-Italic /CordiaNew /CordiaNew-Bold /CordiaNew-BoldItalic /CordiaNew-Italic /CordiaUPC /CordiaUPC-Bold /CordiaUPC-BoldItalic /CordiaUPC-Italic /Courier /Courier-Bold /Courier-BoldOblique /CourierNewPS-BoldItalicMT /CourierNewPS-BoldMT /CourierNewPS-ItalicMT /CourierNewPSMT /Courier-Oblique /CourierStd /CourierStd-Bold /CourierStd-BoldOblique /CourierStd-Oblique /CourierX-Bold /CourierX-BoldOblique /CourierX-Oblique /CourierX-Regular /CreepyRegular /CurlzMT /David-Bold /David-Reg /DavidTransparent /Dcb10 /Dcbx10 /Dcbxsl10 /Dcbxti10 /Dccsc10 /Dcitt10 /Dcr10 /Desdemona /DilleniaUPC /DilleniaUPCBold /DilleniaUPCBoldItalic /DilleniaUPCItalic /Dingbats /DomCasual /Dotum /DotumChe /DoulosSIL /EdwardianScriptITC /Elephant-Italic /Elephant-Regular /EngraversGothicBT-Regular /EngraversMT /EraserDust /ErasITC-Bold /ErasITC-Demi /ErasITC-Light /ErasITC-Medium /ErieBlackPSMT /ErieLightPSMT /EriePSMT /EstrangeloEdessa /Euclid /Euclid-Bold /Euclid-BoldItalic /EuclidExtra /EuclidExtra-Bold /EuclidFraktur /EuclidFraktur-Bold /Euclid-Italic /EuclidMathOne /EuclidMathOne-Bold /EuclidMathTwo /EuclidMathTwo-Bold /EuclidSymbol /EuclidSymbol-Bold /EuclidSymbol-BoldItalic /EuclidSymbol-Italic /EucrosiaUPC /EucrosiaUPCBold /EucrosiaUPCBoldItalic /EucrosiaUPCItalic /EUEX10 /EUEX7 /EUEX8 /EUEX9 /EUFB10 /EUFB5 /EUFB7 /EUFM10 /EUFM5 /EUFM7 /EURB10 /EURB5 /EURB7 /EURM10 /EURM5 /EURM7 /EuroMono-Bold /EuroMono-BoldItalic /EuroMono-Italic /EuroMono-Regular /EuroSans-Bold /EuroSans-BoldItalic /EuroSans-Italic /EuroSans-Regular /EuroSerif-Bold /EuroSerif-BoldItalic /EuroSerif-Italic /EuroSerif-Regular /EUSB10 /EUSB5 /EUSB7 /EUSM10 /EUSM5 /EUSM7 /FelixTitlingMT /Fences /FencesPlain /FigaroMT /FixedMiriamTransparent /FootlightMTLight /Formata-Italic /Formata-Medium /Formata-MediumItalic /Formata-Regular /ForteMT /FranklinGothic-Book /FranklinGothic-BookItalic /FranklinGothic-Demi /FranklinGothic-DemiCond /FranklinGothic-DemiItalic /FranklinGothic-Heavy /FranklinGothic-HeavyItalic /FranklinGothicITCbyBT-Book /FranklinGothicITCbyBT-BookItal /FranklinGothicITCbyBT-Demi /FranklinGothicITCbyBT-DemiItal /FranklinGothic-Medium /FranklinGothic-MediumCond /FranklinGothic-MediumItalic /FrankRuehl /FreesiaUPC /FreesiaUPCBold /FreesiaUPCBoldItalic /FreesiaUPCItalic /FreestyleScript-Regular /FrenchScriptMT /Frutiger-Black /Frutiger-BlackCn /Frutiger-BlackItalic /Frutiger-Bold /Frutiger-BoldCn /Frutiger-BoldItalic /Frutiger-Cn /Frutiger-ExtraBlackCn /Frutiger-Italic /Frutiger-Light /Frutiger-LightCn /Frutiger-LightItalic /Frutiger-Roman /Frutiger-UltraBlack /Futura-Bold /Futura-BoldOblique /Futura-Book /Futura-BookOblique /FuturaBT-Bold /FuturaBT-BoldItalic /FuturaBT-Book /FuturaBT-BookItalic /FuturaBT-Medium /FuturaBT-MediumItalic /Futura-Light /Futura-LightOblique /GalliardITCbyBT-Bold /GalliardITCbyBT-BoldItalic /GalliardITCbyBT-Italic /GalliardITCbyBT-Roman /Garamond /Garamond-Bold /Garamond-BoldCondensed /Garamond-BoldCondensedItalic /Garamond-BoldItalic /Garamond-BookCondensed /Garamond-BookCondensedItalic /Garamond-Italic /Garamond-LightCondensed /Garamond-LightCondensedItalic /Gautami /GeometricSlab703BT-Light /GeometricSlab703BT-LightItalic /Georgia /Georgia-Bold /Georgia-BoldItalic /Georgia-Italic /GeorgiaRef /Giddyup /Giddyup-Thangs /Gigi-Regular /GillSans /GillSans-Bold /GillSans-BoldItalic /GillSans-Condensed /GillSans-CondensedBold /GillSans-Italic /GillSans-Light /GillSans-LightItalic /GillSansMT /GillSansMT-Bold /GillSansMT-BoldItalic /GillSansMT-Condensed /GillSansMT-ExtraCondensedBold /GillSansMT-Italic /GillSans-UltraBold /GillSans-UltraBoldCondensed /GloucesterMT-ExtraCondensed /Gothic-Thirteen /GoudyOldStyleBT-Bold /GoudyOldStyleBT-BoldItalic /GoudyOldStyleBT-Italic /GoudyOldStyleBT-Roman /GoudyOldStyleT-Bold /GoudyOldStyleT-Italic /GoudyOldStyleT-Regular /GoudyStout /GoudyTextMT-LombardicCapitals /GSIDefaultSymbols /Gulim /GulimChe /Gungsuh /GungsuhChe /Haettenschweiler /HarlowSolid /Harrington /Helvetica /Helvetica-Black /Helvetica-BlackOblique /Helvetica-Bold /Helvetica-BoldOblique /Helvetica-Condensed /Helvetica-Condensed-Black /Helvetica-Condensed-BlackObl /Helvetica-Condensed-Bold /Helvetica-Condensed-BoldObl /Helvetica-Condensed-Light /Helvetica-Condensed-LightObl /Helvetica-Condensed-Oblique /Helvetica-Fraction /Helvetica-Narrow /Helvetica-Narrow-Bold /Helvetica-Narrow-BoldOblique /Helvetica-Narrow-Oblique /Helvetica-Oblique /HighTowerText-Italic /HighTowerText-Reg /Humanist521BT-BoldCondensed /Humanist521BT-Light /Humanist521BT-LightItalic /Humanist521BT-RomanCondensed /Imago-ExtraBold /Impact /ImprintMT-Shadow /InformalRoman-Regular /IrisUPC /IrisUPCBold /IrisUPCBoldItalic /IrisUPCItalic /Ironwood /ItcEras-Medium /ItcKabel-Bold /ItcKabel-Book /ItcKabel-Demi /ItcKabel-Medium /ItcKabel-Ultra /JasmineUPC /JasmineUPC-Bold /JasmineUPC-BoldItalic /JasmineUPC-Italic /JoannaMT /JoannaMT-Italic /Jokerman-Regular /JuiceITC-Regular /Kartika /Kaufmann /KaufmannBT-Bold /KaufmannBT-Regular /KidTYPEPaint /KinoMT /KodchiangUPC /KodchiangUPC-Bold /KodchiangUPC-BoldItalic /KodchiangUPC-Italic /KorinnaITCbyBT-Regular /KristenITC-Regular /KrutiDev040Bold /KrutiDev040BoldItalic /KrutiDev040Condensed /KrutiDev040Italic /KrutiDev040Thin /KrutiDev040Wide /KrutiDev060 /KrutiDev060Bold /KrutiDev060BoldItalic /KrutiDev060Condensed /KrutiDev060Italic /KrutiDev060Thin /KrutiDev060Wide /KrutiDev070 /KrutiDev070Condensed /KrutiDev070Italic /KrutiDev070Thin /KrutiDev070Wide /KrutiDev080 /KrutiDev080Condensed /KrutiDev080Italic /KrutiDev080Wide /KrutiDev090 /KrutiDev090Bold /KrutiDev090BoldItalic /KrutiDev090Condensed /KrutiDev090Italic /KrutiDev090Thin /KrutiDev090Wide /KrutiDev100 /KrutiDev100Bold /KrutiDev100BoldItalic /KrutiDev100Condensed /KrutiDev100Italic /KrutiDev100Thin /KrutiDev100Wide /KrutiDev120 /KrutiDev120Condensed /KrutiDev120Thin /KrutiDev120Wide /KrutiDev130…