Computer Scientists at Princeton University have shown some very easy and creative methods to hack
cryptographic key material with physical access to an encrypted
machine. Watch the video embedded below to find out how existing
technology is really vulnerable against Cold Boot Attacks on Encryption Keys.

All you need is a Duster spray can, if that, to cool the DRAM and extract the keys. The paper published
along with the video clearly outlines techniques for finding keys
residing in memory.The really cool part is that this technique doesn't
really hack into the encryption directly. Rather, it depends on
scanning the encryption keys by accessing the contents of the RAM and
then extracting the data either by directly tampering with the RAM or
by simply booting the computer from a USB drive. You can also read the
industry response and more details on these findings in the news.com article.

It is not all bad news ... Intel is planning on releasing a
technology code named “Danbury” which drastically reduces exposure to
the Cold boot attacks. Please note that Danbury technology will be part of the Intel vPro processor technology to be released later this year. Danbury uses dedicated platform hardware to
provide full disk encryption and the actual data encryption keys are
not kept in the DRAM. Although, Intermediate, or ‘wrapping’, keys used
to unlock data encryption keys are stored in DRAM temporarily,
when the user is physically present or while remote IT operation has
control of the platform. These keys are subsequently deleted once no
longer needed, thus reducing the exposure significantly.

I am also very happy to announce that Danbury SDK that can leveraged
by software vendors to enhance encryption software will be made on the manageability developer community
later this year. If you are interested to find out more about this
technology or are interested in developing encryption software using
this technology then feel free to leave a comment on this post.

Check'em out:

• Unattended install of Intel(R) AMT client software/drivers not working properly on Microsoft Windows*
• SoL/IDER does not work with the Lenovo* X61 Tablet
• Are the Weybridge SoL and HECI drivers backward-compatible with Averill?
• Intel SCS returns an error during a partial unprovision
• Validation of SCS service users takes over 30 minutes when installed in a large Active Directory environment
• SCS service crashes due to excessive logs
• Network Load Balancing of SCS Servers
• Weybridge issue causing network disconnects; impacting one Dell configuration

Years before I started working on Intel AMT, designers where creating a list of usages that would be enabled by Intel AMT. The list included, I presume, usages around 3PDS, remote reboot to BIOS, disk redirection, etc. Many of the Intel AMT usages that are promoted on the Intel web site. When I started work on the DTK, a personal challenge had always been to find new ways of using existing features to do different and sometimes unexpected things. Create new usages for Intel AMT that it was never originally designed to do. I now present my top 5 abuses of existing features.

TCP-over-Serial-over-LAN. The Intel AMT serial port I am told, was originally designed as an easy way to remotely take control of the BIOS and recovery OS remotely. Designers needed a way for BIOS to be able to send test display data to a remote console. A virtual serial port was a great solution. It so happens that in the original design, this serial port was always enabled and usable, even when the normal OS was running. This allows a serial agent to talk to a console while bypassing the OS’s network stack. This is interesting on its own and I started work on a serial agent of my own. Things took a weird twist when I started sending binary data and sending files over this serial port, making it very valuable. It’s only a few weeks later that I realized I could also send TCP traffic over this serial link, making it possible to contact TCP services on the Intel AMT computer even if the network stack was disabled. A few days later, I showcased the first demonstration of VNC-over-SOL, and turning this abuse of the serial port into an instant hit. To this day, VNC-over-SOL is still, one of the most impressive demonstrations of Intel AMT.

Reverse Watchdog. When Intel sales people demonstrate Intel AMT to customers, they often get asked if you can shutdown gracefully an Intel AMT computer using Intel AMT. The simple answer was no, Intel AMT will perform a brutal shutdown or reset upon request. To perform operations like a clean shutdown or reset, sleep or hibernation requires the involvement of the OS. You could tell a serial agent like Intel AMT Outpost to perform the shutdown, but that required opening the serial connection and could be a problem if you had to shutdown many computers. I needed a way to pass a small amount of information to a running Intel AMT agent on the PC, do it using SOAP/WSMAN only and if possible get confirmation of reception. We could store the command into 3PDS and have the agent read it periodically, but 3PDS required setup and that little amount of data would have required allocation of a 4K flash page. The solution came when looking at the agent presence feature. When a console creates a new agent, the agent can now register this agent locally. The agent also get the timeout of the agent in seconds (from 1 to 65535), this would be the key. By constantly trying to register a known GUID, Intel AMT Outpost could see if the agent existed or not. If suddenly the registration works, the timeout value would indicate that type of shutdown operation to perform. Better yet, the simple fact that registration occurred changes the state of the agent to “Running”, confirming to the console that the message was indeed received. Today the Intel AMT Terminal has “Agent Commands” in the remote control that allows a user to perform soft operations when the agent is running, even if the OS network stack is not working.

