Android trust all certs

Android Explorations

Using a Custom Certificate Trust Store on Android

• Get link
• Facebook
• Twitter
• Pinterest
• Email
• Other Apps

As mentioned in a previous post, Android 4.0 (ICS) adds both a system UI and SDK API’s that let you add certificates to the system trust store. On all previous version though, the system trust store is read-only and there is no way to add certificates on non-rooted devices. Therefore, if you want to connect to a server that is using a certificate not signed by one of the CA’s included in the system trust store (including a self-signed one), you need to create and use a private trust store for the application. That is not particularly hard to do, but ‘how to connect to a server with a self-signed certificate’ is one of the most asked Android questions on StackOverflow, and the usual answer goes along the lines of ‘simply trust all certificates and you are done’. While this will indeed let you connect, and might be OK for testing, it defeats the whole purpose of using HTTPS: your connection might be encrypted but you have no way of knowing who you are talking to. This opens the door to man-in-the-middle (MITM) attacks, and, needless to say, is bad practice. In this post we will explore how Android’s HTTPS system works pre-ICS and show how to create and use a custom certificate trust store and a dynamically configurable TrustManager .

Some background: JSSE

Java, and by extension Android, implement SSL using a framework called Java Secure Socket Extension (JSSE). A discussion of how SSL and JSSE work is beyond the scope of this post, but you can find a shot introduction to SSL in the context of JSSE here. In brief, SSL provides both privacy and data integrity (i.e., an encrypted communications channel) and authentication of the parties involved. Authentication is implemented using public key cryptography and certificates. Each party presents their certificate, and if the other party trusts it, they negotiate a shared key to encrypt communications using the associated key pairs (public and private). JSSE delegates trust decisions to a TrustManager class, and authentication key selection to a KeyManager class. Each SSLSocket instance created via JSSE has access to those classes via the associated SSLContext (you can find a pretty picture here). Each TrustManager has a set of trusted CA certificates (trust anchors) and makes trust decisions based on those: if the target party’s certificate is issued by one of the trusted CA’s, it is considered trusted itself.

One way to specify the trust anchors is to add the CA certificates to a Java key store file, referred to as a ‘trust store’. The default JSSE TrustManager is initialized using the system trust store which is generally a single key store file, saved to a system location and pre-populated with a set of major commercial and government CA certificates . I f you want to change this, you need to create an appropriately configured TrustManager instance, either via a TrustManagerFactory , or by directly implementing the X509TrustManager interface. To make the general case where one just wants to use their own key store file to initialize the default TrustManager and/or KeyManager , JSSE provides a set of system properties to specify the files to use.

Android and javax.net.ssl.trustStore

If you want to specify your own system trust store file in desktop Java, it is just a matter of setting a value to the javax.net.ssl.trustStore system property when starting the program (usually using the -D JVM command line parameter). This property is also supported on Android, but things work a little differently. If you print the value of the property it will most likely be /system/etc/security/cacerts.bks , the system trust store file (pre-ICS; the property is not set on ICS). This value is used to intialize the default TrustManagerFactory , which in turn creates an X.509 certificate-based TrustManager . You can print the current trust anchors like this:

If you now use System.setProperty() to point the property to your own trust store file, and run the above code again, you will see that it outputs the certificates in the specified file. Check the ‘Set javax.net.ssl.trustStore’ checkbox and use the ‘Dump trusted certs’ button of the sample app to try it.

If we can change the set of trusted certificates using this property, connecting to a server using a custom certificate should be easy, right? It turns out this is not the case. You can try it yourself using the sample app: pressing ‘Default Connect’ will result in a ‘Trust anchor for certificate path not found’ error regardless of the state of the ‘Set javax.net.ssl.trustStore’ checkbox. A little further investigation reveals that the default SSLContext is already initialized with the system trust anchors and setting the javax.net.ssl.trustStore property does not change this. Why? Because Android pre-loads system classes, and by the time your application starts, the default SSLContext is already initialized. Of course, any TrustManager ‘s you create after setting the property will pick it up (see above).

Using your own trust store: HttpClient

Since we can’t use the ‘easy way’ on Android, we need to specify the trust store to use programmatically. This is not hard either, but first we need to create a key store file with the certificates we need. The sample project contains a shell script that does this automatically. All you need is a recent Bouncy Castle jar file and the openssl command (usually available on Linux systems). Drop the jar and a certificate (in PEM format) in the script’s directory and run it like this:

