Darren Reed wrote: > David Chieu wrote: > >> Darren Reed wrote: >> ... >> >>> How does it defend against being brute forced? >> >> I don't understand the question. Can you give an example of brute >> forced? > > > I use a dictionary as a source of usernames and passwords > and send correctly formatted data at the NIC (using a combination > of usernames and passwords) until it respods with a message > indicating a successful authentication attempt. > > Darren > I see. A stronger password (w/ symbols e.g. !,@, etc.) reduces vulnerability of a dictionary attack. I image that an AMD engineer could explore the like :-) If stronger security model is needed, AMT supports certificate-based authentication as well. I'm not an expert in this field, so I quote the following excerpt from the Intel website.
http://softwarecommunity.intel.com/articles/eng/1004.htm ... "Authentication and Authorization Network communications with an Intel AMT-enabled platform should be performed in the most secure way available. An IT administrator can configure for certificate-based authentication and optionally select mutual authentication. Intel AMT has an Access Control List used to authorize all access requests. Intel AMT can use the Kerberos option of Microsoft Active Directory to simplify the authorization process. A remote setup and configuration server is required to prepare Intel AMT for secure operations. Configuring the Intel AMT Security Model Both the Intel AMT platform and the Setup and Configuration (S&C) Server start with two pieces of shared information ? a platform ID and a pre-shared key (PSK). The first communication between Intel AMT and the setup and configuration server is an unencrypted ?hello? message from Intel AMT to the server that contains the platform identifier. The S&C Server then performs the setup and configuration process using the PSK and the TLS-PSK protocol for authentication and encryption of the configuration traffic. The S&C Server downloads Certificates to the Intel AMT platform, which stores them in non-volatile memory. The certificates trace to an enterprise certificate authority and are used by Intel AMT to authenticate to Management Console applications. If Intel AMT is configured for mutual authentication, the S&C Server must provide a client certificate for each application that will communicate with Intel AMT. The S&C server also establishes an Access Control List, enables certain Intel AMT features, and configures device settings. At the end of the setup and configuration process, the keys generated and used during the process are deleted. All subsequent communications use the certificates and Transport Layer Security (TLS) for authentication, confidentiality (encryption), and integrity (mutual authentication). Intel AMT performs authorization using the Access Control List, as described in the following section. HTTP Digest authentication is used for the SOAP over HTTP communications. The Redirection feature uses secure sockets layer (SSL) to establish a secure connection between the remote console and the Intel AMT platform. See the User?s Guide to the Sample Setup and Configuration Application for additional information. Access Control Lists and Realms The Intel AMT Access Control List (ACL) manages who has access to which capabilities within the device. An ACL entry has a user ID and a list of realms to which a user has access. This access is required to use the functionality associated with a realm. In the table above, each interface or service is listed with its realm. A user can be granted access to one or more realms. The single default user is named ?admin? and has ?PTAdministrationRealm? privileges, which includes privileges for all Intel AMT realms. The admin user can use the commands in the Security Administration interface to create additional ACL entries for additional users. As part of the setup and configuration process, create the users necessary for an ISV application, subject to the limits on the number of available ACL entries. There are two kinds of ACL entries: Kerberos and non-Kerberos. The main difference between them is that Kerberos entries have an Active Directory SID to identify a user or group of users. Non-Kerberos entries have a username and password for user identification. See Intel AMT Integration with Active Directory for a description of the difference between these entries."