Mouse over serial. A few months back I started work on a smaller version of Intel AMT Outpost called Intel AMT Guardpost. The idea was that if a serial agent was going to be useful, it was going to need to run on a recovery OS, run in the background with no dependencies and with as little footprint as possible (Is it not annoying to have all there background processes running?). The C/C++ version of Intel AMT Outpost was on its way. One feature I always wanted to work on was a remote Windows command prompt; it took over a week to finally pull this off. I could now remotely shell to DOS and perform basic command line operations. I could also enter the command like editor with the “Edit” command at which point, the temptation to support the mouse-over-serial-over-LAN was a must have. Using the binary serial protocol, I added the support to the terminal in a few hours. To this day, it’s still a fun and amazing demonstration of outstanding remote manageability.

IDE-R within the OS. A few days after first enabling IDE-R within Intel AMT Commander, I stumbled upon something I had not noticed before. If an administrator where to start IDE redirection and the OS was to re-scan its plug & play devices, the additional floppy and CDROM drive would show up in Microsoft Windows. This was immediately interesting since transferring files over the serial port was limited to 115kb/sec a very slow speed in today’s world. With IDE-R, you can copy files at around CDROM 4x speed on a local network. All I needed was a way for Intel AMT Outpost to cause the OS to rescan its plug & play devices. A few hours later the “HWRESCAN” command was built and for the first time, an administrator could mount a CDROM remotely and install a patch as high speed without ever using the OS’s network stack. This feature also turned out to be an excellent compliment to VNC-over-SOL.

Fast data path using IDE-R. This is not an idea I never built into the DTK, but I wanted to add it to this list since it would also be an interesting was to use existing features in new ways. The serial-over-LAN feature turned out to be extremely valuable, but it is also slow. Serial ports are very inefficient. One way someone could speed things up is to use IDE-R as a fast by-pass to the OS. An administrator would mount a virtual floppy disk drive containing a single file. This file, would not really exist, it would contain different data each time it was read, making it possible to send data to an OS agent thru Intel AMT at much higher speeds. Also, since the floppy is a read/write device, the agent could write into the virtual file data that it wants to send to the console. It would be quite a bit of work to pull this off, but it certainly seems possible. Someone would just have to know the internal format of an .img file.

That’s my top 5. I realize this is probably a rather advanced blog article, but this is proof that you can have a lot of fun to any technologies.

Ylian (Intel AMT Blog)

The Intel AMT Developer Tool Kit (DTK) is now over a year old and by many accounts, the most popular software package for using Intel AMT that exists today. As I work on improvements and new features I also get to interact with my users, developers, IT departments, testers, etc. I also come across many common ideas for how Intel AMT should be improved. Today I decided to compile my own list of changes I would make to improve Intel AMT. Even if I work at Intel, I have no special access or power over what gets changed, so it’s important that users of Intel AMT make your voices heard if you think you have changes you need made.

1. No TLS, Serial-over-LAN/IDE-R password in the clear. As many of you have discovered, when using Intel AMT in small business or enterprise mode without TLS, the login username and password is sent on the network in the clear when the administrator performs a serial-over-LAN or IDE redirect operation. With so many coffee shops, schools, Internet cafes playing around with Intel AMT features, this could be a big problem. Imagine a classroom with a few vPro computers with AMT setup in SMB mode by an unsuspecting teacher. A student running a packet sniffer, obtaining the password and rebooting AMT computers remotely. This can be avoided by setting up TLS using Intel AMT Director, but this should not be problem in the first place. The HTTP digest used for web pages could easily be adapted and used.

2. Allow TLS in SMB mode. This is a long time feature request that is somewhat related to the first issue. In my work with Intel AMT, I can do everything I need to setup TLS in SMB mode except enabling it. Allowing administrators to setup server-side authenticated TLS would be very easy to add to Intel AMT and would provide improved security with almost no work. In fact, Intel AMT Commander could just prompt the administrator on first connect if he or she want to enable TLS when a non-TLS SMB computer is found. A new root certificate would be generated if none already exist. Strictly speaking, it would not provide “bank level” security, but would go a long way for shops, schools, small business owners that have more to think about than understanding secure manageability.