This will calculate the certificate subject’s hash and use it as the alias in a Bouncy Castle key store file (BKS format) created in the application’s raw/ resource directory. The script deletes the key store file if it already exists, but you can easily modify it to append certificates instead. If you are not the command-line type, you can use the Portecle GUI utility to create the key store file.

Apache’s HttpClient provides a convenient SSLSocketFactory class that can be directly initialized with a trust store file (and a key store file if client authentication is needed). All you need to do is to register it in the scheme registry to handle the https scheme:

Once initialized like this, the HttpClient instance will use our local trust store when verifying server certificates. If you need to use client authentication as well, just load and pass the key store containing the client’s private key and certificate to the appropriate SSLSocketFactory constructor. See the sample project for details and use the ‘HttpClient SSLSocketFactory Connect’ button to test. Note that, when initialized like this, our HttpClient will use only the certificates in the specified file, completely ignoring the system trust store. Thus connections to say, https://google.com will fail. We will address this later.

Using your own trust store: HttpsURLConnection

Another popular HTTPS API on Android is HttpsURLConnection. Despite the not particularly flexible or expressive interface, apparently this is the preferred API from Android 2.3 (Gingerbread) and on. Whether to actually use is it is, of course, entirely up to you 🙂 It uses JSSE to connect via HTTPS, so initializing it with our own trust and/or key store involves creating and initializing an SSLContext (HttpClient’s SSLSocketFactory does this behind the scenes):

In this example we are using both a trust store and a key store, but if you don’t need client authentication, you can just pass null as the first parameter of SSLContext.init() .

Creating a dynamic TrustManager

As mentioned above, a TrustManager initialized with a custom trust store will only use the certificates in that store as trust anchors: the system defaults will be completely ignored. Sometimes this is all that is needed, but if you need to connect to both your own server and other public servers that use HTTPS (such as Twitter, for example), you will need to create two separate instances of HttpClient or HttpsURLConnection and switch between the two. Additionally, since the trust store is stored as an application resource, there is no way to add trusted certificates dynamically, you need to repackage the application to update the trust anchors. Certainly we can do better than that. The first problem is easily addressed by creating a custom TrustManager that delegates certificate checks to the system default one and uses the local trust store if verification fails. Here’s how this looks like:

To address the second problem, we simply copy the trust store to internal storage when we first start the application and use that file to initialize our TrustManager ‘s. Since the file is owned by the application, you can easily add and remove trusted certificates. To test modifying the trust store works, copy a certificate file(s) in DER format to the SD card (external storage) root and use the sample application’s ‘Add certs’ and ‘Remove certs’ menus to add or remove it to/from the local trust store file. You can then verify the contents of the file by using the ‘Dump trusted certs’ button (don’t forget to check ‘Set javax.net.ssl.trustStore’). To implement this the app simply uses the JCE KeyStore API to add or remove certificates and save the trust store file:

Using our MyTrustManager with HttpsURLConnection is not much different than using the default one:

HttpClient ‘s SSLSocketFactory doesn’t let us specify a custom TrustManager , so we need to create our own SocketFactory . To make initialization consistent with that of HttpsURLConnection , we have it take an already initialized SSLContext as a parameter and use it to get a factory that lets us create SSL sockets as needed:

Initializing an HttpClient instance is now simply a matter of registering our socket factory for the https scheme:

You can check that this actually works with the ‘HttpClient Connect’ and ‘HttpsURLConnection Connect’ buttons of the sample application. Both clients are using our custom TrustManager outlined above and trust anchors are loaded dynamically: adding and removing certificates via the menu will directly influence whether you can connect to the target server.

We’ve shown how the default TrustManager on pre-ICS Android devices works and how to set up both HttpClient and HttpsURLConnection to use a local (application-scoped) trust and/or key store. In addition, the sample app provides a custom TrustManager implementation that both extends the system one, and supports dynamically adding and removing application-specified trust anchors. While this is not as flexible as the system-wide trust store introduced in ICS, it should be sufficient for most applications that need to manage their own SSL trust store. Do use those examples as a starting point and please do not use any of the trust-all ‘solutions’ that pop up on StackOverflow every other day.