3. Release the SOL/IDE-R redirection source code. The library called “IMRSDK.dll” is compiled by Intel and not available in source code form. It’s available in Windows and Linux but it has been a problem for people trying to port this feature on to other platforms. It’s also a problem because this library is far from perfect and I would be the first to make changes to it. One of the most critical changes I would make involves knowing if the Serial-over-LAN is connected or not. Imagine how annoying it is to have the SOL connection drop and that application not know about it. Intel AMT Terminal will show “Connected” at the top even when it’s really not. I also want a debugging feature to know exactly what is going on, people report in forums and privately to me that SOL has problems and I have no way to help. My list does not end there; I have more changes I really need made.

4. Make Intel AMT discovery and connection easier. Some Intel AMT software have a discovery feature that attempts to sweep a network to find Intel AMT computers and add them to a management console. To make it easier on the user, Intel AMT Commander also attempts to automatically detect that type of AMT computer it’s talking to. Once you discover a computer, the work is not done. Is the computer setup with TLS? Is it in WSMAN only mode? Is it using TLS mutual-auth? Are you talking to LMS? What version is this? The Intel AMT DTK has an elaborate system to attempt gather this data when a user connects. With new version of Intel AMT, transition to WSMAN and more, it’s getting more and more difficult to correctly detect and connect to all versions of Intel AMT. Developers looking at the DTK’s connection algorithm will be stunned, we need to simplify this process.

5. Get permitted access realms upon connection. So you setup Intel AMT with various user accounts, one for asset monitoring only, one for packet control, another for remote repair. When software like Intel AMT Commander connects to Intel AMT using one of these accounts, it has no idea what types of permissions this account has. As a result, the software is left to assume it has all rights, or fail with an error when things start to go wrong. I don’t think it would be unreasonable to be able to query the allowed realms upon connection for the account currently being used. This would make it easy for Intel AMT Commander to remove from the UI features that are not allowed.

Of course, being an avid fan of Intel AMT, I could write many things I like about it, just look at my many blogs. It’s my hope that this list will spur discussion and action. If you read this, take the time to write a small comment saying which one of these would want fixed first, or tell me if you have your own issue.

Ylian (Intel AMT Blog)

Check out this excellent example of activating vPro and a usage model in a creative way to achieve a relitivly quick Break Even point and Return on Investment .... vPro ROI Analysis- Reducing IT Resource Needs & Service Costs Through Intel Core2

Abstract: Intel's investigation into the savings offered by Intel vPro technology was conducted in a globally distributed environment. The test environment consisted of 39 training rooms in Asia, the United States, and western Europe, with approximately 800 PCs, of which 300 systems were PCs with Intel vPro technology.

• Brian Brougham

With the launch of Intel Centrino with vPro technology - several medium to large customers (with 1000 or more PCs in the infrastructure) have asked for Intel's help with building the financial business case for the new technology. Given this need, Intel asked WiPro to survey senior IT managers from 41 companies about current notebook PC management costs that could potentially be reduced by taking advantage of the new technology. WiPro specifically focused on PC maintenance costs that IT usually budgets for on an annual basis (these are "hard dollar costs", such as help desk calls, help desk visits (especially for hardware and software malfunctions - such as OS blue screens and hard drive failures), auditing, security incidents, software patch deployment costs, major application (such as Office) deployment costs into the infrastructure, etc.).

WiPro's findings are as follows:

• Estimated hard dollar savings of up to ~$140 / PC / year with Intel Centrino with vPro technology vs. the mobile PC in the installed PC base today
• Reduces the need for hardware-related desk-side visits by as much as 58% and for software-related desk-side visits by as much as 57%
• Up to 51% faster patch saturation per incident and reduces number of inventory failures by 62%
• Enterprises can take advantage of most of the Intel Centrino with vPro technology features (including remote diagnosis and repair) in the mobile PC form factor for about 16 hours a day (the other 8 hours, on average, the mobile PC is asleep or off-line, and an IT manager cannot use the Intel vPro technology features)

Although Danbury is the ultimate solution for Disk Encryption and Remote Manageability, the following whitepaper provides a reference design for using Intel® vPro™ Technology and Serial Over LAN (SOL) as a means to perform remote disk drive unlock on client boot up.

Whitepaper: Intel® vProTM Technology Enables Remote Manageability of PCs Employing Encrypted Disk Technology