Источник

Android trust all certs

In order to have your browser or system automatically trust all certificates signed by the CAcert Certificate Authority, you must instruct your platform or browser to trust the CAcert root certificate http://www.cacert.org/index.php?id=3.

Note that for all systems, you will need to trust both the root certificate root_X0F.crt, as well as the class 3 certificate class3_x14E228.crt.

Some of this information is already covered in the BrowserClients article, so also look there to see if it has the information you need.

Trusting a new Certificate Authority is a process that varies from one platform to the next, so here are some of the ways to trust the CAcert root certificates. The instructions below will only outline how to trust one certificate, and just repeat the process to trust the second certificate.

WARNING: Always double-check the fingerprint on the downloaded certificates before trusting them. If you don’t, you could be trusting a maliciously modified root certificate.

Mac OS X

There are two ways to trust the CAcert root certificates: one from the command line, and one from the Keychain GUI. Each method requires that you use an account with administrative privileges.

Using the Keychain GUI

Download the desired certificate to your desktop from here.

CAUTION: Verify the certificate fingerprints before proceeding!
Open the certificate file, either using Command-O or by double-clicking on the file.

When Keychain appears, select the X509Anchors keychain.

You will be prompted to authenticate with your password to modify the system-wide X509Anchors keychain.

Using the command line

10.5 Leopard

If you’re using 10.5 Leopard and try the certtool command above, you may see this error message:

The solution is to use the security command with add-trusted-cert instead:

Windows

Covering all of the ways to import this certificate into Windows is beyond the scope of this article, and is already covered by How to import CAcert root certificates into browser clients.

Windows: cygwin environment

There is no /etc/ssl; instead, you have to save it in /usr/ssl/certs, and under its special name.

Location found using «strace wget https://somesite 2>&1 |grep ssl», which obviously fails, but you see the attempt to read a cert at this location.

WindowsMobile

Windows Mobile 5

On WindowsMobile2005 you need to download the DER-Encoded certificate (pocketIE cannot save it, so you need to store it in a zip-file for download). Then you’ll need to rename it to .cer . Only then you will be able to install it with a double-click.

OBSOLETE — not valid for the new roots, SHA256 signed! You can also import new certificates using a CAB file in Windows Mobile. Generic instructions on how to make them can be found on the Windows Mobile blog. A prepared CAB file with both the Class 1 and Class 3 certificates can be found at http://jacob.steenhagen.us/CAcert.cab. This CAB, signed by Jacob Steenhagen’s CAcert certificate, can simply be downloaded to your device and installed. You can verify the certificates are genuine by opening the CAB file and inspecting _setup.xml ensuring that the line before the

(which contains the actual certificate) reads:

for class 1 and:

for class 3. (Note: These should be verified against the Internet Explorer thumbprint at http://www.cacert.org/index.php?id=3). The previous thumbprints (MD-5) are valid for the old roots. Now you will find another thumbprints there, namely SHA1 and SHA256.

OBSOLETE — END

PocketPC2002

There is a tool contained in the zip-file downloadable at http://support.microsoft.com/default.aspx?scid=kb;en-us;322956 (pocketIE on a wm2005-device could not display the html-page here but another browser might do.). This tool will only work with Self-Issued certificates.

Load the CA Cert into Internet Explorer as a trusted root.

Export the certificate from IE as a DER encoded binary X.509 (.CER)

Upload the file to your PocketPC

In the File Manager, locate the uploaded certificate and click on it to open and import it.

After loading the certificate, warm-reset the Pocket PC to make it read the new root certificate.

To verify the certificate has been successfully imported into the Pocket PC device:

• In the Settings menu, tap the «System» tab. Then tap «Certificates».
• Tap on the «Root» tab. You should now see the new CA Cert root certificate that you added.

Notes

(Note that for wap1.x-gateways there is no way to host encrypted wap-pages if your provider’s wap-gateway does not have the certificate because it’s not end-to-end but decrypted on the gateway, not the device.)

Linux

How your particular distribution will need to be modified to trust the CAcert root certificates will vary from one distribution to the next. However, there are some distributions about which we know some information, listed below.

The instructions for Red Hat 5+, Red Hat 4 and Fedora are topic of bug 1344: Wrong install instruction.

Knoppix: CD versions newer than 3.8 have the certificates already.

Red Hat 5+:wget -O - http://www.cacert.org/certs/root_X0F.txt >> /etc/pki/tls/certs/ca-bundle.crt (this will be overridden by updated openssl RPMs so it is likely not the best method)

Red Hat 4: Change the above location of ca-bundle.crt to /usr/share/ssl/certs/ca-bundle.crt

Fedora: Copy the certificate to /etc/pki/ca-trust/source/anchors/ then run update-ca-trust extract

The Bug1344 text explains furthermore:

RHEL 4 is deprecated and only supported under very special terms

for RHEL generation 7 the same instruction as for Fedora should be used

The correct call for Fedora is «update-ca-trust» instead of «update-ca-trust extract»

Otherwise, you can obtain the certificates from the website as usual, from here.

Debian

As of March 2014, Debian no longer distributes CACert root certificates as part of Debian releases. Although a package is available in the unstable (sid) distribution (updated in 2019), it is inconvenient to use because you either have to check signatures manually or configure sid as package source.

Install from CAcert site manually (recommended)

Import CAcert root certificates using the following («$» not be entered — is a prompt):

This should output something like this:

Then, you are done. See man update-ca-certificates and /usr/share/doc/ca-certificates/README.Debian from the ca-certificates package for more information.

Install from unstable (sid via package management

You need to add unstable (sid) as a package source in a way that all packages are not considered to resolve versions, except ca-cacert.

Edit as root (so prepend sudo to editor command) file /etc/apt/preferences to contain

Edit as root file /etc/apt/sources.list to contain (feel free to alter mirror according to preexisting entries)

Update package information and install package by running commands

Add trust to fresh certificates interactively running command

sudo dpkg-reconfigure ca-certificates

The certicates to mark as trusted are listed as

• CAcert/class3_x14E228.crt
• CAcert/root_X0F.crt

Install from unstable (sid) manually

Warning: Use this installation method only if you are prepared for cumbersome checking of signatures. The verified file can then be reused for later installs.

Search and download package from packages.debian.org with an expected name of the pattern ca-cacert_ _all.deb .

Manually check the signature of the downloaded file via Release.gpg as described in the Secure APT (Debian wiki)
Install package running command

sudo dpkg -i

Add trust to fresh certificates interactively running command

sudo dpkg-reconfigure ca-certificates

The CAcert root certificate can be added to KDE’s certificate store so that all KDE applications, including Konqueror, will trust certificates signed by it.

Download the certificate(s) in PEM or DER format.

In the KDE Control Center, under «Security & Privacy > Crypto,» go to the «SSL Signers» page, and click «Import.»

Choose a certificate you downloaded.

You may be asked whether to make the certificate available to KMail as well. This is recommended.

IMPORTANT! Find the certificate in the list (it may help to sort by «Organizational Unit» and then look for «http ://www.cacert.org»), click on it, and verify that the MD5 digest shown at the bottom of the window matches the one shown on the download page.

Symbian

Nokia E61

Download the root and class 3 certificates in der format

Copy the certificates to the E61 (the E61 cannot read the files direct from the web)

Open each certificate in File Manager, and save the certificate. You will have to confirm this as the E61 believes that the certificates may be unsafe.

Typical locations of the cacerts keystore:

• Linux Ubuntu: /usr/lib/jvm/java-$VERSION/jre/lib/security/cacerts
• Linux SuSE: /usr/java/jre$VERSION/lib/security/cacerts

Explanations:

1. Name of the keystore file is «cacerts», its password is «changeit» (a clue for you to change this password).
2. $/PATH/TO/CACERTS/KEYSTORE = placeholder of the path to the file named «cacerts», including the filename itself.
3. $VERSION = Java version, examples:
   • Linux Ubuntu: «7-openjdk-amd64» — thus the whole path including the filename is: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts
   • Linux SuSE: «1.8.0_71» — thus the whole path including the filename is: /usr/java/jre1.8.0_71/lib/security/cacerts

Acrobat Reader

Procedure for Acrobat 8:

Menu Document -> Manage Trusted Identities.

Display: Certificates

Button «Add COntacts. «

«Browse» to the root certificates

Edit trust to your liking. «Signatures and as trusted root» is the essential thing, the others are optional.

Android Phones & Tablets

Before Android version 4.0, with Android version Gingerbread & Froyo, there was a single read-only file ( /system/etc/security/cacerts.bks ) containing the trust store with all the CA (‘system’) certificates trusted by default on Android. Both system apps and all applications developed with the Android SDK use this. Use these instructions on installing CAcert certificates on Android Gingerbread, Froyo, .

Starting from Android 4.0 (Android ICS/’Ice Cream Sandwich’, Android 4.3 ‘Jelly Bean’ & Android 4.4 ‘Kit Kat’), system trusted certificates are on the (read-only) system partition in the folder ‘/system/etc/security/’ as individual files. However, users can now easily add their own ‘user’ certificates which will be stored in ‘/data/misc/keychain/certs-added’.

System-installed certificates can be managed on the Android device in the Settings -> Security -> Certificates -> ‘System’-section, whereas the user trusted certificates are manged in the ‘User’-section there. When using user trusted certificates, Android will force the user of the Android device to implement additional safety measures: the use of a PIN-code, a pattern-lock or a password to unlock the device are mandatory when user-supplied certificates are used.

Installing CAcert certificates as ‘user trusted’-certificates is very easy. Installing new certificates as ‘system trusted’-certificates requires more work (and requires root access), but it has the advantage of avoiding the Android lockscreen requirement.

CAcert user trusted certificates

Download the certificate files (‘root_X0F.crt’ and ‘class3_x14E228.crt’) onto the internal flash storage (the ‘/sdcard’ or any subfolder). Browse to this folder with the file manager and open ‘root_X0F.crt’. Although there might not be an icon for certificates and the files will have a ‘?’-icon, files will be opened with the certificate manager, asking you for a name to describe the to-be-imported certificate. If it is the first user certificate you install, the Android Security Model forces you to use a lock-screen to unlock your device (see «CAcert system trusted certificates» if you really need to avoid this) Repeat with the ‘class3_x14E228.crt’ file. Check if both certificate files are installed correctly, Settings -> Security -> Certificates -> ‘User’-section should now list the certificates you have just installed.

CAcert system trusted certificates (without lockscreen)

The existing method of importing user certificates works fine, but it has the disadvantage that it requires a PIN / password lockscreen whenever user certificates are installed. By installing the CAcert certificates as system certificates, these files are better protected from tampering by malicious apps, and there is no lockscreen requirement (allows ‘Slide to unlock’ or no lock at all). You will need a rooted phone (or at least temporary root access), and a system with openssl software for creating the new certificates.

The next steps will show you how to create Android compatible certificate files from the original CAcert certificate files, how to install/import them on your android device, and how to verify everything is correctly installed.

It is possible, in Android OS version 4.4.2, to save certificates as user trusted ones (Android itself creates their correct names, derived from hashes), and then move them into the system trusted certs repository, using program for Android as Terminal, adb shell, or Ghost Commander. If you decide to follow this process, skip to the Importing paragraph replacing the source folder «/sdcard» used there, with the «/data/misc/keychain/cacerts-added» folder, where Android stores user trusted certificates. Do not copy CAcert roots, move them!

Creating

We will create Android compatible certificate files from the original CAcert certificate files.

Both files are prepared and ready to download, with their hashes to check, here.

Get the CAcert root certificates from the cacert.org website https://www.cacert.org/index.php?id=3 Download the root certificate PEM format (root_X0F.crt) and the Class 3 PKI key in PEM format (class3_x14E228.crt) Get the hash of the root_X0F.crt certificate:

This shows you the hash, in the case of the CAcert PEM file ‘root_X0F.crt’ it is ‘5ed36f99’ (note the use of ‘-subject_hash_old’ instead of ‘-subject_hash’, to get an openssl 0.9 compatible hash) We will use this hash value, append ‘.0’ (dot zero) and use this as the filename for the resulting Android certificate:

Repeat these steps for the Class 3 PEM certificate file ‘class3_x14E228.crt’. If things go well you will end up with the files 5ed36f99.0 and e5662767.0 (if you get the hash values 590d426f and 99d0fa06, you are not using the ‘-subject_hash_old’ parameter to openssl).

The md5sum of the certificate files:

The sha1sum of the certificate files:

The sha256sum of the certificate files:

Importing

We now have Android compatible certificate files, and we will import them into Android ‘System’ certificate store. It is necessary for you to gain the super-user rights to be able to write to / remove from / move between system subfolders. To achieve this, the Android system has to contain the «su» (super-user) program, which provides you with the super-user rights. Some phones’ Android systems do not include this program. In such a case, you have to store all certificates added as the user ones.

Copy the files to the /sdcard folder, either with any file manager or with adb push. Go into adb shell (adb shell from commandline), or open the ‘terminal’-application on your android device. You will get a command prompt similar like shell@android:/ $ Gain superuser/root rights, neccessary to perform privileged actions:

Make the /system folder writable (will return to read-only upon reboot):

Copy the new certificate files to the correct folder on your Android device:

Correct the file permissions to u=rw, g=r, o=r:

Check if the files are ok:

Omit ‘-Z’ if you are using a version of Android without SElinux, it just shows some extra security settings which might be useful if you run into trouble.

Amongst the other default android certificate files, you will see the two new files:

The certificates will be loaded upon the next boot of your device, so reboot your device:

Verifying

To verify certificates are installed correctly, go to Settings -> Security -> Certificates. It should list both «CAcert Inc.» and «Root CA» among the other certificates in the ‘System’ section. Make sure that these CAcert certificates are not also in the ‘User’ (user defined) section. From your android device, visit https://www.cacert.org. If you do not see a warning about missing or untrusted certificates, all went well.

Note that some browsers might use their own certificate store instead of the Android one, you might need to import certificate files into those browsers as well.

If you are unable to disable the Android PIN/Pattern lock screen after installing the system certificates, you might need to «Clear/delete credentials» (in Settings -> Security) even though you have removed all user certificates.

If you run into problems, compare the md5 sum of the certificate files with the md5 values in this article, check the file permissions of the newly installed files. Make sure no user certificates are installed (Settings -> Security -> Clear certificates), and make sure you are using a browser app that uses the android certificate store and does not implement an own certificate store.

In the future, newer versions of openssl might be used on Android, if so, you might need to drop the «_old»-part of the «-subject_hash_old» openssl parameter.

References

Cyanogenmod wiki (old) — articke on adding a CA without requiring a PIN(makes the mistake of not using the certificate hash as filename)

Palm Pre (webOS)

Starting with webOS 1.2, the proceeding for adding the root certificates to the Palm Pre is extremely simple and can be done entirely on the phone.

Visit http://www.cacert.org/index.php?id=3 in the Pre’s browser (http://www.cacert.org and click on Root Certificates)

Under Class 1, click the link for Root Certificate (PEM Format)
A gray progress will appear at the bottom of the screen. Once the certificate is fully downloaded, an arrow will appear on the right side of the bar

Click on the bar containing root_X0F.crt and the aforementioned arrow

The certificate manager will open giving you the ability to view detail and accept or reject the certificate

• Unfortunately, I don’t see anything on that details screen to validate the fingerprint

Click on the «Trust Certificate» button

Note: prior to webOS 1.2 you had to copy the .crt files to the phone’s memory using USB mode, load the certificate manager (Device Info; More Info (button at bottom); Certificate Manager (Preferences menu at top)), and import the certificates (icon in lower left of screen to browse for them).

How can I be sure that it is authentic?

There are many ways to ensure that you have an authentic, non-tampered copy of the root certificates, all of which boil down to having a trusted party verify the certificate fingerprints. In some cases, your system distribution is the trusted party, but you can also verify it for yourself.

If your system is mentioned above, you can follow those instructions to ensure you have a authentic copy of the CAcert root certificates.

You can manually download and verify the certificates from here.

Finding the correct fingerprints

CAcert is working to provide multiple places to verify the certificate fingerprints. The following are already known ways to find authentic copies of the CAcert root certificate fingerprints.

You can decrypt the GPG signed message from here and compare the certificate fingerprints contained in the message with those contained in your downloaded certificates.

Obtain a copy printed on the AssuranceForms; ask for one at the next event.

Find them in the Impressum of Linux Magazin

CAcert is currently working on providing fingerprints through these additional means:

• Business cards with the fingerprints printed on them.
• Listing the fingerprints in additional magazines.

FAQ/ImportRootCert (последним исправлял пользователь AlesKastner 2021-07-13 21:48:03)

Источник

Читайте также:  Jet mobile для андроид