Matt Royer

Client Manageability Add-on (aka AMT Add-on) version 3.2 for SMS 2003 has been released. For download and more information, please visit: http://softwarecommunity.intel.com/articles/eng/1356.htm

Bug Fixes / Issues Resolved

• An Intel® AMT PC can be configured to use HTTP Digest network communication. Part of the Digest header is a random string which includes the platform UUID. Under certain circumstances depending on the manufacturing flow, it is possible that the Digest UUID and the actual platform UUID as stored in the hardware inventory table do not match. The Intel® Add-on for SMS would reject HTTP Digest communications from a system with mismatching UUIDs. Note that the Digest string uses the UUID purely as a random number and does not use it as an identifier, so there is no reason that they must match. This hotfix amends the functioning to ignore mismatching UUIDs.
• There were cases involving sites containing very large numbers of AMT devices where menu selections would be displayed unacceptably slowly. This has been solved.
• In rare cases, expired advertisements would wake up AMT devices. This has been solved.
• Due to the way in which SMS performs log message collection large numbers of messages are collected, many of which are not critical AMT device messages. Although these messages are valid, they are nonetheless not required in many situations. A workaround has been implemented that allows for the suppression of various levels of non-critical messages.

• The Add-on service account no longer requires local administrator permissions.
• There is no longer a need for a dedicated Add-on service account. The user specifies the Add-on service account during installation.
• New Active Directory groups.
• The Add-on is integrated with version 3.3 of the Intel® AMT Setup and Configuration Service.
• Operations no longer require SMS Administer permissions, except for changing the Add-on Settings.
• A user in the Redirection Managers group can terminate another user's redirection operation.

Matt Royer

• USB Provisioning Tips for Lenovo T61
• When Intel AMT is disabled, there is a HECI driver problem in the HP dc7800
• What does the Intel AMT status application dialog box signify?
• Are there DLLs in the operating system that access vPro?

This week I was reflecting on my IT journey in the last few years and how I successfully adopted new technology. I thought that sharing this type of information may be helpful to those out there that are either about to start or in the middle of their integration of Intel® vPro™ Technology. First things first, here’s an illustration of the different camps within an IT shop (architecture, engineering, operations, finance, security) and then of course there is the leadership (mgmt) that provides air cover for such new adoptions / also a key stakeholder in the success.

For each of these camps there is a different perspective and frames of reference, therefore let me dive into each one.

ARCHITECTURE: for the architect community, the requirement is to understand their 3-5 year roadmap and how a new client technology fits in - does it violate any major design rules, does it embrace the technology strategy?. Specifically the focus is around conceptual and reference architecture with focus on high level themes i.e. Compliance, Provisioning, Remediation, Automation, Virtualization. The vantage point here is looking at the big picture and being able to define it in relationship to the rest of the architecture. This includes the BDAT model as well (business, data, applications and technology), focus is around the business process changes, data architecture changes with respect to where data is being stored, retained, transmitted, etc.. Applications are all about the application architecture requirements and potentially any changes to the high level picture.

ENGINEERING: for engineering it’s all about the connection points, ports, protocol’s, access rights. What I find very compelling in this realm is that the dialogue is around AS IS and TO BE solution architecture with heavy reference to the BDAT model output. How does it specifically fit in w/ the rest of the pieces, what is the traffic pattern, what is the fault tolerance, how does it reuse the pieces of infrastructure already in place, how does each level of the support stack manage their respective pieces without breaking the separation of duties requirements, scaling out ramifications.

OPERATIONS: for operations it all about what is the process change, realization of the value and how does it all work. As you dig in more in this area it is about the 1-x process steps required, there is a heavier view on automation of remedial tasks, there is focus on ownership of problems, reliability of the solution, SLA’s, OLA’s (operational level agreements). The dialogue for operations is about the minutes it takes to operate a given function, the time to execute, back out, re provision, etc.. This is where the business process understanding and changes are the most critical as they are truly tested in live production scenarios

FINANCE: for finance, it’s a few things that I think are important to know, it’s not all about the ROI & TCO, however that is about 90% of it. The other 10% is primarily focused on how this solution would enable company objectives, goals and vision. They are also the keepers of the value (from Headcount, costs, impact, including how to verbalize) when it’s all said and done, as they play the role in delivering a projected vs. actual account of the events, therefore their keen involvement and insight is important. An Enlisted finance manager can make a world of difference.

SECURITY: I initially did not draw in secu